Language

A lot of the most critical bugs in Beta 5 were caused by the features of PHP itself. First of all, PHP is not really meant to run something as computation-intensive as an online strategy game. Performance problems definitely ensued – even at this time, it takes at least ~40s to compute a complete hour tick. The other major problem that was encountered is that, well, I am clumsy. I make quite a lot of typos. And PHP is quite forgiving of typos in variable or property names – it will in fact completely ignore them, creating the new variable/property when writing, or returning null when reading… This kind of bug is hard to track down, especially because its consequences can become visible only in completely unrelated parts of the code, and because, when reading such code, your brain tends to “fix” what you’re reading for you. You won’t see that variable named $militart. You will in fact read the perfectly correct $military, because you know that’s what it should be.

Because of this (and also because some choices made by the Zend team with regards to PHP 6 annoyed me, but that is another matter entirely), Beta 6 was to be written in another language… But the question was – which one? There are dozens of candidates out there; in addition, it is often the case that language A is better at doing X than language B, but B is better at doing Y than A.

The criteria I used to guide this choice were performance, clarity, support for UTF-8, easy database integration. C++, C#, Java, Python, PHP 5 and 6 as well as Perl were considered.

Of course, in terms of performance, C++ revealed unbeatable, which is not really surprising. On Linux, the Mono implementation of C# turned out to be a little slower than Java, itself a good 10x slower than C++. Python, both PHP’s and Perl were… well, really much slower than either C# or Java (which is not really surprising either, but… I was still a little disappointed regarding Python). That pretty much sealed their fate. In terms of clarity, support for UTF-8 and database integration, C++ is terrible, which also eliminated it. C# and Java remained. In the end, despite C#’s cleaner typing, Mono’s I/O performance (and therefore database integration performance) is not that good, which led me to choose Java.

General architecture

Beta 5′s code has a major flaw, one that shouldn’t have happened but did anyway. I originally intended to completely separate game code – for example ticks, or the actual action that underlies sending a fleet – from display-related code. However, because Beta 5 was sort of rushed and did not undergo proper design, a lot of the game code ended up being coupled with the display code, which (in addition to the massive amount of delicious JavaScript spaghetti) made it totally unmaintainable. That mistake had to be avoided, especially if other interfaces (IRC bot, smartphones, dedicated client) are to be supported at some point.

The decision that was made for Beta 6 was to write a separate game server, which would run independently of any type of user interface. This server handles commands, background tasks such as game updates (“the things formerly known as ticks”) and returns raw data whenever appropriate. “Clients” which provide user interfaces then connect to the server, allowing players or administrators to interact with the game. At the moment, only two such clients exist – the main web site, and the administration site.

Legacy Worlds software deployment

As this diagram shows, it would be relatively easy to add new “clients”, connected to the game server and providing other types of interfaces.

The game server

Because of the “milestone” development process, the server has to follow one major constraint – it must be easy to replace parts of it. This imposes a component-based design where components are as independent as possible.

A client communicates with the server through a set of classes which represent commands, responses and actual data using a component called the SessionClient. This component has a server counterpart, the SessionManager, which supports different types of sessions with different authentication requirements, states and valid commands through specific components called “session definers”. At the moment (and for the foreseeable future), three such definers exist:

• the external session definer handles commands which can be executed by anyone (for example, requesting the list of supported languages),
• the game session definer manages player sessions, their various states (disabled, banned, active, vacation mode…) and commands,
• finally, the administrative session definer handles commands from the administration interface.

While the session definers (and especially the game session definer) will definitely change in future milestones, the essential component that is the session manager itself is stable by now.

Session definers don’t do much by themselves. With the exception of basic constraints checking, most of the logic is actually implemented in lower layers. The validation and transformation components handle proper validation of the commands’ data, forwarding all of this to the data access layer, and then transforming the results into something which can then be sent back to the session layer.

This lower layer (and, to some extent, the administration session definer) relies extensively on a set of system components. These components are in charge of all operations required for the good operation of the server, but which are not really related to the game logic. They include:

• the ConstantsManager, which caches game “constants” in memory for quick access and allows them to be updated by administrators, notifying components who use them as necessary,
• the Ticker, which executes actions on a regular basis at various frequencies, relying on the ConstantsManager for its master frequency,
• the Logging components allows asynchronous logging from the rest of the code, as well as log clean-up and querying,
• the Internationalisation component caches translations from the database, and handles administrative commands updating these translations,
• the Mailer which fetches internationalised e-mail templates, transforms them, and sends them.

Both the system components and the data access layer can access the database. Access is (with one very small exception) never direct – all read-only operations read from views, while the update operations are implemented through stored procedures.

The diagram below shows the various components or groups of components of the server as well as an arbitrary, unnamed client.

The various components of the Legacy Worlds game server

The components in green are stable – they will not change, with the exception of bug fixes. Yellow components contain mostly stable code, but are still missing some parts which will be added in later milestones (for example, the UserAccount component does not support using contribution credits). Finally, components in red are likely to be completely replaced or heavily modified.

What the diagram does not show is that the database is structured using namespaces, which follow the organisation of the server components quite closely.

Next time, on the B6 blog…

The next (and last) post of this series will tell you all about Milestone 2.