Conversation
Brianna Townsend
britown@mastodon.gamedev.place
Edited 1 year ago
I did it I blogged.
This post is about how Chronicles does turn-based gameplay, by executing all of the turn logic in a single frame and constructing a timeline of render data to play out the presentation of the turn.
There's a lot here about state management and immediate mode presentation! I hope you enjoy!
https://blog.brianna.town/turn-based-gaming-the-atomic-execution-function
2
1
0
@britown thanks, bookmarked! There is way too few articles on turn based game loops.
0
0
0
@britown back when i encountered that problem my solution was totally different.
every game actor would register their transition calculation routines, some of them conditional on key presses and others conditionally on other actor's actions or positions. i then performed tge desition tree of all the game transitions in one atomic state on all game actors, then yielded a game state. then i would make an interface for the transitions to register one to several animations.
those animation's render would take as input a previous state (before the turn) and a next state (after the turn), plus a current time; returning an enum (CONTINUE, YIELDED, FINISHED, REPEAT) whether they had completed.
the little animation interface had functions to take into account animations that have to finish after other animations, but also animations that would run independently from all others; even independently from the game state (think of idling animations for instance).
only when all essential animations had run their course would the game yield back to the input stage of all game actors; but the idling animations and even some others would continue (think of the trails of smoke slowly running off whilst the player already continues their next step).
i wish the code wasn't on a lost hard drive; it was a joy to work with and it would mostly run itself. i had so many plans with it (including a visual animation logic editor) but none of it ever got finished.
every game actor would register their transition calculation routines, some of them conditional on key presses and others conditionally on other actor's actions or positions. i then performed tge desition tree of all the game transitions in one atomic state on all game actors, then yielded a game state. then i would make an interface for the transitions to register one to several animations.
those animation's render would take as input a previous state (before the turn) and a next state (after the turn), plus a current time; returning an enum (CONTINUE, YIELDED, FINISHED, REPEAT) whether they had completed.
the little animation interface had functions to take into account animations that have to finish after other animations, but also animations that would run independently from all others; even independently from the game state (think of idling animations for instance).
only when all essential animations had run their course would the game yield back to the input stage of all game actors; but the idling animations and even some others would continue (think of the trails of smoke slowly running off whilst the player already continues their next step).
i wish the code wasn't on a lost hard drive; it was a joy to work with and it would mostly run itself. i had so many plans with it (including a visual animation logic editor) but none of it ever got finished.
1
0
0
@britown interestingly enough, since the animation logic was completely decoupled from the game logic; i could just completely skip animations for debugging with one press of a key.
but even more extreme, since it was developped on an extremely slow laptop (as in, can barely render a single rectangle in one frame slow; that laptop had problems:), i would render the animations out of order; first render the last frame, then the frame halfway through, then the first quarter; and on running out of time it would just present these rendered frames and skip those it had no time to render.
that part was cursed even compared to modern rendering pipelines with their timestretching, but it would outsmooth no matter how heavy the display controller's bus was hit.
but even more extreme, since it was developped on an extremely slow laptop (as in, can barely render a single rectangle in one frame slow; that laptop had problems:), i would render the animations out of order; first render the last frame, then the frame halfway through, then the first quarter; and on running out of time it would just present these rendered frames and skip those it had no time to render.
that part was cursed even compared to modern rendering pipelines with their timestretching, but it would outsmooth no matter how heavy the display controller's bus was hit.
0
0
0