Allt är inte klart än :) Just nu så är enda möjligheten att slänga på en ny animation på spriten, men egentligen ska animationerna ju uppdateras automatiskt. Däremot behöver vi något sätt att signalera till spriten att animationen är slut. Kanske en virtuell metod hos Sprite?
Fattar inte riktigt... menar du att varje reell animation ska vara en subklass och implementera den virtuella metoden? Låter jobbigt... hellre funktionsobjekt så, eller någon annan callback-grej. Men personligen är jag mer för någon form av "uppifrån-styrning", vet inte riktigt hur jag ska kalla det... i princip, när en primitiv rutin inte vet längre vad den ska göra, så ska den returnera. Jag tycker det känns naturligare att tänka så. Men det beror förstås på hur kontrollen över animationerna sköts - jag har ännu inte förstått hur du har tänkt och då blir det svårt att hitta på en passande arkitektur.
Det är ju inte självklart att det ska vara så, kanske ska man ha en separat "motor" som flyttar och uppdaterar sprites, och Display ritar bara upp spritesen där de råkar vara. Detta känns som en bra lösning för Odd.
Mm, det är nog ett exempel på det jag menar med "uppifrån-styrning". Jag röstar för detta förslag!
Så här skulle jag ha tänkt:
På mittenivån finns en klass Animation:
class Animation { public: long getNextUpdateTime(); [kanske virtual] bool isDone(); [kanske virtual] void doUpdate(); };
Den har också fält med all information som behövs för att styra animationen, tex om den loopar eller inte och hur den förflyttar sig, samt förstås pekare till sin Sprite och sin AnimationFrame. För att starta en animation så lägger man till den i en allmän lista över animationer.
På mittennivån ligger också "the main loop" om man säger så. I varje iteration bläddrar den igenom den allmänna animationslistan och kollar för varje animation om det är dags för en uppdatering (getNextUpdateTime() < currentTime). I så fall körs doUpdate(). Om isDone() är true så måste mainloopen vidta någon styråtgärd, vilket kan innebära att returnera till toppnivån ifall det krävs åtgärder på manusnivå. I vilket fall ska animeringsobjektet tas bort ur listan, och förmodligen ersättas med en annan animation för samma Sprite.
Detta hänger ihop med timeOut-parametern på Input::getEvent(). I och med att vi bläddrar igenom alla animationer kan ve se hur lång tid det är tills någon måste uppdateras. Detta värde används då som timeOut, så att getEvent() returnerar lagom tills det är dags att uppdatera.
Men som sagt, ta detta bara som information om hur jag tänker... du är mer erfaren på sånt här så det är bättre att du bygger det som du tror blir bra.
En annan sak jag har i a.s. är att man kan skicka meddelanden mellan alla sprites i spelet; man kan till exempel berätta att de ska svänga vänster, eller ge dem skada. Detta kanske inte behövs på samma sätt i Odd eftersom vi inte har någon "fysik", utan skriptar alla händelser.
Jag tror inte heller att det behövs. I Airstrike fanns det ju anledning att göra Sprites intelligenta, här är de dumma i den meningen att de styrs uppifrån.
En sak som vi kommer behöva är i alla fall en händelsekö, med en viss tid för varje händelse. Detta kanske kan kopplas ihop med GameEvent?
Mm, kanske. GameEvent tänkte jag skulle förmedla handlingar från användaren från mittennivån till toppnivån, typ "Odd undersöker dörr", och sådant behöver ju ingen tidsangivelse. Men kanske måste GameEvent vara något mer. Kan du ge exempel på händelser i en sådan kö?
Dokumentera bättre, ja. Ville bara få fram något fort i söndags. Ska vi köra på någon särskild stil, för Doxygen eller så?
Kör nån som du kan och som inte är för bökig, tycker jag. Jag är bara van vid JavaDoc men den funkar väl inte på C++ antar jag.
/Jerker