Diary of a Developer

[Inveteratus]

I was recently asked to help out with an old MCCodes game that had been running for a good ten years or so. I was quite happy to take it on; it had been a long time since I'd played around with that particular codebase, and I thought it might make a pleasant change to see what had been done with it over the years, particularly after passing through the hands of several different developers.

Oh dear.

There were problems. Lots of problems.

Nothing insurmountable, fortunately, but it quickly became apparent that this wasn't going to be a case of fixing a few bugs and tidying up some CSS.

The game was still largely running on the old procedural MCCodes architecture, with pretty much everything sitting in the public directory. Business logic, database queries and presentation were thoroughly intertwined. The first job, therefore, wasn't really to fix anything at all—it was to understand exactly what was there and work out how to drag it into something resembling a modern application without breaking a game people were actively playing.

After analysing the codebase, I decided to target the Slim framework. It's small, straightforward to learn, uses PSR request/response interfaces and provides proper middleware support. No, it's certainly not Laravel. There are no bells and whistles and the batteries are most definitely not included.

As it turned out, that was actually a good thing.

It took a couple of months and a few false starts before I was completely convinced, but eventually it became clear that this was the right approach. Then began the long process of converting the original procedural files into a Controller / Repository / Template structure.

That relatively simple architectural change made an enormous difference.

Database access was moved into repository classes. Application logic moved into controllers. Presentation moved into templates. Suddenly the different parts of the application had clearly defined responsibilities, and changing the appearance of the game no longer meant risking damage to the underlying game logic.

AI helped speed up some of that process considerably, although a surprising amount was still ported by hand. I wanted to retain control over the architecture and, more importantly, make sure the project was moving in the direction I wanted rather than simply translating old code into newer-looking old code.

Somewhere along the way, things took another unexpected turn: I ended up buying the game.

Being a co-developer is fine.

Owning the project yourself is considerably better.

That gave me much greater freedom to address some of the deeper problems rather than continually working around them.

One of the first major additions was a completely new logging system. Rather than recording only obvious events, it tracks virtually every significant action performed by players. That has proved invaluable for finding those awkward last-minute bugs where somebody reports that "something strange happened" but can't quite remember what they did beforehand.

Alongside that came a much more capable multi-account detection system, and that has produced some particularly interesting results.

It can identify obvious same-IP transfers, but also patterns involving feeder accounts, indirect transfers through several players, suspicious account relationships and activity hidden behind VPNs. Combining that information with general player activity has made it possible to identify bots, multis, feeders and outright cheating—as well as cases where players weren't necessarily cheating at all, but had discovered and exploited flaws in the game's own logic.

And there were plenty of those flaws to discover.

The final major addition to the development process was something the original game had never possessed: a comprehensive automated test suite.

Code coverage went from effectively zero to approximately 98.5%.

That has completely changed the way the game can be developed. Changes that previously required a great deal of manual testing can now be made with considerably more confidence. The tests don't prove that bugs are impossible, of course, but they provide an extremely effective safety net and quickly highlight when a change in one part of the game has unexpectedly affected another.

Static analysis also proved invaluable during the early stages. I believe I eventually cleared more than 5,000 warnings, errors and questionable pieces of code from the original codebase. Static analysis is excellent at finding structural problems, dubious assumptions and outright programming mistakes; unit and feature tests then provide confidence that the behaviour of the application remains correct as it continues to evolve.

And that brings me to perhaps the biggest problem of all.

Ten years is a long time for an online game.

Over those years, a considerable number of mistakes had accumulated. Some came from MCCodes itself, whose underlying design is badly flawed in the way it handles several important aspects of the game economy and player progression. Others came from developers with limited experience blindly copying existing ideas or implementing player requests without considering the long-term consequences.

Some of those mistakes were relatively harmless.

Others allowed enormous and completely unintended gains in experience, skills and money.

The result is a game population with a very unusual distribution. The majority of players occupy the lower end of the progression curve, while a relatively small number sit right at the extreme upper limit—sometimes effectively clamped against values that were never sensibly designed to be reached.

Simply resetting those players isn't reasonable. Leaving everything untouched isn't particularly viable either.

So the next major job is rebalancing the game's statistics and progression system.

This is considerably more complicated than merely dividing everyone's stats by ten. There are numerous relationships and dependencies that have to be preserved, along with a large number of checks that need to be performed. The objective is to compress the inflated values while ensuring that players retain their relative positions. Somebody who has legitimately worked their way into the top 1% should remain in approximately that position afterwards.

The difference is that they'll once again have somewhere to go.

Development testing has shown that this approach works extremely well. Skills, experience and levels return to manageable ranges, while the relative hierarchy between players remains intact. More importantly, it opens up enormous scope for future development.

We can introduce more jobs, courses, houses, crimes and other progression systems. Existing high-level players can finally receive meaningful new content, while newer players have a realistic path towards eventually reaching those same heights.

And, critically, the underlying mathematics can now be designed so that uncontrolled stat inflation simply cannot happen again.

So what have I learned from taking over a decade-old browser game?

Never assume the code is the whole story.

Analyse the code, certainly, but analyse the data just as carefully. Understand how the game has actually been used rather than merely how its code suggests it should have been used. Understand your players and the economy they've created. Introduce logging early. Get static analysis running. Build unit and feature tests as quickly as possible. Look for inconsistencies and investigate the strange outliers rather than dismissing them.

Because sometimes those outliers tell you far more about the health of the game than the code ever will.

In my case, one of those investigations revealed that a single player held approximately a quarter of all the money in the entire game.

At that point, you stop wondering whether the economy might need a little attention.

[Inveteratus]

So, the rebalancing went through almost as expected.

There were a couple of minor hiccups that I hadn't anticipated and, in all honesty, I'm still trying to work out exactly how they happened. Thankfully, neither is damaging to the game. One was a very easy fix; the other... well, I think I'm just going to leave it as-is. It affects a fair few players, certainly, but it's not really a major concern.

The rebalancing was potentially a risky one. If you look back at the original MCCodes codebase, there are quite a few design errors that, often through inexperience on the part of owners and admins, have been propagated into many games that are still being played today.

Some of those problems were sadly the result of the original developers not fully considering the long-term ramifications of what they were writing. But while blaming them might be easy, it's probably not particularly useful either. They built something that lasted, after all.

For a game to really work, a surprising amount of time and investment has to go into it. Code, data, user interface, graphics, setting and story all play crucial roles. They're often the difference between a game that's merely playable and earns a few quid, and one that's actually enjoyable — a game with challenges that keep players engaged and enough depth to give it some longevity.

I've only solved a few of those points!

The legacy game I took over now has a much better codebase and a far more sensible dataset. The challenges, though... I'm still working on those.

Getting the right staff is oddly one of the problems. The current staff are good, but there are probably areas where we're still lacking. The story is almost non-existent, which is something that really needs addressing, and many of the challenges within the game are still relatively minor.

Oddly enough, during this whole process I started creating another game — but this time I approached it completely differently.

I started with the story, the setting, the graphics and the challenges.

The code then fell into place remarkably easily, and the data followed naturally afterwards. It's not released yet, but building it this way has made me wonder whether some of its ideas could be pushed back into the old legacy game. More cooperative play, for example, is something I'd really like to experiment with.

I often wonder where this game will eventually go.

It earns a small income each month — certainly enough to cover the hosting costs, licence fees, AI subscriptions and the other bits and pieces needed to keep it running. It might even pay the mortgage in due course!

But I increasingly find myself asking a different question:

Where do I actually want it to go?

It has taken an enormous amount of time and effort over the last nine months, and I'm not entirely sure my heart is still in it in quite the same way.

What I really need is a few good people who can help run it. People with the vision to generate ideas, keep the players engaged, challenge my decisions and tell me when and where I've got something wrong.

But then... if the game is producing a passable income, why not simply accept it for what it is?

Maybe this is the point many developers eventually reach.

Do we continue developing something that has gradually become more labour and less love? Or do we decide we've taken it as far as we want to and sell it onwards to somebody with fresh enthusiasm?

I genuinely don't know how to answer that yet.

One thing I do know is that running a game like this will always be an ongoing process. If, as a developer, you neglect the game and simply spend the income, eventually the players will notice. They'll become frustrated, they'll start leaving, and the game will slowly decline.

If you're prepared to keep putting that extra effort in, though, perhaps you'll be one of the lucky ones who ends up with a game that survives the test of time.

Me?

I think I'll take the occasional holiday, keep tinkering with things, and keep the game running for as long as both the players and I still have some interest in it.

Hosting is cheap. Licences aren't too painful. The subscriptions... well, hopefully there won't be quite so much need for those in due course.

So that leaves just one question:

What shall we do next?!