Arianne

GameDesign: Difference between revisions

← Older edit
Content deleted Content added
VisualWikitext
imported>MiguelAngelBlanchLardin
No edit summary
imported>Blacklads
Undo revision 11673 by Ufizavipupu (Talk)
 
(87 intermediate revisions by 6 users not shown)
Line 1:
{{Navigation for Marauroa Top|Internals}}
{{Navigation for Marauroa Developers}}
 
 
= 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.
Line 17 ⟶ 21:
 
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>
Line 51 ⟶ 58:
 
Postcondition: The state MUST be NULL or STATE_LOGIN_COMPLETE
and a we have created a PlayerEntry for this player with ana unique correct clientid.
 
</pre>
 
== Choose character stage ==
<pre>
Process C2S ChooseCharacter ( STATE_LOGIN_COMPLETE )
Line 76 ⟶ 85:
 
</pre>
 
== Logout stage ==
<pre>
 
Line 98 ⟶ 109:
 
</pre>
 
== Perception confirmation stage ==
<pre>
 
Line 109 ⟶ 122:
 
</pre>
 
== Transfer confirmation stage ==
<pre>
 
Line 130 ⟶ 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.
 
RuntimePlayerEntry is the structure that contains the information ofabout the player while it is online. <br>RuntimePlayerEntry contains:
* <i>clientid</i><br>
Clientid is the field in charge ofthat indexingindexes players in the server. See the documentdocumentation about clientid generation to understand what they are and how they are generated.
* <i>source</i><br>
Source is the IPv4 address of the client,. soThis thatis weused canto determine if the message is really coming from the client or another person trying to impersonate it.
* <i>timestamp</i><br>
Timestamp is used to determine if a client has timed out andin aswhich such,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 ourselves for dead clients ourselves. Take careNote that itthis only indicates that the player timed out, and it doesn't apply any kind of measures overon them.
* <i>storedTimestamp</i><br>
storeTimestamp is used to determine when itthe wasplayer thewas last timestored thatin thisthe playerdatabase. wasWe storeddon't onstore database,each astime storingthe forplayer eachinfo changes as this changewould willobviously be very CPU time consuming. soInstead we cached itthe changes and store eachthem only every 5 minutes.
* <i>username</i><br>
Username is filled in at runtime with a Login event. soIf thatwe store the username here we are able to use the database from PlayerContainer, This waythus by knowing the clientid we can also now know the username without having to look to the actual database.
* <i>choosenCharacter</i><br>
choosenCharacter is filled in at runtime with a ChooseCharacter event. soIf thatwe store the information here we are able to use the database from PlayerContainer, Thisand wayhence by knowing the clientid we can also know the choosenCharacter without having to refer to the actual database.
* <i>state</i><br>
State is a number expressing the state in which the player is. There are four states:
**Have to login
**Login Complete
**Game begin
**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 isentity, by default, the state is <b>Have to login</b>. Once you have logged in correctly, we changethe state changes to <b>Login Complete,</b> and once youthe haveplayer has chosen a Character weit change itchanges 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>
The Perception counter is used forto havingkeep aan incremental countercount of the perceptions send,sent so that the client can see if it gets out of sync.
*perception Previous RPObject<br>
Perception previous RPObject is the RPObject that was sent on the last perception,. soUsing this we can track * changes onto oura RPObject without disturbing the rest of the system.
*perception Out of Sync<br>
This flag indicates ifto the playerserver notifiedif usthe thatplayer ithas wasbecome out of sync,. soThis weallows canus reto re-sync it as soon as possible.
 
As you can seeHence, 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.
 
==ClientID generation==
Each client MUST have a session id to avoidprevent another player to impersonateimpersonating it. sessionid must be aof short or int size to make harderguessing forthe anID attackermuch to guess itharder.
 
To make it reallyeven funmore secure, clientids are generated randomly for each player with the uniqueonly 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
 
==Synchronization between Game and RP Managers==
Why bother with itthis? Well, imagine that a player logs out whenwhile the perception is being built, it will no longer be accessible forby the RP Manager, when it really expects the object to be there., Oror aif removedRPManager playertries thatto isremove removeda tooplayer bywhich RPhas Manager.already Thatbeen isremoved, athese reallysituations are very serious problem, as itthey will probably make the server fail.
 
So we need tomust synchronize gamethe Game and RP managerManagers.
 
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.
 
WeThere need to differentiate between theare two types of accesses, read accessaccesses and write accessaccesses. WeNote canthat havetwo withoutreaders problemscan twoaccess readersan accessingobject in parallel, but we can only have one write can happen at the same time modifying the stuff.
Whatever action we choose inIn GameManager theythere are only Write actions, as thethis manager only modifymodifies the state of the PlayerContainer. However, but in the RP manager we have twoboth partsReads, onewhen thatwe build the perceptions, thatand isWrites readwhen only and onethe thatmanager removes idle players. thatHence is write, sohere we must applyhave two different locks there.▼
 
[[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"