Initial Game Design - How Do You Plan?

Hello good people.

I know many of you are currently working on fairly large scale projects and I am curious as to how you approach it?

While some people may try to keep it all in their heads I think most of us realize this is not a wise way to go.

I use mind maps to plan stuff. Not just games (in fact my girlfriend once asked me "what can we do?" and I said give me 10 minutes and I created a mind map, printed it out and handed it to her).

Here is the mind map I created for my current main project (the one in my avatar):


This is obviously just an overview of the game mapping out the key aspects of it. Each of the end nodes of course represent a fairly big chunk of work. So... it is high level but still is enough to provide a plan, an outline, of what I want to accomplish.

I am just curious how others do this. Does anyone else use mind maps? Do you use other diagramming tools? Do you do it all on paper? Or do you do it all in your head just working from a very "loose" view and adding stuff directly to the game project as it pops into your head?

 

I just use google docs. I write things down so I dont forget it, although I think you dont want to over-design it and get locked into something that doesnt work, you want it to be somewhat fluid so that you can change things up as your developing it (and iterate the gameplay). My current game battle karts really changed up from a basic mario battle mode clone to something somewhat unique. Just today I had this idea, and thought wouldnt be cool if I added in this feature, sometimes this works (and other times it doesnt).

 

Take your mind map, turn it into a hierarchical list, and you've basically have my notebook which has recently overflowed into another one. That's most of what I use, but it's mostly just to write it down. I rarely, if ever, go back and read my notes though.

There are a couple of text files I made in writemonkey, just so that if I'm ever crazy enough to pursue the idea, I'll expand and adjust the ideas into a serious blueprint for what needs to be done. For right now, it's just a giant list of reasons why I don't want to go near an RPG.

As far as diagrams go, I rarely touch them. I might if I really need to think out system interactions, but they don't usually get that complicated.

 

Mind maps are all well and good for high level work, but at their best they simply provide a list of all of the features for a project. Its difficult to show how different parts of the system interact.

Once I get down to actual design work I tend to use block flow diagrams. Part of this is because of my training, chemical engineers love block flow diagrams. But in general block flow diagrams are pretty great at describing systems, and how those systems interact with each other. And my projects tend to have lots of interacting systems.

 

I use to really like UML but as time has passed I find myself using mind maps for everything. Outlining a presentation I gave at a conference. Software Designs (process flows and so forth). With the use of icons I have used them for sequence diagrams as well. I just find them a very easy way to organize information and design just about anything. My diagram above would represent the very high level diagram probably a simple block diagram in traditional terms. A new mind map can then be created for each node if I want. And mind map nodes can link to other mind map documents. It is actually quite flexible and fast to work with.

Sometimes I just jot down lists on paper as well. I used to design stuff in great detail even creating flow charts for many things. I kind of prefer a more abstract view now although occasionally I will map out some specific mechanic or technical functionality.

I was mainly just curious I guess if there is perhaps some dedicated Game Design tool that some of you may be using that I have never heard of. It sounds like basically we are all doing the same kind of thing... which does make sense.

 

The actual tool I use is pen and paper. I used to use pencil and paper, as that had the ability to reallocate memory that was already assigned. But I found the process of reallocating memory to be painfully slow. With modern pen and paper systems memory space is pretty much unlimited. Its far easier to send any memory that is messed up to garbage collection and start with a fresh allocation.

 

LOL You are THAT guy.

 

I have a background in business analysis/development (just getting started with Unity) and would also like to know how to approach game design from concept to implementation. I'm familiar with mind mapping, flowcharts, detailed documentation, etc. However, with Unity, I feel I'm missing the best practices that will get me from documentation to code. It feels like such a good "prototyping" environment, that it's tempting to just start coding!

Normally I'd take the docs, build a list of candidate entities, create a database schema, model the logical/physical architecture, suggest class hierarchies, etc. Could someone suggest a better way of deciding what classes, scripts, resources, structure, etc. that I need to create, once I've documented the concept of a game? I could follow similar steps to business software, but Unity seems quite different in it's use of "intelligent", independent, interacting swarms of objects.

Thanks!

 

What I say here will not be new and will be mostly reinforcing what people has said before.

1. I get my idea, this may either be from looking at someone else work, discussion with colleges or just some I randomly think up, if I pen is in reach I usually jot something down.
2. I then move onto cutting to game into different "mind maps" with different elements that you have shown above. I sometimes organize parts of these values, to decide what is most important to the game, and try to uncluttered thing.
3. After this is done I move onto doing a quick concept document, I do have a template that I do this on, editing as it needs.
4. Prototyping is something that I do after the concept document. I believe this is crucial to seeing weather or not that a project will be successful and fun, if if not you should drop it. Prototyping should just be basic mechanics, bare bone of the game, or just the core mechanics of what will make game. If your not a coding god don't worry as the asset store has a lot of stuff that may be useful to this project. You can also just pen and paper it out as well.
5. After prototyping I move on to the fully fledged GDD. With the knowledge that you have gained in the previous stages you should be able to get a good idea of the scoop of your project and what is needed to get it achieved. Although experience in this area will help a lot more with this. (my first project I forgot to even think about how I would achieve some of the projects that I would be working on)

Again this is just how I do it, most of the time, and works well for me. In-between these stages I tend write down supporting ideas, doodles and think about my project.

If you are luck enough to get a job in a designer role it will vary from company how they would like you to work as well.

 

I'm curious, I only ever tend to use a GDD, what do you put in your concept document that wouldn't be covered in the GDD or vice-versa?
Do you find an extra planning iteration helps, and does it extend the time you spend iterating/prototyping?
I'd be tempted to try a similar approach if it has merits. I find starting with a GDD means it ends up having many modifications through it's lifetime, which can be confusing.

 

I am not a very advanced unity developer, so my way might not be correct but it's how i do things -
1. Before even thinking about my game, i first think am i ready? Lot of us just jump into our dream game and out of frustration quit developing. I think about if i can do this? I try to think of time I have, if my game will attract people, etc.
2. Next, when mentally prepared, i think of what kind of game i want to make? Do i want to make a 3d FPS? or maybe a 2d platformer? A infinite runner? a puzzle? When choosing design I consider -

• Can I make this design? Is is possible with my programming skills? What about art and graphics?
• Is this design attractive? I try to make something unique, not those over-rated high graphics 3D games?

3. Once satisfied with my design, i think of the game, like if i had chosen a 2d platformer, I would think about a nice 2D game i am capable of making, I think of it's type more specifically, like a puzzle 2d platformer, maybe a 2D platformer with nice story where player has to rescue princess.
4. I plan a rough idea of basic things(& feaures) my game would need, I don't note it, i just keep it in my mind. I only think of basics of the game. What would i need, how would my character look? what controls and uniqueness should i add. And lot more basics, like what will the target, how long or short my game would be, enemies, gameplay and others. I dont think of advanced things yet.
5. Now this was for what i plan BEFORE beginning, after i have a clear cut idea of the game i am making, i first think of programming. I think of the basic scripts i may need, like how would i code character conroller script * Thinking, declare this declare that, do this, do that, fuction blah blah, Vectro3, etc. * I think about all the basic scripts. If I find that ok, i can do programming, then i begin !

I may not be able to express clearly what i meant to say, so here is the rough idea, I am currently working on a game based on mining, so before i began i first decided that I wanted to make a Random-Infinite Generated World based game. Once decided, i decided that i would make a game based on mining(I got inspired by minecraft). and then the rest is just what depends on your skills.

I would say, Don't Underestimate, Don't Overestimate yourself. Choose what you would love to do, not what people would like to get. You are here, making a game, because it's what you want to do. and yes, if you want to make money, and you are only developing games for earning, then forget about all this. Marketing is what i dont know.

*oh sorry, you asked for big projects, nvm... i only work on small projects*

 

Ugh. All this talk of GDDs makes me sick. For games I typically design bottom up, I throw together a couple of key mechanics into a prototype. Play it multiple times, and think "what could make his more fun?" I build whatever the answer is. Then play some more. Build some more and so forth until I have a completed game.

And of course if the game ever stops being fun I stop playing and developing.

I see so many people with massive designs and go "but how do you know that will be engaging?" How can you know if a game is fun without an early prototype?

All that said only one of my games has made it through all of these steps to actual release. So take my thoughts with a grain of salt.

 

It's not like you just write a GDD and then just jump straight into development...
All the things you just stated you do happens with a GDD too. A GDD is essential for a team to work towards the same goal though. I have to assume you are a lone developer? I can certainly see why you'd question the validity of a GDD in that situation. I'd suggest it is still useful though.

Your design methodology is completely separate from the GDD (though the GDD may state what it is).
For instance, what you described is close to Iterative Design: http://en.wikipedia.org/wiki/Iterative_and_incremental_development
The GDD is the thing that you build up during the initial design and planning phases, which helps keep all other phases on track. There's no reason that the GDD couldn't change completely over time.

 

I am a lone developer. I certainly see the value of documenting the design intent and stuff in a team. And I certainly use equivalent documentation in my day job to help keep projects focused and on track.

I guess much I my ire towards the GDDs comes from never having seen one used properly. As a living document to keep track of design decisions it's probably a great idea.

I've just seen to many forum posts with hundreds of pages of 'design' and nothing ever produced.

 

I basicly use the GDD to help me with my prototyping, it is also something fast so if the project isn't very fun, then I can just scrap it without investing to much into the project

 

This is the main problem with the GDD, keeping it relevant and not bloated.
Especially in a situation where the design is flexible it can cause big bits of the document to become irrelevant or require rewriting.
The solution is to start off with a solid understanding of the general game you're aiming for, and sectioning the document around the important bits of that concept (characters, story, important mechanics). Keeping the document as high-level as possible tends to help avoid having redundant sections down the line.

Traditional software development also has TDDs (Technical Design Document), though they are much more bland and I'd say fairly pointless for games unless it has a very complex structure (an MMO I'd expect to have one for instance).

If it's just you working on the game I'd say you have much more flexibility with what you do in terms of documentation, really as long as it works, there's no problem, if you one day decide to add someone to the team they might need to understand it though .

 

+1 for pen and paper. It's the same for creative writing, too. Once you write it, it's there forever -- unlike an electronic copy where if you delete it, it's as if you never thought of it in the first place.

(I also like mind maps, especially for brainstorming. They work well as group exercises, too, on a big whiteboard. Try it at your next game jam!)

I agree with El Maxo that you need some way to document everything, especially in big projects. Rather than a monster GDD, some groups might prefer a wiki. I'm working on a project that has a wiki with different sections such as Story, Art Style Specifications, Level Designer Instructions, and Implementation Details.

As I implement tools and processes for the level designers, I write instructions in the Level Designer Instructions section, such as "How to Create Cutscenes," and "How to Place Triggers." The level designers can add their own notes, too.

The Implementation Details section just documents how things are implemented for the benefit of other coders. I design the implementation separately, and always with pen and paper. There's no room in big projects for cowboy coders who think they can design and code at the same time without pre-planning. Which isn't to say don't prototype! But I reimplement my prototypes properly when I actually put them into the project.

 

Either way you choose, everyone's brain works differently. A mind map is still a good way to organize.

 

As far as I ever heard, the typical industry cases are that GDDs aren't usually looked at past planning. They usually function like an extended pitch document, but actual development usually relies more on TDDs and asset lists/references.

Not like there are any standards though, so to each their own.

 

I imagine so in bigger studios.
For us it makes sense to just have one document (which does have a small area of technical info).

We do have to make sure everyone is aware of changes to the document, so for that reason I could see the benefit in separating the GDD as the initial plan and the TDD as the more frequently changing implementation.

I suppose it's just a case of finding something that works in each persons situation.

 

At the risk of disgressing from the original topic (initial game design), I'm involved in a project that uses Zoho for dev docs. It's working out well. We maintain documentation in a wiki, track issues with their bug tracker, and manage milestones and tasks with their project management tools. Project members can subscribe to alerts so they're aware when changes are made to documents.

Since we're spread out geographically, Zoho's worked out well, too, for sharing concept art and documents containing design ideas since can we make comments and suggestions right on the shared documents.

 

On the subject of mind maps, we use http://minddomo.com/ for our work. How we do things is we create a Mind Map of the user flow in the game, high level stuff. What are the goals, feedback loops, etc. Then we do a design doc to flesh that out (Mormon and I apparently have different methodology here), find flaws and holes, and flesh the concept. Then we go BACK to the mindmap to map out the actual physical flow of the game, what screens connect where (UI), what features are needed where (UX), and so-on. Then we do the tech doc as to implementing each of those mindmap areas.

This method works better on some game genres than others, but that's the general idea of our methodology. The end result is we have a high level mind map that helps visualize the high level design doc and then a UI/UX mindmap that helps visualize the technical docs.

If you are working solo and can do that all in your head, excellent, but I believe this method works best for mid-large team size and for those of us who like to write things down in order to think about them

That said, for Mormon's sake - These docs shouldnt take you TONS of time, if you're spending weeks writing these things then something has gone wrong (or you're working on some sandbox MMO nightmare project, either way).

 

I agree with not spending a lot of time on this stuff. The high level mind map I posted (which is a perfect guide for me but maybe not for others) took maybe 10 to 15 minutes at most. It was just a brain dump basically. But now I don't need to hold it all in my head and can stay on focus.

 

For my Indy projects, I'm with @BoredMormon. Paper and pencil, all the way. I have throwaway sheets with diagrams, designs, and flows. And then, I have my PROJECT TASK LIST sheets, which are handwritten lists of small tasks that I need to do. For example:

• Balance # of Diamonds
• Tap UI/Explode once - all tiles shake
• Play sound during count down

And so on. I've developed patterns for how these evolve, as I approach each major new feature, the tasks go from "Get basic thing", and "Get first working thing", to "Add thing X", and "Add UI for thing Y". If I change my mind, I mark X to cancel the task. Low-priority tasks are marked with an 'L'. Finished things get a check mark. I iterate, until it's ready to ship.

For professional projects, well, that's another story all together.

Gigi

 

A list of objectives is very handy. I also define a list the way you describe @Gigiwoo when I move into the implementation phase. I make a new list at the beginning of each week. Any objectives not completed on last week's list are placed at the start of this week's list. A week at a time works well for me since I only put 2 to 3 hours per night into this stuff. Otherwise I'd do it like for my day job and make that list every morning. If new ideas come up they are tacked on the end of the list. For example if I realize well to do #3 I really need to do this first which sometimes happens but when it does it is usually along the lines of well to do #3 the best way I should do this first then I can also use that for #7.

There is something very satisfying almost addicting about crossing things off a list.

 

That's very interesting, we handle all of that with individual programs/sites for each area currently, it works well, but I suspect there could be some advantages to having it all central. Thanks for the link.

With regards to documentation in a wiki, we do this too, though it has been a very slow process populating it and trying to convince everyone to contribute their knowledge.

 

I hear you. Bringing this around to the original thread topic, it's especially hard at the initial design stage to get everyone into the habit of using the wiki, especially if you're not all located in the same area and not all working the same hours. It helps to designate a single person to hound everyone down with reminders to use the wiki. But then it picks up steam, and people start posting all kinds of ideas, sketches, and comments. I don't know if Zoho has a mind-mapping tool, but it would be a nice addition.

 

That has definitely been me so far haha

 

I just have a literal wall of sticky notes
Its extremely unorganized (and I should really just get a whiteboard), but it works for me

 

Sticky notes are great! My ex-wife designs dialogue trees using sticky notes on a whiteboard, or big easel paper when a whiteboard isn't available. She draws boxes for major topics on the whiteboard, put stickies in the boxes, and draws lines between them. It makes iteration much faster than fiddling with software. So, essentially, a mind map for dialogue.

 

On indie/one-man projects, I agree. I was using TargetProcess a lot, as we use it at my day job for our kanban needs. The problem is...it's just not as useful for capturing thoughts, or for "inspiring" me to remember an idea. I find when I have to actually write the words myself I do a better job of remembering things and thinking about them.

As for how I start things off, I use pen and paper. I've tried more formal means, I've tried a GDD template...it just didn't really stick (though, the GDD template asked good questions of my design that I've tried to incorporate into my processes as I go along.)

Also, I don't have a monolithic "start phase" - that's so Waterfall. Sometimes an initial idea doesn't pan out (see: the side-scrolling version of Sara the Shieldmage.) The ability to adapt to things changing, or to making discoveries, is vital.

Instead, every week I try to make a priorities list fed by some kind of feedback (either posting in the Weekly Design thread, or me playing my own game, or whatever.) I work on those things, then seek more feedback. "Initial game development" is an ongoing thing, and games, like most results of a trade, are seldom ever "done".

 

Whiteboards are great. I have one hanging on dining room wall I use to occasionally doodle game stuff on. Never quite sure what it will have on it. One day my little environment sketch looked "different" and then I noticed a list in small print down the side: apples, bananas, grapes, broccoli.... but that is what I get for putting it in the dining room. I now have a mini whiteboard on the fridge in case elves want to make grocery lists.

 

I used to write ideas on notepad and UML diagrams, but later I've discovered that things written on real paper (unfortunately i don't have a whiteboard ) are... Better. It's just easier to keep them organized, it's also nice to see them on your desk, to feel them in your hand and they'll motivate you, they'll feel that your ideas and dreams are real... ... Yup i'm strange ;d But that's an honest advice from me.

 

Don't be to quick to dismiss the power of sticky notes. For large group brainstorming sessions sticky note are a very good technique. At my day job we tend to use them in sprints. Every one writes down as many ideas on notes for a short time. Then we organise all of the sticky notes into major idea themes. Then repeat a few times.

Using this process of grouping similar ideas is a great way to get refined concepts.

 

I always start with a scope then a risk analysis then just use pen and paper for the nitty gritty design.

 

Well that technique sounds great, sadly mine is more 'write something down very quickly and stick it somewhere random'

 

I just have a note book which is with me most of the time... as I come up with systems, ideas or any potential issues I write them down also do sketches of UIs and animations (and state diagrams) as well (Wait do you count stick figures representing bone hierarchies as animation sketches?). The overall design doesn't happen for me till I am actually sitting in front of the computer and seeing how I can allow various systems to interact (more due to a lack of programming experience then anything). I think I end up writing more in notes then script lines...