interface

I did some coding this weekend on the core framework to Refuge/0 and was faced with the always interesting problem of how to interface your game systems with Unity.

I’ve worked with Unity professionally for the last 6 years.  In that time,  on almost every team I’ve been a part of, my responsibility has been building the core gameplay systems (input, controls, movement, combat…) and on many projects I’ve built the core system framework as well.  The best part about having that responsibility is I’ve been able to try out many different patterns, and I’ve been able to see what works and what doesn’t in the Unity environment.

In my experience, your best option is to keep your game code as isolated from Unity as you can.  I’m not trying to insult Unity here.  In general your best gameplay system designs will follow some sort of MVC pattern, and in this case Unity is the ‘view’.  Of course Unity is your entire engine, so your ‘model’ and your ‘controller’ are also dependent on Unity.  So what’s the point?

The biggest problem I see with Unity projects is relying too much on components or GameObject hierarchies to drive your game logic.  When you have hundreds (or thousands) of objects in a scene, with scripts attached all over the place, debugging becomes a nightmare.  But if you treat GameObjects as tools for visualizing your game logic, and keep your game logic encapsulated with minimal dependencies on the Unity API, then something like an MVC is possible.

There isn’t any strict formalism to this.  As a guiding philosophy it will help you cut down on whole classes of bugs, help improve iteration speed, and make it easier to extend your systems and add new features down the line.  Here’s a simple example using the new framework I started building last week:

MyAwesomeGame.unity3d
`-> GameObject
  `-> Bootstrap script
    `-> Awake()        <=== this is your Main()
    `-> Update()       <=== this is your update loop

So far so good.  I have a Unity scene, with a GameObject that has my Bootstrap script attached.  Bootstrap is the entry point to your application, so you will want to go to your Script Execution Order settings and make sure it is first on the list.  The boostrap script will maybe initialize some other core systems (anything static, like a logger) and then finally will hand over execution to a state machine, which will control the execution of the rest of your game.

Notice the other major Unity dependency here: Update().  I like to use Update() (or FixedUpdate or LateUpdate) to call my own update method with Time.deltaTime as a parameter.  Again, this is probably just a matter of philosophy, but helps keep the mindset that whenever possible you should decouple your game code from the Unity API.

Ok, so I’ve created a state machine and it updates once per frame.  I still need to spawn prefabs into my scene and use them to actually make a game somehow.  But, I need to eat dinner and then hopefully make some progress actually writing code, so this will have to be a cliffhanger until the next post!  duhn duhn duuuuuhn.