Sep 282014

A little while ago I posted about my spaceship building/fighting game, made in Unity. Because Unity is quite different to how I’m used to writing games (pure C++), it required a bit of getting used to how to structure things. This post will give a high level overview of how it works and all fits together. Again, as a Unity novice I’m not saying this is exactly right, but I’m happy with how easily everything came together so it can’t be too far off!

I plan to do a few more improvements and usability tweaks to the game and then I’ll probably put it up for download. No guarantees on when though.


The game consists of just three scenes: Lobby, Garage and Space.

The Lobby contains the UI for creating, joining and leaving servers, a Start button and a chat panel. There is a singleton NetworkManager that stores state about which server you’ve created or joined, and the other players in your game. I talked about that here.

On starting the game, every player loads the Garage scene. This scene contains the base ship and the components available to build it. After 60 seconds of building, the server calls time and tells every client to load the Space scene.

The Space scene contains very little except for a textured quad for the Background, a camera and a couple of manager scripts. All players are added in code, and at the end of the game the Lobby is reloaded.

Quickly about the networking side of things. The server player also plays the game as a client, so as much as possible the code is split out into Server and Client parts. The client-running-on-the-server goes through all the same processes as any other player for simplicity (but the NetworkManager shortcuts the message passing, as I spoke about before).

Garage structure

The Garage scene contains a bunch of GarageSlots which are where the available components appear. There’s also a GarageManager object which has references to all the GarageSlots (set up in the inspector). Finally there’s a PlayerShip which is mainly a container for ShipModules (the square tiles you add to your ship).

Each individual ShipModule is defined as a prefab which contains a sprite, a box collider, a ShipModule script (with info about the connectors on each face, hit points etc), and any module-specific scripts. There are currently eight types of module and around 30 different module variants, so there are 30 different prefabs.


All very straightforward. One problem is then how to create a global accessor for these modules, so that both the Garage and Space scenes can get references to the prefabs. Looks like we need another singleton, which we’ll call the ModuleLibrary.

Singletons with configurable parameters

The ModuleLibrary script contains references to every module prefab, set up in the inspector. This is all fine if the script only exists in one scene because you can just drag one into the scene and set it up. However, singletons like the NetworkManager work by newing up a NetworkManager script and adding it to an object. Instead I want a singleton that I can configure in the editor.

To do this we can set up an object containing a ModuleLibrary script, configure it by adding all the Module prefabs to it, and save that as a prefab. Then you can use this singleton get() function to instantiate it from the prefab:

static ModuleLibrary m_instance;
public static ModuleLibrary Instance
    if (m_instance == null)
      GameObject obj = Instantiate(Resources.Load("ModuleLibrary")) as GameObject;
      m_instance = obj.GetComponent();
    return m_instance;

One thing to note is that Resources.Load() takes a path relative to the Resources folder in your Assets list. This folder doesn’t exist by default so you’ll have to create it.


Now we are able to get a prefab for any tile from this singleton and a module ID number.

Garage security

For a small hobby game I’m not at all worried about cheating, but it’s good practice to design a robust hack-proof system as much as possible anyway. To that end, the server keeps track of and verifies all steps in the ship building process.

The server generates the IDs of the modules that will be available in the slots, and tells all clients. When a player clicks a module to pick it up, their client sends the chosen slot ID back to the server. The server stores which type of module that client has selected, and generates a new one to fill the gap.

When a player then clicks to attach a module to their ship, the client only sends the grid coordinates and the rotation (one of four). The server already knows which component is selected and verifies that it’s valid. Therefore it’s not possible to send new modules back, or create invalid ships, by sending fake packets to the server.

From the Garage to Space

The details of everyone’s ships are stored in a ShipStore, which is another configurable singleton. The ShipStore on the server is what keeps track of the ships that each player is building. When the Space scene has loaded, the server ShipStore uses RPCs to tell every other player the details of all the ships.

Unfortunately the built-in Unity networking doesn’t support sending arbitrary byte arrays, so the transmission is a bit cumbersome – an RPC call is made for every single component on every ship and contains the player, coordinates, module ID and rotation. It’s not ideal but it works, and there are at most a couple of hundred messages.

At this stage there is a little bit of message passing to ensure that every client has finished loading and receiving ship data. Everyone has now build a ship and made it into space so it’s time for some action, but that can wait until part 2.

Sep 042014

I’ll try to keep this brief, I don’t normally like to get too serious on here and everything has been said before more eloquently that I could put it.

I 100% support Anita Sarkeesian and her work on Feminist Frequency, as well as everyone else who has received abuse as a result of working on or expressing a view on video games.

If you don’t know what I’m talking about, count yourself lucky that you’ve been spared this particular display of vulgarity from a small segment of the “gamer” community in response to the Feminist Frequency videos. And if you have any interest in video games and how they can be improved, you could do far worse than watch them yourselves.


My main emotion while writing this is embarrassment. I’m embarrassed to have to state the blindingly obvious: that women and minorities have the right to criticise a medium of entertainment without being subjected to abuse and death threats. I’m embarrassed that the gaming community has allowed mysogynists and sociopaths to be such a prominent part of how the public (and even gamers themselves) perceives it. In 27 years of being a gamer I’ve never once been ashamed of my hobby, but the events of the last few weeks have pushed me perilously close.

This is me stating that those people do no represent me. Along with many many many many others, I believe it’s important to make a public stand – to do my little part in counteracting this toxic culture.

Games have been fighting to be recognised as art for years. Now they’re made it – and they’re starting to get the same level of critical examination as any other media. Some of it is valid, some less so, but any high-quality reasoned commentary is welcome, especially in a medium that has been mostly devoid of it for so long. As a (ex-professional, now spare time) game developer, I wholeheartedly welcome any criticism that makes me think harder about what I do, and what can be improved.

To end on a positive note: in the long run this sorry episode may actually achieve something. The developer community is small, close-knit and predominantly comprised of rational, educated, well-meaning professionals. I believe the issue of equality in games has very much been brought to the forefront for most of those developers. And I believe that gaming will continue to accelerate along the sometimes-rocky road to being a fully-fledged respected artform, one that we can all be proud of.

Thank you. Normal service will be resumed shortly.