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.
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.
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 (127.0.0.1, 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.