[Most] games are awful for about 80 percent of the process—there’s no fun in the game until the very end.

David “Dr. Doak” Doak, excerpt From GoldenEye 007 by Alyse Knorr

I recently read Goldeneye 007, a terrific book covering the making of that classic game, and came across the above quote. I could not help but strongly agree with this observation, as I’ve seen it first hand countless times. Whether it’s making a game, or writing music, drawing art, or any creative activity, it always seems like the first 80% of the project is a slog. It feels like working on something that seems like utter crap and somehow refuses to come together, until the very end. It happens regardless of the type of project, the length, or even how challenging it is.

So it was very heartening to learn how ubiquitous this problem is. Apart from knowing and accepting that most creative work will feel like crap, what other things can we take away?

Things will suck, until they don’t

Even my most successful projects did not break this first-80%-is-crap rule. When making Dunkman for Ludum Dare, about half way through the jam, I posted this progress update:

This project had a very successful process - from the start I had a clear vision of what the game would be about: a silly send-up/homage to shonen sports anime. The game mechanics were simple so I could focus on polish: story, art, effects. But truth be told, until all the pieces were together, I was not sure if it would work, if the stylistic elements would overcome and elevate the simplistic gameplay. But they did come together - the upbeat music, anime speed lines, silly elbow IK animation, the chunibyo dialogue, all made for a ridiculously compelling narrative, like you were playing an anime protagonist.

So if you are a creator in that first 80% of the process, and everything seems to suck and it feels hopeless, take heart! Chances are you haven’t reached the last mile where things come together, like magic.

Finish Strong

When a project is near completion, things are coming together rapidly. The bang-for-buck of putting in work at the end is very high, given that the groundwork has already been put in place. This is where many make the mistake of racing to the finish line: they quickly put the missing pieces together, fix as many issues as they can, and ship the project as soon as possible. But so much value is being added during this last 20%, it often pays big to take your time adding polish and final touches, and you may reap unexpected rewards.

Goldeneye 007 was a cultural phenomenon because of its multiplayer, giving it incredible replayability and contributed massively to its success. And yet, “…GoldenEye’s multiplayer mode almost never got made.” On account of the project being a year behind schedule, Nintendo forbid working on a multiplayer mode, but the dev team, who were given incredible autonomy, did so anyway, furiously hacking it together in just 6 weeks. The rest is history - Goldeneye 007’s multiplayer was so good it overshadowed the already great single player campaign, and the game became one of the top-selling N64 games, revolutionising console FPS games.

On the other hand, I worked on a jam game, Lasso Lassie, which turned out much less well than I had hoped. The process of making the game itself went extremely well. I spent a week researching music and made a pretty cool western-themed chiptune track. I had a clear vision for the game from the get-go, choosing to remake the criminally underrated early NES game Field Combat. I made a solid plan and budget for all the dev tasks, such as implementing the gameplay, enemy logic, spawning waves, and finished on time having implemented everything I planned for. And yet the game just wasn’t that fun.

In retrospect I believe I neglected to spend time fine tuning the gameplay. I had falsely assumed that since I was recreating an already fun game, all I had to do was tick all the checkboxes, put the game together, and it would just work. But things like game feel or “fun” can often be fickle and elusive. Sometimes the difference between a fun game and a boring one is a 20% difference in player speed, or slightly increased enemy density, or a clever level layout, who knows. You really have to sit down and play around with the game, tinker with it until it is just right.

So here’s the take-away: if you have a deadline, or are planning out the phases of your project, don’t keep adding features up to the end. Plan for a feature freeze, and leave ample time at the end for playtesting and polish. It will often pay off in spades. Personally, for jams I leave as much as a third of the time available for polish at the end, and it has worked out extremely well for me.

Finish Your Projects

This is very old and evergreen advice for amateur creators: stop starting new projects and finish more of them. The temptation to abandon your current project and start over is strong, especially when you are in the first 80%. All the sweet ideas you have for new projects will feel infinitely sexier than your current project, which sucks more than ever, even though when you started it it probably seemed like the coolest idea out of them all.

Well now that you know, that’s more reason to stop the foolish cycle of abandoning old projects, starting over, only to abandon them mid-way again. If you start over, the new project will become the next awful project and you are back where you started. But if you persevere with the current project, when you finally reach that last 20% things will be awesome. Not to mention all the benefits of finishing - having good projects to show off, proving that you can deliver, gaining crucial experience in those finishing steps.

This is why I strongly advocate doing game jams. The tight schedule encourages people to finish games, limitations like secret themes encourage creativity, and feedback from fellow creators helps us learn what it takes to make a successful game project. Finishing games in such a short time puts you through that first 80% quickly, making it easy to power through and reap the fruits of that last 20%.

Non-creators will suck at providing early feedback, and that’s OK

When working on our craft - often a lonely endeavour - it’s tempting to seek out approval for our work from friends and family, to share progress or something cool we just made. But the response is rarely positive or helpful, since this rough work is from that first 80% when everything is awful, but this has little to do with skill or artistry. If even creators have trouble seeing past the expected roughness of early work, how can we expect non-creators to do better?

In most cases we should accept that feedback from lay people is not that useful. But what if we really do want to share something, if we’re proud of something we’ve done, how do we help them see it in the same light? My advice is to show finished work. Show stuff that has already made it past the first 80%, and has been polished and put together. This doesn’t mean you have to put in lots of work before being able to show it off, it could be something small, but packaged well. This could be:

• An art study
• Music loops
• A small, completed gameplay prototype or demo

In fact, being good at sharing work, even to non-creators, is a great skill to have and hone. Getting good at creating and sharing little bits of finished work comes in really handy if you want to market your work, build a following, or put together a portfolio.

Getting better at judging early work

What if you’re working on a big project, going on for months (or years 😰), how do you judge how the project is going? The simple answer is to practice and gain experience. A master will be able to look at a piece of work, at any stage of progress, see past the whole and into the components that make it up, and judge the quality of craftsmanship. Drawing from their years of experience, they can tell whether the project shows promise, or if it is fundamentally flawed. But this answer isn’t useful for the rest of us. Is there anything we can do besides, without the benefit of being an expert? Here are my tips:

Make vertical slices, then iterate

A vertical slice is a usable, completed yet very small part of the project. If you’re making an action game, it could be having the player character run around and perform one interaction, with one win and one lose condition. If you’re making music, it could be one looping bar (say the chorus) with full instrumentation. If you’re making a video or animation, it could be one fully developed scene, with sound and special effects.

The point of doing this is to get all the components together as quickly as possible, to see how they work together. By front loading this, you get to that last 20% part sooner, and reap the benefits. Once this vertical slice is done, it’s easier to iteratively expand upon it, which can be done very flexibly, without compromising the feel or the vision of the project, since it’s already put together.

One of the worst game jams I’ve done failed because we didn’t do this. I was on a new and inexperienced team, who did not know how to work well together. We scoped out the project and assigned separate tasks to everybody - art, music, level design, gameplay - hoping that we can just put it all together at the end. Unfortunately this is where things failed miserably. Not only were there technical issues integrating everyone’s work, it turns out everyone had a different idea of what the game would be, so that the work we did separately did not fit together, and lots of adjustments and cutting had to be done. For example, our 3D artist made really awesome character models and animations, but because the gameplay wasn’t ready, almost all that work had to be left out of the game.

These days one of my mantras for game jams is to get a runnable prototype up as quick as possible - preferably in the first day. Get everyone working off this prototype, so they can independently add to it. Audio guys can add partial music and SFX in to get the mixing right. Gameplay designers can get the game feel right at the start, and add things like levels and enemies that fit with the game feel. Artists can gradually replace placeholder art and see how everything looks in game and not just in their concept art. This way even a large team can work towards a cohesive vision.

This example schedule for a 7-day jam from 7 Tips to 7-Day Game Jams gives similar advice: core game mechanics done at 1/3rd, feature complete at 2/3rd, and the last 1/3rd for testing and polish.

Finish More Projects

When you’re in the first 80%, good and bad projects will both seem awful. How can you get better at telling? By finishing more projects! Only by finishing will you get a complete retrospective on what went well and what didn’t, and you’ll get better at what makes or breaks a project. But if you abandon projects half-way, then there’s no way to be sure.

One example: things often go wrong during a project, but they are not always fatal. Sometimes they can be worked around at the end. How can you tell? By sticking with the project until the end, and trying to overcome earlier mistakes. Another example is that projects can often fail because of a feature kept in, rather than a feature left out. A troubled feature can suck up development resources and jeopardise the project itself, but you won’t know this unless you let the project take its course.

When making PepperTown, an RPG-style idle game where characters auto-battle enemies and you buy upgrades for them, I had no experience making idle games, so I wasn’t sure what features would be key vs nice-to-have. I thought that, being RPG themed, I would need at least some sort of interesting combat mechanics, such as magic spells, or at least different types of enemies, but it turns out that was unnecessary. The final game just has characters battling one type of enemy - a slime monster - and with basic attacks, bashing each other repeatedly. But what makes idle games such as this is the visceral sensations of hearing the hit sounds and the coins trickling in, and the satisfaction of waiting and buying upgrades and sensing them affect the game. Thus I learned more about a new genre of game and what makes it work.