In this talk I'll show how we manage our animations using dependency graph, ensuring dynamic Solitaire gameplay.

1. Based on dependency graph
Animation
queue
Viachaslau Kukhtsiuk, 02.03.2023

2. Let’s imagine that you
design a solitaire game

3. Game logic: base components

4. Game logic
• All logic
synchronous;
• All actions perform
per
one update;
• No any knowledge
about
event receivers;

5. Game visual: base components
Animation can contain any logic:
• starting game engine actions;
• starting Spine animations;
• all you want to do here;
Animation

6. Just connect
events with
handlers and run.
Animations handler

7. Game speed: normal

8. Then we add more
game mechanics…

9. We decide to add two more mechanics!
✓Plus card.
Plus card automatically adds more cards to stock when player opens plus card on
board. No need to play it.
✓Half card.
Half card contains two halves that merge automatically to normal card when both
halves opened.
Sounds good, let’s implement them!

12. Game speed: 2/3

13. Idea #1: run animations
one by one

14. Animation queue
Add Event to base animation,
so we can know when animation
ends.
Animation

15. Animation Queue
Two main methods:
• addAnimation to place
new
Animation in queue;
• tryExecuteAnimation to
determine can we
start next animation or
not

17. Game speed: normal

18. Idea #2: run animations
using dependencies

19. We can think of animation as an operation that requires some
objects to be free to start this. Operation also holds some objects
(the same as for start, or not) during its lifetime, such preventing
other operations from start.
Resource can be any object, for example string, int or even
another animation.

21. Game speed: normal

23. Example from Riddle Road: AnimationResources

24. Example from Riddle Road: PlayCardFromBoardToWaste

25. Final touch: release resources
before completion

27. Game speed: 2/3

28. Questions?

29. Thank you!