This is one of many possible schemes for the AI of an enemy NPC in a first-person shooter game. As written, it should (disclaimer: have not coded it yet) be fairly straightforward to translate it to a UE4 blackboard, behavior tree, and tasks, services, and decorators.
Have you tried to create a large game project and got lost in the weeds? It is very easy to do. If you were working for a AAA game development company (like Epic Games), that probably would not be a problem, because the company would have a YUGE staff for all phases of game development, and you would have maybe a 100- or 1000- page Game Design Document. This would detail everything that needs to be done in the game, and it will have been reviewed multiple times by perhaps 100s of employees (developers, designers, testers, artists, management, and so on) (though even with all that, it may be changed as more is learned!) so you always know what needs to be done and how it fits with the rest of the game.
Now, at the other extreme, suppose you are a one-person game studio. You are it! You are the designer, developer, artist, manager, and janitor. You might not relish the idea of writing a 1000-page Game Design Document (GDD) all by yourself, and not only that, reviewing it, editing it, making sure it is all consistent (with itself and with available technology), and so on. The good news is, you don’t have to in order to reap benefits when you find your self headed for the rough.
At the smallest extreme, you can write a one-page GDD that hits the highlights. This is far better than nothing at all, even if it isn’t as detailed and well-reviewed as the AAA Game Development Company’s 1000-page GDD.
If you want more, a 10- or 20-page GDD gives additional benefits. 20 pages easily helps you focus enough that even if you find yourself in the weeds, you can see the way out.
If you are a 10-person game studio, 10 or 20 pages would be the minimum, and you could probably produce larger, with more editing and review. My point is smallness of company is no excuse for not planning at all. Just plan less!
Core Components of a Game Design Document
A Game Design Document (GDD) will likely contain at least the following information: title of game (or working title if not finalized yet), genre of game (first-person shooter, puzzle, classic arcade, etc.), technology used (Unreal Engine 4? Unity?), platform (PC/Mac/Linux, Android, etc.) and a brief description of the game.
I recommend more than one description, of varying lengths (for varying purposes).
The tag line is a one-sentence description of the game. This gives more of a taste than a picture. An example tagline (from a movie rather than a game) is, “In space, nobody can hear you scream”, which was used on movie posters for Alien when it first came out. This drew the crowds by giving a flavor of what the movie was like: terror in space.
The elevator pitch is a one- or two-paragraph description of the game. The name comes from this: you work for a company and you happen to find yourself in an elevator car with the CEO, and the CEO asks, “what are you working on?” In the time it takes to get to your floor, you need to explain what you are doing, and of course, make it sound like it’s worth the salary you are being paid.
Finally, a longer Summary of the game gives a good picture of what is happening when somebody plays it. If it is a multi-page GDD, go ahead and use one or two pages for the summary. If it is a one-page GDD, you might skip it (or just consider the rest of the document to be the summary).
If the game has an unusual key mechanic, it should go in the summary, or perhaps in a section of its own. What I mean by “mechanic” is how the game is played: jiggle the joystick back and forth to make the character run, and jiggling faster makes the character run faster. Pressing a button makes the character jump. (I vaguely recall an Atari console game like that). It’s not always necessary to explain the mechanic. For example, most First Person Shooters work the same way. Still, you might want to explain unusual moves (dodging, double-jumping, wall-walking, turn into a spirit like in Prey, etc.)
Assets needed for the game should be specified. For a one-page GDD, it would be a summary of assets and style for them, but for a more detailed GDD, you can get really detailed if you want.
Rules of the game should be specified. Think of a boxed board game: often on the inside cover of the box, the rules of the game were printed. This would include things like win or lose conditions, mid-game achievements (like how the player would end one level and start another), if and how it is scored, how powerups and pickups affect the game, and so on.
Depending on the game, a section for research might be appropriate. For example, if you are making a bowling game, you might have a section giving all the specifications of bowling determined through online research: lane dimensions, markings on lanes, pin sizes and weights, ball size and weights, and so on.
In addition to data from research done, this section can mention research that still needs to be done. As the research is completed, the section can be edited to show that.
Sample Game Design Document
Here is a (incomplete, but a good start) GDD for a 3D bowling game.
Set up ball speed and spin, choose your target, and try to bowl a perfect game!
Choose a bowler character to select strength and speed as well as appearance. Choose a bowling alley, as well as normal or outer space lighting. Choose a ball to select weight, outer coating, and optional asymmetric weight block, as well as appearance. Choose an alternate spare ball if you want. Choose a lane and oil pattern. Then start bowling!
Select a spot. Select a target. Adjust speed up or down. Adjust spin. Choose to use strike ball or spare ball. Hit “Go” and watch the bowler follow your commands. Score!
Physics, Physics, Physics! Player takes all the time they want setting it up, then hit Go and it’s all physics!
Ball, Pin, Lane , Bowler character(s), Sweeper, Pin Setter, Ball Return, Gutter, Monitor
Alley features: tables, other lanes, back wall, ceiling, other walls and floors, snack bar, juke box, entrance, restrooms, ball washer, front desk and shoe rental, people?
Various ball patterns, normal and space light (cosmic or galactic bowling type of situation, with UV lights)
Standard pin and special pins (e.g. red pin), normal and space light
Wood or composite lane, with oil patterns, normal and space light
Bowling alley features materials, normal and space light
Character skins, normal and space light
Sweeper material, normal and space light
Pin Setter materials, normal and space light
Ball Return materials, normal and space light
Gutter materials, normal and space light
Monitor UI material
Bowling animations for character, including right-hand, left-hand, and for backup ball, straight ball, and spin ball.
Camera animations, Sweeper animation, Pin setter animations, Ball return animations
bowler talk, ball rolling, Pin hits, Ball return sounds, Music, Announcer voice, Ambient bowling alley sounds
Attach to character, Roll, Drop, Destroy, Initialize
Take Ball, Drop Ball, Roll Ball
Reset Ball, Reset Frame
Follow Character, Follow Ball, Overview Lane
- Standard bowling lane, standard bowling balls, standard oil patterns, standard pins, standard pin layout
- Ball return, pin area geometry
- Bowling alley features
- Physics: spin, oil patterns
- Bowling terms, both “official” and informal
- Bowling animations
- Good camera animations
- Sweeper and pin setter
- Rules for scoring!
Sample FPS Game Design Document, 23 pages, team of two