Sorry your browser is not supported!

Hey everyone.

There are basically two distinct types of game developers. I am being very general here.

A. The person who designs everything out from the beginning often creating a Game Design Document. Sometimes documenting every single detail across hundreds of pages. Only when all is documented do they begin any development.

B. The person who has only a concept... often just a vague "image" in their mind... for a game and immediately starts developing. Using a very simplistic presentation they prototype the game very quickly and then iterate developmentally to try out new ideas and find what works and what doesn't work.

There was a time when I focused a lot on doing a more formal design process including sketching out screens, levels, enemies, etc as well as documenting gameplay goals, mechanics, obstacles and so forth. All of that before I started development.

However, I found that so often things changed (needed to change... could change to be much better) I began doing less and less up front design and naturally started doing prototyping only I called it Developmental Design. Meaning I was basically designing through the process of development.

Sometimes I do absolutely no up front design and other times I do write a little story and that serves as my design doc. A story works very well for me because it doesn't impose any restrictions on how to implement things yet it does provide an overall guide for what I am building.

Sometimes I do a tiny bit of planning of things on paper but for the most part these days I do no planning of the tech / implementation side (systems, algorithms) or anything else simply because having done it umpteen times before there is no need to. Yet sometimes I miss that because it was enjoyable.

What about you?

Are you more of a proper detailed design must be completed first type of developer or an interative prototyping (developmental design) kind of developer or a hybrid like myself?

Pencil and paper is a must for me when planning the look and screens of a game. The immediate feedback of lines on real paper helps form ideas without too much effort.

I keep a note book where I can scribble ideas as they come to me at any time.

Having said that, when making a clone of some existing classic game then I know what it is supposed to look like and can skip that step.

I think it is fair to say that the "plan it all out before doing any development", has generally fallen out of favour in many areas of programming. "Agile" programming was a big buzzword a few years back, and is still a good idea, in my opinion.

Part of the Agile philosophy is to build something that does the bare minimum to be functional, get feedback, and then add more and repeat the process. I think this fits well with the small/indie game developer.

As you say, designs can need to change, and if there isn't a working skeleton of the game, then how do I know the game play will be fun or satisfying?

Besides, I am a coder, and writing those lines in the AppGameKit language (or whatever tool I am using) that do magic on screen is way more satisfying than generating pages of spec.

In short, interative prototyping all the way.

Solid stuff @GameDevGuy and I agree it is more satisfying. And we get that insta-feedback from quick iterations especially with AGK2 being so fast to build. Add something, change something. Build. Test. Super fast iterative cycles.

depends for me, I'm not really a pen and paper guy I just wing my apps and half made games most of the time but having done a bit of contract work a solid plan is an absolute must, I got stung with my first ever contract working from a outline and the "oh we want this, and oh we want that" took far longer then I priced for so after that every button, menu and toolbar item and right click menu was planed, written down and agreed upon so any "can you add this n that" was charged as extra, but one thing I still use is a mind map (MindMaple) for my personal projects, it helps me plan state machines and database structures, I find it quite useful.

@PartTimeCoder Absolutely when dealing paid work for other people yes I need it defined so I completely understand what you are saying there. I make (well made... I stopped doing contracting work several years ago) a proposal listing exactly what I will do / deliver and a quote for doing that. Anything outside of that will need to have a separate estimate & quote created.

I also was a big fan of mind maps. I use(d) FreeMind.

It's kind of weird really. Thinking about it... I think why I describe myself as a hybrid is because I have almost like distinct modes for lack of a better term.

When I'm in design mode it is a very different frame of mind than development mode or artist mode (and when I say artist I am only a very amateur artist only having gained experience from decades of making art for my tiny game projects).

So... when I am in design mode I may work on paper or in FreeMind. For example this is a game design I made for a game almost two years ago...


And here is a flowchart (well more like a sequence diagram or heck even just plain "diagram") I used to define enemy behaviors for another game a year or two ago...


Yet at the end of that year I was instead making mockups to design my games and I continued with that approach for quite a while... these are all mockups... most of these are low color... from 10 to 50 colors depending on the game.








Then I switched back to prototyping with very basic graphics...


BTW - that turned into a collab project with another developer and ended up like this when released...


And then kind of a hybrid approach...


I guess I just get bored. ha ha. Need to change how I approach things every so often. And at same time am continually trying to refine the process so I get faster and better at it.

I find the whole wearing different hats aspect of game dev to be interesting. It takes a real mental shift for me to move into art mode and if I am programming and try to make art it is absolutely terrible. When I make the shift... completely shift over then I can make usable art (well if you consider any of the above usable art lol... some of those mockups have some pieces of art made by others and that released game screenshot based on the earlier very simple prototyping is entirely by someone else)). I can shift back to programmer mode much faster than I can switch into art mode. Design mode is about the same as programmer mode yet it feels like a cross between programmer and artist modes.

Whew! Sorry I really rambled on there. As you all probably have guessed I do enjoy talking about game dev. It is a very interesting thing. And like now I have no desire to do anything at all so talking works well. lol

I plan out the interface, important features and graphics ideas on paper. The first thing I code is always the basic game engine (with everything hard coded). Next I modify my code to be extensible (so I can load levels from files etc). Then I build the interface/work on graphics. After that I fine tune/add features to the game engine until it's in the final state. Then I create content and touch up anything I don't like and then the game is done

Really interesting to hear about different people's approaches to this.

For me, although I definitely agree that design needs to be iterative and should not be all done up front, I do also like to have a clear idea of what I'm making before I sit down to try and make it, which does usually lead me to write some kind of high level design doc before I get started. Like Easter Bunny, I also usually try and sketch out what I think the game should look like on paper before I really start work on the game.

With regard to rapid prototyping, I have mixed feelings. Rapid prototyping is certainly a popular approach, but I find that it only works for investigating very specific/narrow things. Some games lend themselves well to it, but in many cases, I find that a game only really becomes "good" when all of its elements come together, so the prototype doesn't necessarily tell me anything useful. What I mean by that is that if the aim of your prototype is to work out if the game is going to be fun, and then you make a prototype of the combat system, but the art and fx and sound and story are missing, and then the game isn't fun, it's hard to know whether that's because it's a bad idea or whether it's because all that stuff is missing. And if you add all that stuff, then it's not really a prototype anymore, right?? Does anyone else get this problem with prototyping?

I think this depends on the type of game. What GarBenjamin describes is mostly more in-depth games for that kind of mind-mapping. For that I see the benefit. Perhaps not too far though, and keep modifying as fast, whatever that means.

For more simple games and game mechanics I think it is much more useful to just make it, play with it and iterate on that.