Worm Farm - Post Mortem

I decided to experiment with some code architecture and process changes to gain more experience in Game Dev with my latest “game”: Worm Farm.  I use the term game loosely - it’s not meant to be fun or designed for the entertainment of the player, it’s purely a learning experience.

The Process

The main focus, and something I’ve historically struggled with, is falling into the pit of over-architecting.  This includes designing for theoretical future features (just in case I want to add the ability to Pause, I need to design for it now) and genericizing libraries off the bat (I’m adding a new feature in this game, I should write it in a way that I can just drop it into any future games).  Coming from my enterprise software architecture background, both of these approaches tend to be how organizations look at enterprise software development. But in personal development, it makes a game “too much like work”, take way more time than it should, and all-too-often derail the game.  In a recent game, I spent 2+ weeks working on a generic interface for Data I/O, which inevitably lead to the death of that game. So my strategy for this game was:

1. Make a pair of lists of what the game IS and ISN’T
2. Whiteboard the architecture of the game
3. Pencil+Paper outline the diff game components and how they interact
4. Implement (with placeholder assets).  And severely limit:
1. divergence from the outline (keep telling myself STOP over-engineering)
2. Research (spend 1-2 minutes researching a thing and then pick whatever seems to be the best idea from there)
5. Create and add final assets

I wanted to take this approach so that as a solo game developer, I am very focused in each phase and limiting task switching.  First I’m a designer, then an architect, then a coder, and finally an artist. In retrospect, it made me feel more productive in shorter periods of time.  It’s difficult for me to purposely write things that I know aren’t “perfect”, but the value gained outweighs that loss. I should be cognizant in the future of if/how I would create or maintain generic framework items.

I will continue following this pattern for my next game - I can see this process working in shorter “sprints” for a larger project.  Identify what feature(s) to add next and then go through the 5 steps to complete them

The Architecture

I also tried something new with this game for the architecture.  Where with the Process, I purposely diverged from the ways of standard enterprise software, for the Architecture I decided to borrow strategies from enterprise software.

Historically I’ve struggled with trying to decide which object is responsible for what.  With Unity game development, it’s possible to architect the same game in radically different ways.  A single entity in the game can be composed of many single-use components that are not aware of each other or one single script.  Game logic can be located in a single place or dispersed across the game objects. Things can be told when to act or can react to events.

I decided to take an approach that would most closely appear to be MVVM (Model-View-ViewModel).  The entirety of the game logic and behavior live in the “Model” of the game. These are pure C# objects (with no awareness of Unity) that simulate the game and react to events from the outside.  The unity objects themselves are the View - they are data bound to the game objects and display them, knowing when to automatically update. The ViewModel surfaces the model and glues the model to the views.  In this game, I decided to put some of the core logic directly in the ViewModel, something that diverges from the standard paradigm.

This approach...worked.  It was nice and easy to code and I could simulate the game without ever being in Unity.  It seems to work well for games with clear steps and state. I’m not sure this would work for a Real Time game, or at least it would make the game needlessly complex.  It’d be difficult to use this approach if I have to rely on in-game physics for some aspect of the game.

In the future I’ll continue to think about where game logic should live.  I think I would prefer to put game logic in back end objects like this to aid in testing, but not at the expense of having to write pass-through or work arounds.