GameDesign: Difference between revisions

Jump to navigation Jump to search
← Older edit
Content deleted Content added
No edit summary
imported>Blacklads
Undo revision 11673 by Ufizavipupu (Talk)
 
(86 intermediate revisions by 6 users not shown)
Line 1: Line 1:
{{Navigation for Marauroa Top|Internals}}
{{Navigation for Marauroa Developers}}


= Basic idea behind GameManager =
= Basic idea behind GameManager =
The idea behind the Game Manager is to handle all the "business logic". This Manager decides how to reply to each individual message.
The idea behind the Game Manager is to handle all the "business logic". This Manager decides how to reply to each individual message.
Line 16: Line 20:
</pre>
</pre>


So let's define the reply to each message. Before explaining how to process eahc message, let's clarify that the best way of modelling this system is using finite automates, (finite state machine) where, based on the input, we change the state we are currently in and produce an output.
So let's define the reply to each message. First, let's clarify that the best way of modelling this system is using finite automates, (a finite state machine) where, based on the input, we change the state we are currently in and produce an output.
== Login stage ==
<b>NOTE</b>: This stage has been split in 3 to allow proper secure login.
<b>NOTE</b>: Explain here how secure login works.


<pre>
<pre>
Line 51: Line 58:


Postcondition: The state MUST be NULL or STATE_LOGIN_COMPLETE
Postcondition: The state MUST be NULL or STATE_LOGIN_COMPLETE
and a we have created a PlayerEntry for this player with an unique correct clientid.
and a we have created a PlayerEntry for this player with a unique clientid.


</pre>
</pre>

== Choose character stage ==
<pre>
<pre>
Process C2S ChooseCharacter ( STATE_LOGIN_COMPLETE )
Process C2S ChooseCharacter ( STATE_LOGIN_COMPLETE )
Line 76: Line 85:


</pre>
</pre>

== Logout stage ==
<pre>
<pre>


Line 98: Line 109:


</pre>
</pre>

== Perception confirmation stage ==
<pre>
<pre>


Line 109: Line 122:


</pre>
</pre>

== Transfer confirmation stage ==
<pre>
<pre>


Line 124: Line 139:
Postcondition: The state is STATE_LOGIN_BEGIN and the content waiting for player is clear.
Postcondition: The state is STATE_LOGIN_BEGIN and the content waiting for player is clear.
</pre>
</pre>

= Basic idea behind Database storage =
==Database Tables and Relationships ==

The database table relationship schema is:
<pre>
Table PLAYER
{
PK(username)
password
}

Table CHARACTERS
{
PK(character)
content
}

Table LOGIN_EVENT
{
PK(id)
address
timedate
result
}

Table STATISTICS
(
PK(timedate)

bytes_send
bytes_recv

players_login
players_logout
players_timeout
players_online
)

Table RPOBJECT
(
PK(id)
slot_id
)

Table RPATTRIBUTE
(
PK(object_id)
PK(name)
value
)

Table RPSLOT
(
object_id
name
PK(slot_id)
)
</pre>

Relationships:
<pre>
Relationship PLAYER_CHARACTERS
{
PK(player_username)
PK(characters_character)
}

Relationship PLAYER_LOGIN_EVENT
{
PK(player_username)
PK(login_event_id)
}
</pre>
Translate this to SQL easily and you have the SQL schema of Marauroa


== JDBC Database HOWTO==
JDBC technology is an API that lets you access virtually any tabular data source from the Java programming language. It provides cross-DBMS connectivity to a wide range of SQL databases, and now, with the new JDBC API, it also provides access to other tabular data sources, such as spreadsheets or flat files.

JDBCPlayerDatabase is anyway not database independent; on the Player table we are using AUTOINCREMENT that is a unique keyword of MySQL that is not part of the SQL standard.

You need to download MySQL Connector/J in order to get it to run. <br>
http://www.mysql.com/downloads/api-jdbc-stable.html

To configure Marauroa to work with a JDBC source we need to modify the configuration of the JDBC Connection.

So open the configuration file marauroad.ini ''(or any other)'' and edit the next fields
<pre>
marauroa_DATABASE=JDBCPlayerDatabase

jdbc_class=com.mysql.jdbc.Driver
jdbc_url=jdbc:mysql://localhost/marauroa
jdbc_user=marauroa_dbuser
jdbc_pwd=marauroa_dbpwd
</pre>

jdbc_class is the field that says what Driver to use. Please refer to your software manual to see the multiple options.

jdbc_url points to the type and source of the information, for MySQL the string must be as follow:

jdbc:mysql://ip:database_name/

jdbc_user is the username for the database and jdbc_pwd is the password for that username in the database.

Then simply save the changes and ready.

Before using the application with the database, you need to create the database itself. So in case of MySQL just open MySQL and write:
<pre>
create database marauroa;
grant all on marauroa.* to marauroa_dbuser@localhost identified by 'marauroa_dbpwd';
</pre>

The rest of code is handled by the server itself, and will create the tables if they don't exits.


=PlayerContainer Explained=
=PlayerContainer Explained=
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 information about the players while the game is 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. <br>RuntimePlayerEntry contains:
RuntimePlayerEntry is the structure that contains the information about the player while it is online. <br>RuntimePlayerEntry contains:
* clientid<br>
* <i>clientid</i><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 that indexes players in the server. See the documentation about clientid generation to understand what they are and how they are generated.
* source<br>
* <i>source</i><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. This is used to determine if the message is really coming from the client or another person trying to impersonate it.
* timestamp<br>
* <i>timestamp</i><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 in which case it is only wasting resources on the server. As you may already know, UDP is not a delivery-guaranteed protocol, so we need to check for dead clients ourselves. Note that this only indicates that the player timed out and it doesn't apply any kind of measures on them.
* storedTimestamp<br>
* <i>storedTimestamp</i><br>
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.
storeTimestamp is used to determine when the player was last stored in the database. We don't store each time the player info changes as this would obviously be very CPU time consuming. Instead we cached the changes and store them only every 5 minutes.
* username<br>
* <i>username</i><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. If we store the username here we are able to use the database from PlayerContainer thus by knowing the clientid we can also now know the username without having to look to the actual database.
* choosenCharacter<br>
* <i>choosenCharacter</i><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. If we store the information here we are able to use the database from PlayerContainer and hence by knowing the clientid we also know the choosenCharacter without having to refer to the actual database.
* state<br>
* <i>state</i><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 entity, by default, the state is <b>Have to login</b>. Once you have logged in correctly, the state changes to <b>Login Complete</b> and once the player has chosen a Character it changes to <b>game begin</b>. The logout state is pretty 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 idea is that some operations are only allowed in certain states, so the state property stores which state they are in to make validating actions easier. ( To read about Perceptions, [[RolePlayingDesign#Perceptions | click here]] )


*perception counter<br>
*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.
The Perception counter is used to keep an incremental count of the perceptions sent so that the client can see if it gets out of sync.
*perception Previous RPObject<br>
*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. Using this we can track changes to a RPObject without disturbing the rest of the system.
*perception Out of Sync<br>
*perception Out of Sync<br>
This flag indicates if the player notified us that it was out of sync, so we can re sync it as soon as possible.
This flag indicates to the server if the player has become out of sync. This allows us to re-sync it as soon as possible.


Hence, all we need to operate PlayerDatabase is a username and choosenCharacter. So using PlayerEntryContainer we can fully operate it.


==ClientID generation==
As you can see all we need to operate PlayerDatabase is a username and choosenCharacter. So using PlayerEntryContainer we can fully operate it.
Each client MUST have a session id to prevent another player impersonating it. sessionid must be of short or int size to make guessing the ID much harder.


To make it even more secure, clientids are generated randomly for each player with the only condition that two different players MUST have two different clientids.
==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.


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


==Synchronization between Game and RP Managers==
==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 this? Well, imagine that a player logs out while the perception is being built, it will no longer be accessible by the RP Manager when it expects the object to be there, or if RPManager tries to remove a player which has already been removed, these situations are very serious as they will probably make the server fail.


So we need to synchronize game and RP manager.
So we must synchronize the Game and RP Managers.


The idea behind the solution is that the each manger requests access to the PlayerEntryContainer via a central mutex (a mutex is a syncronisation element attached to a resource, which can be owned by one task at any point in time. If the mutex is owned already when a task tries to access the object protected by it then the mutex will inform the task that it doesn't have access at this point in time to the object).
The idea is that they request to a central mutex access to the PlayerEntryContainer, and that mutex is the one that decide how the access is done.


We need to differentiate between the two types of accesses, read access and write access. We can have without problems two readers accessing in parallel, but we can only have one write at the same time modifying the stuff.
There are two types of accesses, read accesses and write accesses. Note that two readers can access an object in parallel but only one write can happen at the same time.
In GameManager there are only Write actions, as this manager only modifies the state of the PlayerContainer. However, in the RP manager we have both Reads, when we build the perceptions, and Writes when the manager removes idle players. Hence here we have two different locks.


[[Marauroa]]
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.
Retrieved from "https://meet.konsthol.eu/w/index.php?title=GameDesign"