Published on 23rd October 2015
We have found that Unity 5 is now mature enough to provide a platform for us to develop titles quickly, and yet retain AAA quality of entirely bespoke solutions. One of its key improvements over older versions is a dramatically improved graphics engine, which now includes PBR shaders and modern global illumination through Geomerics Enlighten. Unity provides quick build times for game content, PhysX-based physics, acceptable animation and audio systems, and a clean scene editor. Like most other engines we’ve seen out there, however, networked games development is a bit of an afterthought.
Some games don’t require much of their server – perhaps just some simple logic and message passing. If you’re making the next Hearthstone clone, a message-passing server might just do the trick, and be quick to develop and debug. But what if you really need Unity on your server too? Perhaps you need to have the scene available, or even run some physics on the server. Out of the box, you’ll be plagued with painful client and server builds, timeouts when you’re debugging and some tricky code to test down the line.
If we could consider clients to be simple views of the server, we could develop without the networking complexity. We could swap between these different views to test clients rather than running separate processes and maintaining the connection between them. Achieving this, however, requires considerable attention to how a client may in fact preemptively make decisions to mask latency, and run systems like a user interface that are not seen by the server.
This October, our tech team have produced a networking middleware that allows networked games to be developed without building or running multiple processes, doesn't impose more restrictions than low-level network APIs, and yet can still handle client-server latency as well as any AAA game without the complexity for content developers. We provide a content development style in which the server doesn’t directly call the client (there is only data flow, not control flow). We allow the client to handle all UI code and override scene details, yet we can still run a client within the context of the server, and even detach and remotely re-attach to the same 'client' state. Despite this, we provide a 'preemption' system that allows clients to predict its effects on the server, which carefully prevents content development becoming substantially more complex than in a single player game.
Almost all development proceeds without building a standalone client, since client scripts can execute within the server itself. Supporting this is a transport layer that constructs efficient UDP packets, with logic that can handle packet drops in a game-object-aware manner, allowing a highly efficient pseudo-reliable connection to be established. TCP-based transports can also be supported without any extra overhead when configuring for less twitchy games.
We look forward to announcing the titles that we intend to release with this platform in 2016.
The Automaton Tech Team