Meddelande

Du befinner dig just nu på en äldre version av Pluggakuten, gamla.pluggakuten.se. Nya Pluggakuten lanserades den 6 februari 2017 och du finner forumet på www.pluggakuten.se.

På gamla.pluggakuten.se kan du fortfarande läsa frågorna och svaren som ställts, men du kan inte skapa ett nytt konto eller nya trådar. Är du redan medlem kan du däremot fortfarande logga in och svara i befintliga trådar. Nya frågor och nytt konto skapar du på det nya forumet, välkommen dit!

c# OOP monogame - Problem med kodstruktur

oskillz
Medlem

Offline

Registrerad: 2016-04-02
Inlägg: 34

c# OOP monogame - Problem med kodstruktur

Hejsan, jag gjorde en egen version av spelet PacMan för ett tag sen i en kurs i objekt orienterad programmering och när jag nu kollar tillbaka på den koden så inser jag att jag inte har så bra struktur på vissa delar.

Jag har all logik som kollar om PacMan kolliderar med spöken/mat/powerups i Game1 (dvs main klassen), anledningen till detta är för att jag har instansierat listor av alla dessa objekten i just Game1 så därför fastnade jag lite i det spåret och la in all kollisionslogik där. Men egentligen så vill jag ju kunna ha all logik som rör t.ex spökena i just spök klassen och likadant för PacMan och maten.

Men jag har fastnat lite i gamla spår och vet inte riktigt hur jag ska göra för att kunna lösa det. Ska jag ha till exempel listan med spöken i själva spök klassen? Måste jag inte ändå på något sätt köra spökenas Update metod i Game1s Update metod? Måste man inte instansiera sina objekt i Game1 för att kunna ge dem texturer också eftersom att det är där man initierar dom via content pipelinen? Känner att jag behöver lite hjälp med att komma tillbaka på banan igen och få grepp om dessa grundkoncepten.

 
annlu
Medlem

Offline

Registrerad: 2016-11-02
Inlägg: 58

Re: c# OOP monogame - Problem med kodstruktur

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 22:56)

 


Sidfot

Powered by PunBB
© Copyright 2002–2005 Rickard Andersson

Powered by Mattecentrum
 |  Denna sida använder cookies |  Kontakta oss |  Feedback |