next »

[Guert]

The designer's workshop
From dream to reality: How do you make your game dream an actual design?

   Hello and welcome to this fifth game design workshop. After a short (well, rather long) pause, let's discuss once again the wonderful world that is game design. This time, the workshop topic will be a very obvious yet difficult question to answer. How do you tranform your concept into an actualy playing game? 

Blue magic is the best way to hide palm hair.

   Being a game designer is a wonderful blessing but at the very same time, a terrible curse. A game designer has the talent to use his or her creativity to create epic worlds, concoct delightful challenges for the player to surpass, bring to life characters that can execute incredible feats and most importantly, game designers have

the great ability to make players happy. Alas, the game designer also has the arduous task to take the vaporous ideas that he dreams, and in certain cases that others come up with, and mold them into something solid and substantial. We humans have a great gift that allows us to simplify even the most abstract idea into something easy to digest. As long as a concept remains in the land of ideas, the game is perfect. The second the game needs to step out of this state, the road gets rough and the designer is there to guide the game into an enjoyable experience for the player.    Like many other game design topics, there is no sole solution or path to take in order to realize such exercise. Elaborating the design of a game is never an easy task but having a good startup really helps to get rid of many issues the development team will face while walking down the road to the golden state. And unfortunatly, unlike in the games they create, game

designer cannot use the warp zone to skip ahead. Of course, that is also what's so fun about being a game designer. It's shall we say, part of the game.

So, as a game designer,

• How do you tackle this situation? How do you take your concept and make it happen? What is your personal approach on that topic?
• Do you have tricks to find potential problems with your design at the very beginning of the project?
• Do you simply commence with a small element and pile on top or do you plan big right at the start, figuring out even the small details?
• Also, once you have your concept down, what do you do next? Do you prototype? Do you code the engine right away?

Now, please, ladies and gentlemen, DISCUSS.

Related links
Starting a comercial game (not exactly on game design bit the concept is interesting and applies in many ways)

 

[increpare]

Yay!  I'm going to try join in on this one this time

Following earlier failures, I make sure that, even before I've thought out any rough design concepts, I have a prototype up and running as soon as possible.  If a single prototype (which I would hope to eventually develop into a completed game) isn't possible, I'll go with constructing several (which would have to be consolidated). 

Also, prototyping, for me, encourages the development of a detailed plan.  Some projects (krystallnacht, lacan: trauma) I started on without a clear idea in my head of how things were going to work, and tried to build them from the ground up.  With the former, I started on getting a nice graphical interface up and running first, with the latter, some of the background character generation.  The former has stalled, the latter was a monumental failure.  In both cases I wasn't aiming for interactivity as my first landmark.  I'm never going to make that mistake again (hopefully).

Sometimes it can be good, and it has been good for me, to sit back and think really hard and draw up a detailed plan, but when projects got over a certain (rather small) size I found I could no longer do that reliably.

My current project, the Defez series, is essentially a series of prototypes (2 released, 2 finished but unreleased, 4 on the drawing board).  I've had a lot of fun exploring the various possibilities, and getting a handle on what I can do with the fundamental idea.  There are, in general, many (often surprisingly different) ways to implement any given game idea, and it can be fun to actively explore them.

[azeo]

I find that while designing games the hardest thing to do is not make cuts. You work forever on a single level, and then you try it out and this one thing out of the entire level isn't working, but your tired of working on this one screen so you just get rid of it. The same thing can happen if someone on your team, like an artist, doesn't feel like making a separate sprite for walking and running, so you take out walking as it wasn't put in for game play. I find because there is rarely ever a monetary reward for you making this game, you often lose steam and cut things out until the game is just another run of the mill game, with nothing unique about it because it was "too hard"

[moi]

Here is my method. I know it's kind of lame, so kids, make sure you don't imitate uncle moi's methods!

1-get vague idea (mainly based upon a cool "moment" of the game)
2-code main behaviours, refine
3-design a couple levels for testing, refine
4-code all gameplays, design all levels,refine
5-graphics, sounds, etc
6-...

7-

I don't actually waste too much time designing cool characters with swords and/or big laser guns (like in OP post), but I let in all the wacky ideas that can happen out of thin air during stage 5. Stages 4 and 5 take ages, it's a bit like a test of the will.

[Guert]

Interesting methods to approach the game. Prototyping and play-tests are two good ways to get the game's basic down. How many prototypes do you usualy create for one single game?

Cutting features is the toughest part but there's always a question of why the feature is being cut. If your game ends up with less content because someone got lazy, I don't think it's an acceptable reason. If a feature was removed because it was too time consuming, that's another story, especialy when you have a restricted development time or budget.

Before prototyping, I make a preliminary list of all features I would like to have in the game. Then, I prioritize them so that my prototype tries out as much as possible the most important features. This way, I know that my core has been tried and tested before starting the real work on it. It also helps to focus the cuts. If I know I've flagged a feature as low priority since the first draft, I know that cutting it might simply help the project. On the other hand, if a feature has been marked as priority, cutting it might kill the project in the long run.

Any other methods someone would like to share?

[cyber95]

My method.
1. Get game idea
2. Start coming up with mechanics
3. Start writing story
4. Use up countless papers designing characters/places/items/etc.
5. Forget about project
6. Notice it collecting dust in a folder half a year later
7. Go back to step 3 and repeat from there.

[increpare]

Interesting methods to approach the game. Prototyping and play-tests are two good ways to get the game's basic down. How many prototypes do you usualy create for one single game?

Playytesting is interesting as an idea.  I've not ventured into it too much, but generally that takes place at a much later stage (or not at all, depending on how jealous I'm feeling).  I've had a lot of enjoyment playtesting other people's products though.  Are some sort of concepts more amenable to playtesting than others? (by playtesting I mean playtesting by people other than the programmers; that's what you mean as well?)

[Guert]

In general, I feel playtests are great to find out if your idea is actualy fun. I usualy have 2 phases of play tests while prototyping. The first one is once I've reached half of the prototype. Most important features are in and playable. The second phase is once the prototype is satisfying. Playtesting the prototype helps to spot the good and bad things right away before they are too developed to be easily changed.

In some cases, I may have to do many prototypes, depending on the game. For example, if I have an action game with at least 3 core gameplay mechanics (lets say, figthing, racing carts and hum, I dunno, an inventory system that allows item creation), I'd make a prototype of these three cores. The final prototype would link those three together. This way I can focus the playtest on each core to make them work and then see how they fit together and modify them so that they become coherent as a whole.

My thumbrule for playtest is simple: never do playtest unless you are satisfied gameplay-wise with what you have. If you do playtests while there are too many  issues you are aware of, you'll end up with playtesters pointing them out. Although it's fun to confirm that an issue exists, it can be quite irritating to be told "that's wrong, fix it please" when you already know it. You'll end up with a session with a bad "what you already know" versus "what you didn't know" ratio. On the other hand, if you wait until most of your main personal issues are settled in the build, you'll get a lot more comments about things you didn't see or think of, which will make your playtesters and you much more happier. 

I personaly feel that any game you create, even if its a clear rip-off, should be playtested through prototypes. The reason why is simple: it is something you are creating and you have a biased view on your project. Playtests help to show you how outsiders see and feel the game you are creating. It's even more important when you are doing something completly original. Of course, when choosing playtesters, you have to be smart. If you feel someone can steal your ideas, make them sign a non-disclosure agreement(a paper saying that he'll or she'll shut the hell up about what she just played and recognize that it's your ideas, not his/hers). In fact, it's always better to have one at hand for all playtesters, even friends and family. Well, of course you have to use your judgemnt on this; I don't make my girlfriend or sister sign a paper everytime I show them something but I do ask my cousins that I see only once a few years since they want to work in the biz. I don't make people sign a NDA if it's for freeware release either. In the end, it's your own judgment.

When choosing a playtester, I like to refer to the term virgins and semi-virgins. Virgins are people that never played my game at all. Those are the best players you can get. They'll play the game and you will be able to see what it's like when somone discovers the game for the first time. The semi-virgins are people that know alot about your game and might have played it at an early stage. These people know what they are getting into so they will comment the game in a different way than a virgin. My playtest cycle is something like this.

1- Creator playtest (the designers, coders, artists, etc, play the game and tell their opinions about it. The crucial issues are fixed and when the gameplay is acceptable, we move on to next phase)
2-Semi-virgins playtest ( These are the people who are aware of the development. Mostly friends, family or other co-workers an ex-virgins. They know what the game is supposed to be. Usualy, I have a lot of those around. Issues are raised, fixed and we move on to the next phase)
3-Virgins playtest (Roughly, they can be anyone who doesn't know the game exists or only know little of it. To me, these are the most crucial tests. Those playtesters are usualy friends, family or sometimes people I don't even know. Issues are raised, fixed and then we start the whole process back to step 1)

When doing playtest, I have 2 golden rules.
A) Write, observe, record and watch again. Take as many notes as possible, focus on the player's reaction, performance and behaviors. When doing it with one or a group of semi or full virgins (I love this sentence )I find it better to do playtest with two observers to take different notes (one focuses on one thing while the other focuses on something else). This way you'll have a better understanding of the session. Unfortunalty, I can't do that too often because I'm usualy alone when doing the playtests.
B) Shut the F CK up. When you observe the game, you f**king observe, not tell the player what to do. I always start off by saying "I'm not there, just play the game for the fun of it. There are no good or right answers, just play". Of course, you can talk a bit, especialy when you are play testing with creators and experienced semi-vrigins, but remember that your focus here is getting the natural reaction of your player. Even if he looses, even if the game doesn't work, don't help. It'll simply enhance your game in the end. If the player doesn't understand the interface, well maybe it's because it's broken. If all your playtesters don't understand it, hell, it IS broken.

In my opinion, a good prototype is the game concentrated in a few minutes. The first level of a game, if you will. You can't create a prototype with all the features because most of them will appear after the project has started. But, here's a trick I use to really focus my prototypes with the right features. When I create a game, I start off by asking myself the following question: "what am I doing exactly? What kind of game am I doing?". The concept is called "heartbeat of the game". The idea here is that you must write one single sentence that describes the entire game. This heartbeat will guide you through all the process of the game creation. Like a beacon in the night if you will.

Heartbeat examples:
"A 2D humoristic classic fighting, Street Fighter-esque, game featuring clay animated characters duking it out for control of a circus "
"A action, fast-paced plateformer where plumber must face dangerous perils in a land filled with fantastic creatures in order to rescue a kidnapped princess"
"A 3D plateformer game where the character can hop from one planet to another in order to beat various challenges in order to find lost stars and free a kidnapped princess."
"A role-playing game featuring numerous characters and an elaborated story where the player must wander around the map, fighting random encounters until he can participate in staged battles in order to view a cinematic to change the map" (ok  this one is not a good example )

So with that heartbeat, you can guide yourself through the development process. You can ask yourself: "Does this feature fits with the game I want to do?". The heart beat is essentialy a very rough guideline. So when doing a prototype, I make sure that it follows the heartbeat and see how people react. Sometimes the game I wanna do is not attractive, sometimes it's the features that are broken. Sometimes everything is fine. Its never the same.

So... I hope this answers your question Increpare...

[brog]

My old approach to making games was to have an idea, get excited about it, jump right into coding it, get lost or bored, give up and do something else.  Obviously there were some problems with this.

Now before I start making a game, I hold the idea in the back of my head for months, maybe years.  If I get excited about an idea I'll flesh it out a bit on paper, but I won't start coding.  This filters out the ideas that I actually care enough about to dedicate the necessary time to.  It's very hard to tell when an idea is new how I'm actually going to feel about it months down the track, but if I've already liked it for months I'll probably keep liking it long enough to finsh it.  This also gives the ideas time to ferment, collide with other ideas, grow, or (even better) shrink down to what's really important.

Then I'll make a quick prototype, get the core gameplay running, playtest.  Playtests are awesome.  You have to just sit back and watch people fail, resist the temptation to help them (unless they're about to give up; at this point you know that that part seriously needs work so you may as well help them past it so that they can test the next bit for you).  You have to be physically in the same room as your playtesters, watching them.  Sending a copy of the game to people on the other end of the internet and asking for feedback just doesn't cut it.  They won't be able to explain where they went wrong and what they didn't understand because they don't know.  Remote playtesting isn't completely worthless; if they have some idea about game design and some idea what your game is meant to be like they can often give some useful suggestions, but they won't be able to tell you where you have completely failed.

The idea can change a lot in the prototyping phase.  Since in the time between having the idea and starting work I'll have pruned it down to its essentials and come up with several variations on it, I'm not too attached to specific parts of it that might not work.

After the core gameplay works I'll start building on it.  Things like AI, different game modes, and campaigns get made.  This is a quite hermitic period: I want to build lots of stuff and save it for showing to people until it's reasonably impressive.

Then unveil it, get people to playtest it again, polish polish polish.  This is the point I'm at right now so I'm not sure what comes next, but I suspect it might be "release".

[Matt Thorson]

My game creation process, in practice, has three stages.  The line between the second and third is kind of blurry.

1. Develop the Idea
(Figure shit out)
Basically here I just think of the idea and write stuff down or draw stuff, and make a rough prototype of the game.  The goal here is to get enough specific ideas on how the game will work that I can get excited about actually creating it.  Once I'm motivated enough I go to step 2.  A game will usually spend at least 3 months in this stage, but often a game will be in this stage in my head while I'm finishing up another game (making stage 3 very difficult for that other game!)

During this stage I'll also get other programmers/game designers to play a rough prototype of the game and give feedback.  I find that feedback at this stage from people less knowledgeable about the art is often vague and less valuable ("there should be a tutorial" "there will be in the final game, right now I just want feedback on the feel of the engine" "it feels good" ">_<").

Most of my game ideas die in this stage because they just don't end up working very well or don't seem very fun to make.  I don't mind this, really.  I mostly see this stage as a sort of boot camp for my game ideas - where they'll either prove themselves as viable ideas that can be fun to make and play or die and never see the light of day.

2. Make Stuff
(Create the game)
Here I just make the game.  I code the engine, I design levels, I compose music and I draw graphics.  Here it's important that I keep my eye on the big picture so the game doesn't become a mess, but always thinking of the big picture is one of my strengths so it usually isn't an issue for me.  To organize and motivate myself, I keep to-do lists - usually 3 of them (code, design and art) and then pull one thing off a list depending on what I feel like doing when I sit down to work.  Without lists, I end up just "testing" the game aimlessly for an hour when I sit down, maybe fixing a bug or two, and then running out of time.  When the game has all or nearly all of the core content, I move on to stage 3.

3. Polishing
(Ensure consistency and add subtlety)
Here I add easter eggs and bonus features, polish assets for consistency, and get as many people to test the game as I can.  Some examples of other things I may do in this stage: rearrange stage order for difficulty curve, slightly change some stage designs for difficulty balance, add a secret stage or two, add misc features (like pressing F3 to take screenshots, etc), streamline GUI based on tester feedback, decorate menus, etc.


I think that sort of indirectly answers most of the questions at the end of the original post.  The structure of my method may seem pretty laid back, but during stage 2 I'm quite productive and don't let myself waste any time.  I think the fact that I don't separate code/art/design into different steps lets me stay motivated and keeps progress steady.

[Melly]

If you're right brog, I hav a specific idea I could spend the rest of my life making.

Seriously, it's been hammering in my head for years. It's just too big and ambitious, though I feel the time to make it happen is near.

[Ivan]

Here's my current method:

- Get a vague idea of what the game will be
- Work on really complex engine specifics, preferably involving physics and 3d graphics
- Abandon and Repeat

That's all there's to it, really!

[Renton]

My method:
- Get an idea.
- Work on concept art.
- Change characters, styles, plot a million times.
- Open Construct.
- Stare at Construct blankly.
- Close Construct.
- Repeat.

[Kekskiller]

Though good gamedesign is a complicated process, I tend to do so:
1. Fill up with loved media stuff
2. RAND(MEDIAPOOL) + RAND(MEDIAPOOL) + RAND(MEDIAPOOL) + ... [0;n]
3. Catch fire by these random sparks
4. Having a sleepless night with dreamy visions for a game
5. Write down atleast 10 pages of detailed gameplay concepts next morning
6. Wait an undefined amount of time
8. Write down technical engine specifications ( + formulas and conditional alghorythmic) stuff
7. Start IDE and begin engine coding for the next weeks/months
8. Make the game's content
9. Having fun with polishing the details
10. Publication
11. Feeling ashamed, 'cause of damaged ZIP files...
12. Bugtesting, imroving, neverending

During point 6 and 8 there is a phase of extreme sensitivity. If I can't concentrate 100% on them, I will stop making but resuming in a time I'm able to.

I don't make dreamy gamedesign concepts. Everything I'm writing down is the final concept- But I tend to change the entire gameplay during 6. and 8., mainly because I got better ideas... Thats typical for gamedesign I think.

[marshmonkey]

All the games that I want to make are based around sand-boxy ideas and consist of emergent/reactive game play - so it is pretty easy for the design process.

We always start off with a basic idea of the elements we want to be mixed together, i.e. we know we want it to be multiplayer, have X, Y, and Z, etc - then from there we would just start putting those pieces in place and point them in the general direction we want to go in. From there it is all testing and throwing out what doesn't work and going further along with the stuff that does work.

We usually have a lot of specific ideas for the design that we either put in place once the framework gets built up enough to support it, or it just gets left by the wayside if we don't end up going down that path.

I find that being able to be "nimble"  in your development is really leveraging the strength of having very limited resources. If you have your epic design chiseled in stone tablets from the of of a mountain, it is pretty hard to switch around chunks of your design in order to follow the most efficient design choices possible.

[Hempuli‽]

I have always some game ideas in my head and under construction. I'm pretty good at losing interest on a project, so most of these game ideas never make it. Sometimes I'm extraordinarily interested in a game idea or it just is so good that I make it to a game. I also do many notes on paper and plan everything out, but at least with metroidvanias it result to what they call "big game fever": I design and plan too big games & maps, and lose interest. Usually my ideas base on a single thing, like a puzzle-solving style or a special visual thing.

Then, when I've got an idea and I begin to create a game on it, I usually first draw the main character and code it's engine. Then I start adding more and more stuff on a single level until I feel like everything the game needs is in (though always there're some bugs and things left out that I later on add/fix). Then I just create a "template level", with nothing but the important objects in it, copy it and start slowly creating the gme piece by piece. Mostly when I get to this state I also finish the game, but there are some that I have abandoned even after I've created some levels/bosses, mostly because the graphics/gameplay feels too bad. A good example of this could probably be "The Adventures of Adrian and Axel", a very epic adventure game based on my comics. I started working on it, got quite far, and then started working on other games. After some months I realized how ugly the game was and how primitive the gameplay was, and abandoned it. Quite sad, but meh.

I seriously lack some polishing and testing skills, I help people out too easily and stuff like that, so most of my games appear when they still have some bugs. However I try to fix them ASAP.

[esc]

Familiar with the MoSCoW Method?

http://en.wikipedia.org/wiki/MoSCoW_Method

It helps you prioritize what comes into your game, and also helps you set milestones.

    * M - MUST have this.
    * S - SHOULD have this if at all possible.
    * C - COULD have this if it does not affect anything else.
    * W - WON'T have this time but WOULD like in the future.

the o's don't mean anything.

[rayteoactive]

I'm totally new to this, so I'm not sure if I'm actually qualify to the topic. Still... I will try to pump in what I have, hopefully one or two point turns out useful.

I realize most of the designers are also coders. It make total sense. But sadly for me, I'm an artist, and really just picking up on game design. My team and I(Game design + Art Direction) are halfway through our first game as we speak... and the prototype is almost done (assuming march at this point). I'm also preparing the next game while I'm not working on the current.

For me, no matter game design or art, I usually start off from research and not inspiration. Though you can always research what inspired you, I realize that my research tends to get biases and inaccurate. My take is that inspiration is like a sudden rush. It comes and goes. But with research, it gets you interested along the way, back your ideas with fact, and you don't have to burn all your fuel at the go.

I'd avoid looking too much at games from the next gen, and turn to indie, classics, GBA and NDS stuff. It can be an unexplored feature from another game or something forgotten for too long. It's extremely tough to come up with something no one ever did. And if no one ever did it, there's usually a reason. Even not, it just means that there's no reference, you're on your own, and that's not what a newbie like me want to get into

The actual designing process is about the same as everyone else. But 1 thing I tend to do is not to think out every last detail. I'm not sure if it's the smartest thing to do(probably the opposite), but I prefer to leave somethings open for what doesn't seem to go wrong too easily. Allowing some of the design take place along with the rough work seems to keep the passion going. Bottom line is, when the passion burn out, everything became a chore, and nobody works on, so what's the point.

Hmmm....guess I should stop here. I'm pretty okay with what I've mentioned, but things beyond, I better say after I'm done with my first game prototype. Hopefully, what I mention provides at least a different point of view

[Noel Berry]

I usually end up thinking of a very vague game idea, making some simple graphics for it, program the basic engine, etc, then decide if I actually like it. The odds of me liking it are usually about 1/50, it seems

I think I need to find a new method.

I should probably try doing something similar to this, some time:
1. Draw concepts, make lists of ideas, etc, for a week or two
2. Program a prototype, with simple graphics
3. If the prototype sucks, go back to step 1, else, go on to step 4.
4. Created better graphics for game, re program new engine that you take more time on
5. Work until it's completed.

[Art_Sempai]

My Method: 

1.Get an idea for a character.
2.Make character/concept art and story.
3.Think of game play that can be used to tell story.
4.Polish game concept.
5.Fail to find team members.
6.Put project on back burner.
7 Repeat...Repeat..Repeat.