For a singleplayer game it has recently become standard to allow the player to enter their name or name the location they own within the game (ranch/farm/zoo/store/house/estate/tribe/country). This is a simple input and storage of a text string. This name may be used when the game or an NPC speaks to the player or about the player. It may also be incorporated into the save game file's name. Many singleplayer games do not bother with a password system, but such a system can be used if it seems likely that multiple people will have their own game accounts on the same computer, and players might want to protect their own account from meddling siblings or friends. Passwords in general need to be stored using some kind of encryption. Some singleplayer games are in a free trial mode by default, unless and until the player purchases the game online, receiving an activation code or script. Entering this code or running this script is part of the process of registering the player as an official owner of the game, but it may take place after the player has already been playing the game for an hour or more.
So, where are you storing all this data? A completely singleplayer game typically uses a saved game file stored on the player's own computer. This is possible because with a singleplayer game it does not harm other players if anyone hacks game files on their own computers. Some games even encourage user-modifications, and may offer an online system for distributing these to other players. The Creatures series, Sims series, and Spore are some examples. Multiplayer games on the other hand do not want to put any important data on the players' computers where it is vulnerable to being altered. It's common to have the player's computer store a client, which is more or less an engine for displaying the game's data to the player, and also remembering the player's customized settings and patch history. They also may cache on the player's computer sound files, graphics files, and other data used only by the player's computer to display the game to the player. This can reduce constantly re-downloading the same files from the server, which is annoying to the player and costs bandwith for both the player and the server. For a while people were experimenting with putting hackable data on players' computers and just checking it against the server to make sure it hadn't been tampered with, but players kept finding ways to get around this checking so this method is basically extinct.
Some games, especially those with minimal graphics, store all their data online and don't put anything on the player's computer except possibly a browser cookie. Most browser-based games are in this category. This method can be advantageous because it removes the need for players to wait for a possibly long download before they can start playing, a traditional hurdle to getting potential new players into the game. But on the other hand the game may have a fairly long load time for every play session, which could have been shorter if some of the things being loaded had been cached on the player's computer.
On the server-side of multiplayer games, because the server has data for many, many players, in addition to data for various monsters and items which have many instances within the game, it makes a lot more sense to store all that data in a database rather than a file for every player, every monster, and every item. A database is a system that structures and indexes information so it's fast and retrieve the data you want from it. For example, a common thing a game needs to do is to generate the loot a player gets after winning a combat. Each monster has a standardized set of database entries associated with it, one of which is a loot table. When generating the loot, the game only needs the loot table, not the monster's other data like hp or appearance, so it would be inefficient if they were in the same database entry. And the game needs to quickly grab the loot tables for every monster that was killed in the combat if more than one was. Well-known databases include all those variants of SQL, along with Oracle and Access. Anyway, although someone has to design the particular way a game's information will be stored in a chosen database or saved game file, that's getting more into programming issues and is off-topic for this guide.
Online games typically have a more complex registration system than single-player games. (The major exception is ad-supported minigame archives, which typically have optional registration or no registration, since they do not need billing information for users.) Usually the player will have to state their birthday or that they are over the minimum age your game or a specific server of your game allows. Many games also require an email address. Optionally a game may allow one player to create several characters or locations, each of which needs their own name; in this case the player's name may either be used only by the forum and billing system, or may not be used within the game at all. Online games typically store most of the game's data in database entries. A player's true identity within the game may be their account number, with the player's username being only one of several pieces of data in the database entry for that account number. In some cases a game may be part of a larger network where the player already has an account, from which the game will import some of the player's data, and possibly share the player's achievements within the game back to that network. Typically a player is required to read the game's terms of service during the registration phase if they were not already required to do so during an installation phase. Many people don't actually read those things, so it can be helpful to also present the few major rules of the game in big red letters as part of the registration process.
If your game has servers or realms, helping the player select one and recording that selection is also part of the registration process. Typically the player will want to know the server's age and how full it is. In some cases you will want serves to be functionally different: PvP vs. PvE, or normal vs. heroic (larger rewards and harsher penalties possibly including permadeath), under-18 vs. over-18, or f2p vs. subscriber-only. So you will need to tell the player which servers are which, and also check the player's age or subscriber status to see if they are allowed into a restricted server.
Another standard part of many registration processes is to test the validity of the email address that has been entered by sending a test mail with an activation code, which the player must click on or copy and paste to activate their account. Un-confirmed players may be able to play with some features disabled - usually multiplayer ones like trading and chatting or posting to forums. This is because the email-validity check is designed to help filter out previously-banned people, spammers, and goldfarmers, all of whom cause problems by interacting with other players but aren't really a problem when playing solo.
Hey look, we've gotten to the end of the statement of purpose! For the last sentence you should write something along the lines of "Gameplay will take place [on the player's computer or phone/in a client communicating with an online server/entirely online via a browser.]"
Then let's strike while the iron is hot and start the features list! This is the list that will develop into the main part of your design document (and a non-detailed version of it will be your table of contents). But right now let's just make a list, you will need to look back at what you decided in the first 3 parts:
- Game Data Storage
[indent=1]- [Offline saved game file/Online database/Mainly offline with minimal online friends network or cash shop or ad serving]
- Account Creation and Registration
[indent=1]- [If online, are you handling account creation yourself or is a store or stable handling it for you?]
[indent=1]- [What data do you want to collect from each player?]
[indent=1]- [If you have a free trial, how do you tell whether a player is in that mode or fully activated mode? Some distributors, such as Big Fish, have a standardized free trial system that they apply to all games sold through them.]
[indent=1]- [Do you require email confirmation, credit card confirmation, or age verification? What can't the player do before they are confirmed?]
[indent=1]- [If you intend to have multiple servers, what differentiates them?]
- [Graphics Type]
- [Gameplay Genre(s)]
[indent=1]- [Looking at the description of your genre, what major features does this genre have that you want your game to have? E.g. Combat, racing, crafting, puzzles... Give each of these its own entry here.]
- Story (unless your game has none)
[indent=1]- [Linear or Interactive]
[indent=1]- [Story Genres(s) E.g. Horror, Fantasy, Humor, Romance, Adventure, Mystery]
[indent=1]- [Theme(s)]
[indent=1]- Story is shown to the player through [NPC dialogue, written pages or books, cut-scenes between play segments, comic/manga pages between play segments, direct narration to the player, item flavor texts, graffiti/murals/stained glass images on level walls, etc.]
[indent=1]- Notes: [Any story ideas you have had so far]
- [Number and Type of Playable Characters]
[indent=1]- [Continue to section 5 for the rest! :) ]
