killgore
Legacy Member
Nu effe verdergaan op wat ik bedoelde qua slecht design daarjuist (ik moest naar gent dus had niet teveel tijd om het nog geheel uit te typen).
Wat je (imho) beter doet is een dergelijke structuur:
Je maakt een klasse doolhof, hier wordt logischerwijs de interne structuur (bv. die 2D-array) opgeslagen.
Nu, in deze klasse maak je dan methoden die per veld iets ophalen, een vb is:
Hierbij houdt je bv. doolhof[j] zo bij dat in elk veld een int zit dat overeenkomt met een bepaald getal. Postief -> geblokt, negatief -> item, maar niet geblokt, 0=gewoon pad. Merk op dat hij natuurlijk blocked weergeeft als je buiten je grenzen wilt gaan
! buitengrenzen hoeft trouwens geen aparte functie te zijn, tis nog steeds een soort pseudocode.
Een andere methode kan dan zijn:
Een item kan dan in dat geval bv. een power-up zijn, maar even goed een duer, een muur, een speler, ... . In de meeste game-engines wordt dit dan ook entity genoemd ipv item, maar ik wou de benaming nog duidelijk houden.
Nu, dan ga je ergens een klasse hebben die de input afhandelt, stel dat je ergens een functie hebt die keys opvangt:
Dit is dus eigenlijk je controller. In mijn geval ga ik vanuit controller niets doorgeven aan klasses direct, maar implementeer ik een eigen event-systeem als link daartussen, maar dat leidt u te ver.
Dan heb je in je spelerklasse een functie beweegRechts die er bv. als volgt zal uitzien:
Enige opmerking hierbij: i,j zijn privé-variabelen van de Speler klasse die zijn positie in het doolhof bijhudt.
Ook zou ik niet echt een beweeg-functie maken voor elke richting, maar de richting als argument meegeven
, maar dat zou men vb. code weer wat te lang maken.
Voordelen: beter & duidelijker design. Je gaat richting een MVC-model, je moet al zeer lomp zijn om out-of-bounds errors te krijgen, ...
Wat je (imho) beter doet is een dergelijke structuur:
Je maakt een klasse doolhof, hier wordt logischerwijs de interne structuur (bv. die 2D-array) opgeslagen.
Nu, in deze klasse maak je dan methoden die per veld iets ophalen, een vb is:
Code:
public bool isBlocked(int i, int j)
{
if( buitenGrenzen(i,j) ) return false;
return doolhof[i][j]<=0;
}Hierbij houdt je bv. doolhof[j] zo bij dat in elk veld een int zit dat overeenkomt met een bepaald getal. Postief -> geblokt, negatief -> item, maar niet geblokt, 0=gewoon pad. Merk op dat hij natuurlijk blocked weergeeft als je buiten je grenzen wilt gaan
! buitengrenzen hoeft trouwens geen aparte functie te zijn, tis nog steeds een soort pseudocode.Een andere methode kan dan zijn:
Code:
public Item getItemAt(int i, int j)
{
return intItemMap[doolhof[i][j]];
}Een item kan dan in dat geval bv. een power-up zijn, maar even goed een duer, een muur, een speler, ... . In de meeste game-engines wordt dit dan ook entity genoemd ipv item, maar ik wou de benaming nog duidelijk houden.
Nu, dan ga je ergens een klasse hebben die de input afhandelt, stel dat je ergens een functie hebt die keys opvangt:
Code:
public void getKey(int key)
{
...
if(key == keyRight) speler->beweegRechts();
...
}Dit is dus eigenlijk je controller. In mijn geval ga ik vanuit controller niets doorgeven aan klasses direct, maar implementeer ik een eigen event-systeem als link daartussen, maar dat leidt u te ver
.Dan heb je in je spelerklasse een functie beweegRechts die er bv. als volgt zal uitzien:
Code:
public bool beweegRechts()
{
if(doolhof->isBlocked(i+1,j)) return false;
i++;
Item itemAtNewPos = doolhof->getItem(i,j);
if(itemAtNewPos)
{
/// Roep interactiecode op, bv. itemAtNewPos->action();
}
return true;
}Enige opmerking hierbij: i,j zijn privé-variabelen van de Speler klasse die zijn positie in het doolhof bijhudt.
Ook zou ik niet echt een beweeg-functie maken voor elke richting, maar de richting als argument meegeven
, maar dat zou men vb. code weer wat te lang maken.Voordelen: beter & duidelijker design. Je gaat richting een MVC-model, je moet al zeer lomp zijn om out-of-bounds errors te krijgen, ...
.