Skip to main content
GameDev.net gamedev.net

PRO Tired of ads? Read GameDev.net ad-free and help keep the community independent with GameDev Pro — $3/month.

Duplicate functionality!

Duplicate functionality!

kiwibonga
kiwibonga's Blog · · 2 min read
1,497 0
So lately I've been investing significant amounts of time into a "sequence listener" class that enables sequential and timed actions.

This is useful in the little BlackJack demo game I'm coding alongside the framework; for instance, when the cards are dealt, I can simply string together a bunch of countdowns, animators, etc. to spawn and move cards to the relevant areas, one by one.

The way I implemented this was with a "relationship descriptor" class that I really like -- it attaches a tiny object to one of the game elements on the scene tree, and if ever that game element is deleted, so does the little relationship object, and its destructor informs the relationship descriptor of deletion... It's a way of keeping lists of specific items without having to iterate through the tree, searching for specific objects (such as renderables, objects that respond to user input, etc). So waiting to be notified of the end of a sequential event amounts to waiting for it to die, which is pretty convenient.

But very quickly, this introduced an issue: if I set up a sequence in that system to be executed later, I had to attach the sequence's behavior to the relevant objects before I could push it to the sequence string... So what happens when I need a sequence object to spawn a new object with its own sequences to run? I can't, because I can't attach my sequence objects to something that hasn't been created yet.

In the card dealing example, I want to attach 4 "spawn card" commands to the card deck (2 for the dealer, 2 for the player). Those spawn card commands should then spawn the cards, and then add a sequence object and countdown to the cards so that they can be moved to their destination (the player hands) one after the other...

The problem with the monolithic sequence processor I coded is that if I do use it that way, 4 cards will get spawned in one shot, and then they'll travel to their destination one by one... But I don't want that -- I want each card to be spawned, then moved, before the next card is spawned.

So I got to work on a class that acts as a "group of sequences" -- i.e. a class that acts as a subsequence, so that my "spawn card" commands are actually "spawn+move subsequence" commands.

And that's the story of how I invented "fake threading." Meanwhile, ghosts of programmers past are looking over my shoulder as their bodies turn in their graves.

Discussion

Loading comments...