Finishing games
From Spheriki
Contents |
Part 1: Design Docs
Further discussion about this topic can be found this Spherical forum topic.
Introduction
In a scripting heavy engine such as Sphere so many tutorials go over the absolute necessities of programming so much that a lot of other topics that, while not entirely essential to get a game operating, are still important. In this series of articles I'm going to go over how to help get your game finished by discussing a variety of topics related to it in various ways, such as design documents, teams, and deadlines. This and the other topics may seem incredibly obvious to some people, but the fact of the matter is that to many starting people these concepts never even cross their minds when they could be helping them.
Starting it off: Design Documents. You may have heard the term before, but since it's so vague you may have no idea hat it's actually referring to. In the simplest terms: It concisely describes a game from beginning to end. The actual form it takes depends on the writer and the game. They can range from one paragraph describing the basics of the game, to several megabyte monsters that include spreadsheets describing every item in the game, the complete dialogue, formulas for everything in the game, etc.
The Purpose of Design Docs
The actual utility for one ranges depending on the project in question, but it's pretty much universally useful for every project. A few examples: As a single developer it helps you organize your idea into a form you can refer back to in the middle of development when you may have forgotten important things. Even so it's not total stone- if there's something you can change for the better, change it. But it's far too easy to forget a good idea in the middle of development.
For a team project it's even more important, it lets everyone in the team know what they're working on as a whole since they don't have the primary designer's vision without it. Furthermore, it can be used to delegate tasks for who's supposed to do what or know about things connected to a team member's current job.
It's useful to lay out all the data for a game in advance. Rather than having to come up with a new way for your code to handle your latest idea, you can conveniently see a list of every item or monster or character or whatever and how it's supposed to work before hand so your code ends up cleaner with a clearer purpose from the beginning. Additionally, you can write out, say, all the dialogue for a game's story so you know exactly what happens and what art resources are required for it and you can alter the story to flow better while it's still just an idea, rather than having to revamp half the game you already did.
I should emphasize this once again: While you might write out every detail of your game in your design doc, it's by no means set in stone and you'll inevitably have to alter portions of it from your original design document once you see how things work out in practice rather than concept.
Writing Them
Now that we've laid out the general concepts of design docs and their purpose it's time to move on to actually writing them. There's no real established format. Decide what your game needs laid out and then write it. Look up game design docs on Google to see a few examples if you really need to. I'll list a few ideas of what a design doc can contain to give you some ideas, using examples from my own games (Some of these are old and may contain erratic grammar/spelling).
Overview
Overview: A basic summary of your game as a whole. Shouldn't be more than a paragraph in length, brevity is key here. It's the other sections that require detail. You may also want to compile a list of design goals for the project in this section as well. Ie, if you're making a puzzle game you could put one of the goals as "Sessions only last five minutes or less to give a pick up and play feel".
Example, from Lexico:
The player crash-lands on a mysterious planet. Upon awakening he discovers his ship destroyed beyond repair, and himself trapped on a planet with mysterious panels jutting out of the rock, and impenetrable doors blocking his way out. Soon he discovers the panels have a wide array of uses, from opening and closing doors, controlling the weather, creating food, and more. As he travels onward he discovers robots that he can program with his knowledge of the language on the panels and eventually intelligent robots he can talk to and hopefully arrange for a ship out of the planet. The only question is- what is the purpose of this mysterious mechanical planet?
(Notes: This really isn't descriptive enough of the actual game, partially because it was written before the rest of the design doc. I couldn't find a better one from my list though as they all do a pretty poor job of summarizing all the elements together (rather choosing to primarily rely on detailing each one by category) so it'll have to do.)
Description: A varying number of paragraphs describing a piece of your game in fair detail.
Example, from GRPG (In Planning):
- 2.1 Battle Turns
- Battles take place in a turn-based fashion, with the order of turns being determined by each character and enemy's speed stat. The higher it is, the sooner you're placed in the turn order. If two entities have the same speed stat, the player character is placed higher in the order. If it's between two player characters, the one which gets placed first is decided by their order in the party. The turn order is displayed on top of the screen as a bar as such:
- [Character3][Monster2][Monster1][Character1][Character2][Monster3][Character4]
- Turns are executed all-at-once (ie., you pick your commands and then all of the attacks take place then it's another turn)
- -----------
- 2.2 AP
- Every ability a character uses in battle costs a certain amount of AP (Action Points). The party has a global pool consisting of 50. If a character performs multiple abilities in a single turn, the AP cost of all of their actions will rise based on how many they are attempting to perform at once.
- Global AP Can be raised by:
- -Using a stance that contains +AP (-AP is also possible)
- -Equipping items with +AP
- -Finding an item which permanently increases it. (Rare)
- -Using an ability which increases it temporarily, or having a passive ability equipped that increases it while equipped.
(Notes: This goes on for a fair bit, splitting into sections each part of the battle system specification. I'dve preferred to use a released game's design doc but many of my older ones often had story and game intertwined in their descriptions, making it difficult to have a clear example.)
Map layout
Map Layout: A sketch of the overall world of the game. Might have multiple of these for some games, although in many cases you might not want to make pre-plans of these if you have a great deal of them, it might be more efficent to just directly map them out in the real map editor. This is mostly useful for an overview of the maps and how they connect rather than the individual elements of every map.
Example, from Urgan the White in: THE QUEST FOR COLOR:
Simple map using colors to show the difficulty of enemies present and whether there is a healing tile. Also shows the general linkage between maps, their numbers (to refer to when linking), and their general size. More complex maps would probably have an accompanying document detailing what is in each map.
Item List: A spread sheet of every item in a game, its purpose, statistics, description, etc. The precise amount of detail depends on the game you're making. If you have a really big RPG or something it might be wise to have the game directly import data from a spread sheet to make it easier.
Example, from Linie Schiff 1:
Construction Description ----------- ----------- Line Basic building bones of ship. Three types of it are availble. Weak is cheap, blows up on a single hit. Medium is semi-expensive. Withstands two hits. Strong is VERY expensive. Withstands five hits. 1A Forward gun Shoots basic bullet forward 2B Back gun Shoots basic bullet backwards 3C Left gun Shoots basic bullet to the left 4D Right gun Shoots basic bullet to the right 5E Power gun Gun that shoots forwards. More powerful than standard gun, but slower. 6F Heat seeking missile Missile that locks on to nearest enemies and tracks it until a collision. Each one you place provides 5 missiles. 7G Shield Activates a shield that will protect you from 10 damage. At ten damage it will be destroyed. 8H Laser Constant fire in direction specified when in building mode (full 360 degree placement for the beam) 9L Container Holds special items you can use in battle mode. Each one lets you hold one more item. Doesn't use a trigger group since special items have their own button map. In battle, sometimes enemies drop various power-ups. Power-up Description ----------- ----------- 0 Mega gun Increases regular gun power for duration of mission. Can go up to 5. 1 Heat Missile Gives you 5 more heat seeking missiles to your inventory. 2 Shield Gives you 10 more shields. 3 Explosive Damages your ship on contact. 4 Money Adds a random amount of money to your money when touched. 5 Bullet spread Item. Launches 50 bullets from you from every side of your ship. 6 Peace keeper Item. Destroys all projectiles on screen. (Including your own) 7 Smelt Item. Turns all enemies into super bullets. (Unless they have shields) //8 Laser lengthener Makes your lasers longer for duration of mission. Can go up 3.
(Note: I should probably have included more detail, such as the exact price of every item.)
Script
Script: The complete dialogue from characters in whatever organization you feel is necessary. Leaving out unimportant dialogue such as NPCs might be okay but it's heavily recommended for story-critical events. You should also describe whatever actions they take during scenes.
Example, from Eine Verschmutzung:
- [Peaceful, happy music]
- *Heroine wakes up in her house and gets up and walks towards her mother*
- Heroine: Mother..
- Mother: Oh, you finally woke up, I thought you'd never get up! Now-
- *Screen fades to black with just the heroine and her mother, mother turns into a skeleton*
- [Music fades out]
- Heroine: Mother!
- *Heroine runs up to her mother's remains and kneels, crying*
- *Corpse fades out*
- Voice: You know you did this to her.
- Heroine: What.. who are you?
- Voice: You did this to all of them, reduced them to nothing.
- *Heroine gets up*
- [Cue sad, deserted, lonely music]
- Heroine: I didn't do anything. I could never do this to anyone, never my mother! Who are you?! Why do you accuse me of lies?!
- *Screen fades into a dead world, space is visible from the cracks in it*
- Voice: You promised them you'd save them, but you failed.
- *Heroine moves towards one of the cracks*
- Heroine: Where is this? Answer me!
- Voice: It's your creation.
- Voice: You failed....
- *Brief period of silence*
- Heroine: Are you still there?
- *Brief period of silence*
- Heroine: ...
- Heroine: I don't know where I am, or who that voice is... but, I never did this... not to anyone.
- Heroine: I have to find that voice!
- -Player is given control over the heroine-
(Script goes on to describe the rest of the game. This is the exact dialogue used in the game.)
Mock-up
Mock-up: A simple sketch of how a game's interface should look and work. Can also be used for other things if you're trying to convey an idea to an artist.
Example, from Linie Schiff 1:
Single player works as following. You start out on a mission select screen that looks like this: LEVEL = (LEVEL) ^ ------------------------------------------------------- | |(Mission name) | | |Level: (Mission level) | | |Fly: (C) (S) (G) | | ------------------------------------------------------- | ------------------------------------------------------- | |(Mission name) | | |Level: (Mission level) | | |Fly: (C) (S) (G) | | ------------------------------------------------------- | ------------------------------------------------------- | |(Mission name) | | |Level: (Mission level) | | |Fly: (C) (S) (G) | | ------------------------------------------------------- | XP = (XP) v (SHIP EDIT) (SAVE) (BACK)
The CSGs represent mission medals. C = copper; S = silver G = gold. The higher value, the harder the mission is. Clicking ship edit takes you to the editor to edit your ship. Ships must have at least 3 lines to be able to go on a mission. Clicking on one of the CSGs takes you to that mission's selected medal. When you click one of the CSGs you go to the briefing mode that looks like this:
-------------------------------------------------------- |(Mission name) | |Medal: (m) | | | |(Briefing text) | | | | | | | | | | | | | | | -------------------------------------------------------- (FLY!) (BACK)
- When you press the fly button you begin the mission.
- Certain missions, objects, and upgrades are only obtained by meeting certain goals (eg. beating all gold medals of level 1 missions)
(Notes: Obviously these can also be simple graphics rather than the presented ASCII)
Pseudo code
Pseudo Code: Basically writing the overall flow of your game in simple English. The amount of detail will vary depending on how in-depth you wish to go. You could also use flow charts and other code planning tools that I won't go into heavy detail about. It may also be wise to include details of how you intend to code various aspects along with their base descriptions, but make it easily ignorable by non-programmers on the team.
Schedule
Schedule: A list of dates you intend to get various aspects of a game completed. You could also write this as a check-list without specific dates to give you an idea of what you need to do next.
Conclusion
These are just a small set of types of sections you can have in a design doc, use them as your game requires and come up with new ways of organization as best suits you. Good luck with your future games! The next part of this tutorial series will have to do with deadlines and other things that should be applied to finish a project.
-- SDHawk
