Some recent online discussions have prompted me to write something short on the above ideas. The first discussion erupted when a Kotaku writer called George Kamitani a “14-year-old boy” for including hypersexualized women in the character line-up for Dragon’s Crown. The second discussion had to do with a video I did with Anthony Carboni and Doug Wilsson where we played Spelunky and talked about games a little bit in general. Perhaps “discussion” is too strong a word for a few YouTube comments about maturity and challenging games, but nonetheless, it made me want to develop and clarify my feelings on the topic further.
Every now and then someone will ask me for advice on making it as a professional indie game developer. First, it’s a huge honor to be asked that. So I want to say “Thank you!” Second… damn, if I really want to help out it’s a serious endeavor. Of course, I could always say “Give it your best! Work hard! Be true to yourself!” and it wouldn’t be a terrible reply… just not a terribly useful one, either.
So here it is. Here is what I’m going to link when that rare situation arises again, because it’s too much work to write it up more than once! This is advice that I feel may actually be practical to someone who is just starting out as an indie game developer. Hope it helps!
Note: This tutorial was created in 2007 for my personal website. Some small tweaks have been made since then, but nothing too significant.
In this 10-step tutorial, I’ll teach you how to create a “sprite”, which is a stand-alone two-dimensional character or object. The term comes from video games, of course.
Creating pixel art is a skill I picked up because I needed graphics for my games. After a lot of practice, I became kinda handy with it, and started to see it more as actual art rather than just a tool. These days, pixel art is quite popular in game development and illustration.
This pixel tutorial was created many years ago to teach people the basic concepts behind pixel art, but I’ve streamlined it a lot since its first incarnation. There are other pixel tutorials around, but I find them to be overly-complicated and too wordy. Pixel art is not a science. You should never have to calculate a vector when doing pixel art.
A half hour into Earthworm Jim on SNES, and three things became painfully clear to Andy (Hull) and me: 1. wow, Earthworm Jim is a worse game than we remembered, 2. Earthworm Jim was designed by visual artists with little experience in game design, and 3. modern studios haven’t learned from Earthworm Jim, because some of their games share a lot of its negative traits.
Ultimately, what we enjoyed about EWJ were its quirky characters, humor, and animation, which were unmatched at the time. But it’s because those elements came at such a premium that it pales in comparison to other run n’ guns and platformers of the era, like Contra or Mega Man. Though Jim and his cohorts are remembered fondly (and with good reason), it’s not likely to be a game we’ll come back to very often.
Polish is one of the foremost things on my mind right now (and I don’t mean the language!). This is a Good Thing(tm), because I couldn’t spend this much time thinking about it if we weren’t nearing the end of our game’s development. I know, I can hardly believe it myself!
From my experience, it’s the beginning and end stages of development where you see the greatest returns on investment. In the beginning, you’re laying down large swathes of code and you see the game progress very quickly. In the end, you’re making a lot of tiny adjustments that have profound effects because they ripple across the (hopefully well-laid) infrastructure that you’ve built your game on top of. Even something as simple as a beam of wood that the player can walk behind adds a lot to the way the game feels at this stage, whereas earlier in the development it might go unnoticed amid larger flaws. I love getting to this point, because I love putting little details into my work. In fact, the “Moss” part of my company’s name “Mossmouth” is an allusion to that concept of fine detail.
If you look closely at, say, any recent Mario game, you’ll really see how important polish is to the overall experience. It seems like everything in those games - from the menu buttons to the poofs of dust that appear when something lands on the ground - has a personality and reacts in a very fun way, with a wiggle or a cute sound effect. Likewise, the controls are very responsive and fine-tuned. As players, we may not spend too much time marveling at each of these little details, but nonetheless, we feel the impact and come to love these games in large part because of it. As developers, we should most definitely marvel at them, because it’s our business (and our passion).
The original Spelunky was in development for 2 years (on and off), and the version we’re working on right now has been in development for another 2 years. Throughout that span of time Spelunky’s design has flowed naturally, leaving us enough resources to learn the Xbox 360 and also work on refinements that will take us to that next level. With regards to polish, Microsoft has given us some great suggestions, and definitely deserve credit for their help. There’s a good lesson here: seek help and feedback and especially criticism from every direction if you hope to do your best work.
When Spelunky is finally released on XBLA (To Be Announced!), will we have succeeded in crafting something that feels as good as the amazing games we’ve been inspired by as children and as adults? That’s our goal, but I’ll leave it to you to decide how we did! In the mean time, we’ll keep on polishing until we think we’re there. It shouldn’t be too long now…
1. Any player can clear any obstacle simply by learning from mistakes and paying close attention.
2. The reasons for failure must always be clear and understandable.
3. Every problem must have multiple solutions, so that the player can tackle it in whichever way they want.
4. The game’s controls can never be a factor from which difficulty is derived.
5. There must be the possibility for miracles to happen - those magical moments that spread stories outside of the confines of the game world.
“So long as an obstacle passes those five criteria, we are happy that we have achieved the maximum level of difficulty, while retaining the necessary element of fairness.”
At this year’s Game Developers Conference, I gave a 30-minute talk with my friend Andy Hull about Spelunky and how it went from being a freeware PC game to the XBLA project that we’re both working on right now. Overall, I think the talk went quite well (whew)! You can find footage of the talk somewhere on GDC Vault, but unfortunately, you have to be a registered member of something or another to view it, so I provided the slides here, with some extra commentary.
As I work towards completing my own game, I’ve been thinking a lot about finishing projects in general. I’ve noticed that there are a lot of talented developers out there that have trouble finishing games. Truthfully, I’ve left a long trail of unfinished games in my wake… I think everyone has. Not every project is going to pan out, for whatever reason. But if you find yourself consistently backing out of game projects that have a lot of potential, it could be worth taking a step back and examining why this happens.
We’ve all had that feeling about at least one game, comic book, movie, etc., that comes out: “Gee, I could do better than this! This is overrated.” But it’s important to take a step back and realize that, hey, they put in the time to finish a project and I haven’t. That’s at least one thing they might be better than me at, and it’s probably why they have the recognition I don’t! If you treat finishing like a skill, rather than simply a step in the process, you can acknowledge not only that it’s something you can get better at, but also what habits and thought processes get in your way.
I don’t believe that there’s a right way to make games. It’s a creative endeavor, so there are no hard and fast rules that can’t be broken at some point. But as a game developer who has discussed this problem with other game developers, I feel like there are some mental traps that we all fall into at some point, especially when we’re starting out. Being aware of these traps is a great first step towards finishing something. (Between you and me, codifying these ideas is partly my way of staying on top of them, too!)
So without further ado, here is a list of 15 tips for finishing a game:
My first encounter with the work of Alejandro Jodorowsky was when I read The Metabarons, a comic book series that describes a lineage of superhuman warriors, the titular Metabarons. The book is lavishly illustrated by the Argentinian artist Juan Giminez, who, to his credit, manages to keep up with the maddening pace of Jodorowsky’s ideas as they escalate from weird to absolutely fucking insane within a matter of issues. This is one of my favorite comic books and a must-read for anyone who appreciates the artform.
Later, my friend and fellow independent game developer, Jonatan “cactus” Söderström, introduced me to El Topo and Holy Mountain, the two films for which Jodorowsky is probably best known, and cited them as inspirations for his mind-bending games. At this point I started to wonder what Jodorowsky thought of video games himself. Surely, someone with a mind toward the violent, the surreal, and the mystical would appreciate the possibilities of playing games.
A few interviews on the web revealed that Jodorowsky was, indeed, aware of video games and had some interest in them (apparently there was even the possibility of a Metabarons video game), but it wasn’t until I picked up the first trade paperback of The Technopriests that I realized how keenly aware he actually was. In fact, The Technopriests is very much directed toward the games industry, although in the comic it’s called the Technoguild, having been ported over to the unique sci-fi/fantasy world in which The Metabarons takes place.
(Note: the rest of this post contains spoilers.)
After the first few releases of Spelunky, there was one player who began nagging me constantly to make the game easier. “Derek, I hate your fuckin’ game,” he said. “Because it’s the first roguelike/platformer implementation I’ve ever seen, which is totally awesome. But from this game it seems you suck at difficulty.” I thought about it, but I really felt that the game’s challenge was one of the things that made it work. No challenge, no tension, no mastery… no fun. I tried to explain my thinking to this guy, but he wouldn’t have any of it. “Feeling cheated and insulted by a game is not fun, unless a person is brainwashed or mentally handicapped.”
I considered ignoring him, but I really did want him to enjoy the game. He was annoying but also very passionate, writing short novels describing how much bile was in his throat as he kept playing… and dying. I felt like he might have a good point about the difficulty level of Spelunky, but I couldn’t see how to fix it without diluting the things that made the game compelling.
Instead, I fixed bugs that other players were finding and released new versions of the game. Interestingly enough, I noticed that while The Angry Player(tm) was getting more and more angry, he was also making progress in Spelunky, getting to the later levels and eventually beating the game. This convinced me that the difficulty was not the problem in-and-of-itself, and that I was right to not include an easy mode in the game (since obviously it would have become an unnecessary crutch for players like him). This was a game that you could get better at, even if you weren’t a great video game player.
In the end, the various bug-fixes and improvements I made to the game’s controls DID make the game easier… but in a good way. So in some sense, The Angry Player was right: the game was too hard. But not for the reasons that he or I assumed.
What I got out of this experience was that player feedback is very valuable, but cannot always be taken at face value. I’ve come to think about it as almost a doctor/patient-type relationship: the player may approach you with symptoms (“My head hurts!” or “Your game’s too hard!”) and it’s up to you to figure out what the real problems are. Simply treating the outward symptoms may alleviate them temporarily, but won’t necessarily address the underlying, and more fundamental, problems. I call these types of solutions (e.g. adding an easy mode) “band-aids”.
Taking the doctor analogy further, it’s interesting to think about how doctors actually take care of patients: they ask the patients how they feel and try to eliminate potential illnesses. Eventually, they’re left with just one possible problem. In game development, there’s perhaps an inclination to want players to be more specific with their feedback, but like patients, players are often most in tune with how they feel about the problem rather than the problem itself. With The Angry Player, I probably should have asked him more questions to zero in on what was wrong, rather than spending so much time trying to convince him why I was right.
One of the many things I heard this year at GDC that stuck with me goes something like “design your game for hardcore players first, then make it accessible for casual players.” I’m probably butchering it a little bit - I heard it from my friend Mark Johns, who attributes it to Blizzard. Who knows? Maybe the original saying was “Anchovies are the best pizza topping.”
In any case, I like it. The implication, to me, is that if you start with a shallow game you’ll end up with a shallow game, no matter how many doodads you stick onto it. Instead, start with something deep, complex, and satisfying, and then polish it up. Makes sense.
It also answers simply the question that is on every game designer’s mind: “who should I be designing for?” Other than “myself”, the answer is not “hardcore” or “casual” (or the nebulous “core”), but “hardcore first, then casual”.
Defining hardcore: to me, these are the players who will enjoy your game at its deepest level, who will discover things about your game that you never knew existed, and who will champion your game and give it life for years to come. They’re also the players who might turn off casual players by calling them “scrubs”, or telling them that they just aren’t good enough… or that they “don’t get it”. But I think the benefits of having a hardcore fanbase far outweigh the consequences, and for every asshole who wants to shut new players out you’ll have a knight who wants to spread their infectious enthusiasm for your game far and wide. (See: the Street Fighter and Dwarf Fortress communities)
As a game creator, I like the idea of converting casual players to the cause, rather than conceding things to them, or “dumbing down” my game for them. I’ll enjoy the game more, they’ll enjoy the game more… everyone will enjoy the game more. In game design as in anything else, I believe that win-win situations do exist and we should be seeking them out. This idea - ”design your game for hardcore players first, then make it accessible for casual players” - seems to me like the best way to approach a win-win situation.