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.