The Rise and Fall of a Game, Pt. 2
August 3rd, 2011
So now that I’ve covered some of the key problems I see with Swordfall, I’ll just take a moment and cover some of the hard-won lessons I’ve gained in the process.
Lesson 1: Don’t Make Games For Yourself
Now, I’ve definitely heard this one several times before, and I always thought it a rather stupid rule. I mean, if you love to make games, obviously you’ll want to make something that lines up with your interests. And yes, I absolutely agree that you should. You’re likely to do much better work if you deeply care about what you’re making. But here’s the kicker: don’t imagine you’ll actually end up playing the thing in the end. Whatever connection you have to the game’s idea, art or mechanics gets pretty thoroughly explored during development, especially if you’re working solo. By the time you’re ready to launch, you’ll know every nut and bolt so well that the very idea of playing it fills you with absolute boredom, or perhaps even loathing. The only exception, I think, might be a highly procedural game, like Minecraft or Civilization, where generative algorithms can still throw surprises at you on the umpteenth playthrough.
So what exactly is the harm in making games for yourself? Well, for one thing it’s terribly difficult making a living out of an audience of one. Or ten. Or a hundred, or however many people there might be out there who happen to be just like you. Early playtesting can help here, especially if you can get a variety of people to sit down in front of the game. Preferably people who aren’t afraid of hurting your feelings. Also, don’t rely on enthusiastic fans as an accurate representation of the audience. Fans that actually go to the trouble of contacting you are only the tiniest sliver of a minority among the potential player base. And if you make a game just for them, you’ll once again end up with an awfully small audience. To be fair, this may work with some types of games. If you’re involved in crafting an intricately detailed simulation of medieval banking, you know you’ll have a small audience to begin with, so you’ll need a hefty price tag that only the most enthusiastic fans will swallow. But small audiences don’t really work in the flash world. This market is all about quantity. If you want to make serious money in flash, you need to reach millions of people and put out games at a brisk pace. Which, of course, nicely segues into my next point…
Lesson 2: Don’t Make Five Month Games
The simple fact is that flash games tend not to make much money. Most of them make next to nothing, the decent ones make a grand, the good ones make $5000, and the truly exceptional ones might reach $25,000. And then, of course, you have Fantastic Contraption, which made over a million. But Fantastic Contraption doesn’t really count; even though it was made in flash, it really is more of a traditional pay-to-play indie game. That is naturally a much stronger market for those games that can attract a dedicated paying audience, but it’s not an easy place to break into.
As far as the flash sponsorship & ad market goes, 25-30 grand is pretty much the best you can hope for. And that kind of money only goes to the absolute cream of the crop. Unless you’re making a sequel to a highly popular game, you really have no right to expect anything like it. No matter how brilliant your idea might be or how gorgeous your graphics, it’s still incredibly difficult to predict whether your game is worth 3,000 or 20,000. Naturally, a fair bit of the equation depends on your reputation, how well your vision aligns with the tastes of high-budget sponsors, and on whether you have established sponsor relationships. And regardless of your business skills, the audience itself is a fickle beast, out looking for a quick bit of fun amidst an endless torrent of content. In that choked up jungle some straightforward production quality will raise you above the the herd, but the thing that takes you from good to great isn’t always so obvious. The point of it all is this: hedge your bets. Don’t sink all your time into an elaborate tree that may not bear sufficient fruit. Spending five months on a game and expecting to make a living means all the stars need to align perfectly. Even if you manage to pull off that trick once, can you really make a consistent show of it? Oftentimes, popular games come about through dumb luck more so than brilliance. Novelty is a big part of this business, and the Next Big Thing can land in your head almost by accident, never to be repeated again. Case in point: Alexey Pajitnov, the developer of Tetris, has now worked some fifteen years in the US games industry without coming up with another breakthrough hit. Chances are that Tetris will be all he’s ultimately remembered for.
So, the secret ingredient in the flash sauce is to find a happy medium. One to two months is about ideal in my book, perhaps going down to as little as two weeks if you’re working with a fair number of existing assets. If you’re incredibly brave or don’t need sleep, you might try out a one week game, as long as you don’t make a habit of it. It may just work for something with a very simple core concept that’s playable after a day’s worth of coding. But you need a strong sense of fun and novelty to back it up; at least something that’s likely to fetch a couple grand for your efforts. You will not be able to live on $1000 games, at least not in the developed world. Trying to make fifty games a year that anyone will actually notice is a fool’s errand.
Lesson 3: Depth is Overrated
Sure, most of us like a bit of depth to our games. Variety in level design, different kinds of enemies, lots of meaningful choices, and perhaps a large serving of elaborate upgrade trees. Ultimately, what exactly is depth? It can be a few different things, really. Lots of novel things to discover, plenty of variety in gameplay, and perhaps most importantly a sense of gaining mastery of a difficult but rewarding set of skills. Depth is generally bought at the cost of complexity, an especially important point to keep in mind when developing strategy games or RPGs. You want a system complex enough to support a range of meaningful choices, sufficient variety and a multi-pronged sense of progress. You’ve got to have your leveling, quest completion and your gear drops. You’ll also want some strategic building construction, marching armies and advancing technologies.
At the same time any system you build has to be easy to learn and make some kind of intuitive sense. So using what your players already know, both from other games and the real world, will make your rules much easier to swallow. Naturally, it goes down much easier still if you lead people in gently, taking care to point out all the individual actions that make up the basics of your game. A few might be frustrated enough by this hand-holding to seek fun elsewhere, but that’s a small price to pay.
If you happen to be a new developer and a fan of AAA strategy/RPG games, you might want to scale back on your initial plans for scope and complexity, perhaps by an order of magnitude at least. No flash indie team can go head-to-head with the big boys, and there really isn’t much of a middle ground in this industry anymore. There are small games and big games, but very little in between. Small teams make casual games, and casual games are a very different beast from the giants of the industry. Your players will not have spent months or years reading through all the hype generated by your marketing department. They will not have invested a day’s paycheck in order to play it. They will come in as blank slates, attracted by little more than pretty colors, googly eyes and a catchy title. The moment they encounter frustration or confusion is the moment they’ll go find pretty colors elsewhere.
Angry Birds. Plants vs Zombies. Fruit Ninja. Cut the Rope. These wild success stories did not come about because there’s a lot of meat on the bones. They happened through a touch of novelty, cute characters, a good deal of polish, and a title that instantly reveals the game’s entire premise. In this arena, a pretty surface is worth more than all the deep dark depths in the world. The trick here is to have a strong core, both mechanically and thematically, one that’s easy to both build and communicate. For a month-long project the mechanics should take less than a week to implement. The rest is all polish and testing, with some extra polish on top.
Lesson 4: The Last 10% Will Take Half Your Time
Put another way, you’ll first make 90% of your game, and then still have the other 90% to look forward to. To be fair, I haven’t found this to be true with all my games. With some simple projects and reusable code assets, I have managed to come in at just slightly over schedule. But with anything a little more complex, perhaps something with a synopsis that doesn’t quite seem to fit into a single sentence, all bets are out the window. Two months can just as easily turn into five. There are just too many features and interacting systems to really grasp all the little knobs and widgets you’ll have to make. And the more complex your creation becomes, the more potential there is for things to break, more hidden corners for game-killing bugs to hide. On a five month project the last two may be spent making sure everything still works. You will play your game a lot, you will have to tweak, adjust, fix, and rejigger every little thing. Approximately once every hour you will curse yourself for being an idiot. You’ll remove the evidence of your idiocy, and then compile the game yet again. And again. And then again. So make small games, people. Spend more time with ideas, less time with bugs. Both you and the bugs will be much happier in the end.
And now I believe it’s time to head out to today’s life drawing session, over at the local university. I’ll reveal more about my future plans soon.
– Peace and fair winds
Posted in Current Games | Comments Off on The Rise and Fall of a Game, Pt. 2