An argument for proof of concepts

Welcome back!

For this post, as promised, I wanted to dive into how to start your game without even touching a computer. I will only be scratching the surface of this topic as it can be very big and I'm not wanting to overwhelm all you fine folks.

So let me first discuss a little of my experience and my process as I build various games. Mind you, not all of the games I've made have started this way; Partly because I didn't know better and also partly due to time and restrictions.

The main project I'll be using as an example is an incomplete game I've been working on called Fleet Calamity, which is a digital card game of sorts. I don't mean to plug my games as this is not meant to be an advertising outlet. I'm just mentioning them as a means of showing 'Yes, I've been through this.'. I've also made a match 3 game that needed a physical proof of concept to be green lit by my client.

I'd like to point out that not all games can be easily put into a physical format. The main one that comes to mind is any platformers. A racing sim, or many sims for that matter, would also be difficult to put in physical form. Games like Banished or resource management games you could make into a physical form. But as I move on I'm largely ignoring those - Unless you have a bunch of cars to race, open road and the skill set of a racer that is.

Whenever you make a game you should try to make a proof of concept. This is a quick example of the game that gets to the nitty gritty of your game. For a card collecting game you should print out a few cards to play with. For an RPG you should draw up a few maps and make character sheets. For a tactical shooter try paint ball, or airsoft or nerf guns if you must. The underlining goal is that you can show people what your game is about, what its like and let them play it as fast as possible so they can test before you dump hours into coding and art only to find out the game doesn't work as intended and you need to start over again.

A physical copy should be a cheap solution to get your game into the hands of others. This doesn't need to look pretty nor be fully complete, but it does need to be playable and convey what you are setting out to do.

I'll give you two examples. The first is the match 3 game. I came up with an idea to basically play candy crush, but on a 3D surface, much like a rubics cube. I needed a way to show my bosses how the game would function before they approved the project and dump resources into it. To start off with I created a GDD that answered all the sweeping questions about what you do, how do you do it and what would happen when you do any given thing. This gave me a basic set of rules to follow when I moved to the physical portion. If I made a match I knew how the game should react and fill those spaces so I could show my boss exactly what would happen. This took the longest time, as it should. I had to think of every possible instance and have the game react accordingly. That way if a situation cropped up I could give a quick answer and have them move on, unimpeded.

It's important to note here that I didn't have all the answers. At this time it was only myself working on the project so only I was asking the questions and giving the answers. But I went through as many thought problems as I could and tried to test the game before it was even made. This just goes to show how important testing is. Even as an Idea you can poke and prod it.

Anyways, I finally finished the GDD and now I needed to make a proof of concept. For this I just made a simple block made of legos. I used the various lengths of legos (2x2 and 2x6) to act as the objects you'd be matching. 2X6 blocks acted as two colors next to each other, just needing a 2x2 (single block) to be moved next to them. With this block I could show my bosses how the player could move about the cube, match, how the cube would refill itself and how you could move blocks around. Mind you, this wasn't perfect as I constantly had to take apart the block and put it back together just as it was, but only moving 2 blocks at a time. It also didn't show that in the end result of the game you could see further into the cube, rather than just the surface layer. But these were minor issues. The main game play could be seen and experienced to a degree. The game was then green lit and the programmers got to work, now knowing exactly how things would look, move and work.

Some games are easier to create a physical version of, while others may be more difficult. If this is your first game, why not try something that would be easy to make a physical version of? I would personally highly recommend it and here's why:

1. With a physical version you can clearly show what would happen when the player does X thing. You won't have to tell your programmer, or artist, or whomever “Ok, if you make a match the new blocks will fall in from the top and all the blocks above the matched blocks will fill in the spaces. Also, the 'top' is relative, so in one match the top may be the top, but in the next it's the bottom and now the bottom is the new top....' That gets very confusing very quickly. But if you could just show them it becomes much easier. “If you make a match, this is what happens. Now try and make a match else where and see what would happen then.” Now the player is experiencing your game and not just hearing about it. They learn the rules of your games world by testing them for their selves. Which brings me to my next point.
2. You can test your game right away, no need to re-code or redo art. You can simply re write something on a piece of paper, or make a new block, or what have you. Let me give some examples from Fleet Calamity.

In FC I have over 400 cards that need to be programmed and they all (generally) do different things. Some are 'creature' cards, others are effects. That's a lot to code and would take a lot of time. Not to mention there are 'pawns' on a board that move and react to various elements. Those also all need to be programmed. It would take several months to program all these objects and then I could finally test the game. That's months of time I'm waiting and when it's all done I'll be sure to find many things broken with the base ideas that need to be reprogrammed. Never mind the issues in the code itself!

Instead I could (and did) just print out a bunch of cards with a friend to make decks. Then for the objects on the board I just used some DnD dice I had laying around. When changes needed to be made I simply crossed out what was written on a card and wrote something new. Or I altered the GDD which is as easy as a delete button and typing. That first weekend I had several games being played. I played one after the other and each game improved by making quick changes and telling the next round the new rules.

What would have cost me a couple thousand dollars and months of time I completed in a couple hours. I've been testing FC for months and a lot of changes have been made. Some small, but many big changes too. If I had programmed it all there would be so much rework that it would take years, which, as you may have guessed is our next point.

3. A physical version saves you time and money! Lets pretend you are paying your programmer a terrible wage of $11/hour. First off, can you afford that? I can't and that wage is really low. Then figure how long your game would take to program (you can ask around. There are many forums for game devs). Now take the pay times the amount of time expected to make your game. It adds up fast huh? FC would have cost me around $9,000ish.
   But lets say you found some one who will work for rev share or for free. Alright, then money is not a concern now or ever. But you still have time working against you. People get bored, especially when it's not their project and they have nothing to show for it. As beginners you won't have something cool, even an MVP very quickly. You're skills are just not tuned enough to produce something right away and that’s fine! But if you don't have something to show right away to get invested in and to play with then that time will add up and people will leave. It's a sad truth, but that's what happens.
4. Finally the last reason; Self confidence! This is big and shouldn't go over looked. There is something to be said about showing your mom a piece of artwork you made or some craft you did. She will of course be happy for you, even if it looks terrible. But you get a sense of accomplishment from that and you'll try that craft again to get that feeling once more. Same goes for making a physical version. With a proof of concept you have something you can show off to your friends and family to play and enjoy. They will most likely praise you for your hard work and give you feed back on the parts you over looked or missed. Then when you come back to them with a new and improved version they will praise you again. This encouragement is huge and will help you keep at it even when times are tough. Team mates will leave you, people will not like your game, and of course the internet is super nice! You'll need the encouragement from those close to you and a physical version will help spur you on.

Alright, so this got a bit longer than intended, but I hope I gave you a good introduction to why physical versions are so helpful and shouldn't be over looked. When I was starting FC I was skeptical about making a physical version because I didn't know where to start. I didn't have a bunch of cards in the beginning and I knew my game was incomplete and had lots of issues. I didn't want to subject myself to harsh criticism when I knew my game wasn't 'done'. But eventually I bit the bullet and made a party out of the testing sessions. The testers did point out issues I knew about, which encouraged me to stop slacking and get them done and in the game. They also pointed out many issues I didn't know about. But most importantly they gave advice and suggestions on how to improve my game and now it's worlds stronger than when I started. The people that help you test can help you figure out issues that stump you. A team of people will always have a better chance of solving a problem than just one person, which makes it ever more important to get your game out there.

Get your game out there.

Don't argue with critiques, even if you don't agree.

Get people playing.

Make the changes needed.

Play more.

Once you have a solid game that people are excited to play and you feel ready. Then move on to finding a team to tackle your new awesome game with you.

Next entry I'll be talking about finding a team, where to find people and getting yourself out there into the community.

Take care every one!

Lastly, Please leave some comments. I'd love to hear from you and know what you think. I'd also love to hear suggestions for future posts.

Save Step game deving

Hello again!

I'm going to discuss what I've been calling Save Step developing. I know it goes by a few other names, but I can never remember what they are. This is, in my opinion, the best way to develop games by far. No matter what project you are working on or how many people are on your team this is going to help you a ton

Alright, before I dive in to explain what this is and how it works let me first discuss a few forms of developing that I've seen. I may miss some, so I apologies. But if you know of any others let me know.

To begin with I usually see people view a project as a whole and not pieces that need to fit together. This often overwhelms people and they lose track of whats important very quickly. Pretty much right out of the gate they have lost what is important and instead go for what is interesting and fun. It's hard to blame them, we all want to get to the fun bits and just get to the tedious parts when we get to them. But this often gets the developer to drop out of the project before they even finish what was supposed to be the fun part. They get overwhelmed with all they need to do and with no priority they aren't able to manage the project well.

I've seen some people essentially do a 'you do your thing and I'll do mine and then we'll put it together when we are done.' This seems fine since who ever is on the team is doing what they are good at and thus they should excel at their part. And they do to an extent. They will make some great code or art and they will be happy. But when it comes time to fit the pieces together they find there is much re-work to be done and that puts a damper on the project leaving people to drop out.
We got a basis of some ways that don't work and I'm willing to bet that any I didn't cover will be close to what I explained. So let me explain Save Step and why I think it's a much better approach.
Save step breaks the project down as much as possible. It's all about 'if something goes wrong, I can still ship it.' In the future you'll hear a lot about MVP's which stands for Minimal Viable Product. This is the bare minimum needed for the game to be playable. Save step finds what the MVP is and gets every one focusing on that aspect and making it perfect. Then, when that is playable and looking/feeling good then you move on to alpha, which adds a tiny bit more to make the game even better. A new feature, for example, may be added on top of the already existing MVP.

Let me give you an example of how it might work with a famous game we can all recognize, Mario.
What is Mario's MVP?

Do you need bowser? Nope.
Do you need Peach? Nope.
Toad? Nope, goombas? Nope, Warp tunnels? Nope, nope nope nope.

Ok, so what do you need?

You need Mario, the ability to jump and platforms. That's it. No backgrounds, no music, no SFX, no nothing.

Make Mario moving forward and jumping feel and look good and you've got a game.
Then for the Alpha build you could add Goombas and pillars. Or maybe push those off and instead have Mario walk and run instead of a static speed. Then have the Goombas and Pillars next in Beta. You'd keep adding features like the warp pipes, Bowser, Flying enemies, etc. etc. with each step until you have a game that looks and feels great.

Save Step also helps with feature creep. Wanna add some awesome feature that is going to be so fricken' sweet!? No problem, just make sure you get the base game and plan out when that feature will be added by figuring out what is needed before that feature is even worth having.
For example:

Yeah it would be sweet to have Mario shoot fire balls, who wouldn't want that. But first he needs to jump, there needs to be enemies to shoot at, It probably wouldn't be much fun without having Mario move around a bit. I also need to make a box for him to hit and have a flower sprout out and he needs to be big to shoot the fireball. Ok, no problem.

MVP = Jump, platforms, move forward and death.
Alpha = Run and walk
Beta = Overhead boxes
Capa = Goombas and death animation
Delta = Ability to grow, Mushroom movement
Echo = Flower and fireballs

Now much of these can be changed around based upon what the team feels is more important and easier to do. But you get the idea. There is a lot of steps to get to that awesome feature, but each probably seems much more do-able. It's no longer “I gotta do all of this before I get anything cool!?”. It's more “Ok, now I just need to do this, then that and I'll already have something cool then if I just add a little more it will be even better! Just imagine when I get to the last thing!”

Notice the MVP is the biggest hurdle, but once you get that done you'll already have something to show off to people and get feedback (Always remember to test!!! Test early. Test often!). It's also usually not that big of a hurdle. It's the ground work needed to make the rest of the game even do-able. It's often the easy stuff like making a character walk or what have you. The tough parts come later, but are broken down to bite sized bits. Plus, while you're working away at that tough part you can have people testing and enjoying your creation already and giving you feedback so you can limit the re-work.

With save step every one also needs to be on the same page – for the most part. There is an exception and I'll get to that. For now every one should be on the same step and communicating about what needs to be done during that step and if there is prep work needed for the next step (which shouldn't happen if broken down correctly.)

If one part of your team finishes early, lets say artists, then they can be testing the build as the programmers catch up. This allows every one on the team to be playing the game -which you should do. - and It helps let every one know what needs to be done still. Each step should also be punctuated by a round of testing to help every one on the team get familiar with their product, how it works and how it looks. If you ignore testing then you don't know what your game is lacking and you'll never be able to really improve it.

After the round of testing the whole team can move on to the next step. But to move on the previous version must look awesome!


******* A quick note*****
Notice I never say the game should be perfect. If you are a perfectionist you will have one hell of a hard time. Your game, your art, your product will NEVER be perfect. NOT EVER! There is no such thing as perfection. You can only do good, great, amazing and so on, but never perfect. Does this mean you should skimp or neglect? Of course not, why are you being so silly?
No, you should try your hardest and of course make something you are proud of, but you also can't waste your life on one aspect of one game. You'll have other chances, other games and other projects. Move on and get the game out the door. No one cares about a game they can't play. No one cares about a movie they can't watch and no one cares about a book they can't read.
Sorry about that rant, but this topic kills projects.
*********End of side note*******


Ok, so I mentioned an exception to when people might not be on the same step. That exception is the MVP to Alpha phase. The only reason for this is you can't test the game yet, potentially. If you can't test it then the part of the team that isn't working needs something to do. They may move on to the next step or they could be doing research, marketing, gathering resources, etc. etc. There is a whole slew of things that can be done, but some times it's just best to let them move to Alpha and get a head start. However, once something is playable they should be playing it and also have that round of every one play testing.

Save Step also helps kill babies. - Its a term! I swear, I'm no a jerk!-
The features of the game that really aren't needed should be pushed to the back of the line in save step. Going back to the fireball in Mario; It would be cool to have a fire ball and it's fun to shoot it and you feel powerful. But is it needed? Would the game be enjoyable without it? If you were running out of money or time would you feel that fireball is absolutely needed for the games survival? Will the game die before it was born simply because it lacked the ability to shoot fireballs?
Of course, it would! Fire balls are awesome!

But seriously, No the game doesn't need fireballs. It still would have been fun and enjoyable without them and if the the team ran out of funds or time the fireball would be one of the first things to be cut from the game. Maybe in the sequel you can have fireballs.

So that’s a look at Save Step development. It's a great way to organize a team and keep every one on track. It breaks down an overwhelming project into bite sized tasks and encourages team communication. It helps limit feature creep while ensuring that at any point in time the product you've worked on so hard can be shipped and you still would feel pretty happy with it.


As always, if you have questions, comments or the like I'm always happy to field them.

Hope ya enjoyed this piece and next time I'll cover a topic that really sparked this blog. How to start developing a game without going digital. This topic will cover how to save money, rework and -in the long run – time.

Testing – The most hated and most important part of game development.

Hello and welcome back!

Today's topic is all about testing. I consider this more of an introduction to testing, but it will help to get you started on what to look for, how to look for it and why.

My apologies, but this is a bit of a long one. But I believe it's worth it!

When I talk to people about my previous job as a game tester for 2K games people usually say something like 'Oh my god that must have been a dream job!' as to which I reply 'My dear friend, let me explain the horrors that is game testing...'.

Game testing is not a glamorous thing, as any one who's done it will tell ya. However, that doesn't mean it isn't very important. In what follows I'll explain what it means to test games, how to do it and why it is so crucial. But first let me explain what happens when you don't test, under test or ignore your testers. I'll explain these from personal experience.

Lets start with not testing. I have worked for a game company we'll call 'G-Company'. They are terrible and most of my examples will be from working there. We produced a game (who's name I won't post here) and they wanted this action/adventure mobile game produced in a couple of months. They also did not plan for any testing. We made the game and it looked pretty decent. The art was nice and much of it was thought out a moderate amount. But then we handed it to people saying 'Here is our finished game.'. The people were excited to play, but then quickly turned around with an onslaught of complaints. “How do I do this?” “How do I do that?” “Where do I go?” “Why am I doing this?” “Who is that?” “What is this?”. There was a whole dungeon in the middle of the game that was so confusing and difficult to navigate through due to poor level design, poor camera handling, poor controls and no testing that most people gave up even trying the rest of the game there. This level was also riddled with glitches allowing the player to fall through the world, teleport to the end boss and countless others.

Overall much of these would have been easy fixes if we had tested while developing. Simple story adjustments, ensuring collision boxes were placed correctly and much more would have been a breeze to catch and fix if only we had tested.

What about under testing or ignoring your testers? I worked on another game and this one I was pretty proud of. It was a simple match 3 game in a 3D space so you could rotate the 'board'. I wasn't going to let this game take a dive like the last simply because we didn't test. This time I planned and pushed for testing hard. I wouldn't let up, no matter how much every one else thought it wasn't needed or a waste of time.

Finally testing could start so I and a few other co-workers ripped into the game. We tested for hours on end, every day until the game was released and then we tested more. We tore the game apart and reported every little issue. Everything from small graphics bugs, to big story points. We also sent it to people outside of the dev team, but still part of the company, to test.
The results? Many of the bugs were caught, changed and improved the experience. The game was much stronger than our previous one and I believe testing was a big part of that. But there were plenty of issues. Although we tested and improved the game much of the bugs and issues we found either were ignored by our management and CEO or the programmers, who got it in their heads that testers are only trying to get them more work and criticize them. Because of our management ignoring us there were plenty of story elements that just didn't make sense, didn't influence the game and had no impact at all. Later, because of this, players didn't care about nor like the story, often finding it confusing, boring or just dumb. People started to say having no story would improve the game, but the CEO wouldn't have it.

As for the programmers, let me say this to you all – And really, this goes for you artists too, you're not off the hook. - Testers aren't picking on you. They want to see and play an amazing game just as much as you. They want to enjoy the experience and feel they got their monies worth just like you. If they give you bug it's because something is wrong with your code, your art, and/or your game. They aren't thinking about how much they could make you work more. How much they could hurt your feelings by ripping apart your baby. They are making it a better product for every one and not making it personal for you.

Does that mean you should just take it? Maybe not. Not all bugs are bugs and not all bugs are priority or in the direction you may want the game to go in. This is where you should have a conversation with your tester(s). Find out what the real issue is and pick the problem apart. Testers can't always pin point what it is about the game or experience that they don't like, so they just mark it and move on in hopes the rest of the dev team can figure it out. Starting up a conversation with the tester will reveal much more about their experience and why it wasn't optimal. In turn this will improve your product ten fold. You are all a team and communication is a hug aspect of team work.

Also, As a side note, I'd like to share an instance while working at 2K. I was testing the game Fantastic Four, Rise of the Silver Surfer. That game was crap and terrible. I was so bored playing it for 14 hours a day, every day that I fell asleep playing it and I happened to hold the control stick forward while playing it. When I awoke I found the end credits. I had beat the game while sleeping. I wrote a bug report saying the game is too easy and that I beat it while just holding the control stick forward. The company stated 'not a bug' and ignore it. Soon reviews poured in after the game launched and sure enough a review stated 'I beat the game while sleeping.'.


Alright, so now we know the downfalls of not testing or not caring about the testing process. But how do you become a more meaningful tester yourself?

To begin with play games! Best way to learn is to see how other games do various things well or poorly. I don't simply mean play some of your favorite games and call it work. No, really dig into them. When you play your favorite game ask yourself 'Why do I like this one much more than its competitors?”, “What's different about this game than the others?”. “At what points do I put down this game and why do I pick it back up?” ,”How did this game overcome this obstacle and how did other games approach the same issue?”

Ask these questions and more. Think about why you are playing, what keeps you going or what makes you stop. Then play games you don't really like and ask the same questions. Try and figure out the thought process of the devs and their target market. Do you fit in that market? If so, why did it miss the mark on you?

Now that you've thought about these over arcing questions, its time to dig. Test the limits of your games. Try and break the game and see what happens. I'm going to give an example with Fallout 4 and if you've never played it there is mild spoilers. Nothing too big, but I obviously will be talking about the game. In this example I'll be addressing the very beginning of the game.



****** Mild Spoilers******


















At the beginning of the game bombs are falling and its time for you to get to your vault. This is the first intense moment of the game, but how do you know this? Whats the shift in mood? Well before this point you were just having a slow morning as you wake up and get ready for the day. Your spouse and son are taking it easy and your robot attends to the house. You have time to explore the house and take in the atmosphere with no pressure to move on or do anything specific.

Eventually a news report comes on and your robot sounds alarmed and beckons you to join him. The tone is much more serious now instead of the care free emotions that had just surrounded you. Next you need to evacuate and armed men point you in the direction you need to go. Exits are blocked and all the civilians are running to one location. It's clear where you need to go because of all the pointing and crowds. But what if you don't?

What if you instead try to leave this neighborhood? How does the game stop you from just exploring the waste land? Well in this instance if you run too far off the beaten path the nukes fall and you die. The game doesn't let you really explore at this point. It gives you the impression that you can explore with your house. You search rooms, check out comic books, talk to your family, etc. you feel like you have no limits. But you can never leave your house until the scripted point. Then you must follow the arrows to the next scripted point.

Feelings, level design, sound, and more make you – the player- do different things at different times.
Notice, also, that if you try to leave the starting location you can never see the rest of the world. The world design limits how far you can see, thus letting you wonder whats over that hill. This would help limit what needs to be processed, built and designed but makes it feel like there is much much more to the pre-bombed world.





















*****End mild spoilers*****






In other words what are you not supposed to do in a game? Now do it. Can you? How did the game stop you? Were you surprised? Did it keep up the suspension of disbelief, or did you become ever more aware that you are just playing a game?

But testing isn't all about breaking the game, it's also making it easier to use and more intuitive. I'll compare 2 games I enjoy and how you move about the map. In Divinity Original Sin you move the camera by using W,A,S and D, but in Pillars of Eternity the camera is moved using the arrow keys. As a PC player I find the WASD far more intuitive and it took me time to get used to the arrow keys. However before I got into PC I enjoyed the arrow keys much more and found that more intuitive. Both are good games, but I like Pillars a bit less just because of how unintuitive the controls are for me.

Testing is a lot of things all at once. How fun is the game? Do the controls make sense? Does the game work as intended? Can it prevent players from doing what isn't intended? Is it intuitive? Does it get its theme and emotion across? Is it easy to navigate? Is it easy to learn? At what points is it boring and how can you improve it?

It's all these and more. Testing is a huge part in games and makes a mediocre product into something that really shines. It teaches you what works and what doesn't and it makes you a better developer all around.

I hope this was helpful and if you'd like more examples of good and bad game design let me know!
Also, if you have a topic you'd like me to cover please tell me and I'd be happy to write something up about it.

I'm sure I'll be covering this topic again as it is very important and there is always something to be said about it. However next time I'll be moving on to 'Save step game design'. Save step is a form of planning and developing a product that can be considered done early if all goes wrong.
Take care

GDD's and do they matter?

Like many of you -I assume- I have been scouring the interwebs to find information on best practices on how to start developing a game. I'm not talking about how to start programming or where to begin with art. No, I was more interested in the very beginning. How to plan, how to prepare, how to limit my rework and get my game out there. I did find a few sources that helped, but they were all scattered and fitting all that information together took time and I usually just ended up stumbling through the process myself.
After a while I started working with a small hobby team who wanted to make their first game. Since I had experience I figured I'd share my knowledge and try to help them along. I wrote a few posts for them that described a few game development processes and such and it turned out they really liked it. My writing really helped open doors for them and they suggested I should make a blog. So here we are.


Again, This blog isn't about how to program or how to art. There are tons of tutorials and blogs and guides and the like out there for that. This blog is for the core aspects of game development based on experiences I've had and from what I read and learned while developing my own games. I'd like to point out that I'm not some big shot expert who produced 100's of games. But I have been through the process a few times with several different teams. I'm just wanting to share my experiences and see if they can help more beginners.
Without further ado, shall we get into it?
One of the first steps in developing a game is making a GDD so I thought I'd introduce every one to what a GDD is and some opinions on it.

Please enjoy and let me know if you like this type of thing and if you have suggestions for future topics.

GDD's and do they matter?
To begin with what is a GDD? For those who may not know a GDD is short for Game Design Document. It is essentially the games bible. It contains everything you need know about the game you are making and allows every one on a team to know exactly what needs to be done and why.
A GDD contains information from 'What is the game?' to 'what art assets are needed' to 'How will the game function' and more. Ideally a GDD will answer any question you come up with in regards to what should be in the game and how it will interact with everything else in the game.
Now that we know what a GDD is do we really need one? Why or why not?
Many people will tell you many different things about GDD's and how helpful they are. Some, like myself, are big supporters of the GDD and others are against them and prefer other methods. I'll first explain why I find it important and then follow up with why people may not find them as helpful. Make no mistake though, Neither side is 'correct'. Ultimately it comes down to personal preference and how team is structured, so I won't be harping on those that disagree with me. I fully understand their points of views and find them valid.

Lets begin!

Like I mentioned a GDD is essentially the game bible, but it is not a static document written once and then never touched again. It is a living document that constantly changes and evolves with the project as new problems and solutions crop up. It is also important for all members, regardless of position on the team, to constantly review the GDD and ensure that their tasks conform with the most up to date GDD.

It is also every ones task to ensure the GDD makes sense to them. It should also be as clear as possible to limit rework as much as possible. Some times starting over is actually the fastest and best way to move forward. But in the real world employers wont want rework and they would be much happier -in my opinion- if you ask questions and make sure it's clear.
GDD's don't have all the answers though. They don't detail out time lines, who is doing what task and who reports to who. It is strictly a guideline for what is in the game, what it's about and the points the product is trying to get across. It isn't a marketing tool or daily planner.

To sum up I like using GDD's because the team can stay connected easily and know exactly what needs to be done and what their objective is. They can read about what the final result should be like and judge their progress based on what they have done and how it compares to the desired output of the GDD.

So I've talked a bit about what a GDD is and why I like it, but what about why people don't like them?

Many people dislike GDD's because of the upkeep they require. Projects change constantly and it almost feels like a daily upkeep. If the GDD isn't up to date than every one who is relying on the GDD to be accurate is given miss information.
Some people like to simply talk it out and let the game flow, rather than have a set of 'rules' to guide them so they don't feel as restricted on what can and cannot happen. This is partly because some people don't view the GDD as a living document, but still feel like they can't deviate too much.
Some people work alone and thus don't feel they need a GDD. There isn't any one to communicate to or bounce ideas off of, so there really is no point other than to keep track of your own thoughts.






I'd love to hear your ideas and thoughts about GDD's. Do you like em' or hate em'? I also encourage you to look up some GDD examples and see what you're in for as your project moves forward. You can always google GDD templates or GDD examples. I'd also be happy to share the templates I use when creating my own games; If any one is interested.

I really hope this was informative to you. I'd really like to hear feedback and input from you, the reader.

Next I'll talk about Testing in regards to why it is the worst thing ever, but arguably the most important thing ever.

Thank you for reading and please give me suggestions of topics to cover!