animation and interactivity

Recently I had a meeting with the programmer about if the more refined decisions would still be compatible for the project being made in this game engine - things like knowing a general page count (12), and that it will have animations. It's still possible, but in discussion we talked about how the animation and interactivity could be linked in ways that more took advange of what a game engine can do.

While making the comic into a fully fledged game had been previously considered and rejected, for it would likely distract from the point of the comic and be an unrealistic amount of work, we thought of a simple mechanic that could bring a lot of subtle charm to it. Originally, the interactivity is in controlling the character with arrow keys or WASD and as a corner is touched, the page "turns" in its respective direction. There is a whole platform to work with here, so how can it be utilised to give more character to the comic, but in a way that is still a realistic amount of work for the deadline?

The solution we thought of was if there were things on the platform that the character could interact with on it's way across the page, it could do a little animation upon touching it. It could correlate to something happening on the story page. E.g. If a character was watering flowers on the comic page, while moving the sprite across the bottom, they could come across some little flowers, and do a water animation. This type of interaction is very simple to do on this game engine, so it would only be as much work as me designing an extra couple frames of animation. Logan can program the animation to play when in contact with another object.

Another idea is that triggering the plant watering animation on the platform (for example), could also trigger the respective animation to start on the actual comic page. It is a direct link and would give even purpose to movement other than needing to turn the page. There are 2 ways this could work. 1. The corresponding animation only plays when you stay within close proximity to the interaction object/while doing the sprite animation. 2. Although the sprite animation still stops when you leave the interaction object, the animation stays on. This could reset if you turn the page and then go back again.
It is like playing with the concept of an on/off switch.

I think both ideas are good opportunities for making use of the game engine to improve the user's engagement and the storytelling. The visual impact of the second concept is changed the most: if animations rely on the user moving the sprite, the animations will not be on until triggered, and may be seen for less time. It also means every animation would be expected to have an interactive object to trigger the animation (or it would be confusingly inconsistent), and this could become very cluttered on the platform. However, having this mechanic encourages the reader to use the sprite to engage with the comic more, whereas in idea one, it is still quite seperate from the comic technically. But simple is sometimes best, and idea one would still cause the reader to make connections between the sprite animation and the content in the story. It is less of a forced engagement and would still be very charming.

I conclude that I think idea one is the best fit for this project.

​Sketches while having the meeting: