The Pareto principle, or 80/20 rule, is often applied to software development when we talk about optimisation or the complexity of writing intricate systems. As the saying goes, 80% of the time developing software will be spent fixing up and finishing the hardest and most complex 20%. This principle applies to so many things in game development, but I would like to focus on one specific topic: codebase complexity and optimisation.

In my experience, it's all too easy to fall into the trap of overcomplication. Too many times I have seen people ready to create their own implementations of standard libraries, or revisit solved problems to put their own personal spin on them. We should be unafraid to set aside our egos, stand on the shoulders of giants and reuse solutions where we can, only inventing where we must. Sadly, it's a common practice to spend huge amounts of development effort on finishing systems that have bloated beyond recognition, even when deep down it is understood that there's probably a better approach. How, then, do we manage to solve for the hardest optimisation problem of all: the sunk cost fallacy?

The answer is deceptively simple. At Moon Rover, every major technical choice we make is vetted from the point of view of the most important people: our players. After all, what is a video game if not something to bring joy to those that end up playing it? If we approach our development less from the point of view of optimising unnecessarily complex systems, and more from the point of view of optimising how fun the game ends up, then it is our belief that we will make better games.

But how does this help us solve the undoubtedly difficult problem of actually engineering a video game? It does this by giving us a tangible razor with which we can make decisions: by optimising for fun, we are able to consider what technical choices are truly necessary. Do we need to precisely model each footfall? Do we need bullet trajectories to be simulated at the centimetre level? Do we need the game world to be 100 square kilometres? Sometimes, of course, the answer will be yes, because that is the choice that makes the best game for our players. However, a lot of the time the answer is a definite "no", and it is by finding those "no"s that we are able to chart a course back to where we started: the 80% of the time that we spend on 20% of the systems.

If those systems that we spend our time on are what makes our game fun, not necessarily just complex to create, then we are using our development time in the best possible way: making systems that are just complex enough that we can deliver something remarkable for our players.