Hej!

Jag har själv inte programmerat något i just C# men jag kan kanske ge lite råd generellt vad gäller din OOP design.

När du säger att du har all kollisionslogik i Game1 (fast du vill ha exempelvis all logik som tillhör spökena i deras egen klass) tror jag att du tänker rätt men ändå fel.

Jag kan förklara med ett exempel. När pacman äter en powerup och sedan kolliderar med ett spöke, så ska ju spöket tillbaka till sitt bo (om jag inte minns fel? det kanske dör direkt). Spöket kan alltså ha en metod goBackHome() (eller ett attribute som levande/död, om nu spöken kan vara levande… men du förstår kanske vad jag menar).

Spöket själv behöver däremot inte hålla koll på ifall det just har krockat med pacman, utan det kan du med fördel låta din Engine/Game/Controller kontrollera. Det är alltså hjärnan bakom spelet som, efter att ha analyserat ett "drag" ser att pacman krockat med ett svagt spöke och då säger åt det spöket att: goastPinky.goBackHome().

Om du låter figurerna själva kontrollera ifall de har krockat med något hamnar du i en situation där din logik sprids hej vilt. Om pacman hela tiden ska veta själv, inifrån sin egen klass, ifall han just åt en pac-dot, power-dot eller krockade med ett spöke, uppstår problemet om pacman också ska tala om för dessa objekt att han krockade med dem? Eller har de i sin tur logik som talar om det för dem? Ska en dot verkligen själv lägga till mer poäng till spelaren när den blivit uppäten? Nja, det blir väldigt krångligt efter ett tag. Tänk alltså vad skönt att ha en typ av Controller som fixar allt. Det verkar dessutom vara just en sådan struktur du har i din Game1? I din main kan du helt enkelt instiansera new Game() som i sin tur instianserar Pacman, Spöken, Spelplan, Labyrint, Mat, Poäng, GUI osv. Och ha all spellogik där.

Ju mer du implementerar desto mer kaotisk och stor blir förstås en sådan klass. Då är det såklart läge att dela upp ansvaret mer. Ett sätt som jag gillar är att skapa Events. För varje sak som sker i labyrinten skapas ett Event: "Pacman äter en dot", "Pacman krockar med ett spöke", "Ett spöke äts upp av Pacman", "Pacman gick in i en vägg" etc. Den som upptäcker detta kan vara din Controller/Game1 eller kanske Labyrinten/Spelplanen själv (ifall du gör den intelligent så att den har koll på, förutom sina dots och väggar, också var de rörliga figurerna befinner sig). Vem som än genererar ett Event så är det detta Event som tar hand om konsekvenserna (ta bort ett pacmanliv, öka poängen, ta bort dots, powerupförsvaga alla spöken etc).

Du kan också se till att verkligen dela upp allt i separata klasser. Nu bara slänger jag ur mig namn utan att tänka så mycket men exempelvis: Points, Klasser för din GUI, MazeGenerator, KeyboardListener, AIGoastMove, .... Det finns inte bara ett självklart eller "rätt" sätt att strukturera objekorienterad kod på. Det beror från fall till fall och på programmerarens preferenser och erfarenhet. Att lära sig typiska Design Patterns hjälper dock till att förbättra och generalisera OOstrukturen. Vill du sträva efter ett ideal (näst intill omöjligt) så ska du i princip kunna återanvända koden till ett helt nytt spel, bara behöva implementera nya klasser (från de redan givna abstrakta klasserna och interfaces) med det nya spelets specifika regler, men ha kvar grundkoden i din kontroller och andra centrala kodklasser.

Svårt att säga något mer specifikt eftersom jag inte vet mer om hur du lagt upp din kod, men du kanske fick någon idé iaf.

Senast redigerat av annlu (2017-01-24 15:56)