Your Game Design Workflow?

[Tutorial Doctor]

What's your game design workflow? Tips for a noobs:

 

My status:

I am all about doing things fast and efficiently, so I am always looking for SHORTCUTS. This is part of the reason I am making customizable game script. 

 

I am using the Maratis Game Engine, and I have developed a basic workflow:

 

Idea (brain)

quick sketch (paper)

Collect game assets (photos,sounds,models etc) (google)

Model (Wings 3D)

Uv unwrap (Blender)

texture (Blender)

rig (Blender)

animate (Blender)

lighting (Maratis)

scripting (Maratis)

 

(Or something like that)

 

What is your workflow?

[FrieChamp]

I'd recommend to test whether the game/level is fun first before spending lots of time on texturing, animating ...

[mjens]

I see gigantic differences between programmers and artists. They have completely different workflows, ideas, plans etc. You're asking about game design, right? Not level design but GAME design? Here's my "workflow":

 

Writing, writing and writing. All the ideas should land in game design document. This is the first phase where stupid ideas will go out. Writing about stuff you haven't planned forces you to thing about whole game, not the one feature you started with. It's a good idea to find >REAL< unique selling points. With that list you'll see that few ideas are not enough to make the game interesting. You need to write more - each mechanic, puzzle or plot stuff, do lots of sketches, test it "in brain" and when your GDD is ready you can try to make some prototypes in editor. As FrieChamp said, you don't need graphics to make sure the mechanics are working perfectly. Seriously, don't waste your time with pimping the visuals when your game sucks because of lack of mechanics...

 

Shortcuts can get you into pit and you can loose your enthusiasm, good ideas can be wasted becouse of one bad.

 

Good luck!

[Thrik]

Great stuff above. Frie is definitely right that establishing what's fun is the key for levels unless you're doing it purely for artistic joy. Need to get it in the hands of actual players and refine it until it works, then worry about all the assets and detail which are considerably harder to change than basic building blocks.

It's no coincidence that many of the most successful maps on MapCore are repeatedly playtested. Even just getting your level into the hands of a few friends can be very revealing — are they actually having a good time or bored stiff? Don't be too proud to let people test even when it's just basic geometry and grey textures.

[General Vivi]

Magnar wrote a great little article that explains his flow in level design. Can't hurt to read it, after all, he works at Valve now LOLZ.

 

http://magnarj.net/article_workflow.html

[FrieChamp]

I see gigantic differences between programmers and artists. They have completely different workflows, ideas, plans etc. You're asking about game design, right? Not level design but GAME design? Here's my "workflow":

 

Writing, writing and writing. All the ideas should land in game design document. This is the first phase where stupid ideas will go out. Writing about stuff you haven't planned forces you to thing about whole game, not the one feature you started with. It's a good idea to find >REAL< unique selling points. With that list you'll see that few ideas are not enough to make the game interesting. You need to write more - each mechanic, puzzle or plot stuff, do lots of sketches, test it "in brain" and when your GDD is ready you can try to make some prototypes in editor. 

 

Writing down forces you to think things through and to be more specific, but there's a risk: the danger of spending too much time designing and planning things on paper that turn out to be not-fun or not feasible in practice. The longer you spend time with your idea in your head or on paper the more likely you will fall in love with it and lose objectivity. The lean, iterative approach, where you test ideas and involve others early on in the process seems like the healthiest method to me. So yeah, writing down ideas = good but if you've got 76 pages in your GDD and zero action on your screen - you've gone too far

[mjens]

You can add benchmark or vertical slice to this description. If you have a team of artists they can make a benchmark when you're working with mechanics. Benchmark is one place made perfectly like from concept, with light and stuff. With such test you'll be able to say if the mood from concept art will do in the game. It's a very good idea to make a benchmark because poor art pass can make your mechanics feeling not as you planned. Even if you're one man army and you're the one and only artist and designer it's good to make such benchmark. Verical Slice is good when you have multiple levels with different mechanics - VS is a level that contains every single mechanic. 

[mjens]

Writing down forces you to think things through and to be more specific, but there's a risk: the danger of spending too much time designing and planning things on paper that turn out to be not-fun or not feasible in practice. The longer you spend time with your idea in your head or on paper the more likely you will fall in love with it and lose objectivity. The lean, iterative approach, where you test ideas and involve others early on in the process seems like the healthiest method to me. So yeah, writing down ideas = good but if you've got 76 pages in your GDD and zero action on your screen - you've gone too far

 

Yep, I call it "overplanning"

[Thrik]

By the way, if you haven't seen it already FMPONE wrote a great MapCore article detailing a more improvised approach to making a level, which he admits is risky but can produce some beautiful stuff:

 

Making a Map: CS_Museum

[Sentura]

My workflow is as following: write down, playtest, analyse. Rinse-repeat until PERFECT. Don't start new stuff until you have absolutely nailed what you were going for, or, alternatively, scrapped it. If you are looking to create a vertical slice type of thing where you don't want to spend time on mechanics such as jumping etc., put in a dummy version so you can see how it works in an entirety of a game. BUT remember that it is a dummy version and if it doesn't work in conjunction with other mechanics, reiterate on it until it does or scrap it.

 

For level design, do blockouts and scripts instead of writing stuff down, repeat above. DON'T do any art at all until you know it's working. I generally like using metrics for this, but if none are available go for player feedback/crits, especially if your players are fellow designers.

[FrieChamp]

My workflow is as following: write down, playtest, analyse. Rinse-repeat until PERFECT. Don't start new stuff until you have absolutely nailed what you were going for, or, alternatively, scrapped it. If you are looking to create a vertical slice type of thing where you don't want to spend time on mechanics such as jumping etc., put in a dummy version so you can see how it works in an entirety of a game. BUT remember that it is a dummy version and if it doesn't work in conjunction with other mechanics, reiterate on it until it does or scrap it.

 

For level design, do blockouts and scripts instead of writing stuff down, repeat above. DON'T do any art at all until you know it's working. I generally like using metrics for this, but if none are available go for player feedback/crits, especially if your players are fellow designers.

 

Not sure if I understood that first paragraph correctly, but that sounds to me more like a prototype/whitebox-type of scenario. A "vertical slice" is to me a slice of the game which sets the benchmark for the rest of the game and therefore doesn't use dummy assets (what seir said). If that's what you mean - forget what I just said. I just want to avoid that Tutorial Doctor gets confused.

[Sentura]

My bad, I could have phrased that better.

 

I meant to sketch the mechanics out to see if they work together in a vertical slice like fashion. Since we were talking about game design workflow and not e.g. artist workflows or otherwise, I assumed this was implicit.

What I wanted to arrive at was that you can start your vertical slice as a sketch of the game with whiteboxed environments and then build on top of that - mechanics wise, and gameplay/level design wise.

[Kedhrin]

when it comes to level design i always start with paper

 

i have a weird 'artsy' way of doing things... its almost like i let the level dance in my head a bit.  That sounds really bizarre, but when i'm doing balance and layout it usually works out.

 

when doing game design, i'm stuck in a document for a long time. it may take me a day to write a single paragraph, because i always search for new ideas that are fun, realistic to make within the budget, and make sense to other people reading it.  I'll usually start with a table of contents so i know what bases i need to cover, then i'll branch from there.  I've written so many different game designs at this point that i couldn't even tell you how many... i've never once considered any to be bad (except for the ones i was doing when i was like 14 or 15), if they aren't being made, they are more or less sitting on the back burner.

 

Although i do recommend playing a game as quick as possible, i think if a designer is drastically changing the game non-stop from a document, they just aren't a document designer - which can be a really bad thing, depending on the situation.  I'll generally play the game i design in my mind enough times to know if it is good or not, and trust my gut instinct - it usually works out - there's definitely shifting around, but i think if you're completely rewriting or gutting entire systems you're not designing properly.  I generally design at a higher level, implement, then fill out the guts.  But i document enough to paint a picture and stick to it.  I'm not the type of person that makes my team prototype a million things, throwing them out the door and starting over before committing to something.

 

i really - really - really dislike vertical slices.  It can force people to rush for a hacky rush job like making an E3 Demo over and over.  It's can really be a stress fest and leaves people cleaning up the hacky mess after the vertical slice is achieved.  Some of the people we do work for hire work for do vertical slice work a lot, and it usually always ends up with people crunching at the end... especially because i can't seem to get away from projects that are always reinventing the wheel or dealing with some wrecked technology that causes headaches across the board.  Sure it can give you a preview of what the full game looks like, but usually at a steep cost.

 

Although i definitely use grey boxes for maps, i don't stay in that area too long.  Certain games require very precise levels, like counter-strike, which can tip the odds of gameplay dramatically real quickly. Other games have a lot less emphasis on the inch-by-inch game play.  It all varies.

 

While people may say don't do art during your blue room, i think it is only half true if you are making a game that heavily relies on reflexes (like counter-strike). You need to worry about the colors, lighting, and micro detail you are going to be using in your map. It can change everything.  A player blending in with the environment can radically alter the layout and experience a player will have in the level.  A layout is dictated by the speed players move through the flow.  I think it is important to get a good enough hint of those elements in your level before you move on from your grey room phase.

 

Thats just me and what i generally expect out of my guys here... it's really hard to describe, because there is no absolute "solution" and every project big or small has been different..

[Tutorial Doctor]

Thank you to the posters above (and after if anyone else has anything to add . I do see how different programmers and artist think, and I think that if both had a perfect flow, then that would be the ideal setup. 

 

I find myself RIGHT IN THE MIDDLE. I recently learned how to program, and it is EASY. But the way I learned was in an artistic way (I happen to be a little artistic). So when I am writing the script, I am seeing it visually also. I try to keep my 3d assets in mind when naming variables and/or functions. Most of my functions I keep very dynamic so that they can easily be changed if there is a level design change or something. 

 

For instance, if I had several characters in my game (doesn't matter what type of character) and I wanted them to be able to run, I would have ONE FUNCTION named:

 

Run()

 

this function would then have arguments that change WHO RUNS and HOW IT RUNS.

 

Run(Joe,5mph,forward,UP_BUTTON)

 

If you wanted the dog to run:

 

Run(dog,10mph,backward,DOWN_BUTTON)

 

Anytime a new object is created by a designer, and I want it to run, I can do that. 

 

This helps my workflow a lot (reason why I am creating a customizable game script) because I dislike scripting hehe. 

 

Any programmers out there want to pitch in with their WORKFLOW for programming? Any artists want to pitch in with their workflow for level design? I could use any help.