Design completeness

[zoombapup]

Hi guys..

I'm about to start designing a new game that I really like the idea of, but this time as a practice, I'm going to try and be a bit more thorough about the design than I normally would. Normally I like to iterate a lot and I'm not going to stop doing that, but this time I really want to nail down things like art and code requirements a lot more.

So I was wondering, how far do you guys actually go into design of your games? A full art requirement list up front?

.Zoom.

[woo]

I don't know if I'm entirely qualified to respond, but we certainly didn't for our current game My Bogle (http://mybogle.com). We knew how many characters we were going to have and a general idea of how many levels we could handle. Maybe it's because of our fairly limited experience, but we overestimated how long it would take to create the assets, and underestimated how good they were going to be :)
I think if we had tried to use a rigid plan for our art and hadn't experimented along the way with what was possible, we would never have come up with the great stuff we've got going in the game right now. Luckily, because we had overestimated our timeframes for art creation, expanding our art requirements hasn't really caused our schedule to slip.

Edit: In terms of design - we ripped the rules system out of an old tabletop game we had designed many years ago, so a lot of the game play was designed up front. But we reimagined the entire world, which meant quite a few iterations of the design of the world, and very few iterations of the game play. Again, our situation is a little unusual.

I hope that helps.
-Andrew
http://theoreticalgames.com

[JPickford]

Unless I'm force to (to get publisher funding or whatever) I don't design anything ahead of time.

[Anthony Flack]

I think I will prototype ideas more agressively in future. Letting the game evolve naturally is the way to go, but I have just ended up with too many wasted art assets and over-hacked code this time around. I don't think I'll ever be able to design a great game entirely in my mind, but a little bit more planning would probably save me some grief. But then, maybe that grief is a natural part of game development. Or maybe I will just learn to be more efficient with more experience.

[DrWilloughby]

I design everything I need to beforehand such that I can come up with a complete asset list for all animated 3d art assets. I come up with a rough list for all non-animated objects, a list of how many environemtns, and about the number of objects that go in those environments. I create some basic UI designs, but those always change.

[Mike D Smith]

Here is some good advice for designing that I've heard from some great designers in the industry. Get your game up and running as soon as possible. Don't spend any time on art or any polish stuff, just use place holders or simple shapes like squares or circles etc. Work on your game in this prototype stage until it's fun and all the issues for gameplay have been worked out. If a game is great with cubes, it will be great with better art.

After this, the game is pretty much complete and you can go through the motions of putting in the art, polishing the levels, etc.

Too many people spend way too much time designing details that don't make a difference to the game or end up getting chucked for something else later.

Don't let the art decide the direction of your game, let the gameplay decide the direction of your art.

There is no real substitute for prototyping and playing your game before you invest tons of time and money into it. Once you have a working prototype, then you can make better estimates on programming time and art requirements. Remember, this was a prototype and should now be coded properly to save yourself huge headaches later.

[luggage]

I find that how well a game plays comes from a mixture of everything and using placeholders doesn't work well for all game types. For example, putting sound in a game from early on can really improve on how the game plays - in theory it shouldn't but it does, same goes for art. And if you spend too much time working with placeholders you suddenly find you end up fine tuning a lot of stuff when you actually get the assets in place.

Not totally applicable but FPS's are such an example. If you boiled it down to placeholders there'd be very little difference between Half Life 2 and "Generic Shooter 5". The difference is in the assets and how they hang together.

Personally I find having something a little more substantial than a square as a placeholder gives me a better feel for how the game is coming along.

On another note, I recommend getting a (not final) frontend in place as early as you can. I find it comforting to have the structure in place as soon as I can. ie. Go into frontend, start game, back to frontend, back in game.

[zoombapup]

Typically, I've used placeholder art for everything.

But what I find to be the case, has been that when going to look for an artist to work on the project, they want to see:


A design doc
A full and very specific list of all art assets

Which obviously rules out "design as you go" stuff.

Ok, some of you guys have artists as partners, unfortunately for us, we're code-heavy right now, so our direction has to come from the functionality, but at some point I'd like to ensure the transition from prototype to working title is smoother, which means asset lists and functional lists and stuff.

Essentially, I'm fine with iterative design, but iterative art seems to not be the case unless you are directly working with an artist. If you are doing it as a contract work, then things tend to get a bit more messed up.

I dont know about the placeholder art thing. Most people seem to have a very poor understanding of how to transfer a conceptual icon (i.e. a blob) into a visual peice (i.e. a nice looking character). This can definitely become a problem. I've got no way of solving it, but I think placeholder "real" art is better than placeholder blobs, because 99% of people dont know what the blobs are.

Just to prove my point, go to any games site (garagegames.com) and look at the comments on the games that are works in progress. Notice how people wet themselves over nice looking screenshots and hardly ever post to great concepts done with sub-standard placeholder art?

Besides, I'd like to actually this time round, have a clearer idea of how much my art budget is going to burn and how long it will take.

Damn I wish we had an artist on the team. Sucks to be a programmer.

[woo]

Yeah, I don't think I could have pulled this game off without having an artist as a partner. That being said, we still used programmer art for a lot of the prototyping - we had static pictures of cute little stuffed animals and such, which wasn't really the world we went with, but it gave some context that you just wouldn't get with blue boxes. That, and when the little hare beat the turtle it was a moral victory! :)
Granted, it was still very jarring when they moved from one place to another because they just popped over, and when they died, they just popped off the screen. But it made a big difference in getting a feel for the game. Yeah, those couple hours putting together the images were wasted time, but they were differently worth it.
If we had a 3d game, then it would probably change my perspective a bit, but not much. More power to you if you can plan it all out ahead of time! I can do that with a lot of programming tasks, but not games.
-Andrew

[Anthony Flack]

Any prototyping I would do would be strictly for me; when I make placeholder art I try to do it as quickly as possible but close enough that I can kind of imagine what it would look like for real. Usually that means quick Photoshop sketches, no animation, but roughly correct in colour and appearance.

But on the subject of prototyping, I had an interesting experience the other day. In my game, I have these wires that I can stretch from one point to another, and the player can grab them and slide down them like a flying fox. I've had these things in place for ages, but they never appealed to me. I didn't like the way they worked in the game, so I haven't really included them in the level designs.

The other day, I decided to rework them. Previously, they were just a static graphic; literally just a black line stretching across the screen that the player would slide down. I did a bit of number-crunching, and made them out of two pieces instead, so that when the player slides down them they sag a little, and when he lets go they go "sproing".

And it's made all the difference. Now I want to put them in all over the place, because they're fun...

[LilGames]

Plan plan plan.
Planning is everything. And it applies to all aspects of business (or heck, even your personal life!).

[mahlzeit]

Then again, no plan ever survived first contact with the enemy. (Which doesn't mean you shouldn't plan -- just that a plan isn't anything more than being as prepared as possible.)