Feature Modules in SpatialOS and designing Project Nobody.


Woman silhouette blue light background

Trond Fasteraune is an independent developer from Norway, who worked on games including Among The Sleep, and is currently experimenting with a prototype small-scale MMO on SpatialOS. Last month, he posted his manifesto for designing small-scale MMOs. Here he talks about the features modules he’s been creating to get it off the ground.

Recently, I started work on a new game on SpatialOS. The game – codenamed Project Nobody for now – is a simple top-down isometric game about protecting others and being protected. I planned the mechanics in this game with my design manifesto in mind. To reiterate, as a player I wanted:

  • To change the world I play in.
  • My goals to be reachable with my limited available playtime.
  • My performance to not be a burden to anyone.
  • Maliciousness to not grow.
  • To instantly play with my friends.
  • The population of players to not affect gameplay in a negative way

For example, the combat system is a mix between the ability system from DOTA 2 and the skills and effect system from Guild Wars 2, with the goal being to make it accessible and easy to use – and fair, given certain simple techniques to prevent cheating. As another example, the design is explicitly social: not unlike a gangster racket, the experience you earn in this game is split between you and the person above you. As you become more and more powerful you can recruit people to work under you. In the end, maybe you will be the one at the top of the pile? The game features a branching class system based on your character level in the game; if you die, you lose it all.

Anyway, when I first started working on Project Nobody, it was a huge mix of prototype code and hacked-together asset store plugins. The initial plan was to just go full steam ahead and get a prototype up and running as quickly as possible because that’s how I do it when I prototype games.

As time went on, I quickly realized that this is not going to be of any use to anybody –  my code was a big ball of mess. I wanted my code to be open source, clean and freely available for anyone to use. So I started separating my code into chunks – which developed into standalone feature modules people could easily add to their own games.

“Not unlike a gangster racket, the experience you earn in this game is split between you and the person above you.”

SpatialOS and Feature Modules

The SpatialOS GDK Core for Unity gives you a low-level integration with SpatialOS, enabling you to use Unity to build client or server workers to use in your game. This core package enables basic functionality that developers expect should work out of the box, but it also loads other packages that can be optional should you ever decide to not use them. An example is disabling the GameObject Creation package should you decide to use pure Entity Component Systems on your server worker.

In most cases, developers want to use extra features other than the low-level integration packages, and the GDK also provides some out of the box. Pluggable modules containing features for your game. You can see some of them working nicely together in the First Person Shooter Starter Project.

Project Nobody and its Feature Modules

Health & Armor

This module was the first feature module I wrote before I began working on Project Nobody’s pre-alpha. It was a way for me to learn how feature modules worked and how I could easily use them as submodules in my git repository. Unit tests were added to make sure that it worked properly while writing and refactoring the code. Later on, I found the Unit Tests to be very useful when I had to refactor the whole module after learning new and more efficient ways of writing ECS code.

Get it here.

Status Effects

The effects module is hugely inspired by Guild Wars 2’s effect system. I’m a big fan of how the combat works in Guild Wars 2 and how boons and conditions spice things up in different ways. Doing status effects in this way also compliments the ability system by avoiding hard-coded player effects when casting spells – for example, by simply adding an “Immobilized” effect to a player while they’re casting a teleport spell.

Get it here.


Again, this is hugely inspired by Guild Wars 2, but also a compromise because I didn’t want actual weapon attacks in the game. There is no primary and secondary attack, just abilities on your ability bar. Basically, just how Guild Wars 2 does it with the first skills on your skill bar being weapon skills.

(I’m still working on this feature module but will update this post when it’s available – or you can follow me on Github here.)


Timers are created by simply setting the time when the timer should expire. One huge problem with this is that Unity’s local time on all workers is different as they started up at different times. A solution to this is to keep a time variable synchronized between all Unity workers by having a single worker being the timekeeper and giving its current time when workers ask for it. Without this, it wouldn’t be possible to have effects or abilities. (Note that this solution is not suitable for features requiring sub-second accuracy.)

Get it here.

“Project Nobody is a simple top-down isometric game about protecting others and being protected.”

Other probable features

There are many different features developers might want for their games. Some of these are common enough that they might become developed and maintained by the community. I predict that some of them are what you see below.

  • Server Authoritative Player Movement
  • Chat
  • Voice Communication
  • Class System
  • Weapons
  • Physical Projectiles
  • Inventory
  • Voxels (Minecraft terrain)
  • Procedurally generated world maps

The biggest gain for me is that writing feature modules enables me to write cleaner code and think in a more structured way. Like organizing and cleaning up your room. It feels nice and tidy after you’ve done it, and after doing it you know where everything is.

When writing a Feature Module it should also come with a unit test to make sure, and also to prove, that the module works. By using unit testing, I’m able to make sure that my features work correctly should I ever refactor code or upgrade either SpatialOS or Unity to a newer version. It’s also a sanity check for lead programmers should they ever be used in large-scale projects.

My long-term plans

My long-term future plans are to implement some sort of continuous integration system to oversee all my feature modules to make sure that all unit tests pass on them on different versions of Unity. I also want to engage with the community on Discord to keep making modules developers can use in their games. After all, making games should be about making the games you want and not reinventing the wheel every time.

More solutions. More possibilities.

Explore all IMS solutions