In the making of AkimBear, we chose to use this talk from Vlambeer‘s Jan Willem Nijman, a true master of arcade action games, as our inspiration. In fact, as soon as we had the rough sketch of our idea (i.e. akimbo-wielding bear with sacrifice used in the gameplay design), we watched the talk in order to get it in our heads when we started building the game. The trailer can give you a good idea of the game we ended up with:

https://youtu.be/avRx-U6SNHk

I highly recommend watching the talk if you have an interest in building games with strong immediate feedback. I also really like Nijman’s perspective on the layers of feedback in creating interactive experiences. In the talk he takes a basic game and adds tweaks to get something that is much more appealing to play. Those points are below and I’ve annotated them to show how we used them. The bold points were taken directly and the italic points were only partially implemented in AkimBear.

1. Basic animations & sound
2. Lower enemy HP
3. More enemies
4. Bigger bullets
5. Muzzle flash
6. Faster bullets
7. Less accuracy (missed this one!)
8. Impact effects
9. Hit animation (and effects)
10. Enemy knockback
11. Permanence
12. Camera lerp
13. Camera position
14. Screen shake
15. Player knockback
16. Sleep (time slowdown)
17. Gun delay
18. Gun kick
19. Strafe
20. More permanence
21. More bass
22. Super machinegun
23. (Random) explosions
24. Faster enemies
25. More enemies
26. Even higher rate of fire
27. Camera kick
28. Bigger explosions
29. Even more permanence
30. Meaning

A lot of the above are obvious when you see our gameplay. I’d like to talk about one of the less obvious points that we used when designing AkimBear: Player Knockback. During his talk, Nijman says “if you put a button in a game … give someone a reason not to press it.” This was the inspiration for deciding that Grizzle should stop moving while shooting and how this could be the gameplay sacrifice.

I’ve gotten some feedback about the time slowdown being too strong and I think this is quite valid since it feels almost like framerate issues sometimes (particularly when off screen enemies are killed). I limited the permanence by using a ring buffer object pool for the number of bullets at any time for pre-emptive performance reasons. I know “premature optimization is the root of all evil,” but once you start pooling objects there’s really no reason not to pool everything. In this case, I would disagree with Nijman; despite computers being very good now, you should default to defensive and performant coding (if possible, for your experience level) until there is a design reason to expand. Limiting runtime memory is always a good idea to avoid unnecessary garbage collection (this is especially crucial for mobile devices).

Check out the gameplay by playing AkimBear!

If you have any questions at all, don’t hesitate to ask! My email is ecmjohnson at gmail.com