Its disappointing to have to give an update more than 12 months since the last which shows very little progress on project Kariko. Quite frankly, not showing anything in such a time frame is simply embarrassing.  However, I have genuinely learned a hell of a lot over the last 12 months and feel in a much stronger position despite miserable project progress.

So what happened?

Shortly after deciding to pick up some extra assistance on the development front (Josh), I was persuaded to drop Gamemaker Studio and instead use Unity coupled with C#.  The main reason was that Unity would allow greater control over things like net code, resolutions etc.  However, the real reason was that Josh had never used Gamemaker, but was experienced in C#.  This essentially meant that all of the prototype work would have to be ported over to Unity.

After a month of working together, most of the core mechanics had been transferred – but they weren’t the same.  In agile development, tasks and user stories related to your work usually have what is called a ‘definition of done’.  This is a set of things that need to be completed in order for that piece of code or functionality to be deemed complete.  Typically these are things like tests, commented code and design documentation.  I mention this because while the essence of what I had achieved in Gamemaker was now in Unity – it wasn’t feeling right…  The controls weren’t as snappy, there was a delay on the animations and movement would continue until the animation cycle had finished.

Another thing which began to surface was that we both had different ideas of where the prototype should go next – often the exact opposite.  I had a strong vision in my mind of what I wanted the game to be, and had also spent quite a bit of time working through the design.  On reflection, this probably drained quite a bit of Josh’s enthusiasm – as it probably became less fun.

After another fortnight of work things had slowed quite a bit.  We were still trying to iron out bugs in Unity that I had managed to squash quite quickly in Gamemaker.  It got to the point where I was created mechanics in Gamemaker just to explain clearly how certain things should work.  Doubt started to kick in about the choice to move.  Josh contacted me a few days later to explain that he would be studying computer science part time and this would naturally have an impact on the amount of free time available.  At this point we parted on good terms, and wished him all the best in his studies.  I was back on my own.

At this time work picked up with a promotion and the focus instead had to shift to other things.  Things kept slipping and slipping until I decided to put it on hold and to come back at a later date.  During the months after that, I continued to keep reading and learning design – but it wasn’t until April that I decided to focus on Kariko again.

What I learned

In that short space of time, I quickly picked up a lot of experience – learning more about myself and how to manage work on a personal project between two people.  Below are the key things I learned from the experience:

• Communicating the Vision – In my mind I can vividly see what Kariko looks and feels like.  Each night while trying to sleep, I work out how the mechanics mesh together – things such as which crops should be available to farm and how players could create structures in the world to make it their own.  The challenge is how you manage to communicate these ideas.  I had initially put down the high level overview of the game on Confluence and also started to flesh out the design for the other features (farming, inventory systems and structures for example) – however in hindsight I don’t think that was enough.  You need to be able to communicate the essence as well as all of the core components for your game in an exciting and engaging manner.  A traditional game design document would have been more effective than the wiki approach I had taken. It doesn’t have to be every last detail – but a single document of around 12-14 pages.

• Ways of Working – How you manage and organise any project is integral to its success.  As previously mentioned, I am fortunate enough that my day job gives me great exposure to different ways of working and their challenges.  I had opted to try and take an agile approach to working with Josh, as it would mean we could agree small amounts of scope to be completed in short time frames and tackle functionality in chunks, building up over time.  I underestimated my ability to teach how agile development could be adopted – not because Josh didn’t get it (he was actually a really sharp guy), but because learning how to run projects in such a way would be a task in itself, never mind the development work.  I also didn’t do the greatest job of instilling how I wanted to work at the start.  My advice would be to agree on ways of working from the start!  Agree how you will decide which things to work on, how to determine when it is done and also how often to take a look at progress and recalibrate.

Hopefully this post gives an explanation as to why things abruptly came to a halt.  The one benefit of being on your own again is control.  For now, I can keep trying things out and testing my ideas to see what works.

Pixel