Writing Games Part 4: Making 'Em
In a previous post I talked a little bit about what it takes to get into the industry.
This post basically dispels the notion that what it takes to get into the industry has almost any bearing on what it takes to make great games.
Existence proof: most of the really great game developers made really good first games with no experience. The mod scene is full of people that make fantastic mods using nothing but their imagination. And a lot of really, really bad games are made by experienced developers and teams.
This gives aspiring game developers a little bit of hope to offset the pessimistic outlook that results from realizing you may not have the tangible background to get your foot in the industry -- know this, if you're good, you can make good games, even if your resume doesn't "prove it". Getting your foot in the door and making a difference are two very different things.
Okay, preface established.
Much of what I'm going to post is pretty much 100% opinion, and I'm sure the other developers here will have different takes on it. My points of view are colored from having worked at a small successful development studio; a big successful corporate game company; and from going it on my own.
Note: I'm explicitly ignoring the idea of "what it takes to be a good team member". That is, for the most part, obvious. Express your opinions, be nice, do a good job, stay focused, communicate well, etc. etc. If you have those skills, you can slot right in to a big company working on a game. However, your own individual strengths may get subsumed by the project as a whole. Whether that bugs you or not is a personal call.
Tangent: People with strong egos can swallow 'em for a while, but at some point they need to call the shots if, for no other reason, to prove that they're right. Which I actually think is much better than someone taking no risks at all but is yelling that everyone else is wrong.
So I'm going to concentrate on "What skills do you need to create a game successfully when you're the driving force?" This may mean that you're making a mod with some friends, or that you're a project lead -- the concepts are the same.
1. Vision
The ability to know, in your mind's eye, very clearly, what you are trying
to build. Not some vapid design spec or empty mission statement, but an
actual, concrete understanding in your head of the type of game you're
making, how it's going to be made, who your target audience is, etc.
Without this clear vision of what you're trying to do, everything else is destined to fail. You can't build something if you don't know what you're building.
Surprisingly enough, many projects lack true vision. There is an aimless, meandering quality to them, because the general specification has been laid down by management as "make a game like this other game, but better". There's no one on the team that is passionate about it, or maybe they just don't quite understand what they're really trying to do, both at a nuts and bolts level and at a higher level. This is why so many knock offs and sequels just plain suck.
One of the reasons I deferred starting my own game company -- even though I knew I wanted to do this since I was in my teens -- is because in my heart of hearts I knew I lacked vision. I knew I didn't really understand what I wanted to do other than "make games". I didn't have a clear, concise picture in my head of what kinds of games or how I'd make them. Now that I do, I'm doing my own thing.
2. Prioritization
Know what parts of the project are contingent upon other parts, and work
in order of priority. There's this very, very vague skill of "knowing
what's important" -- it can't be taught, but it can be learned. But
a lot of it is just innate.
I've seen teams stall for a weak because they can't decide if some creature should be red or brown; or if a certain sword should be called one thing or something else. In each of these cases, the leads should have just put a stop to it by saying "For now, we're doing this, unless someone comes up with a real compelling reason to do something else".
(Slight aside: very often team members will say "I don't like this" but they don't offer any viable alternatives. It's important dissenters to realize that the onus is on them to provide alternatives, not to just bitch. I say this as someone that used to bitch a lot but would then just shrug when asked for a better idea =) )
3. Keep it moving forward
I've seen lots of projects stall because some "insurmountable"
problem is presented early on, and because no one has an idea of
how to solve it, everything halts until a solution is presented.
This is a tricky, nasty area, one where leadership and team cohesion
is often tested to its limits. Problems of this nature ARE problems,
but at the same time, not all problems have immediate solutions.
You don't want to ignore a problem, but by the same token, you can't
let every tough problem halt development indefinitely.
In situations like this, you have to be willing to accept that the problem exists, that no obvious and natural solution has presented itself, and that you need to continue development regardless. The latter point is important, because some will (rightfully) argue that any further development may have to be redone once a proper solution is discovered. But, at the same time, in many (if not all) cases, I've found that the solution often comes about as a RESULT of continuing development. Sometimes the problem just goes away (feature removed, another feature cancels it out, etc.). Other times, the solution just appears as an epiphany to someone.
If you stop development every time a problem shows up that no one has a no-brainer answer to, the project will never be completed. And really, if it was that easy, everyone would be doing it =)
4. Problem solving
I hesitate to even use this, since it's so fundamental to many things,
but it's still one of the most important skills you can develop. During
the course of a project's development there will inevitably be several
key points when things don't "feel right". The game doesn't
feel right, the development is slow and arduous, the team seems kind of
tense, whatever. Being able to stand back and identify what is causing
these issues and then getting it solved is incredibly important. I've
seen too many teams that solve this type of problem by either senseless
arguing or denial, neither of which work in the long run.
There are, of course, tons of other attributes that are useful and important, such as communication, focus, hard work, ethics, etc. but I tend to consider these universal, not specific to game development.
5. Know when it's good enough, then ship it
There are many reasons to delay shipping a product, and if you pay attention
to all those reasons, you'll NEVER ship. From day one the goal of a team
should be to have final bits that they can burn or post to the Web so
that players can enjoy the fruits of their success. When the development
becomes the ends unto itself, then things fall apart. I think this subconsciously
happens, especially at companies that have very good funding -- they feel
no pressure to deliver a new product, and they're terrified of providing
something that doesn't meet expectations, so they just take forever. I'm
sure some of us here can think of products that were announced 5 or even
6 years ago that have yet to ship.
I know I've said this before, but I'll keep saying it until I'm blue in the face: In the end, you have to realize that no product is perfect, and that you just have to pick and choose those features that are important to making a very good product, and then ship it. Without this state of mind, a product will drift along forever on the Seas of Potential until its the Reef of Reality.
Whew, okay, that's it for my impromptu series. Next week I actually have to get back to working on stuff instead of talking about stuff =)
-Hook
