Arguably one of the most difficult skills that a game designer can learn is the ability to duly cut something from a game. This isn’t simply about minimalism, or dropping features due to time constraints: no, this is all about hunting down and removing a piece of your own hard work from a project because the core idea unavoidably sucks.

We all hate undoing any sort of work that we’ve put time and effort into, but it’s something that’s important in just about all aspects of life. Writing several drafts of an essay can improve the final script, graphic designers often make multiple concept drawings for a single image and even scientists needs to be open to scrapping older theories in favour of newer, more accurate knowledge models.

Some game developers, however, seem to consider themselves exempt from this particular consideration: they hold the strange belief that once any given feature makes it into a game, that feature needs to stay there indefinitely. Somehow, subsequent versions of the game need to work around said feature’s flaw and turn it into an asset — after all, the more direct route of completely removing the feature would be too painful to even consider.

"The Team Fortress Engineer: always accept the possibility of your hard work being completely *obliterated*."

"The Team Fortress Engineer: always accept the possibility of your hard work being completely *obliterated*."

Fair enough. It’s difficult to kill one’s darlings, even for those who know that it may well be the right thing to do. We all have bad ideas from time to time, and such ideas can vary in scope: maybe it’s an errant menu option, or an unwanted enemy type, or even an entire section of the game. Of course, the size doesn’t really matter — if it turns out that an idea is well and truly poor, it’s time to throw it into the garbage compactor.

Many games go through an initial expansion phase, particularly if they’re complex or experimental in nature: early builds will attempt as many ideas as possible, usually because the best way to test an idea’s effectiveness is to simply code it in and see how it turns out. Dungeon Crawl Stone Soup, a massively popular Roguelike which has been in development for years, has taken this approach in many areas. This expansion, however, is tempered by an overall tightening of the design: along with every new feature added, the devs also remove classes, races, status effect groups and even entire spell trees — some of which have been in the game for a very long time.

Some players occasionally complain about the losses, but on the whole they tend to work towards a better game experience: even though the version number is at a mere 0.6, DCSS is successfully trimming a whole whack of game fat from its overall package.

Don’t be afraid of revising your own games: accept feedback intelligently, establish your project’s weak points and ask yourself honestly whether you can salvage them, or whether you need to remove them entirely. Remember that a wooden raft held together by frayed ropes is destined for trouble no matter how tough the wood may be. Strengthen your own raft by finding those weak points and replacing them with something better.