There are an awful lot of games out there that are… not very good, to put it politely.
Why is that?
The Concept of Concept
Perhaps it’s just that the games were really strange ideas? I mean, there are some pretty wacked ideas out there. There’s this one game where you’re rolling a ball around the place, and stuff sticks to it, and you have to make the ball bigger and bigger… oh, you own that one? OK, then how about… this game where you’re a plumber, and little mushrooms and turtles are attacking you so you have to jump on them, and you explore castles and deserts and stuff, and rescue a princess or something… what? One of the biggest and most successful game franchises in history? Hmm.
People actually bought this.
Maybe weird isn’t a bad thing then. Maybe it’s the less weird, more realistic games that fail? Oh yeah, I heard about this one game that is basically just a ‘ordinary guy’ simulator. You have a little guy, and you make him go to work, and fall in love, and do housework, and all that stuff. Who’d want to play that? I mean, I do enough of those things in real life. What do you mean, it’s the highest-grossing game franchise in PC gaming history? Man, these consumers. They’ll buy anything, huh?
Game ideas can be as strange as you like, or can be so based in real life as to be a simulation of it. They can succeed either way. So, if it’s not because of the concept, why do some game projects fail?
Delta Concept Over Delta Time
I propose that you can start a game project with pretty much any concept, and end up with a hit. It’s not the concept that matters. It’s the process. The right process will take any concept and turn it into a hit – will ‘polish a turd,’ as they put it. It takes time – perhaps more than you have – and the worse your initial concept is then the more time it will take, but you can always get there in the end. The wrong process will founder and flail and flounder and fail.
Everybody knows what bits of this process looks like:
-
It’s agile, and it’s agile for everybody, not just for programmers.
Agile is usually pitched as a programming methodology, and it’s buzzwordy, but all it really means is “able to respond quickly to changes that are needed.” That’s an approach that applies to all parts of development.
This cat is prepared to respond quickly to changes that are needed. Are you?
I’m not sure that there’s much discussion of agile development outside of programming, at least by that name, but I imagine that many people have discovered things about it. For example: on my project, each character animation file has a full copy of the character’s geometry and rig. This makes changes to the geometry and rig quite painful, because each animation file needs to be updated so that things don’t get out of sync. I’ve been considering trying to find an alternative approach that uses Containers or XRef Objects to share one copy of the geometry and rig across all the animation files, making it much easier to respond to changes in the base skin – much more agile. Have any readers tried this?
(If you’ve got other tips on how to be agile in parts of the project beyond programming, share them in the comments!)
-
It doesn’t get attached to anything.
This is almost a repetition of the previous point – being attached to things makes you less agile – but it bears repeating because people often underestimate the emotional impact of change. The artists spent two months working on a particular setting, and now you’re starting to think that the game would be better off without it – how do you think they will take that?
You have to be prepared to “shoot your baby in the crib,” as they say.
Don’t fall for the Sunk Cost Fallacy. Whether it’s a particularly clever bit of code, a particularly beautiful piece of artwork, or a particularly intriguing design concept – it may not be appropriate for the game. And that, at the end of the day, is what matters: that the game is a coherent, balanced, self-consistent whole, not just a collection of beautiful but ill-fitting parts.
If you have to tell someone that their work is going to be cut, it can help if you can help them understand why it’s being cut. The better you can communicate your vision for how things should be, the easier it will be for them to agree with you. Of course, they might disagree that your vision is better, in which case you should listen carefully – they might be right, after all.
Also, never throw beautiful things away entirely: maybe they’re not right for this project, but if you shelve them for now, they might come in very handy on the next project. It’s senseless to simply destroy work that you’ve already paid to develop, and the idea that the work is being shelved for future use, instead of being wasted time, can make it a lot easier on the creator.
-
It actively looks for criticism.
Everyone agrees that QA and play-testing is useful, but most projects do it infrequently, or put it off until really late in the project. Why? I think there are two major factors:
The first is that the importance of criticism isn’t well understood. “The focus is on getting the game right – we can worry about the ways in which it’s wrong after we’ve done that.” But is it really always that easy to identify what’s right? A lot of the time, it’s fine, but every project I’ve worked on has seen disagreements within the development team about how particular things should be done – from the use of set-pieces, to the way a particular explosion effect should look. Lots of predictions are made, and lots of options are presented, with a fair case being made for each one. If, rather than worrying about getting things right, you focus on not getting them wrong, then you will still approach the best option, but you won’t spend any time agonizing over what that option is when really any of them would be perfectly valid.
The second is that people are afraid of criticism because it means they might need to change the way things are going. And this, of course, is extremely silly. If you don’t test to find problems, the problems won’t just go away! It’s better to know about a problem – to know about a criticism – and then choose not to act on it, than it is to not know.
Not an effective problem-solving strategy.
-
Embrace what makes your idea different – and, conversely, don’t put too much effort into trying to beat other games at things that aren’t central to what you’re doing. If what makes your game different is its innovative approach to strategy and macro-management, then it’s fine that you display health bars in the same way as every other game. Nobody buys an RTS game because “it has a particularly innovative approach to displaying health bars.”
Games, while young, have developed a lot of traditions, and those traditions represent the progressive refinement of an idea over multiple iterations. There are ideas that are cliche, sure, but they’re cliche because they were used in many games, and they were used in many games because they worked in many games. If you want to change one of these traditions, you should make sure you understand how your change will improve it; being different just for the sake of being different, without understanding how you’re making things better, makes it very likely that you’ll be making things worse.
The End Boss
There’s one colossal obstacle to all this. The experienced developers amongst you probably already know what it is. It’s the commercial realities of a project – the iron grip of the publisher.
The publisher, all too often, will not understand if you want to spend time and money making your project more agile. They do fall for the sunk cost fallacy, and will actively thwart your attempts to change the direction of the project if it’s too far away from their original plan, regardless of whether the direction is better. They will not fund testing and QA at the times that you need it, because the idea that testing and QA should be a continuous process is a comparatively new – and expensive – idea.
And worst of all, they will put all the emphasis on the original concept. Regardless of your team’s ability to take a concept and make it great, they won’t trust that. They’ll insist that you get the concept right on day one, so they can hold you to it. And when you don’t quite get the concept right on day one – because nobody’s perfect – they’ll keep insisting that you polish it and polish it, regardless how much of a turd it is.
The first publisher to understand that the success of a project depends not on where you start, but on how quickly and effectively you can improve, will produce a lot of hit games, and make a lot of money.
The real key to polishing a turd is being given the freedom to throw the turd away if you need to.