First timer
by Vitreous Humor · in Game Design and Creative Issues · 05/19/2004 (7:45 pm) · 4 replies
I'm a first timer trying to get credit for making a video game. As such, and to get credit, I have taken the job of producer or director or whatever. Basically, I'm doing the basic design for everything. Anybody have any secrets or suggestions on how to get these things started?
#2
Get over your illusions about being some poor, misunderstood artiste... you are creating entertainment, buddy, and if you ain't entertaining, you've failed. Yes, your entertainment can be thought provoking, profound, perhaps even disturbing... but on some level the game has to speak to the player (there's that communication again) on a level that makes them want to play your game instead of doing something else with their precious time.
You need to listen carefully to your team, your testers, and your customers as the game evolves. They'll make an impossible number of suggestions for how you need to improve the game during development. Your job is to be a filter and interpreter for these ideas. Sometimes they are going to make a ton of suggestions ranging from everything from the controls, the sound, the AI, and the framerate. You filter through all these different complaints & suggestions to arrive at the HEART of the matter... they are all REALLY having problems with the control scheme coupled with the camera. But not everybody can put their finger on it. This is an acquired skill of a game designer --- getting past what people are saying to express a problem that they don't fully understand themselves, but which is really bugging them. You'll know you were right when you fix the underlying cause and all the other 'symptoms' - themselves left untreated - all go away.
You need to realize that your 'magnum opus' - your game design document - is not only a 'living document' that needs constant updating, but it's really just a 'paper protype.' It's a vehicle for communicating what the game will be to everyone involved with it... it is NOT the game itself, it is NOT the Bible, nor should it be treated as such. One of the biggest problems I see in the industry is a design document turned into some collossal 500+ page tome that is trying too hard to be exact specifications. There are two problems with this:
1) Nobody's gonna read it. Not REALLY. They may read OVER it, trying hard to note all details pertaining to their task. But you've presented such a huge project at such a fine level of detail that it's going to be hard for people to comprehend it. So they'll ignore it.
2) You can't design fun on paper. Sure you can describe it, describe what you THINK might be fun... but it's not specs. Things can, will, and SHOULD change. Get over it. I heard a best-selling author explain the secret to good writing once... he said (and others on the panel agreed) it's editing, editing, editing, and being willing to 'kill your babies,' meaning cutting out some of your own favorite parts... perhaps even what you once considered the central /pivotal scene of the entire story or a character... for the good of the final story. It evolves. It MUST evolve. So don't write your design doc expecting it to be set in stone. Keep it light, agile, and ready to run with changes.
3) You need to allow for the other guys to have some creative freedom as well. Often times, the best bits of the game are going to come from a level designer who dreams up something wild, wonderful, and unique one caffeine-laden session, or a programmer who suddenly figures out how to make the impossible possible. You need to support and encourage this - and make sure your design doc stays light and flexible enough to do so.
(Continued)
05/20/2004 (10:26 am)
(Part II)Get over your illusions about being some poor, misunderstood artiste... you are creating entertainment, buddy, and if you ain't entertaining, you've failed. Yes, your entertainment can be thought provoking, profound, perhaps even disturbing... but on some level the game has to speak to the player (there's that communication again) on a level that makes them want to play your game instead of doing something else with their precious time.
You need to listen carefully to your team, your testers, and your customers as the game evolves. They'll make an impossible number of suggestions for how you need to improve the game during development. Your job is to be a filter and interpreter for these ideas. Sometimes they are going to make a ton of suggestions ranging from everything from the controls, the sound, the AI, and the framerate. You filter through all these different complaints & suggestions to arrive at the HEART of the matter... they are all REALLY having problems with the control scheme coupled with the camera. But not everybody can put their finger on it. This is an acquired skill of a game designer --- getting past what people are saying to express a problem that they don't fully understand themselves, but which is really bugging them. You'll know you were right when you fix the underlying cause and all the other 'symptoms' - themselves left untreated - all go away.
You need to realize that your 'magnum opus' - your game design document - is not only a 'living document' that needs constant updating, but it's really just a 'paper protype.' It's a vehicle for communicating what the game will be to everyone involved with it... it is NOT the game itself, it is NOT the Bible, nor should it be treated as such. One of the biggest problems I see in the industry is a design document turned into some collossal 500+ page tome that is trying too hard to be exact specifications. There are two problems with this:
1) Nobody's gonna read it. Not REALLY. They may read OVER it, trying hard to note all details pertaining to their task. But you've presented such a huge project at such a fine level of detail that it's going to be hard for people to comprehend it. So they'll ignore it.
2) You can't design fun on paper. Sure you can describe it, describe what you THINK might be fun... but it's not specs. Things can, will, and SHOULD change. Get over it. I heard a best-selling author explain the secret to good writing once... he said (and others on the panel agreed) it's editing, editing, editing, and being willing to 'kill your babies,' meaning cutting out some of your own favorite parts... perhaps even what you once considered the central /pivotal scene of the entire story or a character... for the good of the final story. It evolves. It MUST evolve. So don't write your design doc expecting it to be set in stone. Keep it light, agile, and ready to run with changes.
3) You need to allow for the other guys to have some creative freedom as well. Often times, the best bits of the game are going to come from a level designer who dreams up something wild, wonderful, and unique one caffeine-laden session, or a programmer who suddenly figures out how to make the impossible possible. You need to support and encourage this - and make sure your design doc stays light and flexible enough to do so.
(Continued)
#3
You will need to be able to communicate changes and evolution to the rest of your team effectively. You'll need to manage expectations. You'll need to help keep everyone on the team in the loop creatively; make sure they know changes as soon as possible. You are going to have to figure out the best way to communicate these changes to your team --- simply dropping a revised version of the design documents (or even just the changed sections) in their lap isn't gonna do it for most people (believe me, I've learned this one the hard way).
If you have someone doing marketing, you'll need to work closely with them to help build on your product positioning and make sure that they have a clear idea of what they are selling and how they can best get out the message of what your game is about and why people want to play it. You may need to adapt your design (and communicate the changes to the team) to meet the needs of marketing (yes, they can be lousy weasels, but they can also be the difference between success and failure of your game).
One last thing - on very small projects (like most indie projects), you are going to have to wear multiple hats - just like everyone else. It's unlikely a single project is going to keep you busy as a designer - at least not if you are putting as many hours into it as everyone else. You may need to pick up some new skills to help the group out... art, modeling, programming, maybe doing research on third party libraries of code or content. Maybe web design. Learn as much as you can and try to be as skilled in multiple disciplines as you can get. It will only help you in the long run. You are probably going to end up being the chief tester for the game. You'll need to be able to stand back, ignore what you think the game is SUPPOSED to be, and concentrate on what the game *IS* and how it will be perceived.
Like I said - it's a lot of work. It ain't easy. Good luck!
05/20/2004 (10:31 am)
(Part III)You will need to be able to communicate changes and evolution to the rest of your team effectively. You'll need to manage expectations. You'll need to help keep everyone on the team in the loop creatively; make sure they know changes as soon as possible. You are going to have to figure out the best way to communicate these changes to your team --- simply dropping a revised version of the design documents (or even just the changed sections) in their lap isn't gonna do it for most people (believe me, I've learned this one the hard way).
If you have someone doing marketing, you'll need to work closely with them to help build on your product positioning and make sure that they have a clear idea of what they are selling and how they can best get out the message of what your game is about and why people want to play it. You may need to adapt your design (and communicate the changes to the team) to meet the needs of marketing (yes, they can be lousy weasels, but they can also be the difference between success and failure of your game).
One last thing - on very small projects (like most indie projects), you are going to have to wear multiple hats - just like everyone else. It's unlikely a single project is going to keep you busy as a designer - at least not if you are putting as many hours into it as everyone else. You may need to pick up some new skills to help the group out... art, modeling, programming, maybe doing research on third party libraries of code or content. Maybe web design. Learn as much as you can and try to be as skilled in multiple disciplines as you can get. It will only help you in the long run. You are probably going to end up being the chief tester for the game. You'll need to be able to stand back, ignore what you think the game is SUPPOSED to be, and concentrate on what the game *IS* and how it will be perceived.
Like I said - it's a lot of work. It ain't easy. Good luck!
#4
I am using people who haven't done anything like this before. I have at my disposal about a half-dozen people, and I was wondering what were the most important jobs, so that I'm not wasting my help. (The answer to this doesn't need to be in three parts).
05/29/2004 (11:49 am)
Wow. Thank's a lot! I am using people who haven't done anything like this before. I have at my disposal about a half-dozen people, and I was wondering what were the most important jobs, so that I'm not wasting my help. (The answer to this doesn't need to be in three parts).
Torque 3D Owner Jay Barnson
I'm going to assume that you are already working on a project as a designer, maybe your own game and you really want to know how you can help make it succeed. Good luck - it's not an easy job.
Your primary skill as a game designer is NOT creativity, though that's at least as important as it is for everyone else on the team. But you could get away with being completely uncreative as long as you have some other creative minds on your team. Your primary skill needs to be [u]COMMUNICATION[/u]. Did I stress that enough. You need to be skilled in writing, in verbal skills, and even more important - in LISTENING. If you don't listen, and don't act upon what you hear, you've failed as a designer. Period.
First off, listen to your team. Filter their ideas. If you aren't doing the whole game solo (and you should be recruiting help at least on the testing side), you've got several people who probably have some powerful creativity and a bazillion ideas for what would make the game great (or better). They've probably played a LOT of games themselves, and are at least as qualified at being an 'idea guy' as you are. Accept that with humility. Your job is to filter all these tons of great ideas into one vision. Some ideas will work - could even be the centerpiece of the whole game. Some ideas will completely suck and need to be discarded quickly and tactfully. Some ideas can work, with some modification. Some ideas are great but just won't work for the current game. Some ideas are just too unfeasible, either by themselves or are simply among those elements you'd love to do but just CAN'T due to the limitations of scope of the game. One thing to remember is often what makes a game great is NOT all the features it includes... but what it excludes.
Listen to your programmers! They will tell you what can be done and what can't. You also need to listen when they explain how much time things will take, and what your options are. They may say you can have A or B... make sure you realize that doesn't mean A *AND* B. You will also have to know when and how to "push back," if you are asking for something they don't want to do but which you know will make a huge difference in the game.
(Continued)