• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
  • entries
    53
  • comments
    29
  • views
    121691

Guide To Designing A Pet Game Part 4

Sign in to follow this  
Followers 0
sunandshadow

648 views

4. Player Registration and Account Creation, Data Storage Within The Game

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! :) ]
0
Sign in to follow this  
Followers 0


0 Comments


There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now