What we learned by finishing our first complete project - Pt. 1


So, earlier this year, my three game developer friends and I decided to participate in Ludum Dare 46. While all of us have always wanted to work on a real project from start to end, so far none of us  has ever really published anything complete but game jam entries.  Jams are a great opportunity to explore ideas, and learn new things  - however,  most jam entries get uploaded in an unfinished state and never get completed.  You can find our entry here:

https://ldjam.com/events/ludum-dare/46/how-to-raise-a-demon

So after finishing the jam, which had the theme 'Keep it alive', we ended up with a broken adventure RPG, that left most players that dared to open it  not knowing what exactly to do. Nevertheless, we were very proud of what we created. You could move around in first person,  fight bats with your melee weapon, pick up items and interact with objects in the world.  We admitted to ourselves - none of us has ever gotten so far with a game  on their own. So after the jam we were motivated to say 'let's take this piece of keyboard input processing unit and make an actual game out of it'.  While one team member had to focus on their graduation and one had no time due to his full-time job, two of us decided to spend their spare time on improving the "game" we had created in the jam for the next couple of weeks.

The problems of the jam version

Probably the biggest issue with our jam was, that we had spent  a lot of time creating features and assets and very little time went into designing the level and almost no time at all into testing it. After coding player controls, the basic enemy, the boss enemy and the interactables in the world, one of us started building out the level in the afternoon of the third out of three days. After laying the level out, we figured we needed doors and keys to make the design work,  yet another feature that left us with less time to test and polish. This resulted in the level being painfully small of course, The biggest problem however was that  the boss enemy would get stuck in the ceiling once he spawned. We had no time to make the level bigger, so we scaled the boss down - but we never found out if this would have been a valid fix, because under a  lot of stress and sleep deprivation we accidentally published the wrong version of the game - so the boss enemy, which had cost us the most time, was completely useless and ended up being a waste of time.  

Another issue we had, was that we had spent so much time on implementing features, we had no time to make the game tell the player what to do. Some quickly created collision-triggered voice lines where the only sort of player guidance we had. The third main problem was, that the game felt quite empty, due to the lack of sound effects in it.

Many of these problems, especially the lack of time resulted from a more technical error. We created the game with Unity which suggests a different source control than normal software projects. Unity has its own built-in source control called 'collab'. However, this is a premium feature than can only be used for free for teams of up to three people. Being a team of four and not wanting to pay for collab, we decided to just use git. What we did not know at this point, is that handling source control for unity with git properly requires you to enable special settings and using a special .gitignore file. Instead of doing a simple Google search and finding that out, we struggled for hours and hours fixing broken object references that were lost whenever pushing a commit.  This constantly set our progress back and with it our motivation as well. This was a mistake that could have easily been avoided, but , hindsight is easier than foresight, I guess.

Files

HTML Play in browser
Jun 09, 2020
Windows 86 MB
Jun 09, 2020
Mac OS 87 MB
Jun 09, 2020
Linux 91 MB
Jun 09, 2020

Get How to raise a demon

Download NowName your own price

Leave a comment

Log in with itch.io to leave a comment.