Orbsphere Universe

What is Universe?

Orbsphere Universe was the original game design drawn up on paper, in the back of books, on anything I could get my hands on. It was started in 2004, rewritten in 2007, rewritten in 2009, then finally put on the back-burner in 2012 (due to intellectual property related protections). It’s currently a mess of raw data, coding, artificial intelligence simulations, neural networks, behavioural networks (as distinct from AI and NN), and system networks. It contains more complex code than should ever sanely be debugged in a single sitting and needs to be rewritten.

Is it dead?

The short answer is “yes, for now”, but the longer answer is “hopefully not”.  At this time the game is too large and too complex to continue programming on every day, or even rewriting bit by bit (given the language port); but with modern systems getting more and more powerful every year the original issue (slated as “it can’t be done without dedicated servers”) has been resolved, and with any luck the more complex systems will reach the point of potential viability sometime before 2016.

Another point is that I don’t get paid to do this, this is a passion, and something that may one day turn into a product I might sell, but as those who have been with me since 2009 know, this project does make leaps and bounds and when it does people tend to be rather horrified at how fast it sometimes moves.

Client/Server/Master Division: who/what/why?

Orbsphere started its life being a high latency system.  It would take up to a minute for a turn to complete before I started to use Boost::Python to replace the Python components with C++.  From there is started to drop rapidly, sometimes we’d get good turns (low impact), but regardless of what I did order was maintained and the processes and threads lagged out.  Enter C++11.  At this point Python was used to wrangle a lot of C++11 data from multiple processes using queues and locks.  This was then dumped in favour of Protocol Buffers being used to network the data on the localhost (, bound to whatever port I got back sending 0, as the specs say).  The problem with that approach was that while I could easily fork processes with Python internals, Python was still too slow.  C++ binary/extensions didn’t help, and modules started to become more and more complex as the networking code to make the system semi-transparent internally made debugging near impossible.

During 2010 I’d been using CouchDB (written in a large part, in Erlang).  This sparked my interest but I had not had the time to look into moving to Erlang until mid to late 2014 when I started looking into it for other purposes.  The key joy of Erlang is that it provides the level of transparency I’d been trying to write without me having to bang my head against the wall every time I wanted to make minor changes.  In fact, not only that, it allowed for hot code updating (but only to a degree and only if you’re careful about dependencies), another feature I’d been trying to get working through the loading and unloading of DLLs and a bunch of really, really, superbly hacky C interfaces.  This is where this sits now.

Updates from 2014:

  • Universe’s core is written in Erlang.  This will mean one of many things, but we’ll see as the code develops;
  • The current “interface” is text-based (“ASCII” to many of you), with no real direction when it comes to graphics (I’m not a designer or graphics artist and I’m far more interested in a text-based pseudo-bulletin-board style game if it means good gameplay!);
  • The structure is similar to the first two generations in that the core server is designed to keep ticking, and the client end (local server and interface) are used to link the data but to keep input free and fast.

Pre 2011-2012:

  • Orbsphere Universe clients (first and second alpha generations) connected the GUI to a local server which relayed data to a remote system for multiplayer purposes.  Universe’s “master” was a highly expensive process in terms of running due to the actor model.  The master server was originally written in Python, it then moved to C++.
  • Protocol Buffers were rolled out into the original (undistributed) third generation