Jump to content

  • Log In with Google      Sign In   
  • Create Account

Trying my hand at game design documents.


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
7 replies to this topic

#1 Oxymoron28   Members   -  Reputation: 201

Like
0Likes
Like

Posted 01 January 2013 - 04:09 PM

Hey, again!
 
So I'm making my second topic of game designs here because my first topic fell into obscurity! Anyway, I've worked harder on these designs (I think so anyway) and instead of them being just game design briefs like before, I've made them into game design documents, woo! I was using this template "http://www.gamasutra.com/blogs/JasonBakker/20090604/84211/A_GDD_Template_for_the_Indie_Developer.php" because I believe it was perfect for the size of project I was planning. 
 
Also please note, my spell checker has given up the ghost on me, (probably trying too hard to battle my dyslexia), so I apologise for any spelling mistakes or grammatical errors. I did proof-read them several times though!
 
My first project is "StealIt", a thief game where your job is to become the best thief in the world! I spent about 4 or so days writing this up, so please be gentle! 
 
Also a little game for you all, spot the EA-made-up-genre!
 
StealIt:
 
This next game is "H(a)unted", some of you may remember it? I posted it months and months ago, it's been in varying states of development with different programmers thoughout it's life, but it is a project I would actually like to see get developed (closest it's been was a lighting tech demo).
 
H(a)unted (unfinished):
 
I still have a few more projects in the works, and will post them as and when I can, how ever I thought I'd post these now and start getting some feedback on what you think of my game design documents. Feel free to rip them apart if you want, but I only ask one thing, please leave comments as opposed to just saying "nah they suck mate"!
 
Also you may notice a lack of "Game Flow" in my H(a)unted design doc, this is because the one in StealIt too a bloody life time to do, so I'm wondering what may be the best and most efficient one to cover game flow?
 
If you are at all interested in any of these projects, then feel free to contact me here. I'm open to all suggestions!
 
Brett.


Sponsor:

#2 Dasha   Members   -  Reputation: 140

Like
0Likes
Like

Posted 02 January 2013 - 06:48 AM

Just finished the StealIt document. It was well organized, if the document is going to get any larger, try and keep the more technical stuff in one place, and the goals/overview in another. Game play is a very good introduction to the game and what it will look like for the player. After that would fit the goals for the game such as Time Scale, and possibly assets(if that list remains short and sweet. A more fleshed out version might sit organized on it's own at the end).

 

But besides that, the actual information is articulate and explained enough to give a potential player or team member a clear idea on the type of game it will be. Well done :)

-----

 

Finished the H(a)unted document. My (somewhat anal) comments on organization are the same, but again the document does clearly as intended. It will allow anyone reading to get a good picture of the game and what it will look like.

 

It may benefit to add something  on each about how it will play, such as controls. As well as how the game will be released and/or distributed and on what platform(s) exactly.


My current game: MMORPGRTSFPSRLG. Read: Some sort of mmorpg with a special something that will make everyone want to play but I wont tell you what it is.

Status: Pre-Production, Game Design

Team Openings: None

 

For serious though, my goal is to create a MMO. What kind? Not sure yet. MMO games are my passion and it's a goal of mine to change the industry for the better. Do I know it's an unrealistic goal? Yes. Do I care? Heck no.

 

If you ever need someone to bounce ideas off of, feel free to contact me.

 

--------------------------Hail New^Internet

 

 


#3 Oxymoron28   Members   -  Reputation: 201

Like
0Likes
Like

Posted 02 January 2013 - 07:20 AM

Just finished the StealIt document. It was well organized, if the document is going to get any larger, try and keep the more technical stuff in one place, and the goals/overview in another. Game play is a very good introduction to the game and what it will look like for the player. After that would fit the goals for the game such as Time Scale, and possibly assets(if that list remains short and sweet. A more fleshed out version might sit organized on it's own at the end).

 

But besides that, the actual information is articulate and explained enough to give a potential player or team member a clear idea on the type of game it will be. Well done smile.png

-----

 

Finished the H(a)unted document. My (somewhat anal) comments on organization are the same, but again the document does clearly as intended. It will allow anyone reading to get a good picture of the game and what it will look like.

 

It may benefit to add something  on each about how it will play, such as controls. As well as how the game will be released and/or distributed and on what platform(s) exactly.

Thanks for the reply! I'm going to look at altering it then to your suggestions. I'd completely forgotten about control layout and platforms, so will look at adding them in as well :)



#4 Tom Sloper   Moderators   -  Reputation: 9916

Like
0Likes
Like

Posted 02 January 2013 - 11:07 AM

Dasha said:

1.It may benefit to add something  on each about how it will play, such as controls.

2. As well as how the game will be released and/or distributed

3. and on what platform(s) exactly.

 

1. That's vital information. Without information about controls, it is not a game design.

2. That information is usually not essential to a game design doc, but it is usually helpful to know.

3. That is information vital to understanding the game design.


-- Tom Sloper
Sloperama Productions
Making games fun and getting them done.
www.sloperama.com

Please do not PM me. My email address is easy to find, but note that I do not give private advice.

#5 Oxymoron28   Members   -  Reputation: 201

Like
0Likes
Like

Posted 02 January 2013 - 11:32 AM

Dasha said:

 

1.It may benefit to add something  on each about how it will play, such as controls.

2. As well as how the game will be released and/or distributed

3. and on what platform(s) exactly.

 

 

1. That's vital information. Without information about controls, it is not a game design.

2. That information is usually not essential to a game design doc, but it is usually helpful to know.

3. That is information vital to understanding the game design.

 

Yeah I should of really known to add the controls in it, after all I did go quite in-depth when it came to describing the menu!

 

Does anyone know of a good and efficient way to do game flow? as I think my diagrams are the most awkward things ever!



#6 Dan Violet Sagmiller   Members   -  Reputation: 896

Like
0Likes
Like

Posted 02 January 2013 - 02:49 PM

Interesting, I use a very different technique for Game Design Documents.

First thing, is that you have spelling issues. such as the first sentance of your dgg, "by" => "buy".

Second thing, is that after reading the first paragraph, I had no feeling of how the game worked. I really like what I read, which is great from an advertising perspective, but it lacked a good feeling what the game will be like.

I have a book on Game Design/Marketing that is in review now, and *hopefully* will be published soon, and I'll try to water down a few concepts from it into a short message here.

[30 Second Commercial]
The first paragraph is great, but I recommend another section called 30 Second Commercial, directly after.
- You write out a script of what would be covered in a commercial of your game. Imagine you had 30 seconds of time to show a player a video of your game, to try to get the interested enough to try it out. 30 seconds is not much, but considering all the games out there, and your probable budget for advertising, 30 seconds is a lot. in this you would typically have 5 to 10 second sections showing off a key area. NO WORD Montages (I.e. Flashing a bunch of buzzwords on the screen. Game Goliaths can say things like that because people already know they can back it up.) Describe what the players will see and hear.
- Focus on the key things about your game that current similar games don't provide, while still expressing the basic game play.
- This is really good for conveying not just the general idea, but the core concepts of how the game runs and *feels*. For instance, starcraft and warcraft 2 have different feels to them, even though the game play is very similar.
- Use this 30 second commercial as a guiding post to NOT WASTE TIME. I.e. you need to get something out soon, anything really. Trying a 3 year concept without pay will probably have everyone lose interest in your project. If an idea or concept you are considering does not help you create a game that the commercial shows, don't do it. Put it in a bucket of things to add to a version 2, or a version 1.1. or 0.2 even.. The point is, figure out the most important things about your game, (just a couple) and get them done.

[Why is it fun]
The 30 second commercial usually does a pretty good job of describing the appearance of the game, how it feels for instance, and a couple key features of it. this section now aims to express what the key factors of making it fun are. Its not fun because its a game. We've all played "games" that we stopped almost immediately, because it was terrible, not fun at all. Also, we've played games where its fun in one area, but another area really losses that feeling.
- Its important to figure out the key features of fun, and then anytime your designing, programming or thinking about the game in the future, you can try to make sure the idea or thing your working on helps to bring that out or reduce it. For yours, it sounds like identifying patterns in how people act or times people move. This means that in your data for your player to review, maybe they have access to all the tapes from a night. It would be booring to make them sit their and watch each video from start to finish, but it also takes the fun away to just present the time that every 15 minutes past the hour, a guard walks through X hall way. Another thing about your game might be how you layout the game plan. The players get to work out ideas of what time ranges they have to get through a section, and should be able to see it work out a bit prior to executing it. Seeing their game plan operate, like X's on a blue print moving around. These things need to be considered.
- The idea sounds fun over all, but your game design document isn't to sell the public on what your doing, its to keep everyone developing it on the same page. I.e. one player might imagine it like rainbow 6, for planning things out, while another might imainge it more like Ghost, where you find things out as you sneak around. Figure out what the fun parts are, what the players will enjoy the most. Don't worry as much about the details of how its done, but instead the underlying theme of what makes it fun.

[Why it will sell]
I add this section to my GDD's to make sure me and everyone else on the team know how the game will make money. This could be as short as "Planning on posting it to XBox Live for 7$, with a demo that has these key features..." or it could be "Free to play, but payments will be made in Microtransactions, to give players bonuses in play."
- if its a demo, then sell, you need to consider what this demo really needs to have. your dev team should really understand the key differences between the demo and the sold version. Is it the same engine with different levels? Separate these two. Also express clearly the goals of this demo. How can it get people excited about a certain style of game play, but make sure they understand there is more to get?
- If it is a Micro-transaction based system, then consider what will the balancing system be. I.e. if a player pays a buck, and then gets awesome powers, and they annihilate other Free players hard work, despite having played less, you've probably just lost yourselves a bunch of potential purchases. You need to make sure your keeping in mind how to balance paying vs free.
- If it is monthly payments, or arcade/credit style, you need to have a plan in mind of what will make the people come back and keep paying up, instead of leaving and moving on to some other game.
- The key idea, is that just like everyone understanding what is fun about the game and applying it where ever they can, they also need to keep in mind its sales points and make sure that any reasonable spot of the game that can promote your needs, does.

[Player Stories]
- Player stories has no direct link to a "plot", but instead to different modes of game play. A good example of a story is an the classic Zelda 2 from NES.
Story: travel the country - In this, the player will travel around, exploring areas, from an overhead view. All very high level perspective of country side and mountains and rivers. (Note that this story said nothing about battles or sales?)
Story: travel the country (Monsters) - While travelling the country side, monsters may appear around you and chase your character. If you don't avoid them you will get pulled into a forest Scene loaded with extra monsters to fight.
Story: travel the country (Fairies) - While travelling the country side, rarely a fairy may appear, and if you capture it, you are taken to a forest with only a Fairy and no monsters. The Fairy heals your magic and Health.
Story: In a Village/town/forest - In this, the game is now a side scroller where the player can jump, battle monsters and gain items.
Story: Healing Houses - In this, the player can enter some houses that will either heal the Health or Restore the Magic.
Story: Using Magic - The player can pause the game, and choose to invoke a magic at almost any time where they might also do battle. MAgic comes in different forms and will aid in different ways.

Normally, the stories would have a bit more description, but not a lot. What makes Stories helpful is it identifies the core screens to code in the game, and the key events that make them help transition them. This should not do the programmers job; it should not tell them to use a HashTable or store everything globally. it should only tell them what the user will see. Once that basic feature is built, it can always be clarified, and them more sub features can be added.


Aside from including some graphics idea, usually near the 30 second commercial, that is the majority of the game design doc I use. You don't want to add to much detail or people won't read it, and you want to make sure they key values come across well.


Edited by hpdvs2, 02 January 2013 - 02:56 PM.

Moltar - "Do you even know how to use that?"

Space Ghost - “Moltar, I have a giant brain that is able to reduce any complex machine into a simple yes or no answer."

Dan - "Best Description of AI ever."

My Game(s), Warp Wars is in early development and can be found here: http://blog.WarpWars.Net.


#7 Oxymoron28   Members   -  Reputation: 201

Like
0Likes
Like

Posted 05 February 2013 - 05:56 PM

It's been a long time since I last posted in this topic, so here's an update!

 

I've worked on a new design document for a game called "Destroy All Towers". Some of the things I've been told I should add have been added so comment away! :)

https://docs.google.com/file/d/0B0NVva_nspitcjEyMXg1NmhuVHc/edit?usp=sharing

 

The others are being re-done a little to add all the other comments in so thanks!



#8 Oxymoron28   Members   -  Reputation: 201

Like
0Likes
Like

Posted 06 February 2013 - 05:25 PM

Okay added the control scheme to "StealIt" now as well, more to come soon! Plus another new design document in the works! Feel free to C&C away! All advice welcome :).

 

https://docs.google.com/file/d/0B0NVva_nspitUDc1RS1UOTBqUXc/edit?usp=sharing






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS