Design your own spaceships, prepare your armada, and fight online against other players in thrilling real time strategy battles for supremacy over the interplanetary battlefield!
Trailer
Goals
In our design document, the team goal was defined as "work on a project that is worth crunching for.". While the statement might be a bit dramatic, the message is clear: With Space Force, we wanted to create something big in a really short time—an online multiplayer real-time strategy game. Space Force was supposed to truly test our technical finesse and be a great piece for our portfolio.
Specs
Screenshots
My Tasks
Introduction
I love real-time strategy games. I grew up with them, and one of my goals as a kid was to create an actual RTS. Over the years, even before studying game design and programming, I kept trying to create my own strategy game, yet it was always way too complicated and hard for me.
Before leaving Games Academy, I really wanted to try and see again if I am now capable of accomplishing this goal. So I sat together with Felix Günther, and we thought about the best approach to creating an RTS. We didn't just want to make a small, cute RTS like my GameMaker prototype from 2017; we wanted to make a game that makes people go "wow"—we wanted to raise the bar of what students can do at the Games Academy in such a short time. So A LOT had to be done.
Design, Ideas and Passion
So, we took a lot of inspiration from Star Wars: Empire at War. A space RTS would make things way easier. We didn't have to handle terrain and complex lighting on planets. We also didn't need a lot of vegetation or environment assets. Our artists could focus a lot on the ships and VFX to make combat look as good as possible. Additionally, we didn't have to think too much about units clogging up and getting stuck at each other because we could just move our ships on different layers on the Z-axis so they could dodge each other. In short, an RTS in space can work and look good way quicker.
Felix came up with the idea of making ships customizable and creating loadouts the player could select before starting a match. That would allow the player to create ships and strategies none of the other players had ever seen.
Sounds overscoped for a bunch of students that are only supposed to work on the project 8 out of 16 weeks? Well yes, it was—but we knew that, and we were ready to invest way more than 8 weeks into this. I was passionate to get this done.
"Lead Programmer"
I was the Lead Programmer on this project since it was the first project where we were more than 2 programmers on the team, and I had the "most experience" from all of us at the time. Also, I was the only person that actually wanted to create meeting logs and track the tasks of the programming department, so there is that.
I scheduled and discussed tasks with the other 2 programmers. I created a small TDD with coding guidelines and naming conventions and outlined what we had to create from a technical standpoint to get this game going. On top of that, I occasionally reviewed, discussed, and evaluated the code of our youngest programmer at the time. I was constantly working together with our artists and designers to discuss tasks and bugs and evaluate tools we needed.
Networking & Online Multiplayer
To us, it was clear that the game needs online multiplayer. Creating an RTS where you play against an AI can be fun, playing against other players though, is even more enjoyable. We wanted to get the multiplayer architecture done as soon as possible so that we could build all the other systems on top of that with multiplayer in mind.
Before the semester, and therefore the actual project phase, started, I had already worked on the core server-client architecture. We didn't want to use any existing plugins for unity, we wanted to do it ourselves. The core of the multiplayer architecture is rather simple. There would be server software running outside the game. And the game itself, being the client. Like that, everyone could just start the server software on their PC to host a game, or we could deploy it on a server online; what we eventually did during the project to make playtests easier, especially if people outside the local network wanted to play with us.
The server was written in C# with .NET Core 2.2 for cross-platform compatibility. Since we wanted to deploy the software on a Linux server and not rent a Windows server.
Additionally i created a small unity editor tool which basically was just a wrapper of the server, so other people of the team could easily start a session without knowing command line tools.
Messages & Activities
The networking code itself was pretty straightforward, especially since .NET Core already did the heavy lifting. The server would just wait for players to connect, handle rooms, and then receive messages and activities from players and send them to all the other players in the lobby or a dedicated room.
The lobby is a place where all connected players are, and a room is basically just a lobby a player can open for a limited number of players in order to play a game.
Messages were small packages with data that would get sent over the network and then handled by the clients. The server itself didn't have much authority, it was just a middleman to send all the packages to the corresponding players. E.g., a ChatMessage would get sent by a client with its UID and text. The server would read the text, log it, and send it to all the connected clients who are in the same room as the player who sent the message.
Activities, on the other hand, were messages that could also get invoked. Activities were client-side only. The server would receive them and send them to other players but would have no idea what they are. E.g., a UnitDeployActivity would get sent and distributed like any other message; the clients would then call the invoke function. In this case, a certain unit would get deployed at specified coordinates.
Of course this system would make it really easy to cheat. But we didn't really care enough, nor did we have enough time to implement anti-cheating measurements.
Determinism, Lockstepping and Fixed Point Numbers
Since we didn't want any unit limits, we decided that we had to make the game deterministic so that it didn't have to synchronize every unit by itself; that could easily overwhelm the network. With determinism, every client only had to receive activities and then simulate them locally, like that the game should look exactly the same for every client.
We utilized lockstepping and a tick system to synchronize the clients. A player would send an activity to the server, and the server would send the activity back to all the clients. Yet the activity wouldn't get invoked instantly; instead, it would get scheduled to a future tick (~200-400 ms in the future).
Players would also send dummy activities to the server every tick, except if they actually did any sort of input that is relevant for other players. Like deploying a unit.
The server would send a tick message at a constant rate to all the clients, unless a client didn't send any messages for that tick, not even a dummy message. Like that, we could detect disconnects and pause the simulation on all client machines until the player reconnects or gets timed out. The server also wouldn't progress if a client didn't send back a confirmation that it received activities for future ticks. Otherwise, the simulation would get paused yet again, and all the clients would wait for that one client to receive the message again. Players usually don't notice those kinds of pauses, since the clients are always a couple ticks behind the server.
In order to make a game in Unity deterministic, we had to forego floating point numbers. That means we had to use integers wherever possible or use a custom-made fixed-point class for deterministic, yet inaccurate, floating-point numbers.
Noah, one of our programmers, built that fixed-point class over the course of the whole project. Additionally, he had to create a math class for fixed-point numbers.
On top of that, we couldn't utilize Unity's built-in AI and navmesh solution, so we had to write our own pathfinding and navmesh solutions to make them work with fixed point numbers. Unity's transforms and physics were also not deterministic. So we had to create a simple physics engine and our own transforms as well. Quite a bunch of complex and advanced tasks, but he managed to pull it off.
Of course, that was only for the actual deterministic simulation part. We used the model-view-controller pattern and detached units that had to be synchronized completely from Unity. They were bascially the controllers. The model was then represented in Unity and was allowed to make use of floating-point numbers and so on. Like that the game wouldn't stutter around and wait for ticks to update, we could just interpolate objects between ticks on the clients simulations.
Tools
Since the programming department was extremely busy getting the actual game up and running, I decided to create an asset management tool for all of us to use in order to make it easier for designers and artists to implement assets and change values.
The module manager was a tool where all defined ship chassis, weapon and utility modules, and bullets could be edited. The tool itself was pretty much just a scriptable object library with extra steps and some QoL features. That being said, with this tool, our artists could assign VFX, particles, and models to ships and modules. Designers could adjust every value and stat—sometimes with calculations that show DPS and so on. And on top of that, we were able to visualize hitboxes of projectiles since we couldn't use Unity's internal physics system.
It was a tool that drastically helped us to quickly get things up and running in the game.
I also created a small utility tool to implement and test weapon modules. The weapon editor was a good way to quickly get any kind of weapon implemented into the game and check out their shooting patterns, VFX, and speeds without having to start a game.
A couple more tools were created by our 3rd programmer, Lukas. I wasn't too involved in the development of these tools. I only helped Lukas out from time to time, reviewed the code he had written, and checked his progress.
He was in charge of the in-game ship and loadout editor as well as the internal dev-only map editor seen here:
GUI and Technical Art
In all previous projects, I handled the UI and VFX. This time we fortunately had a dedicated designer for the GUI, and our artists were interested and eager to create VFX on their own.
That being said, I still blocked out a big amount of the GUI, especially for the main menu and multiplayer lobby, and was responsible for the technical side of the GUI. The only exception being the ship and loadout editor created by Lukas.
Some more small technical VFX and animations got added into the game by me as well. E.g., the ships stretching when leaving hyperdrive.
Post Mortem
This was my last student project, and to this day I am still blown away by what we managed to create here. My goal wasn't to get a good grade but rather to realize an ambitious project and learn a lot of new and more complex things in my last semester. And I certainly reached that goal.
Looking back at this project, it still boggles my mind how many things we managed to get done in such a short time. Of course, the game comes with a ton of shortcomings and criticisms. The project was even bigger in scope when we initially planned it out. We had to cut a lot of things, including base building and a replay player, even though the latter still exists in a really basic form.
We crunched a lot… like A LOT. And though we were just students and could endure such pressures and the lack of sleep, it still was getting quite rough at the end of the semester. Especially when keeping in mind that during the last few weeks of the project I was also looking for my first job in the industry.
The game is riddled with bugs and glitches. Even though we managed to get rid of massive desync bugs and heavy game breakers, it never reached a point where someone should release a game. A couple of maps are not playable—the game just won't start on them. Playing with more than 2 players is also really risky for no apparent reason. I need to profile and debug more to find out why that is, but I haven't taken a good look at the project for quite some time now.
Units and modules are generally quite unbalanced. The whole game mode is getting quite snowbally quickly. Not every weapon module behaves like it should. The unit movement is clunky, and the UI is not as responsive as it should be at times.
The funniest "bug" to this day is that after finishing a match, everyone should just quit and restart the whole game and wait for the server to get restarted as well; otherwise, a 2nd match would just start with a static camera, and the player couldn't do anything.
Those bugs probably appeared quite late in development, since I remember playing multiple matches in a row without issues or playing matches with up to 8 people.
In 2021, Felix and I sat together again in a video call and talked a lot about the game. I fixed a couple of minor issues and updated the server to a newer .NET version so that we could play again. In 2023, we sat together again, and I fixed even more minor bugs while Felix changed some values on units and modules to balance the game a bit more. To this day we still play a couple of matches from time to time, and we are determined to eventually make a fully fledged game out of Space Force and release it in the future.