Intresseanmälan. skapa CocoaChess

Kan du inte bara använda detta forum för det?

Varför inte bara implementera en metod som kollar om kungen är hotad (ur kungens "synvinkel" alltså). Den metoden kan köras efter varje drag.

Ciryon

Här är en länk med rätt mycket information om schackprogrammering. Kanske du redan har hittat?

Ciryon

Ursäkta att jag lägger mig i, men...

Att kolla om någon kung är hotad är inte någon tung beräkning alls.

Jag skulle rekomendera följande sätt. Låt varje pjäs kunna svara på metod isValidMove(startPos,endPos). För att Kolla om Svart kung är schackad så skickar man isValidMove() till alla vita pjäser. Argumentet blir då, pjäsens egen position samt kungen position. om isValidMove-meddelandet returnera true för någon pjäs så är spelaren schackad.

Det blir en gnutta tyngre att räkna ut om någon är mattad. Då måste man ta hjälp av en metod som returnerar listan av en pjäs alla giltiga drag.
Så, om svart är schackad måste man skapa en lista av vits samtliga spelares samtliga möjliga drag. För summa av alla dessa drag måste det finnas minst en ställning där kungen inte längre är schackad, om inte så är svart matt.

Inte för att dissa dig men du börjar totalt i fel ände av programmeringen, visst trevligt att ha ett GUI, men är det inte mer värt att kolla upp hur ett ev. UML diagram eller liknande ser ut först för en "backend", sedan kollar man på hur grafiska ska vara implementerat efter det.

Själv tänkte jag fixa så min gamla IRC klient fungerar i OS X Panther senare idag och om jag kommer ihåg något alls av min gamla kod. Den är rätt hyfsat byggd och om jag får igång den så kan ni använda er av nätverksbiten där ifrån som en plugin rätt lätt.

En annan sak ni också bör börja med är att sätta upp något i stil med use cases så ni vet vad som behövs. Jag skulle rekommendera er att leta upp något färdigt sätt att gå tillväga vid utvecklingen t ex XP(extreme programming), RUP(Rational Unified Process) eller någon annan iterativ utvecklings modell. DVS inte vattenfallmetoden.

Sen när man tänker på UML biten så går det rätt lätt att göra så att spelaren är utbyggbar mot en klass som datorn styr, för eventuell AI motor. Har själv gjort tillsammans med två andra ett Checkers(Dam) spel på AI kursen vid Lunds Universitet/LTH.(Omreggar mig den här månaden på kursen even, fast dam spelet är iaf godkänt sen innan) Då gjorde vi det i Java och det var rätt kul, roligare med AI biten i ett brädspel än det ni tänker på, fast tar sin tid att få evaluering etc att bli bra, samt trädsökningar(som nog var lite fel i vår version men nästan bra ändån).

Ivar, jag skall kommentera Ekelunds inlägg också. Han har i någon bemärkelse alldelses rätt. Men, eftersom jag undervisar i OOP, UML och RUP (fast jag inte är någon guru) så kanske jag kan få nyansera lite.

Alla traditionella utvecklingsmodeller har en grundförutsättning som kanske inte är riktigt för just ditt/ert projekt. Grundförutsättningen är att slutresultatet skall bli så bra som möjligt, och att man under resans gång har mycket bra koll på risker/hur lång tid som man har kvar hur mycket det kostar etc. DITT projekt kanske har alla dess, tråkiga affärsmässiga målen. Du kanske bara vill ha kul. Kanske lära dig lite mer om Cocoa. Så, med tanke på det kanske man inte behöver upprätta alla av dom otal dokument som du måste upprätta i ett RUP-projekt.

Ni måste hitta en balans mellan kul och nyttigt. För att uttrycka mig i projektledartermer så är faktsik ert störa riskmoment i projektet att medlemmarna tycker att projektet blir tråkigt, och därför slutar bidra.

Så, lyssna på Ekelunds råd, men så fort något blir så tråkigt att det hotar projeketet -- skit i det och gladhacka istället!

Själv tycker jag XP verkar lösa lite av det problemet själv, eftersom man itererar så pass mycket. Menar det är ju inte så att man får flera veckor som bara går åt åt en sak utan snarare så att man gör lite av varje hela tiden. Brukar inte folk gilla att göra lite av varje, iaf så länge inte majoriteten av små sakerna är tradiga

Japp, XP är mycker mera "hackervänligt".

Vi håller nog med varandra helt och hållet. Jag bara ville betona att gör man ett hobbyprojekt skall det vara kul. Allt annat är egentligen underordnat.

Jag förstår att du inte vill dokumentera, inte många som vill det. Dock är det rätt bra att skriva något i stil med javadoc fast för obj.c i dina filer. Det underlättar för de andra i gruppen när man ska använda andras klasser. Behöver inte vara avancerade dokument i .m filerna men iaf informativa.

Även ett dokument som berättar lite allmänt om projektet är bra, så andra vet hur det är tänkt att byggas annars riskerar man massa problem i stil att man implementerar samma sak på flera ställen(olika personer alltså som gör samma sak), kanske att man missar något viktigt eller så. Och i det fallet står ditt UML diagram samt dina use cases som bra svar på många frågor vilket jag tror kan minska en hel del riktig dokument text.

Tips eftersom ni kommer bli många programmerare så är CVS bra att använda.

UML kan användas till mycket. Men, man kan använda det till småsaker också. Det går att beskriva mycket i UMl. Du kan dokumentera användarfall mha av UML. Vanligast är nog att man beskriver objekt med UML. Det går att beskriva olika saker med avsende objekt. Du kan beskriva relationer mellan objekt. Men, det går att att beskrive lite mera detaljerat vilka attribut och metoder som finns för varje objekt.

Nyckeln till att få frågställningen ni hade angående läge "schack" och "matt" är som sagt metoden "gilltigt drag". Det är den som allt kretsar omkring. En spelares möjliga drag är summan av alla hans pjäsers gilltiga drag, t ex.

Tänk på att "gilltigt drag" för en pjäs kanske är lite knivigare än att bara lista ut hur pjäserna förflyttar sig. Man får ju t ex inte flytta en pjäs så att man själv hamnar i schakk-läge. Detta löser man ju genom att ha implementerat metoden "är schack?". Självklart är det så komplicerat att även det har ett undantag. Draget är ju gilltigt trots att man kommer i eget läge schack efter sitt drag, om ens eget drag slår motståndarens kung...

Sedan måste man tänka på att man kan konvertera bönder genom att nå motståndarens kant. Ytterligare är väl specialfallet att man inte får upprepa samma drag mer än åtta ggr. Jag kommer inte ihåg hur reglerna är. Om det blir remi då, eller hur det nu är. Det kanske man kan strunta i till att börja med.

Bortsätt från att UML tillåter att man har USE CASES och Klass diagram, så tillåter den även Collaboration- och Sekvensdiagram. Finns annat med, t ex status på vissa objekt attributer mm. dvs vad som händer med attributet när någon metod anropas mm.

Just det undantaget borde gå strunta i för om man kan slå motståndarens kung överhuvudtaget lämnade motståndaren sin kung i schack draget innan vilket inte är tillåtet. Antingen så måste han flytta en pjäs så att han häver schack eller så är han matt. Det ger än ännu svårare sak vilket är att låta kungen vackert falla när schackmatt uppstått. Svårigheten syftar inte på det grafiska utan på att gå igenom alla möjliga drag för att se om schack kan upphävas.

Hoppas att jag förstått reglerna rätt.

Att kolla schack, tillåtet eller icke tillåtet drag, utknuffad pjäs med mera borde inte ta särskilt mycket beräkningskraft. Det handlar om att stega fram(några beräkningar) och kolla om ett villkor är falskt eller sant. Även hundratals sådan falsifieringar och stegningar borde väl en modern Mac greja i ett nafs även om det går åt lite mer än den förenkling jag givit?

Sist jag programerade något på egen hand var på min Comodore 64 och då gjorde jag trummor som fick sina respektive slag separerade i tidsled med hjälp av att låta datorn blind-räkna en stund. Jag mins inte hur mycket den hann räkna innan nästa slag skulle komma men det kanske var några hundra eller något tusental. Om det var tiden det tog för min 64:a att räkna till några hundra eller tusen skulle jag bli mycket besviken om inte min Mac kunde göra samma sak fast tusenfaldigt mycket snabbare.

Du har rätt och jag hade fel. Tänkte inte på det. Det finns en allmängilltig slutsats att dra från vårt resonemang om hur det här fungerar. Projekt måste alltid börja med en fas där man analyser vad det är man skall göra. Vi håller nu på att förfina vår tolkning av reglerna i schack. Det visar sig ganska snart att mina förfiningar av reglerna har fel. Det är med hjälp av våra skrivna tolkningar av reglerna som kan hjälpas åt att skjuta felresonmang i sänk. När projektet har nått enighet om hur reglerna fungerar och dokumenterat det på ett schematiskt sätt kan man mycket enklare implementer dom genom att koda det man har beskrivit.

En schackregel som ett vettigt program måste ha med är lång och kort rokad. Om jag kommer ihåg rätt så är det inte tillåtet att utföra rokade om man har blivit schackad innan.

I ett utvecklingprojekt är det lämpligt att ta små tuggor åt gången. Den första utvecklingsversionen av programmet gör ni kanske internt utan vissa av dom avanerade reglerna. Det fina i kråksången att den övergripande algoritmen som hanterar gilltigt drag/vems tur det är etc är oförändrad. Ni behöver sedan bara förfina metoden validMove när ni lägger till dom sista specialfallsreglerna i programmet.

Jag tror det råder lite begreppsförvirring. Ord som lätt, svår, optimal och tung kan måste defineras med avsende på vad?

Det kan vara svårt för en nybörjare att programmera en viss algoritm, men det kan vara lätt för datorn (läs snabbt) att utföra beräkningen. Det kan också vara lätt för en programmerare att implementera en viss algoritm men den kan ta fruktansvärt lång tid att beräkna för en dator.

Att konstruera en algoritm (för en programmerare) som kan bedömma om en shcackställning är gilltig eller ej tycker jag är en hyffsat svår uppgift för en nybörjarprogrammerare. Däremot så behövs det nog bara en tvättmaskinsprocessor för att köra den fungerande algoritmen och ge blixtsnabba svar. Att skriva ett program som kan *spela* schack är i stort sett samma problem. Man behöver bara låta datorn välja ett slumpmässigt drag av dom möjliga dragen. Men, att skriva ett program som spelar schack *bra* är ett svårara på alla sätt och vis. Då blir uppgiften klart svårare för programmeraren, och den blir sjukt mycket tyngre för datorn.

Varför inte använda schackmotorn på gnuchess (som Chess.app är byggd på) och försöka nätverksifiera och bygga ett snyggt GUI kring detta?

All teknik verkar ju finnas, uppgiften är att sätta ihop allt på rätt sätt.

Begreppsförvirringar är ofta vanligt när nybörjare börjar treva sig fram. Här har du en till exempel. Jag menade tidigare med svårare att kolla schack matt att det är mer komplicerat för oss att bena ut. Datorn har inga svårigheter med det om bara koden ges vilken givetvis måste vara förnuftigt(i vidaste mening) ihopsnickrad.

Ska väl gå rätt enkelt att lösa om man gör pjäserna till rätt smarta klasser som vet hur dom får gå. Kungens klass kollar givetvis om han hamnar i schack innan han godkänner ett drag så då kan man enkelt kolla om kungen kan gå någon stans utan att hamna i schack.

Att veta vilken pjäs som ställt kungen i shack är ju en lätt sak att lösa, då vet man vilka rutor man kan täcka på också, sen är det bara att fråga alla pjäser på bordet om dom kan gå dit, får man bara nej så är det schack matt.

Dock så måste man ju kolla så man inte flyttar någon pjäs så att kungen hamnar i schack, men allt sådant ska man nog kunna lösa rätt enkelt om pjäserna i sig själva är rätt "smarta"...

Så skulle jag har gjort det om jag haft tid iaf, sen om det är det bästa sättet, det är en annan sak. Men mest modulärt blir det iaf, och det är viktigt om det ska vara ett utspritt projekt.

Häpp!

För tillfället håller jag kurs i Java där vi använder oss av UML och RUP för att driva ett gemensamt Othelloprojekt. Mina studenter är ganska gröna på området, men dom har mycket kul. Vi har precis börjat köra studenternas "othellocpuhjärnor" mot varandra.

Jag följer gärna schackprojektet och kan kasta in lite åsikter/tips när jag har tid. Dessvärre vill jag inte "lova" något, eller åta mig något arbete. Det är rätt mycket på jobbet nu...

Det är en kurs på en tvårig yrkesutbildning till systemutvecklare. Min studenter är nybörjare, och jag har haft dom på en treveckors introduktion i OOP-programmering med Java innan den här kursen.

Vi har bara jobbat 4 dagar med Othelloprojektet och vi RUP-itererar så gott vi kan. Användningsfallen är mycket grova för tillfället, studenterna behöver förfina dom nästa vecka.