First hello to everybody,
I am looking around the Unity forum for a while now, not posting so many posts,
but now i have a question for a essay.
The essay I am talking about is really important because its for our exams.
The question:
What are the steps of designing a game.
Like sketches, storyline, that sort of things.
We would really appreciate any help with our essay.
If there are any questions about what I ask, or anything els, just ask me.
Padrini
You should take a look at how to create a GDD (Game Design Document) It covers so much of the design, you’d probably not even think of.
I know about the GDD, but I was looking for how it was done, which steps would be taken to make the game like first thinking about the story then storyboard then the models and programming.
So i mean the way the process wil be done at a studio.
www.gamedev.net could help you out a lot with this assignment. They have some really good articles on the process.
A GDD is divided into several pieces:
*Overview
*Story
*Characters
*Non-Playable Characters(NPCs)
*Enemies
*Level Design
*Mechanics
*Interface
An overview contains the concept, genre, market, and features of the game. The concept tells what the game is about and is the core concept of the game. The genre is the type of game. The Marketing plan tells if you are going to sell the game and who you’re going market it to. The features list the things that set the game apart from the rest.
The story is what’s going on in the game. You inform the player about events that are occurring in the game and how they fit into it. The theme of the plot should match the game. List the plot elements and be through with your story.
Characters are the stars of the story. You should list the characters personalities, backstory, weapons, roles in the story, relationships, appearances, and abilities if they apply for the game. When making a character, try not to make them too shallow or too perfect. You characters should be unique and individuals, not generic and bland.
NPCs are just background characters who hang out doing nothing, even if the world is ending. Allies, Neutral, and Hostile are the three types of NPCs. Allies will assist you for a reason, Neutral are just on their own side, and Hostile lash out against you.
Enemies are the opposition. These break down into Normal enemies and Bosses. Most normal enemies are cannon fodder, but they still need to be thought out. Bosses are usually important to the plot and should be as well developed as characters.
Level design should have a description of each level as well as placement of enemies, items, important points, etc. You should also tell how the player interacts with the environment and how to progress to the goal of the level. You should also tell how the level connect.
Mechanics are the functions of the game. These includes the controls, which should be well explained and defined. If you don’t have this section then technical information won’t have anywhere to be placed.
Interface is the user’s window into the game. These include health, score, etc. In general display only what needs to be shown and don’t clutter the screen.
These are basics of a GDD. Some parts can be omitted and others can be added, it depends on the game you’re making. This is in no way a fixed guide, as you will constantly need to change around the document as your game evolves.
Persona thank you for your explanation it is very helpful for us.
MakerOfGames, I will give it a try, thank you for the link.
You would probably plan out everything first before doing anything else. Then you would create storylines and simple concepts. Then you would try to program the base of the game without any art or anything, just simple primitive shapes for testing. Then when the base is done you move onto the art side and produce 3d models, work on environments and so on. Lastly you implement the GUI, sound and what ever else.
At least that’s what I think (probably wrong though 
)
Not a problem, I specialize in making GDDs
Well, a GDD also contains technical things, like what game engine you choose, and what language you want to use for the game.
GDD is only a part of game development process.
Usually it comes to waterfall methodology when developing small games.
pre 1. have a good idea of what you want to achieve,
btw, unity IDE feels to be more suited for agile workflow.
The GDD can also include prototypes of the mechanics, concept/style guides of characters and levels, mockup UIs, marketing strategies, etc.
If you are trying to tout your game to a Publisher, the more you can put in the better. It also stops them coming back at a later date and refusing to pay for “features” that weren’t in the GDD. They’ll have you by the balls financially so it’s hard enough to keep development control.
It does depend on the platform you’re developing for and the size of the project (xbox/ps3 will need a publisher) and not necessarily required for smaller self-published games on the app store, steam, portals, etc.
Game Design theory is well and good, but I think in practise the process often goes like this:
@mr. wrong - in my experience it depends on the size of the project, and if it’s for profit or not (usually dictates polish, and if you need to use other compensation models - eg. in-game purchases.)
The game design process I follow is:
Course I use my toolbox templates (shameless plug 
).
@padrini - That plug wasn’t necessarily directed at you… I firmly believe that when you’re starting out, find what’s free and test the waters. As you get going you’ll sort out what to invest in (there’s no end to what you could buy and it would help).
Cheers,
Galen
I actually work in the oil industry and we use a piece of software called MindManager all the time. I just recently joined an MMO class at 3D buzz and was surprised to see them using a similar product to map out the game beforehand.
My game that I am making at home has played out like this:
First I started making some basic tech demos of basic things like third person/first person movement. After those tech demos I took a step back and wrote a GDD. I actually split my document into two documents. Functionality and Technical. Functionality = How the User sees the game and Technical = How we code the game. Obviously if you start with how the user interprets the game it allows you to focus on the fun factor and the playability. After that is mostly done you can start describing how you program all of that in the Tech document. After that my friends and I actually started to piece together a storyline. We used a private Blog at first. Occasionally I created a MindMap of things like the crafting system.
Next I started down the path of a “playable level demo” in which you create one level that has 80% of the things in your documents and shows off the meat of your game elements. That is as far as I have gotten. Next on my list is to start extending that.
With game development, and something not a lot of people realize, you have to actually build up and tear down and build up and tear down through an iterative process. Yes you can make a game in a week or a day or whatever. But if you want your game to last for more than a month you have to really build up the core mechanics and story through this iterative process. Game studios do this process much faster and Indy devs seem to ignore this process because they know for them it will turn into a never ending cycle because there is no decision maker that tells them to move forward with a deadline. Hobbyist seem to perpetually live in this iteration cycle.
In my team of friends that make this game we have two that are in no way game developers. They are involved in the process in order to keep the rest of us in check and say “Are you beating a dead horse?”
Anyways that is my take on it.
I’ve tried mindmaps a couple of times, but never got a good “fit” feel from them. I know lots of people who do use them well though.
I come from the Business IT world (IBM, global consulting, etc…). I’m taking a longer view of making games, I’ve got a technology roadmap, where I’m iteratively building pieces, testing them, enhancing them, what not… over the course of a series of games. I agree most studios (particularly the bigger ones) do tend to build/tear-down/build again. At least according to the post-mortems and chats I’ve had with folks inside… but that requires 2 things to work well 1) really talented and skilled teams and 2) a heck of a long budget rope. It also leads to the failure rates you see in the industry (look at Gearbox buying Duke Nukem IP and the total collapse of Cheyenne Mountain last year). That Duke game burned on forever, under the same leaders that created it … I do think Gearbox will drive it home, but… it cost 3D Realms 10+ yrs… right into the ground. I won’t even touch Cheyenne Mountain… ye gods!
Indie games are always about doing what you can with what you have (time, money, skills, friends, etc…). yes, Game Development is more complicated than most who first wander in “off the street” are prepared for (most times). Happily we seem to have a large pool of noob herders here in the Unity forums Of course, uttering the MMO incantation will bring out the “boots of reality” folks … hehe. MMO is different in many ways, mostly technical. If you don’t design your MMO… very well… your chances are low. Funny thing is, gameplay, art and general game design for MMO doesn’t really change much, just expands to include more social aspects. The technical on the other hand, is a different skill set. No different than desktop apps devs branching into network development really.
Good luck with your game,
Cheers,
Galen
@padrini - if you’re interested in how the big ones do, there’s a good article here