InvinciKnight

Development Process

Pre-production

A lot of our project's pre-production was fairly brief thanks to scheduling conflicts forcing us to start work on our project 4 days into the jam. It mostly comprised of group calls where we brainstormed different game ideas we could do related to the game's theme (invincible). Past that, we worked together to compile reference material in the form of moodboards. We considered working on a bit of concept art (and in retrospect we should've) but decided to get straight into production instead.

In addition to nailing down an idea to pursue and establishing an art style for the game, I took the time to set up a Trello. Our Trello was instrumental in ensuring that everyone knew what tasks they had done and what was left to do, and helped me (as producer) to see where people needed extra help and guidance. It was also invaluable experience in using Trello in a more professional manor, as prior to this I had only ever used it for keeping track of my own progress on personal / solo projects. It also showed how much progress we had failed to achieve thanks to both me and Owen being fairly busy outside of the project towards the end of the jam.

Production

Production began with a lot of setting up. I got the game's GitHub up and running (which can be publicly viewed here), set up a very basic player controller, and made a main level from which to work and experiment in. The original camera view for the player was (in my entire team's opinion) awful - it was at an awkward angle that I had landed on thanks to some inspiration from Don't Starve. This also included a camera movement system inspired by the same game, moving it left and right in 45 degree angles using Q/E.

Once we had landed on the final camera system - a top-down perspective with a self-made movement lag that makes rapid left/right movements feel much less jittery - I began work on the core gameplay loop of the game - this included a few key aspects:

• Player Attacks

• Enemy Movement

• Magic Enemy Attacks

• KOTH Progress

• Victory / Death

I never found any of these core gameplay aspects to be difficult to implement. Issues mostly arose with spawning enemies, projectiles, etc. I found out post-jam that it was because I had fundamentally misunderstood how I was spawning objects into the scene. I was making them siblings of the scene root rather than children, and as such when reloading the scene it would entirely break the game, forcing me to remove the in-game ability to restart after you win/lose as this issue mostly cropped up at the end of the jam. It was an easy fix, merely changing how I called the scene root caused the issue to disappear. Restarting has since been re-implemented in patch v1.0.1.0, which was released after the game jam and judge voting period that followed.