Opinion: Starting a new game project? Ask the hard questions first
In this reprinted #altdevblogaday opinion piece, Mylodon producer Raul Aliaga Diaz discusses why and how game developers should ask themselves the right tough questions before starting a new project.
We have all been there. You want to start a new game project, and possibly have been dreaming of the possibilities for a long time, crafting stories, drawing sketches, imagining the dazzling effects on that particular epic moment of the game… then you start to talk to some friends about it, they give you feedback, and even might join you in the crazy journey of actually doing something about it.
Fast forward some weeks or months, and you've been pulling too many all-nighters, having lots of junk food and heated discussions. You might even have a playable prototype, several character models, animations, a carefully crafted storyline, a website with a logo and everything but… it just doesn't feel right.
It's not coming together and everyone involved with the project is afraid to say something. What happened? What went wrong? How did such an awesome idea become this huge mess?
Usually all game projects emerge from a simple statement that quickly pushes the mind to imagine the possibilities. Depending on your particular tastes, background, and peers, these statements can be like: "Ace Attorney
, but solving medical cases, like House M.D.!" (Ace House™), "Wario meets Braid
!" (Wraid™), "Starcraft
but casual, on a phone!" (Casualcraft™). These ideas can be just fine as starting points, but somewhere down the line the hardest question is: Is this game something worth doing?
When you work at a game studio and a new idea arises, that's the first question it faces. And depending on the studio's strengths, business strategy, and past experiences, the definition of "worth" is very, very specific. It usually involves a quick set of constraints such as: time, budget, platforms, audience, team, among others.
So for a particular studio that has developed hidden object games and has done work for hire creating art, characters and stories for several other games, an idea like Ace House™ can be a very good fit, something they can quickly prototype and pitch to a publisher with convincing arguments to move it forward.
However, in the case of a studio focused solely on casual puzzle games that has just one multi-purposed artist/designer and two programmers, it can be rather unfeasible, much more if all but one says: "What's Ace Attorney
? What's House M.D.?"
Okay, you might say, "But I'm doing this on my own, so I can fly as free as I want!" That's not entirely true. If you want to gather a team behind an idea, all of the team members must agree that the project is worth doing, and even if you do it on your own, you must answer the question to yourself.
Having less limitations can positively set you free, but take that freedom to find out your personal definition of worth, not to waste months on something that goes nowhere
. Unless you can, like, literally burn money.
Joker Game Studios
"Why is the project worth doing?
" is the hardest question, and the one that must be answered with the most sincere honesty by everyone involved. The tricky part is that it is widely different for many people working on a game project out of their regular job or studies.
It can be to start learning about game development, to improve a particular set of skills, to start an indie game studio, to beef up a portfolio, etc. It is okay to have different goals, but they all must map to a mutually agreed level of time commitment, priorities, and vision. But even if you figured this out, there are still other issues.
All creative projects can be formulated as a set of risks or uncertainties, and the problem with video game development -- given its highly multidisciplinary nature -- is that is very easy missing to tackle the key uncertainties, and start working on the "easy" parts instead.
So for example, for the Ace House™ project, it can be lots of fun to start imagining characters and doctors, nurses, patients and whatnot; there's plenty of TV series about medical drama to draw inspiration from, and almost surely you can have a good time developing these characters, writing about them, or doing concept art of medical staff in the Ace Attorney
style, but what about the game?
How do you precisely translate the mechanics from Ace Attorney
to a medical drama? How is this different from a mere re-skin project? Which mechanics can be taken away? What mechanic can be unique given a medical setting? How can you ensure that Capcom won't sue you? Are there any medic-like games already? How can we blend them? Is it possible? Is this fun at all? Is "fun" a reasonable expectation or should the experience be designed differently?
Let's talk about Wraid™ now. If Konami pulled off Parodius
doing a parody from Gradius
, "how cool would it be to do a parody of Braid
using the characters from the WarioWare
franchise?" Here you have a starting point for lots of laughs remembering playing Braid
, and putting Wario, Mona
, Jimmy T., and the rest of the characters in the game, wacky backgrounds, special effects, and everything.
But: Is this reasonable? Let's start with the fact that Konami owns the IP of Gradius
so they can do whatever they want to it. Can you get away with making a parody of both Nintendo and Jonathan Blow's IPs? Sure, sure, the possibilities can be awesome but let's face it: It is not going to happen.
What can be a valuable spin-off though? What if WarioWare
games have a time-manipulation mechanic? What if you take Wario's minigames and shape them around an art style and setting akin to Braid
? (Professor Layton
? Anyone?) How can you take the "parody" concept to the next level and just make "references" to lots of IPs, but the game is something completely new in itself?
What about Casualcraft™? Starcraft
can be said to have roughly two levels of enjoyment: as an e-sport, and whatever other pleasure the other people draw from it. If we want to make it casual, it should not be an e-sport, should it?
If you're a Starcraft
fan and have experience doing stuff for smartphones, you might think "This should be easy, I can make a prototype quickly." And given that a mouse interface can be reasonably translated to touch, you start coding, and get a lot of fun implementing gameplay features that pumps all your OOP knowledge and creative juices to the roof.
But… what does exactly mean "Casual Starcraft
?" How can a strategy game be casual? What is the specific thing different from the e-sport experience that we want to bring to a phone? Is it the graphics? Is it the unit building-leveling? Is it playing with other friends? Which one of those should we aim for? Can it still be an RTS? What about asynchronous gameplay? Can this be played without a keyboard? Can it still be fast? Would it fit on a phone? People that play on a phone: would they play this game?
So, all these are tricky and uncomfortable questions, but they are meant to identify the sources of risk and figure out a way to address them
. Maybe the ideas I presented here are plain bad, sure, but they are only for illustrational purposes. Since I started working in games, I've seen countless ideas from enthusiasts that are not really too far away from these examples anyway. The usual patterns I've seen are:
Not identifying the core valuable innovation, and failing to simplify the rest:
It is hard to innovate, much harder to do several innovations at once. Also, people have trouble learning about your game having too many simultaneous innovations and can quickly get lost, rendering your game as something they simply "don't get."
The key is to identify what's the core innovation or value of your idea, the one single thing that if done right, can make your game shine, and then adjust all the rest to known formulas. And by "key" innovation, I mean something important, critical, not stuff like "I won't use hearts as a health meter but rainbows!" That can be cute, but it's not necessarily a "key innovation."
Putting known techniques and tools over the idea's requirements:
"I only do 3D modeling so it has to be 3D," "I know how to use Unity so it has to be done in Unity," "I only know RPG Maker so let's make an RPG." It is perfectly okay to stick to what you feel comfortable doing, but then choose a different idea.
A game that's way too heavy on 3D might be awesome but completely out of scope for a side project. Unity can be a great engine, but if all the other team members can work together in Flash on a game that it will live primarily on the web, it can't hurt to learn Flash.
RPG Maker is a great piece of software, but if you can't really add new mechanics and will concentrate only in creating a story, why not just develop a story then? A comic book project is much more suitable. Why play your particular game when everyone that is into RPGs surely has at least two awesome ones that they still can't find the time to play? Instead of crippling down the value or feasibility of your idea to your skills and resources, change the idea to something that fits.
Obsessing over a particular area of the game (tech, story, etc):
This usually happens when the true reason to do the project is to learn. You're learning how to code graphic effects, or how to effectively use design patterns to code gameplay, a new texturing technique, vehicle and machines modeling, a story communicated through all game assets and no words, etc. You can get huge experience and knowledge doing this. But then it's not a game meant to be shipped, it is a learning project, or an excuse to fulfill something you feel passionate about.
Failing to define constraints:
The romantic idea of developing a game until "it feels right." If Blizzard or Valve can do it, why can't you? Well, because at some point, you'll want to see something done and not feel that your time has gone to waste. The dirty little secret is that constraints almost all the time induce creativity instead of hinder it. So choose a set of constraints to start with, at least a time frame and something you would like to see done at particular milestones: key concept, prototype, expanded prototype, game.
Refusing to change the idea:
This is usually a sign of failing to realize sunken costs. "I've spent so much time on this idea, I must continue until I'm done!" The ugly truth is that if you're having serious doubts, those will still be there and will make you feel miserable until you address them, and the sooner you act, the better. It can be that all the time you spent is effectively not wasted, but only when you frame it as your learning source to do the right things.
So, if you're starting a new game project, or are in the middle of one, try asking the tough questions: Do you know why is worth doing? Do all people involved agree on that? Are you making satisfying progress?
Are you sure there isn't a question about your project you are afraid to ask because you fear that it can render your idea unfeasible, invaluable or messy?
Don't be frightened, go ahead. If it goes wrong, you will learn, you will improve, and the next idea will get to be shaped much better.
[This piece was reprinted from #AltDevBlogADay, a shared blog initiative started by @mike_acton devoted to giving game developers of all disciplines a place to motivate each other to write regularly about their personal game development passions.]