Sign in to follow this  
Afr0m@n

My first gamedesign doc...

Recommended Posts

I'm just going to post here to (hopefully) get a grasp of how people thing I'm doing in terms of indenting and stuff. Also, it wouldn't hurt if some network guys could give me input on how I'm doing in terms of coming to grasp with the loginprocess so far! I'll also put the file up for download, just in case someone wants to see the original look. Please be nice, this is my first try, and I'm not feeling very cocky! :)
Nimdalin

Design Document

I.	Overview
A.	Technical design
Article I.	Networking protocol

II.	Networking protocol

A.	Login process

Brief
When a player logs into the game, he will do so through the login server. When the login request hits the login server, he must have supplied his account name and password, which is what the initial login packet should consist of. When the initial login packet hits the login server, the login server will retrieve the account name and password, and send it in a UserCheck package to the database server. 

If the database server cannot find any account in the database that has the same username AND password as the contents of incoming UserCheck packet, the temporary data from the packet will be discarded immediately, and a FAILURELOGIN packet will be sent back to the login server, which will, upon arrival, simply be relayed to the client, which will then display an informal message to the user, telling him that his account name or password might be wrong. 

On the other hand, if the database server is able to match up the account name and password from the UserCheck packet with an equivalent entry in the database (which must have a matching username AND password), it’ll send a SUCCESSLOGIN packet to the login server.
 
Upon receiving a SUCCESSLOGIN packet, the login server will send a SUCCESSLOGIN packet to the client.  This time, it will contain a unique ticket number, as well as the account name and password. Once received, the client will use this packet to do a check on the username and password in the packet versus the ones typed in. If they match up, the client will let the user through to the character selection screen. Once the player has selected his character, and selected to log in, the client will create and send a GAMELOGIN packet to the login server, consisting of the ticket (which must be stored), account name, password and character name.

When the GAMELOGIN packet is received by the login server, the server will check the ticket, account name and password against previously stored TICKET class instances, which will be stored as they are created. If the account name, password and ticket code matches up, the login server will construct a GAMELOGIN packet consisting of the character name, account name and password of the player, and send it off to the main game server.  In addition, the login server will also send a GAMELOGIN packet back to the client, containing his character name, account name, password and the IP and port of the main game server.

The client will, when receiving a GAMELOGIN packet from the login server, attempt to connect to the main game server. 

When the main server receives the GAMELOGIN packet from the login server, it will send a PLAYERINFO packet to the database server, containing all the data from the GAMELOGIN packet (character name, account name, password). If the database server finds an account in the database that matches the credentials given, that has a character with the same name as the one in the PLAYERINFO packet, it will construct a new PLAYERINFO packet containing the player’s character name, the character’s position on the X, Y and Z axis and which map the player is on.

If the attempt to connect to the main game server was successful for the client within a period of maximum 2 minutes, it will send a new GAMELOGIN packet to the main server, identical to the one it got from the login server. The main server will, by now, have stored the necessary information about the player that it got from the database server in an instance of the PLAYER class. The data will be stored in memory, as these instances won’t take much space. If the GAMELOGIN packet from the client had a character name that matched the one in an instance of the PLAYER class in the main server’s memory, the main server will respond with a new USERINFO packet containing the character’s name, position and current map. Once the USERINFO packet has been received, the client will attempt to load the map and place the player’s character model on the given position on the map.

However, if the attempt to connect to the main server was unsuccessful within 2 minutes, the client will stop the connection attempt IMMEDIATELY and display an informal message, explaining to the player that the main server is possibly dead or that his internet connection is lost. The same thing will also happen if the client is not able to connect to the login server initially within a period of 2 minutes.

Packet classes required for this operation:

INITLOGIN
Should exist on:  Login server and client.
	Public variables:
	Std::String AccountName
	Std::String AccountPassword
	Private variables: None.

	USERCHECK
	Should exist on: Login server and database server.
Public variables:
	Std::String AccountName
	Std::String AccountPassword
	Private variables: None.







Here's the original file: Nimdalin Design Document Nimdalin Design Document, Text version [Edited by - Afr0m@n on June 8, 2006 1:22:11 AM]

Share this post


Link to post
Share on other sites
I am sorry, but I couldnt even read it. The thing is huge. You shouldnt make it so people have to scroll in that scroll box and then scroll in the browser window. Its a pain to read. I think you will get some replies if you form it better.

Share this post


Link to post
Share on other sites
Looks okay, but not as a game design document. It's more like a technical design document, or a use-case.

A game design document should describe the world, the characters, the story, the game rules, etc.

Share this post


Link to post
Share on other sites
Ok, I have to admit that the original indention etc. didn't turn out so good in the codebox! ^^ So, that's why I supplied the word document as a download! But I'll follow up on Palidine's suggestion (thanks!) and supply it as a txt file as well.

@ Sijmen: I'm trying to create a design document that has the technical and game design in it. Hence the "Technical design" header.

Edit: Thanks alot Sijmen, for apparently having the guts to download the word doc and pointing out that it looks ok!

Share this post


Link to post
Share on other sites

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

Sign in to follow this