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.
Scenes
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
{
get
{
if (m_instance == null)
{
GameObject obj = Instantiate(Resources.Load("ModuleLibrary")) as GameObject;
m_instance = obj.GetComponent();
DontDestroyOnLoad(m_instance);
}
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.
