The following post is a summary of my work during Week 3 or the Game Development module, focusing on Programming. The goal of the weekly challenge was to create a “Grey Box” prototype of my game as defined in my proposal from the previous week. Due to the volume of work and time constraints, again, the post for this week is a collection of observations and reflections rather than academic prose.
Itch link: https://nickadance.itch.io/rhythm-dice-early-prototype
- Reaction to the learning material
- Felt comfortable rushing through the coding fundamentals
- Challenges encountered during making the grey box prototype
- Initial estimation: not a lot of time, so tended to underestimate
- Observer pattern for notifying objects of the beat was a good idea
- Dice mechanics development ended up severely underestimated (4h worked vs 1h estimated)
- Overall development time: 14+ hours
- Implemented:
- Setting up project & repository, Metronome observer pattern, Grid system, Simple die/obstacle models, Die movement and control, Stationary enemy and die interaction, Walls, Simple die sounds, Simple camera follow, a prototype level.
- Not implemented:
- Refined animation of die, Moving enemies, Bottomless pits, Health system, Spawning, Goals
- Optional: Dice swapping, sound swapping, power-ups, UI
- Own observation from the prototype
- Input feedback needed – especially at lower speed, the player only sees the die move at pre-determined beats. Indication should be given immediately after input is registered (can refer to Don Norman or Celia Hodent’s talk (GDC 2020)):
- Display indicator of where die is heading
- Use animation of the die itself
- Alternative change: allow player to move off-beat like in NecroDancer
- Predicting future value unclear, and
- Observing current value difficult.
- Battle outcome is currently determined by comparing the potential value of the die as it would appear when stepping on the obstacle’s tile. It would be much easier for the player to predict the outcome if battle was determined by a comparison of values while the die was still adjacent to the obstacle (and give the player a chance to change direction in the last second).
- Reinforce the values via indicators above both die and enemy prior to interaction
- Use colour coding (but with respect to colour-blindness)
- Encounters could be enhanced by use of theming (e.g. emulating classic RPG fights and using classic indicators like HP numbers, attack/defense icons etc.) – see Lens #11 – The Lens of Unification (Schell 2019)
- Might need to send out pre-beat notifications to observers to set up animations
- Input feedback needed – especially at lower speed, the player only sees the die move at pre-determined beats. Indication should be given immediately after input is registered (can refer to Don Norman or Celia Hodent’s talk (GDC 2020)):
- Peer feedback
- Elliot: “really fun and addictive gameplay loop”, potential for adding juice and enhancing game feel via theme
- Also – couldn’t complete the level
- Will – agreed with the game’s potential for implementing good game feel
- Paul – the sound effects keep you involved
- Agreed with determining outcome of battle one step before
- Suggested a “slow mode” for planning out movement outside of rhythm
- Elliot: “really fun and addictive gameplay loop”, potential for adding juice and enhancing game feel via theme
References
GDC. 2020. “The Gamer’s Brain, Part 3: The UX of Engagement and Immersion (or Retention).” YouTube. Available at: https://www.youtube.com/watch?v=CozTtfhwPX0 [accessed 16 Feb 2021].
NORMAN, Donald A. 2013. The Design of Everyday Things. New York, New York: Basic Books.
SCHELL, Jesse. 2019. The Art of Game Design : A Book of Lenses. Boca Raton: Taylor & Francis, A Crc Title, Part Of The Taylor & Francis Imprint, A Member Of The Taylor & Francis Group, The Academic Division Of T&F Informa, Plc.
inverted ↄontrols 