Do you have a game spec before you start making your game?

I'm curious to know if people have a complete, semi-complete, or any spec at all before they start working on their games?

I find myself in a situation where, had I spent some time designing the game and writing out a game spec, I might have avoided the situations where I have written a functioning system, only to have to re-write it later on when it becomes evident that the current implementation is incompatible with another system that must interact with it.

But on the other hand I cannot imagine myself being able to write an even semi-complete "design document" for a game before I even start working on it. Many ideas that I try to implement into my games come to me as I am working on a game, and wouldn't have come up in my mind if I weren't deeply involved with the game as I am when I am actively working on it.

I guess that makes me a poor game designer? I imagine working on a team with several people, where someone takes the initiative to plot down the entire (or most of it) game into a design spec for programmers to work off would be much more productive than one guy making it all up as they go along.

 

Sort of, but only in the loosest sense. Sometimes it'll be "a newtonian physics based space game" and then I'll prototype out some systems. Depending on how those things go, I could start with a 2D overhead game that gradually transitions into a full on 3D first person experience.

Once I have a prototype I enjoy, I'll generally focus on outlining loose features, tone, and similar until I have a reference document I can look at during development.

 

I would be willing to bet most people on the forum have a notebook at arm's reach. Of course if you read said notebooks, it would probably be closer to the scrawls of a madman then a technical design doc.

I at least try to get all of the "it would be cool if's" out before starting to code on something. I have been working on a lot of systems that have been fairly modular though, so good chucks of it are expected to handle much more complexity even if it's not there yet.

 

I'm flying completely solo on my project so, I just go by the idea I have in my head. It's a concept I've been thinking about for years, so I have it imagined in pretty good detail. I figure it would be a waste of time and energy to write it down.

But I would suppose having a well documented spec is good for those working on a team.

 

Since Intersog is a game development company with many developers working on every project we do have a game spec before the development. But how complete it is depends moreon clients. From my experience, I can say that the more complete is the spec before development, the more successful development phase will be. Plus complete spec ensures that the time estimation for development will be right and the game will be ready for the release in time.

 

I use a notebook a lot of time for complex problem solving, and then also have very bare bones GDD open when developing. If I hit a brick wall, which needs more fleshed out design, I'll just start filling in the GDD.

 

If I'm building a solo game I'll usually just fly by the seat of my pants, but if I've assembled a team then the GDD is one of the most valuable assets for keeping the project on schedule. Don't leave home without it. It is never complete until the game is complete. Google Drive can be your best friend throughout the life of a team project.

 

Having some sort of design down is important. Having a full rigid spec... I actually think that's more likely to hurt than to help.

To me game design is largely an explorative process. You get an idea, you do something to test whether or not it works - on its own and in conjunction with other ideas - you tweak things, add things, and iterate.

If you're too rigid about where you think you're going you won't end up with optimal results because you're not "exploring", you're just barging ahead without regard for how well things are actually working. You might get exactly where you intended to go, only to discover it actually sucks.

On the other hand, if you have no clue about where you're even trying to get then there's a good chance you won't get anywhere at all. Or you'll get somewhere but never be able to decide when you're "finished" because you never had goals to aim for.

To me a game design is about having a clear vision to work towards, while being willing to change the details along the way.

What do you mean by "incompatible"? Is it a code thing or a design thing? As in, is the issue that one piece of code will no longer be able to talk to another, or is it that the designs of the two systems are now at odds with one another?

 

Absolutely.

 

Excerpted from another thread:

TL;DR; I prototype, settle on a project I like, and then work from hand-written task-lists.

Gigi

 

I tried in the past but I discovered that kind of work flow is not my type. I usually just start with a broad random idea I have in my head. From there I just start developing my game. Making it up as I go.

I feel if I spend too much time planning out the project, writing, documenting everything I want to do and achieve that I would just be overwhelmed and end up not making 80% of the things I planed out on paper in the final actual game. I would waste a ton of time and the projects development would extend to months. I am the type of person who likes to start and finish projects rapidly and not spend to much time on one single project because I want to move onto the next.

It has happened to me before because I tried to plan out some of my past projects and they didn't end up so good and even left unfinished. Lost a lot of time and work in the end.

So pretty much I make up my games randomly as I go when developing my projects. That is the time when I decide to add stuff I want and don't want into the game and when I experiment and see if implementing certain things are proper or not.

I found this to be a better and much more efficient way of creating my game ideas and is just my preferred work flow. I also save so much more time by making up things as I go because I don't need to sit there and debate with myself if this certain thing goes in the game properly or not. Most of the time I just throw in whatever ideas come to me and leave them with out any question as to how it fits in the game or not which is why often people find strange and random things in my game projects.

I realized that my favorite game projects I ever made up are the ones I made up randomly because I had the most fun creating them. I didn't limit myself to anything I just left them completely open to whatever ideas came to me and put them in there.

Its all about personal game development style in the end and everyone has their own workflows. Some prefer a planned out one and some prefer to make it up as they go like me. But regardless of which of the two workflows are chosen I feel that they can both be very organized if done right

 

Gotta go back to the difference I mentioned before between lone gunman vs. a team. A lone gunman has the convenience of keeping a morphing GDD within their own skull. There's no need to write it down when it's just you. When you have a team, a lack of a clean and up-to-date GDD is a death sentence. I've seen the horrors it can cause first-hand.

That said, I totally agree that a rigid plan is a bad idea, and every successful game design process should have large amounts of exploratory iteration. The GDD should evolve primordially as a record of your exploratory results as you go, but it should not fall far behind your progress, and the team should be able to rely upon it daily for coordination.

 

I find that writing it down can be immensely helpful. It can help clarify things, and seeing it not-in-your-brain will help you identify issues. Plus, if you're breaking it down into tasks or making a project plan it's good to have the end goal explicitly documented before starting those things.

 

Getting the plot line down (if one is required) seems to heavily dictate what the game is going to graphically look like, they also define cut scenes. Always a good place to start .

Then there is drafts for combat mechanics / UI / features, which then in turn leads to a near complete game.

Obviously it never goes 100% to plan, but it gets you most of the way there.

 

Especially when the notebook is kept near a bed. There have been times I've been trying to sleep only to have a solution to a coding problem pop into my head. Now whether or not I understand what I wrote the next day is another matter.

 

I would advise writing down a list of the risks of your game in order of the highest risk to the lowest one. This becomes your specification / order of work document. You start at the highest risk and once you've mastered it you move onto the next risk.
For most games the biggest risk is that the core game play isn't fun so you start with that. But for some other games there are risks that some technology or game mechanic won't work or that you won't be able to organise all the content. This way you minimise having to redo work because things about your game changed that you weren't expecting without committing yourself to an overly rigid specification.

 

While I can see how you could derive an order of work from this, it's in no way the same as a spec...

I definitely agree in regards to doing the riskiest bits first, though. No point investing any more than you have to before confirming that your ideas are sound.

 

It's spooky how many devs I've spoken to who have this happen. I even had someone tell me they used their phone to record a short vid of them blurting out the solutions instead of writing it down, hoping that this would solve the "wtf did I write" situation next morning. It didn't


As others have said, I will usually prototype the key parts of the gameplay before writing much down, then rough out the design in more detail afterwards. I usually only write specific lists when I feel it really calls for it (List of weapons in a FPS etc).

It's also a good practice to prototype any risky 'tech' part of what you want to do, just to make sure you do waste a lot of time working on a project to later hit a roadblock with a key tech feature. For example: If you want the game to take part on the back of an 80 foot tall sentient voxel hippo, that morphs and adjust to how the player plays - make sure you can pull that off before you spend 3 days designing the bonus outfits available from your DLC!

I do have that notepad handy, but I also use a personal wiki to keep everything organised - everything from 1 line ideas right up to 'fully' fleshed out designs.

 

I'm a lucky one, in that a) I do typically understand what I wrote but moreover b) it usually doesn't matter because I remember the solution anyway. For me the major downside is that if I don't write it down my brain keeps a death grip on the solution so darn hard that it keeps me awake. So I write it down more as a cathartic release to make my brain happy to let it go.

It's not just sleeping, either. Doing stuff generally other than programming is a great way to come up with neat programming solutions. Apparently the same applies to other creative or problem solving stuff too and there's some psychological theory behind why that's the case, but I've no idea what it might be called.

 

In a recent Rami Ismail talk, he describes this in a couple of different ways:

* Don't make the game that's in your head, since you don't want to go from A to B only to discover that "B" actually isn't fun. You want to pick a direction and go from A to "question mark."
* Let the game speak to you as it evolves. Don't force it to go where is doesn't naturally want to go.

In other words, exactly what you're saying. Food for thought for sure.