Game design--an unnecessary process?

As I was thinking of asking this; I answered my question. I was going to ask "In a multiplayer game should every attack have a defense?". The answer was yes, the other question was just how. The popular Call of Duty series seemed to allow three "perks" (advantages) and a few attachments. If your player character didn't have a particular defense you were SOL until respawn.

Well after going through all that, a thought occurred.

Its been said game design documents are not very useful. They don't predict the end-game accurately. Problems may arise in the middle of development. Some features get cut.

What if games are just not meant to be designed?

I'm sorry if that sounds wrong or "against the grain"--the process seems fundamentally broken to me. I struggle to put together a coherent GDD and the implications of my designs are a thousand-fold and dark.

What if games are just something you've got to iterate on to find something fun in? How board games like Chess, Checkers or even Monopoly were created I am not sure. I do think the creators chose a theme and iterated to produce the final.

So maybe a better way to "design" games is to think of a theme and imagine mechanics built around it. Then, iterate!

Food for thought.

 

As a designer, I'm tempt to say yes and no. In practice I found that game design document are useful planning tool for the overall progression. But the lower level the gameplay is, the more it will break, for low level gameplay, at best you should outline "intent" and the "target experience". It's useless to put that your input will need a 3 frames buffer on attacks if it's has never been proven in practice. Also design doc are supposed to be flexible and be constantly updated. They are useful to document the current state of gameplay decisions, based on observation (playtest) and implementation, and keep track of the high level structure of the game.

Personally I have separated game design and play design. In this personal version, game design is the high level structure and general goal, that is generally stable for implementation; it is mostly affected by production events like cost evaluations and resources affectation, it's basically the holder of the scope. Play design is the risky part, you have to prove it against a targeted audience, it's unstable and rely on iteration to get perfected; it's the reason why some game designer get totally stump as why their magnificient idea are trump by a silly bird going between pipe, belching cat and bubble wrap popper, it's all about psychology, visceral and the tactile aspects, it's about the immediate fun and comfort.

What you often see is some games that are immensely fun but have poor progression mechanics and don't hold you long, even though you had a good time, then there is the game that have a solid structure in which you go through the motion but realize it's a rather shallow experience (for rpg full of silly fetch quest), it's because game design is easier to rationalize and repeat than play design. It open the door for some company to abuse design in cloning fun game with great play design and put the works in polishing the game design, Zynga use to do this to dominate the market, find idea that works and add the progression (retention they use to call this) to make it stick.

It's my personal interpretation, does that make sense?

 

As far as I know there's great consensus in the project management discipline that planning is an often neglected, but very important factor for an efficient, succesful project. Game development is a project, design is part of the planning part. If you start building without properly planning first, you are bound to make errors costing huge amounts of time and/or problems with the end product.

The plans/design document will cost time and rarely, if ever, be perfect. But time invested in early planning will save time later in a project, it will generally save more time than time spent. As the early planning will not be perfect, most project requires revisiting of planning/rethinking of plans later on in the project.

The bigger the project and the more people involved, the more important is the planning/game design and the quality of the documentation/GDD.

 

I think that's true, but we also have to recognize that games are not like other projects in one important way: they have to be fun.

I do a lot of non-game projects in my day job, and a successful project there is one that solves a problem. It's often pretty easy to define what that problem is and what would solve it, so you design a product that does that in a smooth, efficient manner, implement that design, and users are delighted.

But with a game, it's much harder — you could make a smooth, efficient implementation of a clear design, and still end up with something that is no fun to play. Finding the fun is a very tricky business, and I think iteration works much better for most of us than standing on a whiteboard trying to plan the fun.

 

Design is a lot more than just the design documentation. So if you ask if games were meant to be designed? They yes, of course they were! Even checkers was designed by someone who came up with the idea and tested it to see if it worked...of course it came from ancient games and then evolved over many years into the version we see today.

So basically, design then coupled with hundreds of years of play testing and changes, etc. In fact, recently a man came to our Unity User group with a new board game, sort of like chess but much more complex. He talked to us about the years of testing with friends and the changes he made along the way. It was quite interesting.

Of course games are usually made to "evolve" during the testing period at a much faster rate. The design of the game is simply a plan for what the game is about, the target audience, the game mechanics and how they will be done, the marketing plan, etc. It is never set in stone, as it will change again and again. But without it, you risk the chance of feature creep and losing your way. I would argue that even the simple use of Trello or HacknPlan are a part of the overall design, as well as spreadsheets for content.

Could you make a game without a design? I am not sure it is entirely possible at all! Even if the design is all in your head, it is still a design. The documents just keep you organized and on track. The simpler the game, the less docs you need. But if you want to make an rpg or an rts, I suggest you document your ideas at the very least or you will end up with so much fluff and extra "cool" stuff, that your game will go on forever. Iteration during playtesting may help but if you have everything documented, it will be much easier to go back and make changes. You will know what you did, why you did it, and be able to limit the scope to something realistic.

And game design only costs time. Iteration could cost money, depending on if you have to hire out for some of the work or if you have to toss work that you paid for...or even buy new assets.

 

In regard to the GDD- a document detailing the design of a game is of increasing usefulness as the team size grows. When a team consists of one person, you can keep most of the design in your head- and perhaps jot down some notes whenever you think of something new you can't implement right away.

When you need to communicate the design to another person, you can probably just make do with a short meeting.. but as the team grows it will become very valuable to have more and more of the design in a written form.

A GDD can also be valuable as a sales tool- you can flip to a page and show "THIS is why our plan for monotization will work." flip to another page and show how "X Y and Z features will work together to drive players to return."

As always, what works for you is always better than what works for other people.

 

You are confusing game design with game design document.

Game design is critical. It represents every desicion you make about how the game feels and plays.

A game design document is only useful once you start to get to a mid sized or larger team. As long as you can get everyone together in a room frequently, a GDD might be a waste of time. But once that becomes impossible, some sort of guiding documentation is critical. Otherwise the team will head off in different directions.

And as a solo dev, GDDs are just a fancy way of procrastinating.

 

Pretty much what I said. I can't imagine just making a game as you go and not put any thought into the end product at all. Sounds fun but probably won't produce a finished product...even if just a hobbyist.

 

It's also worth pointing out that games aren't super amenable to front end loading. In the normal project world you do all of your design up front, before you start building anything. Games tend to do better with ongoing design work and iteration.

 

I used to think that, a few failure after I don't anymore, it depend on if you have game dependent on low level gameplay or hi level progression. I would say low level gameplay don't need one for sure. But if you go RPG, put that down asap and work on it, you can figure out a lot of thing before botching implementation and waste time, like did repeatedly before. For some project a GDD can double as a paper prototype.

 

Absolutely.

I think that is a personal opinion that does not apply to everyone. It really matters on your goal. I know plenty of solo developers whose goal is to produce a finished product and who hope to gain contract work. A hobbyist maybe doesnt have to worry about it but then again, many hobbyists turn professional eventually.

A game doc shows they are serious, aids in fundraising, can be used to show concepts, and will keep them on track.

Procrastinating? I might agree that posting on the forums is a way to procrastinate, but sitting down and organizing your thoughts on paper makes you actually think about what you are doing. I know I have had some great ideas, forgot to write them down, and lost them.

Procrastination means putting off making the game, but in reality, designing and even making the document if that helps you is part of making the game. Not everyone needs it but no need to insult folks who do.

 

Perhaps I was overly harsh. But perhaps not. Can someone show me examples of successful solo devs that started with GDDs?

We gave plenty of examples just in this forum of people with comprehensive docs and no games. I've been involved in a few projects that went that way myself.

 

Can confirm. I've been guilty of this.

GDD definitely has potential value even to the solo dev, but when I'm doing my best design work, I'm pouring myself into prototyping, iterating, trying to "fail fast" ect... When I sit down to write a GDD its usually not until I start to feel the need for one- I've forgotten an idea, or I'm getting ready to explain it to somebody else, and I want to put the pitch in order so it sounds good.

 

Is there solo dev with ambitious high level structure that finished something? Now you brought that up, I'm questioning myself lol about this point. All I know is that my current project (that is both story and culture constrained) start to go better when I wasn't trying to do random model and random code.

 

Three second later

...

Well do devlog count? Because where I come from (tigsource) there is plenty of them and they sure are documenting change and anticipating addition. Notable are minecraft, Ultima Regum Ratio, Cogmind, Paper please, and many others ...

 

btw. regarding game design documents, they are not supposed to be rigid. They are meant as a way of structuring and organizing your thoughts/ideas and get a better idea of what your plan is and how to realize a game/project.
Those documents SHOULD adapt, the moment you gain new knowledge that would discard certain parts of the design document....and same goes for game design in general.
planning out the game is an orientation, a place to start from, something you can look at and see what needs to be done or also in retro-perspective, to see what didn't work out. It makes you think deeper about certain topics and specifically with games and the vast range of working fields, it would be (almost) impossible to keep everything in your mind at all times, so it's always helpful to have some place, where everything is written down and best, if it's somehow organized, every important easily visible.

Just as an example, in my game critters, I had an idea to let my cubs jump on the backs mom, when they are going to sleep or crossing lakes and such. I loved that idea, but when I actually started going deeper into it and had set the sizes I wanted them to be (cubs needing to be visibly smaller than mom, but they grow to full size and their faces need to be visible cause they are the "interface" for seeing what they need, so they can't be too small)
I realized, that I can't actually let them jump on moms back if they are the same size as mom I didn't even write a single line of code for that "jump on mommys back" functionality and I already had discovered that one of my ideas is flawed and needs to be redesigned to work (or discarded).
If I decide to discard it, that saved me a lot of work. If I decide to keep it, it's probably gonna be more work, but might just add more content to the game for the player to enjoy, that is following a consistent logic. Although, to be fair, it would be funny if they would stack on top of each other, giant tower of cubs XD

 

For the record, your example is a good case of why game design is important. It doesn't actually make a case for writing it down.

As I pointed out earlier, doing game design is independent from writing it down.

 

Ok so I've been reading your responses. Most of them. Wish people would keep things short, sometimes I don't like reading a wall of text.

Recently found myself actually putting together a GDD. At first it was difficult figuring knowing which direction to take, but then it just flowed. I've always aimed to improve the mechanics my game is inspired by, ie. Freelancer. that's where I started. Thinking of better ways to do things. FL had so many... interesting design decisions it boggles the mind.

After writing down what I wanted to accomplish I set out to start changing the code to reflect it. I immediately groaned. That is when I made it a goal to plan out my code before sitting down. Never been one to plan code for personal projects but now I see the utility.

I even thought of a few theme's/settings/story elements. It was difficult at first because I was stuck with certain ideas. It struck me that sometimes you just gotta throw some things more or less out the window if you want it to work. Don't limit your creativity!

The utility in GDD's I think is that you know whats next. Before I had a general set of features in mind, and got halfway in to implementing them before settling on a GDD. Glad I did this now, not ten weeks down the road when I have 6 more features implemented and no reason to have them (~time + effort wasted).

 

that is correct, my example was for the game design part. I was elaborating above, why I think writing it down is important and when.

 

I've been trying to dig more into design patterns mostly for this reason- I think when you can abstract a problem and match it to a pattern, planning the macro design of the code becomes a much shorter process, and you spend a lot less time trying to fit square pegs in round holes.

 

I think some design up front is definitely important but not a detailed design document. Definitely some design though. But that can just be some rough ideas, some scenarios, play mechanics, etc. Then you do some tests of actually building stuff which I see as part of the design process. Prototyping it is most often called. I see it as developmental design. But it all goes together. Design is more than just papers / writings and sketches. Those are basically just some planning activities.

 

Still a design doc, rough ideas, scenarios, play mechanics. Even a list of features with necessary models, audio, etc. can still be a design doc. If you are solo, you write it for yourself so you can pull in the detail when you need it. And yes, it should be flexible.

The larger your game, the more detailed the design doc especially if you have to share it with others, team members, investors, etc.

You are so fortunate that you can remember every idea, every feature and have no need for a pencil. lol

I think sometimes, folks just like to justify what they do not want to do.

Fortunately, that is okay because in this case, it hurts no one but possibly you.

 

Absolutely. Every game I make. All of the tiny game projects inspired by classics even those there is always some time spent on design up front. Just not much. At one time I was into really detailing out everything but I found it is actually either a big problem or a waste of time to do so. Problem if trying to force the design to work instead of adjusting the design based on what does work (through development and testing). Waste of time because the details will often change in practice.

So I think it is more important to document the essence instead of the details. Conceptual goals but open to interpretation as far as exactly how to achieve them. So in this way it becomes a guide... kind of a birds eye view of where I am going with it that keeps everything on track and cohesive yet doesn't dictate detail by detail along the way. Just my view may not work for others.

Definitely agree that for a team the docs need to be in a format and detailed enough for the others to also clearly understand the overall goals so there work will fit in. But that often won't happen unless only one person is tasking everyone else with what to do anyway.

 

With modern tools like Trello and HacknSlash, it is easier to task than ever before. But I use my design doc as a way to keep my programmers and artists on task. So my very creative programmer decides...hey, this would be cool..and I can program it...I can send him back to the design doc and tell him to add the cool idea to a "Maybe" list. Or lets say he forgets how we had planned to do the stats or if I forget which skills were supposed to be in the first test iteration.

Having worked on a game that failed due to feature creep, this is something important to me. Our design doc has helped us remember why made the decision to scale back but it doesn't stop us from making changes when needed. It is not set in stone but we are less likely to go to far off the path of that path is there to guide us.

BTW, ours is written on a private wiki so we can all get to it easily, no matter where we are.

 

That is a great strategy. I do the same with ideas that come up while developing. I just write them down (unless it is a core change that would make a big improvement and development is near the very beginning... then I implement) and then at the end I revisit those and cherry pick the few with most bang for the buck.

 

Speaking of scope, how do you guys plan for it?

I tend to scope using time (or burn rate) as an estimation, first I try to find what time length would represent the average play beat (say 5mn) and decide an arbitrary time scope (say 40h) which give me a rough estimation of the production load (1h/5mn x 40 = 480 beat). Then I try to triage play beat per type (cinematics, boss, town, etc for a rpg like game) and estimate an average asset cost per type beat, then add all them up. For example I can evaluate how many gameplay element I will have by dividing gameplay beat by 3, the rational being I need 3 beats to fully exploit one gameplay (introduction, reinforcement, test) but generally I only pick two third of the gameplay load THEN divide it by 3 (to have a better margin than 3 beats to exploit gameplay elements). I do that after the picth and before the design of the overalll structure. When I have the final estimation I start to strategically structure the game around the load and make decision how to distribute it, where to overload (for example key moment) or underload (minor side quest) to keep the production manageable regarding estimated resources.

Then I start to design the game proper by looking at distinct gameplay situation that can fill the beat, evaluating each gameplay elements by how many potential beat they can fill (I may not use up all the potential) by finding gameplay pattern with them (the unit play) that I can combine later to make a progression. Then I do a prototype of each beat to evaluate the actual charge and find potential roadblock, which my prompt another reevaluation of the load, it's cheap and fast relative to the rest of the project so it's in constant flux to anticipate load at each stage and make decision base on it, with time it's more and more precise.

It keep me in check from over designing the game and going out of scope as I'm already prone to overthink.

For example my current project have an estimated of 173 1mn beats, so around 3~4h of game, it's story base the gameplay hasn't been fully decide yet, I'm currently putting down spec for an aspect (which is R&D) and plan to start prototype after this step (I will do the equivalent of an animatique for the entire length, so not just one beat). However this is a project from which I purposefully didn't set hard dead line due to R&D aspects that are unpredictable, but planning help me ruthlessly scope down to protect this aspects that is core to the project (along with the story), it started as a zelda like open world game with crafting (maroon simulator basically) but been downgrade to a 3d cinematic visual novel (cinematic only because it use fancy flying cam position instead of static pose like VN) with no character navigation (direct selection, you don't move around like point and click) and self contain action scene comparable to mini game (no system dependence between scenes).

 

Huh. Why do you comment code?
Same reason I think.
In 6 months when the developer comes back from vacation (or whatever) or revisits crossing hazards in the game world - reviewing documentation is a lot quicker than attempting to remember one of the 500 ideas/concepts a developer scrapped for legitimate reasons - 6 or more months ago.

Does everyone on the team have read/write access - or is there a gate keeper for the document/updates?

 

@Braineeee I thought of this thread while reading an article on medium.

Share
https://medium.com/ironequal/8-cruc...efore-starting-a-commercial-game-135024fc8130

 

I am the gate keeper. The team does have read access.

 

I don't, not to any large extent.

A layer of comments adds an extra layer to maintain on top of the code. It's often simply adding more work, just for the sake of it. If my code is not clear, I write comments. But I prefer to write clear code.

My normal design docs just consist of a few mock screen shots showing gameplay, and perhaps a few key equations or mechanics. That's about it. Everything else is captured in the prototypes.

 

In the army, they say "No plan survives contact with the enemy, but no one survives contact with the enemy without a plan" or something along those lines.

Point is, you've got to know where you intend to go if you want to get anything done. I think the question raised here is not "Should I just wing it or not?", but "To what degree of precision should I make my initial plans."

Sorry if somebody already said something like this. Haven't read every reply.