Improbable Icon


Game Designers: UML or other Project Organization Techniques for SpatialOS



I know some game developers don’t care much for design documents.

However with SpatialOS it seems like good planning may be more important than the common prototyping practice of ‘iterate quickly through stuff in Unity until it works’.

Have people found any particular tools or techniques useful for organizing their projects around SpatialOS architecture?

I have in mind tools like UML. Or practices such as that you perhaps design all your entities first, and only then look at how you’d define your workers. Or maybe you always start a project with a camera and world terrain.

What do you think?


Ive always been bad at keeping game design docs organized or up to date so everything ends up messing. I tried organizing tasks in Trello but it wasn’t until I found HacknPlan that my design has become more orderly. Its a kanban board with sprints tied to a game design category tree.

Nothing really specific to Spatial but milestones help a bit to keep on task.


Oh, I had been looking for a Project management program and hadn’t found a good one. I used to work with MS Project back in the days as a Traffic Engineer, but I felt it wasn’t suitable for Game Design. I’m using Visual Studio Team Services for my git repositories, but I wasn’t to thrilled yet about the management system.
This HacknPlan seems like a very good solution! Thanks for sharing it, @judah4 I’m certainly going to try that out!


I use Asana, which just launched a Kanban competitor called ‘boards’. I will have to check out HacknPlan.


This is a topic we are discussing every few months again, but it seems that for our small team it works best to do iterative prototyping. Of course this strongly depends on the participating people and their abilities, not everyone can do this as i have learned…

We are using gitlab together with gitlab kanban to get the project organized in general. For some important features we are using google tools (docs, calc or draw) to work out the implementation details together. If you are aware of the security considerations the google tools are really good at working collaboratively.


Thanks @daschatten. Beyond these workflow tools, I’m really curious how small teams like yours are conceptually organizing their SpatialOS work.

Here’s why:

  1. Iterating in SpatialOS seems a bit slower than Unity, especially as the project gets larger and you have to do ‘spatial builds’ etc. It’s not like pressing Play in Unity and seeing quickly whether the guy can now swing his sword. It can take several minutes each time.

  2. New features require editing across several files to update nature/behaviours/components etc. It’s not like editing a single base class in an OOP design in Unity and then watching how things change.

On the spectrum of total-planning waterfall and no-docs-rapid-fire prototyping, this seems to suggest a lean towards planning.

Or do you find that this really doesn’t matter and your team maintains good momentum when prototyping together?


I use Gitlab issues to plan my work and start off with a basic GDD to create an outline of the project. When I work on an issue I tend to create a Sandbox scene where I write my visualisations and basic behaviour.

As soon as I am satisfied with my behaviour I start abstracting it out into Natures, States and Events so that all behaviour is performed in the Gsim and Fsim.

I have noticed that this increases the speed at which I execute my workflow because I can avoid things such as spatial builds for a long time. The downside is that this workflow makes it harder for a distributed team to work on the same pieces. This can be minimised with clear communication or tasking the issues to a minimum but it is an inherent downside.

I have deliberately postponed my work on the Gsim for now until the C# workers are usuable; by planning my behaviours as Unity independent C# code I will be able to more easily move the code to the backend then.


Random interjection: I know @alastair wrote a neat little script for pulling out nature dependencies as an HTML rendered graph. Just in case anyone wants to see it!

Iteration times can be a problem: @draconigra has a sort of “offline / online” mode enabled that allows Unity to run locally and just forget if SpatialOS is running or not. Something like that is definitely worth investment.

@oddur and @rainer.hilscher are OBSESSED with the idea of test driven development: they constantly ask for test frameworks and integrations: I absolutely agree. With a complicated product like SpatialOS: good tests are going to pay off even in the short term.

Our internal recommendation is to test first, fast and early: both the design and the tech. Persistence and scale are going to drive engagement in weird and wonderful ways: but it’s all new…even for us here at Improbable. Find the fun…move fast and break things in order to do so.
We’re hoping to build a real community that will allow you to quickly get lots of eyes on a mechanic as soon as its ready.

LOTS more on process to come soon…great question as always @zachc


I want to throw a design tool out there for everyone, Articy:Draft. This is one of the best tools I have ever used or seen for game design or world design. I highly recommend checking it out.