If you’ve read our recent post about How SpatialOS works with game engines, you’ll know a bit about how the SpatialOS Worker Service, the Runtime and the SDK work. You’ll know how our Game Development Kits, which we’ve been building and refining for the last year, enable you to build and operate multiplayer games using the workflows you’re used to from the likes of Unity and Unreal. You may have seen that Automaton built their own integration with Crytek’s CRYENGINE. You may not know, however, that SpatialOS can integrate with any engine you want.
Which brings us to Charlie Micou and Godot.
Charlie’s one of our own. During the week, he’s an engineer building the SpatialOS Runtime, the server side of all SpatialOS games. Whilst his day-to-day doesn’t involve game engines, for a few months now he has very quietly, and unbeknownst to almost anyone, been engaging in some light dog-fooding. He has, in fact, been building an integration between SpatialOS and Godot. As an external developer. On his own.
Charlie is quick to point out that his Saturday-afternoon noodling hasn’t [yet] resulted in a full GDK. It’s merely a proof of concept that aims to marry the freely available Godot engine to the free, publicly available tier of SpatialOS.
Why Godot, though? “As a developer,” says Charlie, “I’m totally paranoid about giant codebases with years and years of accumulated magic. I love understanding what my engine is doing and how it’s put together. Godot is open source, actively maintained and very compact - making it a pleasure to work with. (Also, it supports Linux as a development platform.)”
Aside from developing his own game demo, SpellCrest, the main thing that preoccupies our rogue open-platform developer - and anyone thinking of constructing an integration - is how two independently developed technologies with different workflows can be made to come together and produce something special. How visible should you make your integration framework and SpatialOS?
Visibility differs in our existing integrations. The GDK for Unreal essentially replaces the Unreal networking stack with SpatialOS, whereas the GDK for Unity makes SpatialOS more visible as a co-worker. Our raw SDKs, on the other hand, pretty much ask the user to explicitly manipulate entity data with worker instances.
Engines near the top of this spectrum are easier to integrate. Anyone familiar with your engine could just set up your module and keep developing as they always had. This typically means actually iterating on gameplay and experimenting with “fun” is much faster - you don’t worry about networking at all, you just build your game. And the more native you make the experience to the engine, the more consistent an experience you get for anyone using your engine.
Charlie’s Godot integration is further towards the other end of the spectrum. It asks you to be explicit about your schema and data formats. It asks you to acknowledge when you’re synchronising data over the network. It asks you to understand that you’re using SpatialOS.
There are three reasons he’s taken this approach. First, simply, it’s easier to build - important for a sole developer. Second, going totally native has its own problems - the more you’ve had to tailor your deployments and schema to the engine, the more difficult it is to use worker types built for general SpatialOS use. Third, Charlie likes the implementation being transparent and compact, in keeping with Godot’s own design principles.
With this in mind, he’s built a low-level core with utilities on top, to make common tasks easier - but his users will need to get more hands-on with SpatialOS.
Godot reasons about its world in terms of a hierarchy of nodes. A Godot worker, therefore, should reason about the SpatialOS world in terms of a hierarchy of nodes.
The “World View” node has as its children all entities that the Godot worker can currently see. These “Entity View” children have, in turn, “Component View” children which contain the component data of each entity and allow manipulating that data upstream.
The SpatialOS C++ SDK exposes a stream of messages from SpatialOS to the worker. Charlie’s Godot integration is responsible for converting this stream of messages into terms this World-Entity-Component hierarchy can understand.
The world view is simple. It allows accessing of entities by their ID, and whenever an entity enters or leaves the worker’s view, it emits a signal referring to the entity view node.
Similarly, the entity view gives out signals when components are added or removed from the entity, and gives out references to component views.
Finally, component views allow for access of the underlying data. They emit signals when the data changes and when the worker gains or loses write access to the component. When the worker has write access, it allows pushing local data upstream.
Low-level abstractions are well and good for building an integration between Godot and SpatialOS, but they don’t necessarily make building a game any easier.
Charlie’s Godot integration exposes several tools for game developers familiar with Godot’s scene editing to create content for the game.
For example, Godot’s tile map editor can be used to construct worlds that can be converted into the SpatialOS snapshot format. Game clients can stream down the tile map data surrounding them and render it locally. Game servers can also modify the tilemap while the game is running and have the changes propagated to clients, allowing for an evolving game world.
Charlie is clear that his work isn’t complete yet. “This integration definitely is not a point where you can just pick it up and have a great time developing a game. It’s meant to be an example of “If I were to integrate Godot, how would I do it?” and serve as a reference point.”
But what’s humbling for the rest of us at Improbable - but also hugely encouraging - is the realisation that even if you aren’t in the business of working with schema namespaces, positionsync nodes, auto-instantiable scenes and tilemap streaming, the whole process of integrating a new game engine seems achievable. Realistic. Do-able.
We are, in short, inspired.
So here’s to the individual developers. Here’s to the two-man bands and the small independents. Here’s to Saturday afternoons and working-after-work teams. Here’s to clear thinking, collaboration and individual determination.
You can watch his whole talk here, and follow him on Github here. He’s got a long way to go before this integration’s publicly available, but we’ll certainly be there, clapping from the curb and helping out where we can.