Skip to main content

On Sale: GamesAssetsToolsTabletopComics
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

Great question! Exactly right, this is my first time really trying this technique out. 

What we're doing is keeping an event queue (basically just an array with FIFO order... with some exceptions). The main driver behind this was the Chain Lightning spell, since we wanted to animate each chain separately (seen in the above gif). Some other examples of things we want delayed are player/ally/monster movement; it's nice to distinguish those in order

The one tricky part so far is that it turns out it's not simply enough to always put things on the end of the queue to be popped off the start. There may already be future events on the queue when we do the Chain Lightning for instance and we want all those parts of the spell to come before anything else. So we added a priority to events as well. I'm sure some other method would work equally well, like nested events or something like that.

It certainly seems easier than doing all game logic immediately and then trying to animate to pretend like the logic happened sequentially. So far I'm really happy with this direction. Hope that helps.

So the game state isn't updated immediately? Does that mean that it blocks player action now?

Game state is updated in sync with the animations. And currently yes it's blocking player action but that's not really inherent to this approach. In either case you can queue player inputs and speed up animations as the player plays faster. No need to block. That's probably what we'll do eventually... It's less of a priority because there's no need to play super fast in Leyliner.

Makes sense. Though if unblocked, seems like there could be some timing weirdness with UI (like if game state affects the UI based on what actions are valid). Not sure if that's applicable at all to Leyliner, just thinking through my own games. Anyways, looking good! Thanks for the insight