No documents. No documents.

the typical "original design doc" for one of my games is a single sheet of notebook paper with a single phrase describing the idea of the game, such as "simcity with tanks!" and a feature list. maybe one or two passing references to technologies to be used. no artwork, no drawings. nothing else. the next step then is usually void main{}, and away you go! <g>. of course, i've been doing this a long time...

note that as i add features, there may be many design details that are worked out on paper before implementation. i could probably fill 2 or 3 3-ring binders with all the design notes generated while making caveman 3.0. then again, its an exceedingly complex game.

SVGP:

does your team have a game idea in mind yet? that's the first step, irregardless of what development methodologies you use.

For my solo hobby project, I have no real initial plan and I just make it up as I go along (referencing development notes as needed). But I would do it differently if I was working with a team or trying to make money off the end result.

The point of having things like a design document or a planned release date is so that everyone on the team has an understanding of what's expected of them. An offshoot of that is that you are also giving everyone a way to recognize that a project is actually completed successfully or not.

You can certainly get away without a GDD, but you can probably see value in having a way to ensure that everyone is working towards the same goal.

Also, as mentioned, prototyping an idea to get a handle on the fun factor, or to identify potential challenges you might expect on the way, is a good way to ensure that you're not wasting effort. But this could be looked at as a sort of project in of itself and so, again, maybe your team could benefit with a common understanding of what's expected of them as they're working on the prototype.

if you think about it, is waterfall even really possible in game development?

stuff (hardware, techniques, etc) changes so fast, and game designs change so often that i'm not sure its even possible to simply design, it type it in, debug it, profile and optimize, then release. being a development method originally developed for applications, not games, waterfall doesn't include playtesting and balancing in the process, a step which is not required in applications, but almost definitely required for games (unless you're making a chess clone or something).

It is, but you end up shipping a game, where it is unclear whether you'll be hitting fun or not. A lot of hit and miss because you refuse to adjust your plan as you go.

This, sadly, occurs much more often than one might be led to believe.

No documents. No documents.

Some documents. Some documents. I agree that there is such a thing as too many documents, especially with a new team who is not creating a publisher-requested or existing-IP-based game. But to quote Dr. Phil, "you gotta have a plan, or you're just clowning around." Start with a plan. Write it down (even if it's just on a whiteboard, or just stickynotes on a wall) so everyone is sharing the same vision. Agile is not exclusive of planning documents.

Also: if the OP's actual question is "do I write documents and if so, what documents in what order," then this is a Game Design topic. But I sense that the OP's actual question goes far beyond game design, and is actually talking Production/Management (for which we have a separate board).

Waterfall or agile? That's the first thing to decide

Tip: Agile is the correct one.

Next, how many times you have failed already? It changes things, unless you are overgod (there are some people like that), you will fail several first projects. So for first time failure the critical part is a strict deadline (if you are pressed on time), since you want to fail fast, early and a lot (on the other hand going on with a long project doomed to failure gives you some additional experience). After you finished your first game you can give yourself some more slack (but not too much ).

Basicly, determine your time budget, this is the most important aspect that will affect the whole design process.

Next, get a decent solid idea before you start (it's highly recommend to talk about it with others - not your team). You don't want to invent core features after you started the project (I make this mistake over and over again and always pay for it So, don't be like me ).

Then determine your financial budget (how much money you are willing to put into it before you get any sales - if that's your first project set it at "0" ).

Once these are covered I start the project:

1) I write down all core design goals and explanation of some mechanics (not all). Also I research the "marketing" part (who will play my game, track appropriate forums, websites of that genre, fan groups, etc).

2) Then I decide on release date (extremelly important!) and the price.

3) Then I make a prototype.

4) If prototype is good I proceed, if not the project is scrapped.

5) I decide on some sort of overall shedule, at least the milestones like alpha, beta, crowdfunding/greenlight (if needed/planned), final release, etc. Also look for contractors (artists in my case).

6) Then I make the game (if lucky ) adjusting it/redoing as needed.

7) If the game was not cancelled by now I do the release (and all alpha/beta/whatever). And... go on vacations

8) Then, after release I end up in a hell, bug fixing, missing urgent features, etc, etc. All the usual pile of stuff that pop up after you thought you made the game.

9) After like 6 months it all calms down and I only maintain the game and can proceed with another one.

Original Poster here!

Solid responce guys! (not just this quoter)

I have failed about 4 times in the past and I TOTALLY agree, failing faster is very important! hahah I am relativly new to game design practices and find that failing is the best thing you can do! (for leaning and improving that is). It's funny, when starting game design I thought failing faster was a weird concept until you do it. Then you truly understand how benificial it is.

I have been tinkering away at this new game for a few months now. I was in pre-production faze ironing out the details, getting some rough concepts done just to spit ball ideas and now we are in the prototype faze. We were doing heavy research into planetary procedural generation and that gobbled a lot of time. I decided to scrap that for now and stick to more traditional methods for our first project. Too much time was waisted and we need more practice with standard stuff.

Working on this for a hobby, its hard to have all team members get jazzed about working on this. Especially programmers, coding is hard work so asking some people to help after a fulls day work on another job is tricky.

I find that artists are like dogs, cool with helping into all hours of the morning, with you through thick and thin. While programmers are like cats effeciant,finiky, scare easy and operate on their own time. ( No offence to anyone, I say this in good humor )

I guess I was looking for more of a general order of how games are typically built. I know every person or studio is different, and so is project scope. I would like to know a tried and tested way that works commonly in game development.

Example: What should the team do first, work from the inside out (Characters, core mechanics, weapons than environments etc) or work from the outside in (environment, level design, characters, core mechanics etc). I asked a few other devs and everyone gives different advice, most cut eachother up for their design tecnique. Some say use GDD, some don't even bother with it (silly in my mind not to).

Dirty prototypes are the way of it. After working from the outside in, I realize that working from the inside out is best. Working on core mechanics and making sure its fun just to be in the game in the first place. Then we should see how it plays in the environment with the core mechanics at work. (unless I am wrong about that haha)

I need to know what should generally be created asset wise first. I have made massive milestone schedules in the past and more often than not people don't follow along and miss their dead lines constantly. No pay, people just don't bother as much as I would like. Understandable but poor work eithic. I understand why indie teams fail (in the bad way) so much! Money talks.

1)What should artists work on first?

2)What should programmers code first?

Basically I would like to have a guidline, more like a mentor to help me out and steer me in the right direction! An apprenticeship so to speak, without the hassle of going to game design school (over priced and some say not worth it). I come to you guys, looking for this help, please be kind and remember what it was like when you first started.

PS: No spell check, so don't harp on me grammer lovers ;)

I also realize that it's very situational! So asking what should be created art and code wise is a silly question. I am just looking for general techique I suppose :)

> Basically I would like to have a guidline, more like a mentor to help me out and steer me in the right direction!

First step is deciding which elements you are borrowing and which you are innovating on.. Because few games are 100% innovation.

In a small volunteer team, progress and momentum is your friend, boredom and failure are your enemy.

What takes 1 day to write in an elaborate design doc can take months or years to make real. Unless there is a real commitment (like salary), its unlikely to help.

Therefore, while you might write yourself a big design doc of ideas, what you share with the team is a plan for what they can make real in 1-2 weeks that will show a glimmer of fun - something that will create momentum. Something that will convince them "we can really do this".

If you can have fun playing something with stand-in art in 2-4 weeks, then you have a chance of taking it all the way.

Its hard to say much more without knowing anything about your game idea...

If you are making a cookie cutter game (eg like most FPS games) then start with an engine like UE4, make a storyboard, and start assembling assets into a working prototype. Low fidelity at first, raising fidelity as it "works".

If you are doing something more original, start with a 1 paragraph description and a couple sketches, and focus 100% on a working prototype. Make it fun. Do it with stand in art.