GameDesign: Difference between revisions

Jump to navigation Jump to search
← Older editNewer edit →
Content deleted Content added
No edit summary
No edit summary
Line 239: Line 239:
The rest of code is handled by the server itself, and will create the tables if they don't exits.
The rest of code is handled by the server itself, and will create the tables if they don't exits.


3.c PlayerContainer Explained
=PlayerContainer Explained=
Last updated: 2003/10/23

PlayerContainer is the data structure that contains all of the needed info about the players to keep the game running.
PlayerContainer is the data structure that contains all of the needed info about the players to keep the game running.


It consists of a list of RuntimePlayerEntry objects, and is heavily linked with the PlayerDatabase, so we can hide the complexity to GameManager. By making PlayerDatabase hidden by PlayerContainer we achieve the illusion that managing the runtime behavior we modify automatically the permanent one.
It consists of a list of RuntimePlayerEntry objects, and is heavily linked with the PlayerDatabase, so we can hide the complexity to GameManager. By making PlayerDatabase hidden by PlayerContainer we achieve the illusion that managing the runtime behavior we modify automatically the permanent one.


RuntimePlayerEntry is the structure that contains the information of the player while it is online. RuntimePlayerEntry contains:
RuntimePlayerEntry is the structure that contains the information of the player while it is online. <br>RuntimePlayerEntry contains:
clientid
* clientid<br>
Clientid is the field in charge of indexing players in the server. See the document about clientid generation to understand what they are and how they are generated.
Clientid is the field in charge of indexing players in the server. See the document about clientid generation to understand what they are and how they are generated.
source
* source<br>
Source is the IPv4 address of the client, so that we can determine if the message is really coming from client or another person trying to impersonate it.
Source is the IPv4 address of the client, so that we can determine if the message is really coming from client or another person trying to impersonate it.
timestamp
* timestamp<br>
Timestamp is used to determine if a client has timed out and as such, it is only wasting resources on the server. As you know, UDP is not a delivery-guaranteed protocol, so we need to check ourselves for dead clients. Take care that it only indicates that the player timed out, it doesn't apply any kind of measures over them.
Timestamp is used to determine if a client has timed out and as such, it is only wasting resources on the server. As you know, UDP is not a delivery-guaranteed protocol, so we need to check ourselves for dead clients. Take care that it only indicates that the player timed out, it doesn't apply any kind of measures over them.
* storedTimestamp<br>
⚫
username
storeTimestamp is used to determine when it was the last time that this player was stored on database, as storing for each change will be very CPU consuming so we cached it and store each 5 minutes.
⚫
* username<br>
Username is filled in at runtime with a Login event so that we are able to use the database from PlayerContainer, This way by knowing the clientid we can also know the username.
Username is filled in at runtime with a Login event so that we are able to use the database from PlayerContainer, This way by knowing the clientid we can also know the username.
choosenCharacter
* choosenCharacter<br>
choosenCharacter is filled in at runtime with a ChooseCharacter event so that we are able to use the database from PlayerContainer, This way by knowing the clientid we can also know the choosenCharacter.
choosenCharacter is filled in at runtime with a ChooseCharacter event so that we are able to use the database from PlayerContainer, This way by knowing the clientid we can also know the choosenCharacter.
state
* state<br>
State is a number expressing the state in which the player is. There are four states:
State is a number expressing the state in which the player is. There are four states:
Have to login
**Have to login
Login Complete
**Login Complete
Game begin
**Game begin
Logout
**Logout
When we create the entry it is by default Have to login. Once you have logged in correctly, we change state to Login Complete, and once you have chosen a Character we change it to game begin. The logout state is trivial :)
When we create the entry it is by default Have to login. Once you have logged in correctly, we change state to Login Complete, and once you have chosen a Character we change it to game begin. The logout state is trivial :)


The main idea is that some operations are only allowed in one state, so we can more easily control it with the state property.
The main idea is that some operations are only allowed in one state, so we can more easily control it with the state property.

perception counter
*perception counter<br>
Perception counter is used for having a incremental counter of the perceptions send, so that client can see if it gets out of sync.
Perception counter is used for having a incremental counter of the perceptions send, so that client can see if it gets out of sync.
perception Previous RPObject
*perception Previous RPObject<br>
Perception previous RPObject is the RPObject that was sent on the last perception, so we can track changes on our RPObject without disturbing the rest of the system.
Perception previous RPObject is the RPObject that was sent on the last perception, so we can track * changes on our RPObject without disturbing the rest of the system.
*perception Out of Sync<br>
timestamp of the Last time it was stored
This flag indicates if the player notified us that it was out of sync, so we can re sync it as soon as possible.
Timestamp of the Last time it was stored means the timestamp of the moment in which the object was stored at Database.



As you can see all we need to operate PlayerDatabase is a username and choosenCharacter. So using PlayerEntryContainer we can fully operate it.
As you can see all we need to operate PlayerDatabase is a username and choosenCharacter. So using PlayerEntryContainer we can fully operate it.
Home
⚫
3.d ClientID generation
Last updated: 2003/10/23


⚫
==ClientID generation==
Each client MUST have a session id to avoid another player to impersonate it. sessionid must be a short or int to make harder for an attacker to guess it.
Each client MUST have a session id to avoid another player to impersonate it. sessionid must be a short or int to make harder for an attacker to guess it.


To make it really fun, clientids are generated randomly for each player with the unique condition that two different players MUST have two different clientids.
To make it really fun, clientids are generated randomly for each player with the unique condition that two different players MUST have two different clientids.
Home
Home
⚫
3.e Synchronization between Game and RP Managers
Last updated: 2003/12/06


⚫
==Synchronization between Game and RP Managers==
Why bother with it? Well, imagine that a player logs out when the perception is being built, it will no longer be accessible for the RP Manager, when it really expects the object to be there. Or a removed player that is removed too by RP Manager. That is a really serious problem, as it will make the server fail.
Why bother with it? Well, imagine that a player logs out when the perception is being built, it will no longer be accessible for the RP Manager, when it really expects the object to be there. Or a removed player that is removed too by RP Manager. That is a really serious problem, as it will make the server fail.


Line 294: Line 293:


Whatever action we choose in GameManager they are Write actions, as the modify the state of the PlayerContainer, but in RP we have two parts, one that build the perceptions that is read only and one that removes idle players that is write, so we must apply two different locks there.
Whatever action we choose in GameManager they are Write actions, as the modify the state of the PlayerContainer, but in RP we have two parts, one that build the perceptions that is read only and one that removes idle players that is write, so we must apply two different locks there.
Home
3.f Persistent Objects ER
Last updated: ?


use marauroa;

drop table rpobject;
drop table rpattribute;
drop table rpslot;
drop table RPObjectInRPSlot;

CREATE TABLE rpattribute (
object_id int(11) NOT NULL default '0',
name varchar(64) NOT NULL default '',
value varchar(255) default NULL,
PRIMARY KEY (object_id,name)
) TYPE=InnoDB;


CREATE TABLE rpslot (
object_id int(11) NOT NULL default '0',
name varchar(64) NOT NULL default '',
slot_id int(11) NOT NULL auto_increment,
PRIMARY KEY (slot_id)
) TYPE=InnoDB;


CREATE TABLE rpobject (
id int(11) NOT NULL default '0',
slot_id int(11) default NULL,
PRIMARY KEY (id)
) TYPE=InnoDB;
Home
4.a Actions and Objects
4.a Actions and Objects
Last updated: 2003/10/07
Last updated: 2003/10/07
Retrieved from "https://meet.konsthol.eu/w/index.php?title=GameDesign"