Game Design Cheat Sheet?

I need to get up to speed on the basics of game design, but I don’t want to read a whole book and it would just bore me with details anyway, because I just want a cheat sheet. You know, the Reader’s Digest or Cliff’s Notes version, quick and dirty. E.g., best practices for design docs, jargon, the way it works in a professional game studio, etc.

Anybody know a web page or PDF like that? If it makes a difference, all my ideas are in the 1st/3rd-person shooter/roleplaying/action/adventure type genres.

Yeah screw details. Who needs them. You know that’s where the Devil hides right?

If you are too lazy to read a book I dont see you creating a game anytime soon. It takes time to learn anything in life.

[Changed my mind; no need to respond to rudeness with more rudeness]

A primer shouldn’t involve reading a whole book. For subjects that don’t require reading an entire book (like, say, a primer on game design), no, I don’t like paying for or reading entire books.

The bookstores are full of books full of self-help genius like “if you are too lazy duh, duh, et cetera,” too. If I want to read that **** I’ll buy one.

I don’t see anything rude about this post. He pretty much sums it up. If your not willing to take the time to learn then why bother in the first place, also there is a reason why books have chapters. Just saying…

There’s no magic ‘cheat sheets’ or shortcuts; game design is a vocational skill that must be learnt by doing. Reading can certainly help, and there are a few decent books on the subject.

Was thinking about opening same thread,

What I think JHighsmith meant and what I mean is to create some kind of list of best practices for game development (3d modelling, etc.)
I know that there is a lot to learn but knowing best practices can really help, we will keep them in mind when learning or creating games/models etc.
Maybe someone could create WIKI page for it, or at least share link where we can find that information…

ambershee, what books would you recommend? (if we allowed to recommend books here…)

A Theory of Fun for Game Design is quite light, but a good read.

Chris Crawford on Game Design is interesting as he talks about his actual projects and the reasons why they succeeded or failed in his eyes.

I’ve been doing games design for 5 years now, there’s not magic shortcut, you need to research and read things to learn over time, you won’t just pick everything up by some “cheat sheet”

I’ve never read any books on game design and neither have I used any short-cuts. What I did do though was spent 11 hours a day, for six years working in 3ds Max, Maya and UDK
“Practice makes perfect” and short-cuts teach you nothing! :slight_smile:

@JHighsmith: There is no comprehensive cheat sheet (aside from some books and our library of Documentation](Unreal Engine 4 Documentation | Unreal Engine Documentation) and Tutorials on the Community Wiki](A new, community-hosted Unreal Engine Wiki - Announcements and Releases - Unreal Engine Forums)), but a great place to start learning with minimal reading is our Video Tutorials](!

Have fun!

Game design in nutshell:

  1. Get your self two A4 pages of paper.
  2. Write down your ideas.
  3. If need more paper than two pages, rethink what have you wrote.
  4. Congrats you have basis of your game!

Go into editor of your choice

  1. Take one idea
  2. Break idea into the most basic iteration (ie elaborate AI behaviors start with simple pathing to a target)
  3. Build functionality of basic iteration
  4. Add to basic iteration until you have a completely functional version of your original idea. Test it through trial and error. At any point you may need to go back to step 5 with this idea.
  5. Add more to your idea because I’m sure new things were discovered during the dev process. Test it through trial and error. At any point you may need to go back to step 5 with this idea.
  6. Repeat steps 5 through 9 until you have a full set of playable ideas (mechanics)
  7. Repeat for every other step of the development process (art/level design/etc…)

You don’t code with the goal “I’m making advanced squad based AI that utilizes cover system and cover fire”…You start out with the base level of every aspect of that AI and build upwards. This modulates your game and results in actual progress towards goals.

Okay, I can entertain the possibility that replying to a thread with a useless, off-topic, cliched, nanny-type response might’ve just been stupid.

So, there aren’t any conventions in how game design docs are structured, common practices in game development, etc? Nonsense.

NoobCube is correct. I suppose what we’re facing here is the fact that the training for Game Design is roughly as math- and skill-intensive as your typical liberal arts degree. So, the GD types are a bit touchy.

Wow, a useful post, thanks ambershee.

Shortcut = straw man. And you don’t learn game design by learning Max, Maya, or UDK. You learn how to use Max, Maya, or UDK.

Thanks for another useful post, Stephen. I downloaded all the official vids and am currently going through them. I plan to comb through the docs and everything else for UE4. But the thing I’m really after in this thread is, well, I guess it’s the Game Dev version of how to format a script. I have plenty of books on scriptwriting, but when you really want to know how to format a script, you download the scripts of actual movies.

Haha, that’s what I’m doing! Well, I’m using OneNote (which I recently discovered and love; great for organizing ideas).

But that “no more than two pages” rule of thumb is useful food for thought, thanks.

Alg0801, aren’t you confusing game design and game development?

Well the Extra Credits show is generally a good starting point to learn about Game Design. The videos are entertaining to watch, so you don’t have much to loose… and most of them contain great advice for game designers.
Like anything you have to take the advice with a grain of salt. Sometimes they go a bit too far for the meaningful games, that probably noone would want to buy. :smiley:

@JHighSmith, I’ll throw in my two cents worth.

I’ll particularly grab onto this question you asked Alg0801: “aren’t you confusing game design and game development?”

Nope, he’s not confusing anything. The problem is that lots of things can seem like a good idea in principle but when you actually put them into practice they suck harder than a tornado at a smurf convention. So a big part of designing games is actually trying stuff and seeing whether or not it works as well as you thought it would, and whether or not it’s actually fun to play.

I’ll also pick you up on the first thing you said “I don’t want to read a whole book and it would just bore me with details anyway”.

First up, that’s just high octane flame bait, if you talk like that on anywhere on the internet you’re just going to get dumped on plain and simple. Second, I heard a saying a while back “there’s a big difference between what people say they want and what they’re prepared to work their **** off for”. In other words, lot’s of people like the idea of being rich and famous and successful but it’s the ones who are prepared to do the work that actually get there.

So the big question for you is “if you realised that being a game designer was going to be ten times harder than you thought it would be and take ten times longer than you thought it would, would you still want to do it?”. If not, no shame, keep looking until you find the thing you don’t mind doing all that work for. If yes, dig in for the long haul and go for it.

Ok, links:

(NOTE: The below information is based on my experience as an enterprise-level project manager, integrations developer, and customer analytics professional within the healthcare technology market. I am a hobbyist when it comes to game development, but certain heuristic ideas spread across all genres of software development and marketing.)

Not to dive too far into the argument of semantics, but a primer “is” a book or other piece of work to help learn introductory material. So your statement is technically untrue. Game Design is an extremely broad topic, covering all aspects of content creation and organization within a game. Let’s take the examples you’ve given us of your ideas in the original post.

Your Idea

Congratulations, you’re one of the many, many individuals that have taken a step towards wanting to make a video game. Too often aspiring game designers still wet behind their ears decide that they’re through with playing other people’s games - they have an idea of their own that’s “never been done before” and is “totally awesome”. Let me be the first to disappoint you and tell you that your idea probably isn’t original, it’s most likely shown up over time in other video games, movies, theatrical performances, novels, etc. That being said, your awesome idea(s) isn’t going to carry a video game, it isn’t going to make it sell, and it isn’t going to create assets, documentation, or code for you.

Now that we’ve moved through the pessimistic introductions, let’s take your idea and do something with it. The first thing you’ll want to create is a Project Capstone. A Project Capstone, like it’s architectural equivalent, is a one-to-two sentence statement detailing what you plan to achieve, as a whole, with the project you’re starting - It will hold up the rest of your project for the duration of the project’s life. If you find that you’re unable to describe what you’re trying to achieve in one to two sentences, there’s a great likelihood that your main goal is too complex to manage effectively - and may need to be split into multiple projects. This will be the “Mission Statement” of sorts for everything else that you do for your project. The Project Capstone is something that I’ve adopted into my professional career, and it’s benefits are not to be trifled with.

As an example, below is a Project Capstone for one of my World-Building projects I have on my plate:

This is a quick, concise definition that will be used as a stake for the rest of the project. Type this Capstone up, print it out and stick it in front of your computer. Get it tattoo’d on the insides of your eyelids, inscribe it on your tombstone - because this will be the sentence or two that directs the rest of your project until the project has been completed. In business, this is often called the “Minimum Viable Idea” - which is the smallest version of your idea that you can test and get meaningful results from.

The Opportunity Assessment

Now that you’ve properly defined your idea, you’ll want to run your idea through a gauntlet to see if it’s actually worthwhile in trying to produce. In this step, you’re still not building anything, you’re simply asking questions on the basis of your idea to see if it’s an idea worth wasting your time on. You’re conducting what we call an “Opportunity Assessment”. Below is the series of questions you should ask yourself about your idea:

1. Exactly What Problem Will This Idea Solve?

Example: We have been unable to find a sandbox, rogue-like, city-building game that also boosts impressive graphics and is encompassed in an evocative storyline. Given that the market is now being flooded with Minecraft and Dwarf Fortress clones, we feel that the market is currently saturated with feature-less mockups of this genre.

2. For whom do we solve this problem? (Target Market)

Example: We intend to provide a product for previous fans of rogue-like, city-building games while working to capture role-playing fans as well with an evocative storyline. The photorealistic graphics will add to both target markets to ensure that the product does not become outdated fast.

3. How will we measure success?

Example: X number of hours of storyline, Photo-Realistic Graphics, X number of craftable items, X difficulty, X number of building materials, etc.

Find something to measure the quality of your idea - something that is able to be put into metrics.

4. What alternatives are out there? (Competition)

Example: We have found that the notable competition based on the definition of our idea is Minecraft, Dwarf Fortress, Everquest Next Landmark, Teraria, and Starbound.

5. Why we are best suited to pursue this idea?

Example: We are set apart due to our strong knowledge of a AAA game engine called UnrealEngine 4. Additionally, we have a world-renowned writer and possible investors seeking stakeholder positions.

6. How will we deploy this?

Example: We will be releasing this on PC and Mac, other platforms may be considered closer to release or thereafter. We do not intend to use a publisher or ship boxed copies, all releases will be done via DRM-Cloud Services.

7. What is the preliminary estimated costs?

Example: After adding up possible freelance or outside work, team collaboration software, modeling software, source control software, Development IDE, Logo and Branding, Project Management Software, and initial hardware setups we have found the initial, bare-minimum cost to be $47,000 for development.

8. What factors are critical to success?

Example: Steam Integration, Investor Backing, Cutting-Edge Software, Replayability, etc.

9. What’s the Overall Recommendation for the Idea?

Example: We have found that our initial idea is over-reaching in terms of staff resources and finances. We have recommended taking the idea back to the drawing board for something less resource intensive for our first game, and more towards the $15,000 budget.

The Software Specifications Document

You’ll most likely visit, or already have visited, some game development websites/organization/books etc. that explain this step as creating a “Game Design Document”. Most game design documents that I’ve found are too narrow in their approach with the actual creation of the game, instead I propose that you use an enterprise level Software Specifications Document. While similar, this document also covers more of the nitty-gritty technical portions that you’ll need to document and think about prior to digging into the creation of your game. Things such as Non-Functional Requirements, Class Diagrams, Dependencies, etc. You can edit said document to then include your game-specific categories. These categories are pretty much self-explanatory, and gives you a good idea - and possibly some new ones - on what it will take to create this game.

Below is an example of this type of document:

Software Specifications Document


Project Planning

The next stage will institute a project plan for the implementation, testing, deployment and maintenance portions of the software development life-cycle. So far, you’ve 1) Written a Capstone for your idea, 2) Taken your idea through an Opportunity Assessment to see if it’s worthwhile to further proceed with and 3) Worked on documenting as much of your idea as possible with both technical and non-technical specifications in your Software Specifications Document. This covers the documentation phase and some of the planning phase. Only 4 more phases to go, are you still with me? Good - Let’s do this.

One of the mishaps that I see in pretty much every request for staffing for a game design idea is the lack of a technical writer or project coordinator/manager. About 80% of everything that you do on a project should be in the Planning and Documentation stages of the product design. There have been a large number of studies done on cost effectiveness and project timelines, and all result in the realization that mistakes that could of been alleviated by proper documentation are the most cost intensive portions of product development. Not fully understanding the architecture that you’re developing on, or missing key, critical features during the deployment stages of your product can result in astronomical resource and financial costs. Knowing this, I doubt every person that starts looking for a game development team is an expert in technical writing and project management, which is why I find it so queer as to leaving out those positions when looking for a team. Perhaps the Lead Designer feels that he can manage these areas, though I highly doubt it.

Furthermore, and especially with indie development, keeping morale up (since most of your staff will probably be remote) and continuing to push ahead on your project is paramount. No other one thing in a project can provide as much detailed achievement as a project plan. Keeping this project plan transparent to the rest of your team will show team members that things are actively being completed by all areas of the team, and will give the team a much better focus on what they should be working on and when.

The Project Plan should be as detailed as possible without drifting into a documentation timesink. It should effectively detail each stage of the Implementation, Testing, Deployment and Maintenance phases of the software development lifecycle - breaking this down into identifiable and achievable tasks. You should work to identify milestones within your project plan that will reverberate back to your team - “Hey, we’ve finally gotten to THIS point and accomplished THIS! Awesome!”. Additionally, your Project Plan should detail out what positions should work on which tasks and estimate how much time the task should take(this is an art-form in and of itself) - what dependencies one task has to another task, and so on. I’m not going to go into detail on how to setup a project plan, there are hundreds of books out there that detail this process in length - and this portion of the product development is a particular, skilled expertise - meaning there’s no other way around it than just studying it out the ***.


If you finish with the above and still feel like creating a game, then hit me up and I’ll detail the rest of the stages. I feel this is a good primer to get you started. Additionally, I would recommend you study up on the following categories:

Project Management
People/Team Management
User Experience
Unit Testing
Software Design Patterns
Software Development Lifecycles
Process Improvement

Below, I have a list of books that I would like to recommend. The down-and-dirty is that reading is fundamental - you’ll be creating, essentially, a book in it’s own right just with the first few steps shown above. You’ll need to dive deep into certain topics, and there’s no alternative other than busting your ***:

The Mythical Man Month
The Power of Habit
UI is Communication
Programming Language Pragmatics
The Pragmatic Programmer
Design Patterns: Elements of Reusable Object-Oriented Programming
Good To Great
The Innovator’s Dilemma

Anyways, I hope you enjoyed this quick primer. I know I certainly did! Parting ways before I go, I would like to share some wisdom - Be wary of any type of educational or tutorial material that’s specific to Game Design and Development - stick with enterprise industry standards, and do not narrow your knowledge to just Game Design itself. Be aware that everything stated here is of my own opinion and experiences.

@Elynole I think you just became my idol. Not because of your most excellent “detailed” post, although that in itself is worthy of praise, but rather for demonstrating amazing patience and super-humanity through willingness to reach out and help someone who through attitude alone rendered themselves not worthy of help.

I feel belittled by your graciousness and my earlier sarcasm in response to this individual now seems a lot less clever than it felt when I first responded. I think I learned something today and it wasn’t about project management.

Actually, no, there are no global standards. Each studio/team is different. While internally, at each place, there will be conventions, there are no “globally you do this” like in skyscraper construction, car manufacturing, etc…

I guess that is also false, because I’d say if anything the global standard is to have an actual internal standard of naming/labeling/categorizing, so any stadnard practice of any digital production arm of any industry (games, film, tv, etc…)

And game design and development are not really different. You will most likely find games are not like films or tv where a plan is laid out 100% ahead of time and small deviations are ok. Games are more like a plan is laid out ahead of time and you will encounter more deviation during development, which requires some re-design, wash-repeat. Games are very much software engineering, and any good/great engineering will tell you iterate, iterate, iterate.

I dont consider myself good or great, but I have been doing sw engineering/game development and production pipeline software for twenty years =p