Design How do you plan your game's development?


Yellow Dog
I've often fallen into the trap myself of plunging straight into the heart of a game's development without properly planning ahead. This leads to a rapidly escalating level of complexity which leaves the project difficult to continue developing. I was always taught at school to plan my essays and such before starting to write them, so I don't know why I never seem to take the same approach with game development.

I'm assuming that any successful - and sufficiently large - projects that you lot have produced were backed up by a huge amount of planning beforehand. I get that some games just don't need it (like Flappy Bird) but I'd say anything more complex than that really ought to have a plan in place before development begins.

My question is then how do you structure your plans? Do you write out a full game design document and make sure that's absolutely perfect before writing even your first line of code? Or do you write the first half of the document and then begin developing the game and the document side-by-side? If you later come up with features that weren't considered in your design document, do you try and add them or leave them out to avoid the risk of having the project get too complex?

At a deeper level, do you perhaps plan out your code structure before beginning to write it? Maybe some sort of giant flowchart which shows the inputs and outputs of all your scripts and the ways they interact, but none of the actual code. Do you perhaps write pseudocode first and then write it out properly later? If you produce prototypes for the various mechanics in your game, do you start your project building outward from these prototypes? Or do you start a new project at the very beginning (menus and stuff, I guess?) and implement the prototypes as-and-when they become relevant?

I think knowing how to properly plan projects would massively increase my ability to actually produce games, so I'm eager to find out what approaches work for this community (and indeed which ones don't). Looking forward to hearing your contributions. Sorry if this post lacks structure - ironically I didn't plan it.

Many thanks,
~Druid TC


As someone who does game dev as a hobby rather than professionally, I usually have ideas swimming around in my head for a few days, and then write down briefly some key points I want in the game.

My current game for example, I had written down that I wanted to first and foremost create a multiplayer/party racing game, ideally with 8 player support, and with customization elements, such as a variety of options to change the game, and a track editor. Along with a list of game modes to include, and a list of similar games I knew of to play through and see how they handled things or if there was any features in them that I wanted to recreate in my own game.

I then alter the games design based upon other games I play on the "similar games" list, and feedback and suggestions I get. If I get a good suggestion, I have to weigh up the "benefit vs time" of it. If it's a big benefit, it's probably worth any amount of time to implement, and it goes onto the "TODO" list. If it's a "nice-to-have", then it gets written into a "suggestions" list, where if I have some spare time, I go and look at and see if I have the time to add any of the suggestions I've received from testers.

TL;DR I make a basic document outlining my goals, what key features I want the game to have. It gets altered as I receive inspiration from similar games and feedback from players.



Make lists for everything.

Everything that needs to be done, add it to the list. If one of the items in the list is a bit more complex and it's soon to be done, break it down on a separate list. It'll help visualize how much work it's gonna require.

Also, everyone will have billions of ideas in their head. That's normal. But if there's anything you've already decided on, write it down. Sometimes, writing things down will actually help you realize that your idea doesn't work. Or that you're still missing something for it to actually make sense, even if in your head "it just works". I'm not saying you always need to write a complex, detailed design document. Just something to make sure you can make sense of everything.
I find that whenever I try to plan out a game, I go overboard planning and never get to actually developing anything. I get stuck in planning and designing limbo.
But as projects get larger, keeping track of certain things like assets or systems you have/want with lists can help.


The community has pretty mixed opinions about planning in general I've noticed.

Personally I probably learn more towards the pro-planning side than most.

I think GDD's have a lot of benefits even to solo devs. However they're meant to be a tool that works for you, there is no need to have a fully verbose GDD if you're solo. Most my GDD's tend to be sections of bullet points rather than elaborate paragraphs of prose. I also usually maintain a handful of google doc documents for jotting ideas down as they come to me. Being cloud based means I can do this on my PC, or my laptop or even my phone, then at a later point I can go through these docs, decide which ideas are good and integrate them into my GDD.

Trello is another planning/admin tool that I personally find invaluable. I currently have multiple trello boards set up for my current project. I have a big content and features board, that includes all the things I need to add or change to get to 1.0 state. Currently I'm on a big "game feel" push, so have set up a board for that. My game feel board has sections for mechanics, animations, vfx and AI. I also maintain another trello board as a bug tracker. I find this helpful as when I am working on one aspect I will find bugs or notice issues with other aspects of the project, rather than getting distracted fixing these other issues I can just add them to the relevant trello and keep focused on what I am currently doing, safe in the knowledge that they're being tracked and wont be forgotten about.

The main thing with this sort of planning/project management to remember is that, its all meant to be a time investment. Every minute you spend on planning/project admin should save yourself multiple minutes over the life of the project so be wary of taking this planning/management side of things too far.


I totally started the wrong way....

I had a vague concept in my head of the type of game I wanted to make, then plowed straight into creating icons, main interface, individual tiles for the game map and then various other graphical bits ..... nothing at all of the "design" really.

After a good few months of this, I figured I would spend however long I felt like to get done everything but the programming, then seek out a coder to collaborate with. However, I got a wake up call when a programmer volunteered out of the blue after seeing some of the gfx work, so the laid back attitude had to change.

I needed to plan it out more so it made sense to me and I could hand it over to be coded and have it still make sense, so then I started researching game design documents.

Completely changed how I looked at things, and now the gfx are taking a back seat and all the design work is the first priority. Lots and lots of work to do, but hopefully, it's now going the right way.
Last edited:

Joe Ellis

My plan is: don't plan, it makes stress and that makes you work less effectively, I work on what I'm interested in, and most of the time, my interests revolve around the things that are most imporant, I think this is a good cycle to get into, it really works


Yellow Dog
Do you find that you run into hurdles that could have been overcome by a more thorough planning approach? Like halfway through development you realise that an important feature is gonna require a complete rewrite of some earlier code you had. It might just be because I'm only a second-rate programmer but that's the trap I always seem to fall into. I've tried jotting down ideas in the past for almost all of the larger projects I've started but that never ends up being the area I falter on. I've never finished a project and realised 'oh snap I forgot to put in this feature' as the outcome would be if I were writing an essay, for example. It's always a case of trying to tackle a problem from the wrong angle and either being unable to do so, or have features become conflicting later on and requiring that large portions of the project basically be restarted from scratch.

Golly yes I do love a good list. The approach I'm taking on my current project (and the reason I made this topic in the first place) is to try and develop the game completely in Microsoft Word, before I even open the IDE. Then it should simply be a matter of writing a bunch of scripts to achieve all the various tasks and stitching everything together into a game. I don't want to have to do any thinking once I open GM. At the moment the GDD is just reams and reams of lists.

@Siolfor the Jackal
Can there be such a thing as too much planning? Surely one day you'll reach the ultimate plan and be able to bang out your project in a matter of weeks,

I'd never heard of Trello before but I've just looked it up and registered an account. It looks like it'll be very useful! I also like your approach to planning as a time investment. Fortunately my average development time for a project is infinity so anything that allows me to actually get a project finished is a worthy investment ;)

I envy your ability to actually complete projects without planning them :p

I confess I wasn't expecting a response from anyone coming from a graphics background rather than a programming background. That sounds like a very unorthodox system you had in place - it reminds me a bit of a competition a while back where entrants had to design everything about a game except the game itself. That is to say, they'd design the box art and the cartridge and maybe some fake screenshots, but never actually program the game. I can't find a link but maybe someone else knows the one I'm talking about and can find one?
Have you ended up with sets of sprites and stuff sitting away in folders that you never found a programmer for? I confess I haven't spent all too much time in the new forum but on the old one at least, programmers far exceeded artists in number. There were hundreds of topics of programmers looking for artists to draw the sprites for their games.
I'm also curious as to how your approach changed once you started looking more into the programming side. I would have thought that the graphics would remain unchanged? If you have a set idea for how you want your game to play, then surely regardless of how it's programmed you still need sprites of your character moving around, etc.? Or was it more that you came to appreciate how feasible certain ideas were in the first place?

@Joe Ellis
Personally I get more stressed when my projects fall apart after I fail to plan correctly. I can see your approach working on smaller projects but would you change anything if you started working on a game of - let's say - An Untitled Story's proportions? How about taking it one step further and considering something like Undertale?


@Druid TC

I didn't have a system at all, I just knew I wanted to make one, and plowed ahead with the bit I knew best.

I did some playing with ideas, and have some spare graphics stuff lying about, but nothing spectacular, just work in progress mainly, so never looked for a programmer at that point. The last one I messed with some time ago was the beginning of some isometric city stuff, which i'd never attempted before, but it didn't get far so I threw it on opengameart before I started my current stuff rather than let it just fester on my hdd.

As for the old forum, I did a basic test interface for someone on there just before it was archived and this one released, but have no idea if it was used.

Right now i've just been working on my current stuff, primarily overhead city, but need to stop as the design needs to be first and I keep procrastinating and going back to the gfx instead.

For instance, in the last week i've done five logo samples for other people and a railway footbridge for my game rather than the design itself....

As for the approach change ...... Rather than just an idea in my head, I actually started making a game design document, and writing down the basics of the game plan, then went off on other tangents listing testing requirements, questions to ask the programmer (sort of musing to myself in the document), listing character skills, roles, role modifiers, character improvements and how they affect stats, gameplay ideas, a to-do list, in-game news event lists, gang names, random events, gang events, all sorts of stuff that will be needed, but that I had never documented before.

The graphics themselves didn't change as such, just that the other requirements I needed to do for it, became much clearer when they needed to be written down, and then other things crept up that I hadn't considered, more to do with gameplay and with the scope rather than feasibility, but that the main thing was I really needed to force the gfx to take a backseat. Still working on that one :) .....


My game design document template has this section in it to get me thinking and started quickly.

Development Stages

n stages are planned for in development.

  • The date of the original idea 00/00/2018.

This is the current state of development as of 00/00/2018.
  • Create a game design document(this document) nn pages long.
Pre-Alpha 1.0
  • Define a minimal viable product(MVP).
  • Build the MVP within 6 weeks.
  • Evaluate the MVP and update this document if we decide to continue the project
  • Include plans for the engine and systems needed
Release Candidate 1.0
Lifetime support
I never do any careful planning, just maybe think up of some rough idea(s) of what I want to make in my head, and then go with the flow. I'd only begin listing out what I need to do or fix at a very late stage of the development. Not a good practice, and extremely unorganized - don't follow my footsteps it's extremely bad practice. :p But if I was to be organized, I'd spend more time planning than actually making it. :rolleyes:


I don't have a resume full of large projects that were finished and I'm still struggling to figure out how to keep programs clean, but this is what I've managed to use in the past.

For any story based game a storyboard system is generally what I go with; which can actually help with how to break down your program, before you start to code.
I find it hard to plan without some type of actual prototype. So, I'll often just start playing with things and seeing what I can wham together and where it starts falling apart. The latest game I've been working on has probably been "re-coded" close to 5 times, if you notice yourself "tacking" things on here and there, it is probably a good time to stop and figure out why you are needing to add things to your structure.

I have slowly been moving away from projects that leave me paralyzed with complexity. If it's not easily summed up and understood within 10, or so seconds it is probably not worth the mental energy; although this probably varies with personal ability and attention span. I find I need to be able to quickly look at something find what it does and then free up my mental energy to focus on the next thing. Here I am strictly speaking about reading code that has already been written and if you notice an area of your code that is not working you may have to actively work on it, which will take more time.

Here is a succinct article on program structure from a c++ point of view. It is a good way to conceptualize most programming tasks even in gml; although, with an event system things can get more complicated.

For me personally the whole point of planning is to be able to free up my mental space, so I can effectively focus on 1 and only 1 thing. This may result in my programs becoming more verbose, but any time I can write a function prove to myself it works and then never have to check the implementation of that function again is sweat off my brow. I'm not really sure how to effectively apply this to gml yet, but trying to keep the lines of code for the script or object event in scope to what fits on the screen is something I am considering. In my case that is 50 lines, if it can't be done in 50 lines then it needs to be broken up more.

I tend to stay away from flow charts except for really specific things. I wouldn't write a flow chart for a full game, but might for any type of system that has strict ins and outs like state machines or some network operations. Anything that loops on a time based structure or you need a circle to represent would be a good candidate for a flow chart, but for other things a list from top to bottom I find is easier to keep clean.

Basically if I find myself avoiding a project or procrastinating -because the mental energy to figure out what to do next is daunting or I'm going to need to bog through old code for 20 minutes to figure out where to start- then it's time to figure out where things went wrong and fix them, which might involve re-writing most if not all of the code... except this time with a new plan. Once, it's good and you can forget about it, that is a good feeling!

I also need to better follow the don't repeat yourself rule. But, it's also a good indicator that things need to be redesigned or fixed if you find yourself copying and pasting or repeating a lot.
Last edited:


I don't do any planning at all, other than having some vague notion of the game's style and genre, because I'm a pathologically disorganized person. I've tried doing GDDs in the past but they just stressed me out and I was immediately unable to stick to them anyway when some new inspiration struck. My projects grow like bonsai trees, as I slowly add new elements, pare others down, or weave others into a single system. My process is to run the game, think "what would make this slightly better?" and make changes accordingly. I have like 6 main projects and none of them are complete. Usually I'm working on 2-3 of them in a given week. Some of them are getting pretty close to completion, I think, though I don't truly care if I ever finish them. For me this is more about artistic expression through design than creating a product or appealing to an audience.


I usually do things in steps: Big Picture, Prototyping, Define Ideas

Big Picture: write everything that the game will have, but in very broad strokes. Here goes the game mechanics, major functionalities, etc. This will give you the major idea of the game. Example:
  • Customizeable ship
  • Heavy use of particles, for shots specially
  • Adaptable leveling
  • Unlimited random levels in waves
  • Enemies with patterns

Prototyping: after that, you know what the game will be at the end. So you start prototyping one item at a time. In the prototype you will often find new ideas and difficulties and some points could be added or included on...:

Define Ideas: at this step I define and write what will be "inside" of each item in the Big Picture. Again, in broad strokes, but not that broad now. After I get the picture of everything on that module, I define each item and DO IT. After an item is done, I define the other, and so on and so forth, until there is no more items to do.

This works amazingly for me. I'm delivering a second game in July. Took me 2 years of leasure-time. But it's done! =]


šŸ§ *penguin noises*
GMC Elder
I make lists for everything. I usually have a "main GDD" which has the broad strokes (always starting with an elevator-pitch synopsis), and then a bunch of "SubDD" documents which has all the details about a single thing (usually these are detailed lists of items, characters, etc that would bog down the size of the GDD and make it a pain to sift through). Obviously all of these documents reside together in a project folder so it's easy to switch between them, or open all of them at once when you wanna do some serious planning.

And then I have a TODO list which I add the next bunch of features to hack together, which is a very living document (just a text file that's permanently open in Sublime) - add something when you feel it's time to actually implement it, break it down into simple tasks (each one should be trivial to implement), mark each done task with a checkmark or # sign or whatever, and then delete stuff from the list once it's fully complete, tested and backed up in the game file. TODO lists on paper are nice too (since it feels much nicer to check something off on those) but it's a bit impractical if you work on the game from more than one computer / location.