Hej igen.
[..]
GameEvent event = LetODDWalkAround();
switch (event->type()) { case EVENT_PICKUP: .. case EVENT_USE: .. case EVENT_TALKTO: .. };
[..]
Precis så hade jag tänkt ja! Vad är det du inte gillar? Jag kan mycket väl ha missat något... men tanken är precis som du säger, att all kod för en scen är samlad, så att man kan "programmera" manuset direkt i C++.
Det är ju inte så "objektorienterat", fast det gör kanske inget.
Som ovan blir det ungefär:
case EVENT_USE: if (event.useWhichObject() == "pinnen" && event.useOnObject() == "ögat") print("aj!") .. massa if-satser ..
Alternativet är väl att skriva kod i varje "fysiskt" objekt i spelet.
Pinnen::useOn(GameObject obj) { if (obj == "ögat") print("aj"); }
Det här var ju väldigt simpelt, men ofta har ju "användningar" bieffekter som påverkar på manusnivå, men det kanske räcker med att ha ett gäng tillståndsvariabler för varje scen. Eftersom varje objekt i spelet i princip är unikt så blir nog metod 1 bäst, som du säger. Med en klass för varje objekt blir det ju också en himla mass onödig kod.
Jag använde strängar i exemplet för att slippa hitta på en ny klass, men det kanske inte är så dumt att ha en dynamisk namnrymd för objekt i spelet?
I vilket fall ska animeringsobjektet tas bort ur listan, och förmodligen ersättas med en annan animation för samma Sprite.
Mm. Detta ska ju i högst möjliga mån gå automatiskt.
Hur menar du? Allt som inte användaren behöver göra är ju automatiskt... du kanske menar att Animation-objektet är tillräckligt smart för att själv länka sig till en ny animation när den gamla är klar? Helt OK för mig!
Jag menar att animationsbyte inte ska komma upp till en högre nivå än vad som krävs för att bestämma nästa animation, men det är ju självklart märker jag nu när jag skriver ut det.
[events]
"Dina" GameEvents är väl något som initeras baserat på manuset, och som poppas på mittennivån?
Japp.
Ulf