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.
My first gamedesign doc...
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! :)
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]
_______________________Afr0Games
upload it as a text file not a word doc. .doc files are easy virus transporters.
-me
-me
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.
A game design document should describe the world, the characters, the story, the game rules, etc.
Now that I'm blind from trying to read it. . .
Okay, here is a link with several game design documents and a template you can study. It will help you.
Link
Okay, here is a link with several game design documents and a template you can study. It will help you.
Link
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!
@ 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!
_______________________Afr0Games
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement