Introduction

This week we put our all effort in getting ready for the production phase. We made a final prototype to proof that our game not only works, but is also fun to play. For this we also experimented with a new alternative movement system. We also finished our art bible, sound bible, technical document and game design model. Once production start we will be ready.

Final prototypes

This week we added some traps to the prototypes. These include the spike trap which gets activated when a player goes over it. It uses a coroutine to have everything go smooth and nicely timed. We first give the player a warning by moving the spikes slightly up, wait for a bit. Then apply some knockback to the player.  Another feature that has now been introduced is a stun system. When a player gets hit by a trap he will get stunned for some time. The second trap we have is quite simular in function to the spikes. It's a spring trap, which will just push the player in a random direction but without any stun.

Art Bible

The art bible has been completed and can now serve as a guide for us during asset creation. It now contains the entire *vibe* we are aiming for. Guidelines on character design, the UI, props, textures etc will help us give this game the the best fitting art style possible.

We also created a mindmap for our asset pipeline and tested it out on a banner asset.

Apart from that some more sketches were created and we couldn't be more happy with the design of the knight.

Finally, also a "Font Bible" was made to experiment with fun fonts for our UI

Sound Bible

The sound bible received some minor changes, but the biggest of all was a good system for the integration process. Using a scriptable object will make the sound implementation smooth and clean. Because it keeps all the randomization regarding volume, pitch and which sound to play, all in one script. The only thing needed in code is a sound object and the function to call play. So we can keep the code seperated, because the sound modulation is handled mostly within the editor and not within code.

Tech doc

The tech doc now finally contains our complete folder structure, all naming conventions with both good and bad examples. Instructions for the artists were added on how to in- and export correctly between different software and how to work with the shaders in Unity. Our programmers now have clear coding guidelines and a basic structure for organising their scripts

Game design model

We cleaned up the last version of the GDM: it was restructered, some visuals were added and we added additional descriptions and visual representations to the elements that were still needing one.

Here is a rough sketch that was trying to capture the main elements of gameplay. It wasn't made with all the decisions from the art bible in mind yet and hopefully the final game will look much better.