[AS3]Opzet spel

[compufreak88]

Ik ben bezig met het maken van een spel. In dat spel bestuur je een poppetje. Dat poppetje kan lopen en springen.

Nu heb ik iets dat goed werkt. Dat wil zeggen, hij kan lopen, springen, en stopt weer op de grond. Het probleem waar ik mee zit is de structuur.

Ik heb een class Character, wat een MovieClip is die in de library staat. Dit is het poppetje, met een aantal animaties voor het lopen. Verder heb ik momenteel een class WalkingCharacter, die ervoor zorgt dat het poppetje kan lopen, en zorgt er ook voor dat het poppetje geanimeerd wordt.

Dan heb ik nog een class CharacterPhysics die er voor zorgt dat het poppetje kan springen, en zorgt er voor dat hij op de grond stopt (gewoon even als test). Daarbij was ik bezig met een class die de eigenlijke collision detection moest doen.

WalkingCharacter en CharacterPhysics hebben beiden referenties naar elkaar om ze te laten werken.

Verder heb ik nog een class KeyboardHandler die luister naar de toetsen, en dan de juiste methodes op de verschillende classes (WalkingCharacter, CharacterPhysics) aanroept, en dus ook naar beiden referenties heeft.

Niet echt een ideale situatie, omdat alles naar elkaar verwijst, en als je iets wilt veranderen, moet je van alles veranderen.

Ik zit al een aantal dagen te denken aan hoe ik dit netjes kan laten werken, maar kom er niet echt uit. Wat ik altijd geleerd heb is dat elke onderdeel alleen verantwoordelijk is voor zijn eigen werk, en dat je zo min mogelijk koppeling tussen classes wil.

Zouden jullie mij een handje kunnen helpen met de opzet hiervan?

[Razr]

compufreak88 schreef op vrijdag 14 november 2008 @ 22:04:
Verder heb ik nog een class KeyboardHandler die luister naar de toetsen, en dan de juiste methodes op de verschillende classes (WalkingCharacter, CharacterPhysics) aanroept, en dus ook naar beiden referenties heeft.

Dit kun je al vrij simpel aanpassen. Je zou het kunnen omdraaien en dus niet de KeyboardHandler de methoden laten aanroepen, maar de klasse die geïnteresseerd is in keyboard events zich laten aanmelden bij de KeyboardHandler.

Wanneer er dan een toets ingedrukt wordt brengt de KeyboardHandler alle bij hem geregistreerde objecten op de hoogte van de ingedrukte toets. Dan kan elk geregistreerd object vervolgens voor zichzelf bepalen wat hij gaat doen.

Dit wordt ook wel het Observer Pattern genoemd, hier kun je er meer over vinden

[compufreak88]

Ik ben bekend met het observer pattern. Waar ik zelf nog aan zat te denken is het Command pattern. Dan zorgt het command object dat de juiste methodes worden aangeroepen.

Maar voor de rest. Ik kan alles wel in èèn class zetten, maar dan krijg je een hele grote class die allemaal verschillende dingen doet. Maar het probleem wat ik heb als ik het over verschillende classes verdeel hoe ik het doe met de communicatie ertussen. Heeft iemand hier ideeën over?

[GTOfire]

Wat ik op school voor ons spel heb gedaan was gebruik maken van overerving voor de functionaliteit. De class TangibleObject regelde dat een object ergens in de wereld tastbaar was, DynamicObject erft hier weer van over en laat het object bewegen aan de hand van Force objecten die erop worden toegepast, een specifieke class bijv. Ship die daar weer van overerft kan schieten e.d.

Die opzet (functionaliteit splitsen in verschillende klasses) heb je in feite al, en da's ook zeker goed. Ik weet niet precies hoe je de relaties onderling hebt liggen. Ik vond zelf een super/sub-klasse relatie logisch omdat een object dat kan bewegen ook altijd de attributen heeft van een object dat een bepaalde plaats in de wereld heeft. Het klinkt een beetje alsof je een soort hoofdklasse Character hebt die referenties naar instanties van deze andere klasses heeft, dus een Character heeft een WalkingCharacter en een CharacterPhysics. Da's maar een gokje van mijn kant, maar ook dat kan op zich prima werken, ook al vind ik het op het eerste gezicht minder logisch.


Wat betreft keyboard afhandeling is mijn voorstel:
Maak een class CommandQueue waarin je Command objecten opslaat (iedere afzonderlijke handeling hadden we in een aparte Command subklasse gestopt). Wanneer de speler een toets drukt zet je die keypress om in het juiste Command (bijv. move of jump), en die zet je in de CommandQueue. Tijdens je game loop loop je iedere loop je command queue door en check je of er commands zijn. Zoja dan voer je ze uit. Een Command heeft zelf een execute methode die de handeling uitvoert. Onze MoveCommand maakte bijvoorbeeld een Force object en paste dat toe op ons speler's Ship. Bij de eerstvolgende loop begon het schip daardoor dus te bewegen.
(sidenote, ja dat is idd het Command pattern, anders heb ik het verkeerd uitgelegd )

Als het concept Game Loop onbekend in de oren klinkt en je zoiets hebt van huh? hoezo een loop die een command queue telkens pollt... dan zou ik eens wat bronnen zoeken over basis game development. De game loop is een belangrijk beginsel wat een hoop problemen die je anders tegen zou komen voor je op kan lossen.