[Java/ALG] Statisch vs Niet-Statisch

[Nick The Heazk]

Ik ben momenteel aan een klein game aan het werken dat we in opdracht van de universiteit moeten maken.

De opdracht bestaat eruit een doolhof te maken waarin de speler vrij kan bewegen. In de doolhof bevinden zich een aantal objecten zoals deuren, sleutels, powerups etc. Deze objecten zijn allen - indirecte - afstammelingen van de superklasse Vakje. Verder heb ik een klasse Speler en Doolhof.

De klasse Doolhof heeft een Speler (has-a) en een 2 dimensionale array van Vakjes (has-a). Om een speler op een deur te laten staan, heeft de speler de desbetreffende sleutel nodig. Hier wringt het schoentje.

Ik gebruik in de Deur-objecten (3 soorten deuren: rood, blauw, groen) een statische aanroep naar de hasKey() methode van de Doolhof. Dit omdat de Doolhof notie heeft van de 'inventory' van de speler (De inventory wordt voorgesteld door een aantal Opslag vakjes die willekeurig op het bord staan. Er is dus meer sprake van een doolhofgebonden inventory dan een spelergebonden inventory.)

Dit wordt echter afgeraden door de assistenten. Deze willen dat ik de hele doolhof als parameter doorgeef aan de verschillende Deur-instanties.

Persoonlijk vind ik dit een heel vreemde benadering. Je geeft een subklasse van een has-a relatie de volledige controle over het object waarmee je aan het spelen bent. Het zou dus perfect mogelijk zijn om plotseling die ene Deur alle bewegingen af te laten handelen.

Mijn vraag is dan ook bij deze:
"is dit nu eerder een normale oplossing en wordt het wel vaker gedaan dat een volledig autonoom object wordt meegegeven als parameter bij een has-a relatie of is dit eerder ?"

Kleine klassen schets:

Doolhof
- heeft Speler
- heeft Vakje[][]

Vakje
> subklasse Hindernis
--> subklasse Muur
--> subklasse Opslag
--> subklasse Deur
----> subklasse GroeneDeur <--- hier de volledige doolhof meegeven als argument
[...]

_{Eventuele opmerkingen over klassenstructuur en dergelijke zijn niet echt aan de orde, daar hier pas tijdens het tweede semester uitgebreid word op ingegaan.}

[ Voor 3% gewijzigd door Nick The Heazk op 05-12-2005 19:39 ]

[Gerco]

Ik zou waarschijnlijk die Sleutel (dat is toch ook een object op je veld?) een property deur geven en als je die sleutel oppakt kan hij deur.unlock() doen. De Deur hoeft vervolgens alleen nog maar naar zijn eigen locked property te kijken om te weten of hij open moet gaan.

Wat ook kan (in het geval van meerdere deuren met dezelfde kleur makkelijker) is de speler een Inventory geven (heb je al) en wanneer de Deur getriggerd wordt (speler probeert erop te staan), bijvoorbeeld met "bool Vakje.spelerGaatOpJeStaan(Speler speler)", kan die kijken of de speler de goede sleutel heeft (return speler.hasObject(GreenKey)).

De hele doolhof meegeven aan de class Deur lijkt me wat vreemd, maar de inventory aan de doolhof geven is ook vreemd. Ik denk dat de assistent bedoelt dat de Speler/Doolhof geen method hasKey() moet hebben, maar de Deur moet laten beslissen of hij open gaat door hem de benodigde informatie te verschaffen (in mijn voorbeeld, je Speler of Inventory object).

DISCLAIMER: Ik heb hier dan wel voor gestudeerd, maar ben het inmiddels al lang weer vergeten. Het is best mogelijk dat het bovenstaande onzin is

[ Voor 12% gewijzigd door Gerco op 05-12-2005 19:58 ]

[Woy]

Ik zou zowiezo je power-ups niet laten inheriten van Vakje. Dat je deur inherit van vakje is wel logisch aangezien dat een fysiek object is. Een sleutel bijvoorbeeld die pak je op. Dus je kan het denk beter zo modeleren dat een vakje 1 of meer Power-Up objecten kan bevatten ( Ook een soort inventory dus ).

Als je dan bij een vakje zoals Gerco hierboven voorsteld een spelerGaatOpJeStaan( Speler s ) maakt dan kan het vakje actie ondernemen door bijvoorbeeld zijn inventory over te dragen aan de speler. Of in het geval van een deur controleren of de speler de benodigde sleutel in zijn inventory heeft en als dat niet het geval is de toegang weigeren.

Over het algemeen kun je static meestal het beste zo veel mogenlijk vermijden. Het kan soms handig zijn voor Utility classes enzo waar je geen instances van hoeft te maken. Maar door gebruik van static maak je het voor jezelf meestal heel moeilijk om het later uit te breiden. Stel dat je straks bijvoorbeeld wilt dat je 2 doolhoven tegelijk kunt doen dan heb je al weer problemen met static.

[ Voor 26% gewijzigd door Woy op 05-12-2005 20:08 ]

[Nick The Heazk]

Gerco schreef op maandag 05 december 2005 @ 19:55:
Ik zou waarschijnlijk die Sleutel (dat is toch ook een object op je veld?) een property deur geven en als je die sleutel oppakt kan hij deur.unlock() doen. De Deur hoeft vervolgens alleen nog maar naar zijn eigen locked property te kijken om te weten of hij open moet gaan.

Een goed voorstel, ware het niet dat sleutels mogelijkerwijze kunnen verdwijnen doordat je inventory overvol is. Dan moet je bij het overschrijven (gebeurt in Doolhof) de trukkendoos weer bovenhalen. Verder weet ik ook niet waar welke deur staat, dus dan moet ik mijn hele Vakjes array doorlopen om de deuren te zoeken (tijdscomplexiteit n²)

Wat ook kan (in het geval van meerdere deuren met dezelfde kleur makkelijker) is de speler een Inventory geven (heb je al) en wanneer de Deur getriggerd wordt (speler probeert erop te staan), bijvoorbeeld met "bool Vakje.spelerGaatOpJeStaan(Speler speler)", kan die kijken of de speler de goede sleutel heeft (return speler.hasObject(GreenKey)).

De Doolhof bepaald in mijn geval of de speler naar het vakje kan moven. In het geval van een deur hangt deze mogelijkheid af van het in bezit zijn van een sleutel. Het probleem is hier een beetje de informatie-verdeling. Het al dan niet hebben van een sleutel is niet aan een Deur om te weten. Het is iets dat de inventory weet. De inventory is eigenlijk een rij van Opslag-vakjes die dynamisch worden uitgebreid naarmate bij het inlezen meer Opslagvakjes worden gemaakt. In mijn huidige implementatie is deze inventory statisch, zodat de Deur aan de doolhof kan vragen of de juiste sleutel in de inventory zit.
De inventory aan de speler meegeven, is een veel logischere zet. Het probleem blijft echter hetzelfde. Dan moet ik een speler meegeven aan mijn Deur om geen statische aanroep te gebruiken. Het voordeel is echter dat de speler minder 'rechten' heeft.
Ik heb nu overwogen om de Inventory aan de deur mee te geven. De deur weet dan welke items er in de inventory zitten, en of de juiste sleutel aanwzig is. Ik ben hier nog steeds niet tevreden mee, want feitelijk geef je een inventory mee aan een deur, wat vrij absurd klinkt.
_{Het voordeel is wel dat deze Inventory niet meer dan een rij van Opslag-vakjes is. Je kunt dus niet de hele doolhof of speler aanpassen}

De hele doolhof meegeven aan de class Deur lijkt me wat vreemd, maar de inventory aan de doolhof geven is ook vreemd.

De inventory word bij het inlezen van het bestand dynamisch uitgebreid. Het is geen apparte klasse, maar een speciaal soort Vakje.

[ Voor 4% gewijzigd door Nick The Heazk op 05-12-2005 20:23 ]

[Gerco]

Nick The Heazk schreef op maandag 05 december 2005 @ 20:21:
Verder weet ik ook niet waar welke deur staat, dus dan moet ik mijn hele Vakjes array doorlopen om de deuren te zoeken (tijdscomplexiteit n²)

De deur koppel je natuurlijk op creatie-tijd aan de sleutel, waardoor je helemaal niet meer hoeft te zoeken als de sleutel opgepakt wordt. Helaas is dit dus door je "verdwijnende inventory items" niet meer mogelijk.

De Doolhof bepaald in mijn geval of de speler naar het vakje kan moven. In het geval van een deur hangt deze mogelijkheid af van het in bezit zijn van een sleutel.

Hier beschrijf je precies wat het probleem is. De doolhof moet in jouw ontwerp bepalen of de speler door een deur mag lopen, maar de doolhof moet dan dus weten wat voort barrieres er zijn en wat er nodig is om daar doorheen te mogen lopen. Dat is iets wat die barriere (de Deur) veel beter zelf kan bepalen.

Het probleem is hier een beetje de informatie-verdeling. Het al dan niet hebben van een sleutel is niet aan een Deur om te weten. Het is iets dat de inventory weet.

Klopt, maar die Deur is de enige die weet welke sleutel de speler in zijn bezit moet hebben om erdoor te mogen. Lijkt me logisch dat die Deur dan aan de Speler vraagt of hij de betreffende sleutel heeft. Zo hoeft alleen de deur maar de condities te weten waaronder hij open moet gaan, de andere objecten voorzien hem alleen van de informatie die hij nodig heeft om zijn beslissing te maken.

Ik heb nu overwogen om de Inventory aan de deur mee te geven. De deur weet dan welke items er in de inventory zitten, en of de juiste sleutel aanwzig is. Ik ben hier nog steeds niet tevreden mee, want feitelijk geef je een inventory mee aan een deur, wat vrij absurd klinkt.

Dat klinkt mij helemaal niet raar in de oren, wat je eigenlijk vraagt aan de deur is: "Mag ik erdoor, gegeven dat ik de volgende items in mijn bezit heb? <inventory>". De Deur is de enige die die beslissing zou mogen nemen imo.

Vergelijk het met een real-life deur, je steekt de sleutel erin en vraagt dus eigenlijk aan die deur of je erdoor mag, gegeven dat jij die sleutel in je bezit hebt. Je huis weet hier niets van en zo hoort het ook.

[ Voor 7% gewijzigd door Gerco op 05-12-2005 20:32 ]

[Woy]

Het lijkt me zowiezo dat je invetory bij je speler hoort. Stel dat je 2 spelers in je doolhof opneemt in een later stadium dan zal elke speler toch zijn eigen inventory moeten hebben ( hier ook meteen weer het probleem met static ). je zou een vakje bijvoorbeeld een methode
boolean TryEnter( Player p ) en
void Enter( Player p )

In je doolhof kun je dan iets dergelijks doen

Java:

public boolean MoveUp( Player p )
{
    Position position= //Select the right position
    if( position.TryEnter( p ) )
    {
        position.Enter( p );
        //update position of player here
        return true;
    }
    return false;
}

In TryEnter kun je dan eventueel controle doen of er een sleutel aanwezig is en in Enter kan je de acties ondernemen die er plaatsvinden als een speler een vakje betreedt. Dus bijvoorbeeld dingen in zijn inventory zetten of als je later een val plaatst level van de speler afhalen.

Gerco schreef op maandag 05 december 2005 @ 20:29:
Vergelijk het met een real-life deur, je steekt de sleutel erin en vraagt dus eigenlijk aan die deur of je erdoor mag, gegeven dat jij die sleutel in je bezit hebt. Je huis weet hier niets van en zo hoort het ook.

Als je het met een real-life deur wilt vergelijken zal de speler telkens de goede sleutel moeten pakken en die in de deur doen om hem te unlocken. Dat zou dus een aparte actie zijn. Je kan het bijvoorbeeld ook met een Pasjes systeem vergelijken. De deur is de hele tijd aan het wachten totdat er een goed pasje voorbij komt. In dit geval is het dus eigenlijk wel de deur die aan de speler vraagt of hij de juiste key(card) heeft.

[ Voor 38% gewijzigd door Woy op 05-12-2005 20:46 ]

[Confusion]

Nick The Heazk schreef op maandag 05 december 2005 @ 20:21:
Ik heb nu overwogen om de Inventory aan de deur mee te geven.

Je moet uberhaupt niets aan de deur geven. Ieder 'vakje' hoort een boolean methode 'playerCanMoveHere()' te hebben, die als enige argument de player krijgt (de inventory is een eigenschap van de player, tenzij je een heel afwijkend doolhofspel aan het maken bent, waarbij je dan nog steeds zou kunnen zeggen dat een speler bepaalde doolhofvakjes met items tot zijn beschikking heeft en de items dus nog steeds indirect van de speler zijn). Afhankelijk van het soort vakje bepaald die methode of de speler (met zijn inventory) naar het vakje mag moven. Het is niet netjes om aan het ene vakje het hele doolhof, aan het volgende vakje de speler en aan een derde vakje alleen de inventory mee te geven om te kijken of een speler er heen mag bewegen. Dan is vakje geen abstracte superklasse meer, omdat de subklassen zo'n fundamentele methode als 'playerCanMoveHere()' aan het overloaden zijn.

[ Voor 6% gewijzigd door Confusion op 05-12-2005 20:39 ]

[Nick The Heazk]

Hier beschrijf je precies wat het probleem is. De doolhof moet in jouw ontwerp bepalen of de speler door een deur mag lopen, maar de doolhof moet dan dus weten wat voort barrieres er zijn en wat er nodig is om daar doorheen te mogen lopen. Dat is iets wat die barriere (de Deur) veel beter zelf kan bepalen.

De doolhof weet de positie van de speler (door die op te vragen) en de positie van alle objecten in de wereld. Indien de player op het rechterpijltje duwt gaat de Doolhof aan het vakje rechts van de speler vragen of die toegankelijk is (Vakje heeft een abstracte methode allowMove, dewelke in GroeneDeur ... zijn implementatie krijgt. Namelijk als de inventory de juiste sleutel bevat). De inhoud van dat vakje bepaald dan of het vakje toegankelijk is. In feite bepaald het vakje zelf of het betreden kan worden. Mijn formulering was wat onduidelijk.

EDIT: Ik ga me even bezighouden met de implementatie van Confusions voorstel. Dit lijkt mij inderdaad veel beter dan mijn huidig ontwerp

[ Voor 8% gewijzigd door Nick The Heazk op 05-12-2005 20:42 ]

[Woy]

Nick The Heazk schreef op maandag 05 december 2005 @ 20:38:
[...]


De doolhof weet de positie van de speler (door die op te vragen) en de positie van alle objecten in de wereld. Indien de player op het rechterpijltje duwt gaat de Doolhof aan het vakje rechts van de speler vragen of die toegankelijk is (Vakje heeft een abstracte methode allowMove, dewelke in GroeneDeur ... zijn implementatie krijgt. Namelijk als de inventory de juiste sleutel bevat). De inhoud van dat vakje bepaald dan of het vakje toegankelijk is. In feite bepaald het vakje zelf of het betreden kan worden. Mijn formulering was wat onduidelijk.

EDIT: Ik ga me even bezighouden met de implementatie van Confusions voorstel. Dit lijkt mij inderdaad veel beter dan mijn huidig ontwerp

Je grote probleem ligt denk waar je je verantwoordelijkheden legt. Je hebt een methode allowMove die aangeroepen wordt door de speler, de speler is hier echter helemaal niet verantwoordelijk voor om dit te controleren. Dat zijn het doolhof en het vakje samen.
Je speler zou in princiepe alleen een Move functie aan moeten roepen ( Die eventueel terug geeft of het gelukt is of niet ), deze Move functie uit het doolhof die controleert eerst of hij wel kan bewegen en verplaatst daarna de speler een plaats. Je invetory hoort bij je speler en niet bij je Doolhof. Je speler heeft het tenslotte opgepakt. Dus ik denk dat je nog een keer goed na moet kijken welke objecten welke verantwoordelijkheden hebben.

[Nick The Heazk]

Je grote probleem ligt denk waar je je verantwoordelijkheden legt. Je hebt een methode allowMove die aangeroepen wordt door de speler, de speler is hier echter helemaal niet verantwoordelijk voor om dit te controleren. Dat zijn het doolhof en het vakje samen.

Lees jij niet goed of schrijf ik slecht? Dat staat toch exact in het gequote stukje

"gaat de Doolhof aan het vakje rechts van de speler vragen of die toegankelijk is (Vakje heeft een abstracte methode allowMove [...])"

De Doolhof vraagt aan het vakje of het betreedbaar is. Het vakje zegt Ja/Nee. Zo Ja dan beweegt de speler naar het vakje (via de Move methode van de speler - zoals ook jij voorstelt).


Edit: Zozo, nu vraagt de Deur aan de speler of deze de juiste sleutel in zijn/haar inventory heeft. Dit is inderdaad beter dan dat de Deur dit aan de Doolhof zelf gaat vragen.

Iedereen bedankt voor de feedback

_{Bolds weggehaald}

[ Voor 16% gewijzigd door Nick The Heazk op 05-12-2005 21:17 ]

[Woy]

Ok even niet goed gelezen. Was nog een beetje in de war met wat je eerst zei. Maar dan nog is het de deur die bij de speler moet controleren of hij de deur open kan maken. En niet bij het doolhof. Als je al een allowMove methode hebt in je vakje zou je het ongeveer zo op kunnen lossen zoals ik in het stukje code hierboven aangaf. Door het doolhof eerst te laten controleren of de speler het vakje mag betreden en daarna de speler het vakje te laten betreden kun je later ook flexibel omgaan met andere soorten vakjes die speciale dingen met je speler doen ( Bijvoorbeeld tijdelijk super-powers of valkuilen )

[vinnux]

De deur moet alleen controleren of de aan hem getoonde sleutel past.
Dus de speler vraag aan de deur wat voor sleutel heb jij nodig?
De speler kijkt in zijn inventory of ie die sleutel heeft.
Vervolgens steekt de speler de sleutel in de deur en controleert de deur of de sleutel past.
Een deur kan niks .. ik heb nog nooit van een deur gehoord die in je inventory kan kijken
Nu wil de speler naar het vakje en zeg dat tegen het vakje. Het vakje controleert of het dat mag of niet.
C.q vraag aan alle objecten die erop staan of het mag.

In principe heb je niks meer daan een aantal aan elkaar geschakelde vakjes en objecten die erop staan en of bewegen. Andere objecten kunnen voorkomen dat opjecten op hun vakje komen te staan. etc ...

[ Voor 34% gewijzigd door vinnux op 05-12-2005 21:19 ]

[Nick The Heazk]

Ja ik bedoel dat de Deur aan de speler vraagt offie de juiste sleutel heeft he. De speler staat voor de deur en als de speler door de deur wil zal die de juiste sleutel moeten bezitten. Pratende deuren hoezo nooit van gehoord ?

@rwb: Dit gebeurt ook

[vinnux]

Nick The Heazk schreef op maandag 05 december 2005 @ 21:19:
Ja ik bedoel dat de Deur aan de speler vraagt offie de juiste sleutel heeft he. De speler staat voor de deur en als de speler door de deur wil zal die de juiste sleutel moeten bezitten. Pratende deuren hoezo nooit van gehoord ?

Sorry wist niet dat het een Harry Potter doolhof was .. maar laat jij die deur zomaar je zakken doorzoeken naar een sleutel? Dacht het niet .. zelf Harry niet !
Misscien is het wel een boze door en pakt ie alles en heb je niks meer

[ Voor 8% gewijzigd door vinnux op 05-12-2005 21:23 ]

[Nick The Heazk]

De deur activeert de zoekSleutel methode van de Speler om het zo te zeggen. De Deur zelf doorzoekt niets. De Deur vraagt aan de speler of hij/zij de sleutel heeft. Dit weet de Speler door in zijn/haar inventory te zoeken.
Dus als de speler door de Deur wil lopen, herinnert de Speler zich dat hij/zij eerst die verdomde sleutel moet insteken.

[ Voor 22% gewijzigd door Nick The Heazk op 05-12-2005 21:25 ]

[vinnux]

Nick The Heazk schreef op maandag 05 december 2005 @ 21:24:
De deur activeert de zoekSleutel methode van de Speler om het zo te zeggen. De Deur zelf doorzoekt niets. De Deur vraagt aan de speler of hij/zij de sleutel heeft. Dit weet de Speler door in zijn/haar inventory te zoeken.
Dus als de speler door de Deur wil lopen, herinnert de Speler zich dat hij/zij eerst die verdomde sleutel moet insteken.

Ja ik ken zulke deuren in de echt wereld niet. Waarom zou de deur actie moeten ondernemen? Jij wil er graag door, het zal die deur een rotzorg zijn of je er wel of niet door wil.
Jij zegt dus dat je bij elke beurt alle deuren laat controleren of er een speler voor staat? In mijn beleving wil de speler dingen en moet hij ze ook uitvoeren. Ik wil ook niet dat de parkeermeter in mijn portemenee kiijkt of ik voldoene geld heb. Dat doe ik zelf wel.

[Nick The Heazk]

Jij zegt dus dat je bij elke beurt alle deuren laat controleren of er een speler voor staat? In mijn beleving wil de speler dingen en moet hij ze ook uitvoeren.

Die controle wordt enkel uitgevoerd als de speler zich door een deur wil bewegen. De speler geeft aan naar waar hij/zij beweegt. De Doolhof vraagt of het mogelijk is. De Deur zegt dan dat er een sleutel nodig is. De speler kijkt of hij die heeft. Dan pas kan de Speler door de deur.

[vinnux]

Waarom zou een speler aan het doolhof vragen of ie naat een vakje mag .. dat kan dat vakje heel goed zelf bepalen. Het doolhof heeft daar geen enkele functie in. Volgens mij is Doolhof zelfs geen entiteit .. ff de regels doorlezen .. moment.

Nick The Heazk schreef op maandag 05 december 2005 @ 21:32:
[...]Die controle wordt enkel uitgevoerd als de speler zich door een deur wil bewegen. De speler geeft aan naar waar hij/zij beweegt. De Doolhof vraagt of het mogelijk is. De Deur zegt dan dat er een sleutel nodig is. De speler kijkt of hij die heeft. Dan pas kan de Speler door de deur.

Das al weer anders dan je net zei, nu kijt de deur niet in je inventory, al een hele verbetering mijn inziens. Ik vind trouwens dat doolhof geen entiteit is. Hij voegt niks toe. Een doolhof is niks anders dan een aantal vakjes die aan elkaar hangen. Doolhof heeft geen enkele eigenschap die niet volgt uit de verzameling vakjes. Zo ja dan mag jij zeggen welke.
Breedte ? -> volgt uit de vakjes.

Ik zal niet zeggen dat het niet handig is een klass doolhoof .. maar redundant is het wel.

[ Voor 69% gewijzigd door vinnux op 05-12-2005 21:49 ]

[Nick The Heazk]

De klasse Doolhof is eigenlijk het volledige spelletje. Het bevat een Speler en een spelbord (een spelbord is die 2 dimensionale array van Vakjes). De meerwaarde die Doolhof als klasse biedt, is het inlezen van het bestand waaruit de informatie komt.

Bij het aanmaken van een Doolhof geef je namelijk een bestandsnaam als argument. Uit dit bestand wordt dan deze array van Vakjes 'geparst'.

Dit is inderdaad meer een designkeuze, want dit kan ook in de main methode. Ik vind het echter mooier op deze manier omdat ik zo meerdere levels kan laden door steeds een nieuw Doolhof-object te creëren.

_{Eigenlijk is Level een betere benaming voor de Doolhof klasse. Ik kan dan nog een extra klasse Doolhof maken die een aantal Levels bevat. Dat geheel terzijde.}

[vinnux]

Waarom zou je een 2d array gebruiken? Waarom niet elke vakje een reference laten hebben naar zijn boven onder en zij buren? Wordt het allemaal een heel stuk eenvoudig door. De speler kan toch niet verder kijken dan de vakjes rondom zijn vakjes? Vervolgens heb je een klein lijstje met ingang en uitgang vakjes en hup spelen maar.

Geef gelijk toe dat array makkelijk lijkt, maar er is eigenlijk geen reden toe?

[Confusion]

vgouw schreef op maandag 05 december 2005 @ 22:11:
Waarom zou je een 2d array gebruiken? Waarom niet elke vakje een reference laten hebben naar zijn boven onder en zij buren? Wordt het allemaal een heel stuk eenvoudig door. De speler kan toch niet verder kijken dan de vakjes rondom zijn vakjes? Vervolgens heb je een klein lijstje met ingang en uitgang vakjes en hup spelen maar.

Geef gelijk toe dat array makkelijk lijkt, maar er is eigenlijk geen reden toe?

Als je een bepaald voorwerp aan een bepaald coordinaat wilt koppelen en niet random wilt laten verschijnen op aanliggende vakjes, dan zal je toch elk vakje een coordinaat moeten toewijzen, om voorwerpen een absolute plaats te kunnen geven. Die 2D array, of soortgelijke structuur, heb je dus sowieso. 'vakje' een methode geven die een array van de (max) 8 omliggende vakjes retourneert is natuurlijk een goed idee.

[Cuball]

offtopic:
in het boek Gof design patterns staan als ik me niet vergis enkele voorbeelden van hoe je een doolhof kan opbouwen met gebruik van enkele gekende design patterns, misschien eens te bekijken?

[Hydra]

Confusion schreef op dinsdag 06 december 2005 @ 08:29:
Als je een bepaald voorwerp aan een bepaald coordinaat wilt koppelen en niet random wilt laten verschijnen op aanliggende vakjes, dan zal je toch elk vakje een coordinaat moeten toewijzen, om voorwerpen een absolute plaats te kunnen geven. Die 2D array, of soortgelijke structuur, heb je dus sowieso. 'vakje' een methode geven die een array van de (max) 8 omliggende vakjes retourneert is natuurlijk een goed idee.

Het is niet nodig het in een array te stoppen. Een doolhof kan ook prima een netwerk van vakjes zijn. Kun je 'em ook makkelijker uitbreiden naar een 3D doolhof.

Wat ik wel wat vreemd vind dat alles een afstammeling is van de klasse 'Vakje'. Een vakje heeft een deur naar een ander vakje, maar een vakje is geen deur lijkt me. Net zoals dat een vakje een aantal powerups oid kan bevatten. IMHO zouden de deuren paden moeten zijn tussen vakjes.

[Confusion]

Hydra schreef op dinsdag 06 december 2005 @ 11:07:
Het is niet nodig het in een array te stoppen. Een doolhof kan ook prima een netwerk van vakjes zijn. Kun je 'em ook makkelijker uitbreiden naar een 3D doolhof.

Zoals ik daarboven ook al een keer schreef: 'of soortgelijke structuur'. Feit blijft dat je iets zal moeten retourneren dat de naburige elementen bevat. Dat aan een vakje vragen, die zichzelf aan een methode doorgeeft die dat bepaald, is volgens mij een aardige oplossing. Wat wil je daar aan veranderen door het doolhof als 'netwerk van vakjes' te zien? Wat voor implementatie-idee heb je daarbij?

Wat ik wel wat vreemd vind dat alles een afstammeling is van de klasse 'Vakje'. Een vakje heeft een deur naar een ander vakje, maar een vakje is geen deur lijkt me. Net zoals dat een vakje een aantal powerups oid kan bevatten. IMHO zouden de deuren paden moeten zijn tussen vakjes.

Tjah, je kan het zo complex maken als je wilt, maar op een gegeven moment ben je het onnodig abstract aan het maken. Als ieder vakje maximaal 1 item bevat en de hoeveelheid items beperkt is, dan kan je best over 'deurvakjes' en 'powerupvakjes', etc. spreken. Maargoed, ik zeg ook maar wat als eerste in me opkomt .

[ Voor 6% gewijzigd door Confusion op 06-12-2005 11:40 ]

[Woy]

Confusion schreef op dinsdag 06 december 2005 @ 11:38:
Tjah, je kan het zo complex maken als je wilt, maar op een gegeven moment ben je het onnodig abstract aan het maken. Als ieder vakje maximaal 1 item bevat en de hoeveelheid items beperkt is, dan kan je best over 'deurvakjes' en 'powerupvakjes', etc. spreken. Maargoed, ik zeg ook maar wat als eerste in me opkomt .

Tja toch vindt ik dat een beetje vreemd. Je kan een powerup namenlijk oppakken en dan is die niet meer aanwezig op het vakje. Dus dan zou je in principe het vakje moeten vervangen. Je kan beter zorgen dat het Vakje een soort Inventory heeft. Als hij maar 1 powerup kan hebben dan kan je dat gewoon doen door een member variabele te maken die een power up kan bevatten. Een power-up is nou eenmaal geen vakje.

Als het een 'heal' vakje o.i.d. is kan ik het me wel weer voorstellen. De eigenschap is dan namenlijk van het vakje en het is niet iets wat je kan 'oppakken'. Die eigenschap zou je dan bijvoorbeeld in de Enter van het vakje kunnen implementeren.

Maar voor keys enzo zou ik toch een soort inventory aan een vakje toe kennen. Kan je later ook makkelijker maken dat er meer power-ups op een vakje kunnen staan.

[Hydra]

Confusion schreef op dinsdag 06 december 2005 @ 11:38:
Zoals ik daarboven ook al een keer schreef: 'of soortgelijke structuur'. Feit blijft dat je iets zal moeten retourneren dat de naburige elementen bevat. Dat aan een vakje vragen, die zichzelf aan een methode doorgeeft die dat bepaald, is volgens mij een aardige oplossing. Wat wil je daar aan veranderen door het doolhof als 'netwerk van vakjes' te zien? Wat voor implementatie-idee heb je daarbij?

Zoals ik al zei, een netwerk, en geen 2D array. Sowieso hoeft niet elke X/Y coordinaat een vakje te bevatten, en misschien wil je ook boven/onder richtingen hebben. Een netwerk is dan IMHO logischer dan een 2D-array. Een andere mogelijkheid met een netwerk is een deur die naar zichzelf wijst, of naar een kamer een eind verderop wijst.

Tjah, je kan het zo complex maken als je wilt, maar op een gegeven moment ben je het onnodig abstract aan het maken. Als ieder vakje maximaal 1 item bevat en de hoeveelheid items beperkt is, dan kan je best over 'deurvakjes' en 'powerupvakjes', etc. spreken. Maargoed, ik zeg ook maar wat als eerste in me opkomt .

Dit heeft niks met 'abstract' maken te maken. Dit is een kwestie van een juist ontwerp maken, en dat is waar het IMHO in het begin al fout mee ging. Ik neem aan dat het doel van zijn opleiding niet het maken van doolhofspelletjes is. Een deur laten inheriten van een vakje is op zich al vreemd, maar een powerup laten inheriten van een vakje is IMHO gewoon fout.

rwb schreef op dinsdag 06 december 2005 @ 12:39:
Als het een 'heal' vakje o.i.d. is kan ik het me wel weer voorstellen. De eigenschap is dan namenlijk van het vakje en het is niet iets wat je kan 'oppakken'. Die eigenschap zou je dan bijvoorbeeld in de Enter van het vakje kunnen implementeren.

Dan nog is het een eigenschap van een specifiek vakje, en wat nou als je een 'heal' wilt hebben in een vakje met een deur? Maak je dan een DeurEnHealVakje?

[ Voor 16% gewijzigd door Hydra op 06-12-2005 13:06 ]

[.oisyn]

Laten we overigens wel wezen, als je met zo'n ontwerp bij een gamebedrijf aankomt wordt je al snel weer naar het gat van de deur verwezen

[Confusion]

Hydra schreef op dinsdag 06 december 2005 @ 13:04:
Zoals ik al zei, een netwerk, en geen 2D array. Sowieso hoeft niet elke X/Y coordinaat een vakje te bevatten, en misschien wil je ook boven/onder richtingen hebben. Een netwerk is dan IMHO logischer dan een 2D-array. Een andere mogelijkheid met een netwerk is een deur die naar zichzelf wijst, of naar een kamer een eind verderop wijst.

Tjah, een collectie vakjes waarin ieder vakje een collectie 'omliggende vakjes' heeft is natuurlijk een optie, maar dat is al snel onoverzichtelijk: het verband tussen twee willekeurige vakjes uit de verzameling is niet eenvoudig te overzien. Initialisatie is een crime. Om overzicht te houden zal je de vakjes met iets als coordinaatparen aan willen duiden, bijvoorbeeld om op de jouw gewenste plekken voorwerpen te leggen. Op dat moment blijft de structuur gelijk aan die van een 2D array, maar daarmee bedoelde ik niet dat je een structuur met X² geheugenplaatsen moet gebruiken. Maar dat kan toch prima een designbeslissing zijn, als je weet dat je spel vrij traditioneel is opgezet en zal blijven? Ook in een array van vakjesobjecten kan je de mogelijkheid tot teleporten wel ondersteunen; daar heb je geen netwerk voor nodig.

Dit heeft niks met 'abstract' maken te maken. Dit is een kwestie van een juist ontwerp maken, en dat is waar het IMHO in het begin al fout mee ging. Ik neem aan dat het doel van zijn opleiding niet het maken van doolhofspelletjes is. Een deur laten inheriten van een vakje is op zich al vreemd, maar een powerup laten inheriten van een vakje is IMHO gewoon fout.

Dat ben ik met je eens. Zoals rwb aangeeft zat ik aan een powerupvakje te denken, en riep ik al dat ik er vanuit ging dat een vakje maar 1 eigenschap had, maar inderdaad is dat met sleutels en andere verdwijnende items die niet inherent aan het vakje zijn geen goed idee. Aan de andere kant is het gissen naar het doel van de opleiding.

[Nick The Heazk]

Zoals rwb aangeeft zat ik aan een powerupvakje te denken, en riep ik al dat ik er vanuit ging dat een vakje maar 1 eigenschap had, maar inderdaad is dat met sleutels en andere verdwijnende items die niet inherent aan het vakje zijn geen goed idee. Aan de andere kant is het gissen naar het doel van de opleiding.

Na al deze replies te hebben doorgelezen, moet ik inderdaad erkennen dat de keuze om van de voorwerpen een subklasse van Vakje te maken absoluut geen goed idee was. Ik merk dat ik mij iets teveel op het visueel voorstellen van het spelbord heb geconcentreerd, en dat dat ten koste ging van een goed design. Dat weten we dan ook weer voor de volgende keer.

Het doel van dit practicum ligt me mijn inziens in het gebruiken van polymorfisme en overerving. Dat is de stof die we de week voor het practicum 'behandeld' hebben. Laat ik toch even vermelden dat ons enkel de techniek werd 'uitgelegd' (In de trant van kijk je kan deze methodes dan in de Child-klasse gebruiken, allemaal erg basis.) en geen aandacht werd geschonken aan hoe je een degelijke structuur hierin aanbrengt (Veel mensen uit mijn richting hebben de neiging om alles rechtstreekse descendant van Vakje te maken). Ik vind het zelf ook jammer dat er weinig aandacht aan structuur wordt besteed. Al moet ik nuanceren dat het doel van deze cursus enkel is een kleine inleiding in het programmeren te geven, en dat dergelijke designkwesties in latere cursussen aan bod komen.

Desalniettemin heb ik uit deze replies weer veel geleerd !

[kenneth]

Kick man. Het gaat inderdaad om de lessen die je eruit leert, zodat het de volgende keer beter kan.
Volgens mij heeft bijna iedere ervaren programmeur nog steeds na de release iets van "hmmm, de volgende keer doe ik dat anders".

[Confusion]

kenneth schreef op woensdag 07 december 2005 @ 17:27:
Kick man. Het gaat inderdaad om de lessen die je eruit leert, zodat het de volgende keer beter kan.
Volgens mij heeft bijna iedere ervaren programmeur nog steeds na de release iets van "hmmm, de volgende keer doe ik dat anders".

Zoals Brooks al zei: "Plan to throw one away. You will do that, anyway. Your only choice is whether to try to sell the throwaway to customers."