Before you click "New project"

Hey all, just wondering how everybody does their "perp work" before starting the actual code and art for the game.
How do you layout your ideas and understanding of the mechanics and whatnot on paper/text file?
This part is taking me way too long and I could really use some insight on the subject.

 

If you've done all the prototype stuff up front - a dev can jump in with only a pitch or treatment document. I prefer and enjoy the design document writing process. I think it brings the game even closer/intimate to the developer - and can even provide some detailed indepth knowledge of all the features/mechanics - prior to starting on development. Even though this might take 5-6 days (my time) it is still a time saver - imo - because it makes the developer think critically and technically about areas of the game they may not have considered before.
This can also be a disadvantage because by becoming intimate with the design - one might become disillusioned by a certain element/mechanic of the design that is not good for the overall experience. This is unlikely because by writing the design - it kind of forces the creator to work out all aspects of the game along with prototyping - so one can't simply be short sighted on much of anything - unless they are not truly committed to the design document.

An alternate view point - which is just as productive to some developers is to get to work directly after outlining the pitch or treatment. These documents are not as detailed as the design doc, but can be used in place of one (imo). Especially for smaller less complex games, games like rpgs, simulations, fighting games, rts or branching narrative based design kind of require a no-sh1t design document to keep everything organized and everyone aligned. If your game isn't one of these - you might be able to progress well with only a pitch or treatment.

With a treatment or pitch I'd scrap all non-indie stuff that doesn't relate - investors, exec summary, bla bla stuff, just focus on mechanics implementation and flow. Other non-essential stuff will fall into place. A treatment/design doc mismatch is kind of needed, without certain elements of the DD a treatment can only be used as a high level guide towards the overall goal/experience.

And then lastly - there are those developers who are able to design while creating. I think this workflow is kind of unfocused and loose, but can lead to some interesting - things. It's not my preferred process - but it seems others have had success with less structured design/development processes.

Someone years ago posted on gamasutra 3 documents, the pitch, treatment and design document. I don't have the links at hand - but I found those documents to be a great starting place - to modify the documents for ones personal use.

 

For me making a cup of coffee is pretty good at creating the illusion of having done any sensible prep work.

Otherwise I'm starting to think the most efficient thing for me to do is assume most of my ideas are bad ideas, and trying to find out the specifics for why something is a bad idea as soon as possible. Usually that will be something gameplay related or the process requiring a bunch of a kind of work that I don't like and might not have considered yet. Then abandon project and repeat for the next idea. Not sure if that will ever amount to any project getting finished, but if I can just cut down on time being wasted on projects that will get abandoned anyway, then I consider that a huge win. E.g. recently I thought I had a great idea for a game about zero-g spaceship hull repair, but through the roughest of prototypes I could determine within a day that any kind of true zero-g controls are nauseating as hell for players, so I dropped it. Great success! Not even a full day spent to learn something important. Other things I've abondoned are in the hundreds of hours...

 

Maybe that could be considered part of the difficulty - rather than git gud - it could be don't barf! HA!
"I challenge you not to barf"

 

Paper prototype, and playtest the prototype with friends. It's much faster than struggling with Unity and other tools while you're prototyping. Think of how many more bad ideas you can get through if you can prototype faster. Some things are hard to paper prototype (such as zero-g physics), but you'd be surprised how many things you can approximate on paper.

Once you have a fun paper prototype, you can jump into implementing it in Unity as a digital prototype. Playtest this. Then write your treatment (1-2 page document). Then start a new Unity project from scratch using good software engineering practices. Don't try to build your prototype project into a releasable game project. It'll waste more time in the long run than if you start clean.

 

I think it takes some experience before you even know how to plan.

I can only speak from my short experience with 3d modeling, but it wasn't until I'd made a handful of complete models that I really started to learn what things I really need to plan for from the beginning. You kind of need a good amount of trial runs to learn what you didn't know you need to know.

This all assumes OP is a neophyte. Sorry if that's not the case.

Coffee helps. Get one of the manual hand grinders and get it real fine.

 

This makes me wonder why we don't have something like a "paper prototyping" thread. Or perhaps one could make a thread for a single prototype? This seems like a good place to discuss such things, but we mostly talk about specific design issues here, and almost never about a full experience.

 

There have been a couple threads discussing paper prototyping, but I can't recall any threads specifically dedicated to feedback on paper prototypes. I think the Feedback Friday thread would be a good place to post photos or other paper prototype materials to get feedback.

 

The first thing I do is I scope the project. I start with a high level idea of what the game will be, then I break it down into high level features from the user perspective, at this stage I include anything I want in the game I can think of. I do a lot of investigating the competition or other games of the genre, talk to people about the game idea and what they think, ask friends who play that type of game what they would want in the game, etc.

Then I rate all the features on a scale something like Required, Really Want, Nice to Have, If I Have Time. I then look at just the Required features and determine if I only did those, is this going to be a good enough game for people to play and to fulfill my vision for it. If not then I repeat the process of rating them all, until there is a good enough game with only the Required features.

I then start investigating what will be involved to implement all the Required features. This may be just writing it down, or might need some web investigation or in Unity prototyping. If it is a big feature then I will break it down into components and rate them all like I did the high level features. I'll then estimate the amount of dev time it will take to complete all the required components. I'll do the same for any costs involved, such as hiring a modeler or buying 3rd party assets to implement the feature.

I'll add up all the time and costs involved in all the required components of all the required features, and decide if I should move forward with it.

So at the point I decide to run with the project, I come up with a rough order that I want to work on different parts, which usually involves doing an early pass through features to get them to a minimally implemented level (AI just runs at the player instead of more complex behavior for example) and have in the plan to make a full pass through to fill out the feature later.

After I have that general plan I start getting to work on it, and depending on how things are progressing I consider bringing in some of the lower priority features or components or whether they need to stay scoped out. Some of them I will specifically slate for a later update if the game is successful, some of thing I will bring into the initial release, and some will just stay as notes to be considered again down the road after the game is released.