Khunum development has been slow the last few weeks. That really means no work has been done on it. I’m using this journal entry to try to understand why this happened. I know why no work has been done on it – it comes down to a lack of motivation and interest. But now it is ‘why’ this came about. It seems something related to the ‘start-up’ cost, i.e. how much effort is required to begin working on it and whether what needs to be worked on is enjoyable. Right now the list of things to fix are all small tweaks such as tiny visual changes to textures, bugs with hand interactions, and player controller fixes. Saying that, we also wanted to add two new levels at the end of the game because we threw out the end levels that were too uninteresting and non-clay related. So why are things so hard to work on right now?

It might just be a case of procrastination and once I start to work on it, it will become easier to complete. But something else must be there too. This idea of ‘start-up’ cost. What I mean by this is the energy it requires to restart a project once it has been dormant for a while. Maybe it should be called the ‘restart-up’ cost. Low restart-up costs happen when the project is built modularly and the parts that have been built have been tested well so that they don’t need to be addressed again. This means that the ‘restart-up’ cost does not require going back to previous code, scenes, or assets and trying to remember how they work in order to start working from where the project was left. A high restart-up cost is the opposite: leaving bugs behind and incomplete assets or code, having a difficult interface for design that needs to be remembered every time you start working again. These things deter you from wanting to get back to a project that has been long put off.

The question then is, how can we keep restart-up costs to a minimum? Here are some bullet point ideas off the top of my head:

1. Build modular systems. This means to build things which can be self-contained and self-functioning and easily interact with other parts of other systems without needing to be edited at all.
2. Invest in usable systems. A modular system isn’t beneficial if it is still complex to try to integrate it with other systems. This will make you avoid using it when you haven’t used it in a while. Therefor it is worth investing time in a good interface that makes it straightforward to use the module. This could be a good UI, good code variable organisation and naming, or good code documentation.
3. Build automated testing systems. If your modules are complex and have many different potential interactions, define a set of tests that covers these interactions and confirms the module functions under these interactions. Then if comes down to needing to edit your module at some point, you won’t have to worry about breaking its function.
4. Define the scope and work only within that scope until necessary. Scope creep will violate all of the above points. If you build a module and follow steps 1-3, but then later in your development decide that you want to add a new feature C to said module, this will require you to edit the module (step 1 violated), make the feature usable (step 2), and build a test for it (step 3). Because you are not building a new module, but editing an existing module, you hit a very steep restart-up cost of having to learn this modules inner functions again to make this feature.

So where does Khunum fail on these points right now?

1. Only some of our systems are modular. Some of our non-modular, co-dependent systems include the coupling of level design and level aesthetic and dependencies in the codebase for interactions with the user hands and other controls.
2. Only some of our systems are usable. We only have a couple very complex systems that need user tuning but sadly these aren’t usable. For example, the VR character controller and hands have many different parameters, but all of these are raw variable UIs making it difficult to remember how tuning one affects the others. Code is not well document and doesn’t follow a consistent design pattern. I had the idea to build a few templates for starting new scripts that keeps things clean.
3. Some things are tested, some things are not. One interesting thing we did for physics testing was build scenes that defined a grid of all possible interactions we could think of. For other things, testing fell short. Again, time wasn’t invested into making a VR character controller that could be tested without the hardware.
4. Scope creep was everywhere. From adding new level mechanics, to increasing the scope of the game mechanic. This bit us in so many ways, from having to rewrite behaviours of old objects, to introducing game-breaking bugs in alpha versions.

So in conclusion, this is what the state of things look like when planning has been avoided as a project scales. If I were to do things differently I would first build a working prototype without any complex level assets so that the coupling of aesthetic and design can be avoided early on. Then once that is polished I would design a level-building system that avoids being caught by model redesign problems – one way this can be done is keeping everything to predefined grid cells. Perhaps there are other approaches. And finally I would keep the code clean and modular, solving self-contained problems with each script that don’t couple too closely with other scripts. Templates and early design decisions could prevent this from becoming messy with dependencies.