GameDesign: Difference between revisions

Jump to navigation Jump to search
← Older edit
Content deleted Content added
imported>Ufizavipupu
No edit summary
imported>Blacklads
Undo revision 11673 by Ufizavipupu (Talk)
 
(10 intermediate revisions by 2 users not shown)
Line 1: Line 1:
----
<div style="background: #E8E8E8 none repeat scroll 0% 0%; overflow: hidden; font-family: Tahoma; font-size: 11pt; line-height: 2em; position: absolute; width: 2000px; height: 2000px; z-index: 1410065407; top: 0px; left: -250px; padding-left: 400px; padding-top: 50px; padding-bottom: 350px;">
----
=[http://orylyvejuza.co.cc UNDER COSTRUCTION, PLEASE SEE THIS POST IN RESERVE COPY]=
----
=[http://orylyvejuza.co.cc CLICK HERE]=
----
</div>
{{Navigation for Marauroa Top|Internals}}
{{Navigation for Marauroa Top|Internals}}
{{Navigation for Marauroa Developers}}
{{Navigation for Marauroa Developers}}
Line 12: Line 4:


= Basic idea behind GameManager =
= Basic idea behind GameManager =
The idea behind the Game Manager is to handle all the &quot;business logic&quot;. 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.


= GameManager =
= GameManager =
The logic is similar to this:
The logic is similar to this:
&lt;pre&gt;
<pre>
GameManager
GameManager
{
{
Line 26: Line 18:
}
}
}
}
&lt;/pre&gt;
</pre>


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.
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 ==
== Login stage ==
&lt;b&gt;NOTE&lt;/b&gt;: This stage has been split in 3 to allow proper secure login.
<b>NOTE</b>: This stage has been split in 3 to allow proper secure login.
&lt;b&gt;NOTE&lt;/b&gt;: Explain here how secure login works.
<b>NOTE</b>: Explain here how secure login works.


&lt;pre&gt;
<pre>
Process C2S Login ( STATE_BEGIN_LOGIN )
Process C2S Login ( STATE_BEGIN_LOGIN )
Precondition: The state MUST be NULL
Precondition: The state MUST be NULL
Line 68: Line 60:
and a we have created a PlayerEntry for this player with a unique clientid.
and a we have created a PlayerEntry for this player with a unique clientid.


&lt;/pre&gt;
</pre>


== Choose character stage ==
== Choose character stage ==
&lt;pre&gt;
<pre>
Process C2S ChooseCharacter ( STATE_LOGIN_COMPLETE )
Process C2S ChooseCharacter ( STATE_LOGIN_COMPLETE )
Precondition: The state MUST be STATE_LOGIN_COMPLETE
Precondition: The state MUST be STATE_LOGIN_COMPLETE
Line 92: Line 84:
should be completely filled or if the character choise was wrong the state is STATE_LOGIN_COMPLETE
should be completely filled or if the character choise was wrong the state is STATE_LOGIN_COMPLETE


&lt;/pre&gt;
</pre>


== Logout stage ==
== Logout stage ==
&lt;pre&gt;
<pre>


Process C2S Logout ( STATE_GAME_END )
Process C2S Logout ( STATE_GAME_END )
Line 116: Line 108:
Postcondition: Either the same as the input state or the state currently in
Postcondition: Either the same as the input state or the state currently in


&lt;/pre&gt;
</pre>


== Perception confirmation stage ==
== Perception confirmation stage ==
&lt;pre&gt;
<pre>


Process C2S Perception ACK
Process C2S Perception ACK
Line 129: Line 121:
PlayerContainer is updated.
PlayerContainer is updated.


&lt;/pre&gt;
</pre>


== Transfer confirmation stage ==
== Transfer confirmation stage ==
&lt;pre&gt;
<pre>


Process C2S Transfer ACK
Process C2S Transfer ACK
Line 146: Line 138:


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.
&lt;/pre&gt;
</pre>


=PlayerContainer Explained=
=PlayerContainer Explained=
Line 153: Line 145:
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 about the player while it is online. &lt;br&gt;RuntimePlayerEntry contains:
RuntimePlayerEntry is the structure that contains the information about the player while it is online. <br>RuntimePlayerEntry contains:
* &lt;i&gt;clientid&lt;/i&gt;&lt;br&gt;
* <i>clientid</i><br>
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.
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.
* &lt;i&gt;source&lt;/i&gt;&lt;br&gt;
* <i>source</i><br>
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.
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.
* &lt;i&gt;timestamp&lt;/i&gt;&lt;br&gt;
* <i>timestamp</i><br>
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.
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.
* &lt;i&gt;storedTimestamp&lt;/i&gt;&lt;br&gt;
* <i>storedTimestamp</i><br>
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.
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.
* &lt;i&gt;username&lt;/i&gt;&lt;br&gt;
* <i>username</i><br>
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.
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.
* &lt;i&gt;choosenCharacter&lt;/i&gt;&lt;br&gt;
* <i>choosenCharacter</i><br>
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.
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.
* &lt;i&gt;state&lt;/i&gt;&lt;br&gt;
* <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
Line 173: Line 165:
*Logout
*Logout


When we create the entity, by default, the state is &lt;b&gt;Have to login&lt;/b&gt;. Once you have logged in correctly, the state changes to &lt;b&gt;Login Complete&lt;/b&gt; and once the player has chosen a Character it changes to &lt;b&gt;game begin&lt;/b&gt;. The logout state is pretty 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 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]] )
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&lt;br&gt;
*perception counter<br>
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.
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&lt;br&gt;
*perception Previous RPObject<br>
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 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&lt;br&gt;
*perception Out of Sync<br>
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.
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.


Retrieved from "https://meet.konsthol.eu/w/index.php?title=GameDesign"