How hard is Games Design? Thread

A few years a go when I first started to get serious about programming my own game I thought this would be easy. I thought to myself I play games all the time. I would totally make the best game in the world. I will write up a games design document this week and release a game in a few months.

Obviously to any one that has been doing it for a serious length of time knows this is not true. Its so dam hard to get GOOD game concept written down. Sure your ideas sound great in your head, but trying to define the core mechanics of a game, into sound coherent written form is a nightmare. Its both fun, frustrating and just down right time consuming. No wonder so many people never make it to release.

Then you get the people that think that a games core elements don't even need to be defined, you can just make the game up as you go along. I am a firm believer that this is not true, sure the game changes over time, it evolves and the original idea is just a distant memory. But the core mechanics, the core elements stay the same throughout the life cycle of the project, and ultimately define what the game is about and what challenges the player faces.

In my eyes a game is a set of core mechanics and challenges, both of which are intertwined. The core mechanics define how the player interacts with the world and how the world offers feedback to the players input. Challenges come in many forums but follow a simple principle. A player is faced with a task, if he succeeds he is reworded, if he fails he is punished. An example of which could be anything from moment in a platformer, all the way up to collecting and moving items around to solve a puzzle, hell even a head shot.

What is my point here, to be honest I am not so sure any more. What I am really looking for here is to know what you guys and gals think about games design and the importance of writing a solid games design document. Or how do you go about creating games and getting your ideas out there. I can not be the only one faced with these issues.

The "making up the game as you go" approach can work, provided you do the making up before you create stuff for the game. Alone in the Dark was made when they had a core concept, but the specifics of monsters, puzzles, ect were all "designed" during a 3 day long RP session of sorts.

One thing I have learned playing board games is that even simple games like Settlers of Catan, or Battlestar Glactica, sound complex and convoluted when written down or explained, but when playing, it's a simple case of "move there, do the thing, vote/skill check, next turn..."

While I have never released a game publicly, I find that there is always stuff missing from my design. eg. I list of assests might not have all the animations I need, or some minor knick knack might be missing. I also think you can short hand alot. You don't need to define the exact range and spread of a weapon until the weapon is done. It's likely going to tweaked anyway. As long as you have "high damage, low RoF" or something of that nature you can wing it.

You dont need to be on either side of the fence definitively. Do some rough layout on paper. Implement it. Find out what works and then go back to the drawing board. To think you can get the basic mechanics down on paper perfectly without some prototyping is too optimistic.

So basically. Combine both approaches.

SabreXT and ShinobiNFC some solid comments right there. They have helped me put things back in to perspective. Thanks a lot for your input.

One thing I am concerned with on my latest project, which has happened on numerous projects I have joined in the past. People start off with a lot of enthusiasm. They start making models, textures and things that look really nice. But after a few months because there is no solid direction or a written development plan things fall apart and people wonder off.

I though this time I would push the team to define the core mechanics of the game down on paper first, then a small list of assets based on the core concepts, and then I could just start coding away.

I just really annoying the amount of people, that to put it lightly just waste my time. Games dev is a lot of fun, but sitting around playing games all day and talking is not how you make a game. I have given up so much to try and make this work, I just don't want to see it fail.

Edited by: GamerKnight

That's your issue?

Sorry, but in my limited experience, that happens even if there is a plan. I try to do everything myself now because everyone would start of passionate then just leave.

Edited by: SabreXT

Haha i guess you right, there is only so much you can plan for. But things seem to be progressing steadily with this new methodology.

Also I am very sad to hear you are doing everything yourself, although often its the only way to get things moving in my own experience.

I am a strong believer that to make a great game you need a small team, a team that is passionate about the area they will be working on. For example I love to program, and I put my heart and soul in to my code. With other people who feel just as passionately about there area (modellers, artists, composers, writers, designers), there is nothing we can not achieve.

Also team work brings to the table new ideas, all from different perspectives that often helps progress thing much faster. I know I could not have gotten this far alone. Thank you to the UDK community and the IndieDB community, I have met some great people on here who have helped me bring my ideas to life.

Edited by: GamerKnight

yeah I went from large teams to only doing solo work the last couple years. Now I"m starting to just do very small scope projects. For instance the game I'm doing now is just me and an artist (and a composer when i find one) and the next game is the same. The rate at which you produce when leading a team declines exponentially with each additional team member. This is why large teams actually do need managers (well, they need good managers anyways).

Hello everyone, Gamer asked me to post here as a reply. So I'm sharing my perspective towards game design and how I think gamers look at game mechanics from their perspective.

My philosophy is that there aren't bad ideas. There are ideas that fit in the puzzle and there are that don't. The ideas that me and gamer wrote down couple months ago were brilliant, could bring something different to the RPG games. But as any other idea, it should have depth behind it. And by depth i mean, it should have its use outside its initial purpose. I believe that depth is a thing subjectively defined. Everything at some point starts to makes sense, but how much of it makes sense, and how long does it take to understand. For me DOTA is a game with a lot of depth, just because it shows a difference in my performance in different matches. Even if i had the same strategy, the same amount of money and experience income each game, my game would be different, cause I'm playing with other people, who have different play styles, different heroes, and different enemies. Other people see the monotony of the game, just cause they see it as the same thing over and over, The heroes farm till they become strong and they fight till one team falls. The depth for some people come from the idea how much is there to do. Not how differently they can do the same thing.

What I'm probably saying is that i believe game mechanics should have at least some sort of depth, if it's crafting, it should have both positive and negative impact for a use of an item, throw in method of usage, that makes it have more depth.

But as a gamer i found something, calling it depth would be wrong. Depth doesn't come from how much content a system has, depth comes from how difficult is it to understand it. And I'm not talking about the math part. I'm talking about the organic part of the game. Understanding when to dodge, how long during the dodge you have this immunity from damage. When to parry, when to use an item, when to attack, when to run, when to do anything for that matter. I just can't find any reason to believe that you can write down a feeling of a mechanic on paper without experiencing it first.
Depth is what i like to call the learning curve, or the pit which you need to climb out. You climb, till you reach an area where you know the game well enough, that you can just simply run through the game again with no issues. I believe a mechanic should be accessible as much as possible, but it shouldn't be simply understood.

Just a simple example I'd give would be finding items in dark souls. You can find an item called rubbish. What idea that gives you? it's rubbish, i don't thing it can be any value in the game. Well, you can trade in rubbish for a crafting material. The game doesn't tell that to the player, he needs to find out himself. Or fighting a tough enemy, what you know, is how your character works, you got acquainted with it in the first 10 minutes, you don't know everything about how his mechanics work, like parrying, backstabbing, stamina regeneration. As a player you learn those things eventually, you understand when to initiate a parry, at what degree you need to stand to backstab, when to lower your shield to regenerate stamina faster. But that is a small part, everything else is knowledge, if you know what the enemy is capable of, you know how to counter that, you know how to beat it. Dark souls plays it cheaply, and it laughs at your face for falling for that, but when you understand that it's cheap, the game is as easy as any other.

A lot of things come from trial and error, having something to work with is a start.
The first GTA design document was 12 pages long, under the title Race'n'Chase. While Grim Fandango had 72 pages a point and click adventure game.
You can either go to detail in documents, or you can evolve as you go. It's best to know what to do next, instead of dwell on one issue forever, progress only stops when people stop working.

Thanks a lot guys for your input, i am going to need all the help I can get to see this through to the end.

When people take the time to read my concerns and offer some helpful feedback it really does help me out a lot.

Edited by: GamerKnight

I like the "writing game design doc" approach better. If you write everything down, you can get your priorities straight. There will always be features to implement, so dropping the less important ones can be the difference between a finished game and a never completed one. Also, everything I just said might be wrong as I have yet to complete a game.

Endijs1 wrote: I like the "writing game design doc" approach better. If you write everything down, you can get your priorities straight. There will always be features to implement, so dropping the less important ones can be the difference between a finished game and a never completed one. Also, everything I just said might be wrong as I have yet to complete a game.

I couldn't agree more, it also helps keep the team motivated. There is no maybe, if, kind of. It is this is where we are heading. We need this, this, and this to get there.

GamerKnight wrote: I couldn't agree more, it also helps keep the team motivated. There is no maybe, if, kind of. It is this is where we are heading. We need this, this, and this to get there.

Also helps to stop procrastination on the important parts. If you have a design doc, it is clear that you will have to implement that difficult feature no matter what and you can't spend the evening adjusting the position of buttons in the menu.

I have also heard that it might help to stop any new team members from pulling the design in their direction. If there is one general design doc, someone can't just barge in and try to push their own ideas into the game. Dunno how often that actually happens in a real project.

I find that development on a project, whether it be game related or otherwise, falls into an almost Pareto Distribution curve in a number of respects.

As you noted GamerKnight, when you start development on a project, things fly by at a pretty good pace. Big chunks of the project are being implement, perhaps not to the best quality, but your team is making leaps and bounds in progress. As development goes on, your focus narrows as your team begins to work on polish/minor changes. At this point, while you are making progress in completing the project, your only making small/insignificant changes, which make it feel as though your not really making great progress. This in turn can lead people to feel disinterested/unmotivated.

80% of the project will be easy, the last 20% is the hard part.

I believe that it's an invaluable skill to have the drive to be able to push past that 20% and get something finished, even if it's not up to as high a standard as you would like.

Good luck with your development. Good luck with that 20%.

You should not make a game "as you go", unless you are an one-in-all game developer, who can do (most) everything required to make a game by himself. However, even that person will rely on their experience when attempting to create a game. You don't do shit in the games industry without year of experience.

Reasons I see why game developers fail:

- no clear idea of what they are making; no documentation
- flawed idea of production processes, i.e. time it takes to polish assets is underestimated
- too much arguing/discussion on the team due to the missing documentation
- flawed leadership/ communication
- no real interest to work as a long-time commitment
- bad design choices
- public interest fades

There is a lot more to say. I think ambition is often in the way of these "young" projects. Instead of prototyping and stress testing, teams jump right into implementing all the features they want to see done. Which often leads to nothing working and a broken team. Start small, make a game around the simplest idea you have in your concept. Strategize.

Making games is a pain, because most things are learnt the hard way. However, after enough trial and error and spending days/weeks looking for solutions, you get a lot faster at whatever you are doing. I actually noticed the transition between barely knowing what I need to do and total confidence over my mesh production. I think you need that confidence to be a game developer and speed things up. However, it is only won through countless failures and experimenting. Making games isn't easy. Join a team, before you create one. See how it goes. It seems the time for big mod teams is over anyway. Maybe everything is going the indie way now: smaller production, small team, big skills.

Nebjezus wrote: 80% of the project will be easy, the last 20% is the hard part.

I was thinking the same thing the other day, but not about games dev. Just programming and learning new things in general. Very well worded.

SinKing wrote: Reasons I see why game developers fail:

- no clear idea of what they are making; no documentation
- flawed idea of production processes, i.e. time it takes to polish assets is underestimated

- too much arguing/discussion on the team due to the missing documentation
- flawed leadership/ communication
- no real interest to work as a long-time commitment
- bad design choices
- public interest fades

I agree, planning and testing is so important. But maybe that is because I am a programming, and my mind is broken from to many years of debugging haha. If its not an ordered list my mind cant handle it. One thing I have seen lots of groups do, myself included in the early years. Trying to making something to big to soon. Lets face it we all have great ideas, well they sound great in our heads. But its important to prototype the games core mechanics and release them to the public to play and give you feedback. Developing a full game that might take up to and over a year, then only to find out that it was a terrible idea is such a waste of good development time.

SinKing wrote: Making games isn't easy. Join a team, before you create one. See how it goes.

I tried this one, but so many people just wasted my time. I would be sitting there all day long coding, getting stuff in game so people could see and play. Only to release other people where just leading me on and doing nothing themselves. Indie Games development is serious work, I enjoy doing it, but some people just do not take this seriously enough.

It sounds more organised than it really is. In reality it is just a document with some ideas and models that are needed, but it helps having a list that can be looked at so there is no confusion on what is needed to get the game moving forward.

Edited by: GamerKnight

There's a great article about all this on the "What Games Are" blog-- the author gives his views on why game design docs aren't as useful as they're meant to be (sorry, you'll have to search for it-- this forum won't let me post a link yet because I'm a new member!)

In an argument against GDDs he makes a point that I really like:

"There are just four things that developers really need:

1. A direction that they can understand
2. A clear sense of what they are making and what they are NOT making
3. A path to production that they can visualise
4. A leader in whom to believe"

...so if you're working with others, know that it's important to be a confident leader, and to have a clear vision of what the project needs (and to make this vision clear to everyone else!). If you can do that best by organizing everything into a document, then I guess there's no harm in doing so-- as long as you understand that a document can only do so much.Regardless of whether you use a document-- I think it's really important to have as much of the game "fleshed out" in your mind as possible before you start. When other team members ask you questions about the project, you NEED to have answers for them. That'll inspire confidence in the project & keep people dedicated for longer... OTOH if your replies are always "let me get back to you on that", or "it's too soon to say", or "for now just do it this way, we'll change it later"-- that only shows others that the project has no direction / no real goal / no chance of being successful... and that you don't know what you're doing!

I've worked (as programmer) for some young "designers" who are never able to answer design questions on the spot.. It quickly became obvious that the project was going nowhere, and they had no real plan to make the game fun or compelling... And I mean-- how could a team stay motivated to work for a year or more, when they don't even understand the goals?? Without clear goals, you never achieve a sense of progress. Without a sense of progress, you feel hopeless. And when you're hopeless, you stop working.-----Ken

Thanks for you input, I will defiantly take on board your advice and try to improve the way I do things.

I think that is the reason most groups fail is not because they don't have design document, but because they do not have a game. They have a couple of great ideas in their head, but that really doesn't make a game. You need to know in detail what you are making. I am firm believer if you cant write it down, then its just a vague idea. There are so many different ways a design document can be written.

1. Through the use of tickets/jobs
2. Through a well organised word document
3. Source code / Pseudo code
4. Flowcharts / UML Diagrams
5. Concept Art

My own personal approach is all of them, in a well organised written document, with references to each section where appropriate.

I would love to read the article in more detail, Could you PM a direct link?

For anyone else interested in the article Designsfromthedeep was refering to, but couldnt post because he is new to the community:
Whatgamesare.com

The writer does make some very good points to why a "HUGE GDD" is a bad idea, and although I still think a design document is needed. I will definitely approach it differently after reading this article.

Thanks again Designsfromthedeep

I've been working on a few games for 3 years now as a hobby and couldn't agree more to the OP.

I find the best ideas come during play testing. I've found so many good ideas on paper didn't work in game using the mechanics present. My longest project I put on hold in hopes of releasing some small games in the app stores, then come back to it. The final straw for it was I screwed myself over when I tried to make a drastic change to the character controls and have to put it back together from scratch and rewrite a lot of code to incorporate the new controller mechanics.

I usually do what I'd consider a beat chart, physical papers with notes/lists of ideas, mechanics, etc. Then work through them, play test and adapt to changes. I do make some text docs where I just describe the the design, gameplay, etc, and some technical notes where I write down variable names for different systems so I can keep track of persistent data, paths, methods/functions.

On the big project that's on hold I did a GDD because I was working with another person long distance and it was the easiest way for us to contribute to the design, but a lot of it was me adding whatever mechanics I'd already written as I wrote them based off my notes/lists, and him updating his stuff to reflect the direction things were going...

Edited by: shindig