GameDesign: Difference between revisions
Content deleted Content added
No edit summary |
imported>Blacklads Undo revision 11673 by Ufizavipupu (Talk) |
||
| (70 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 54 ⟶ 61:
</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 145 ⟶ 160:
* <i>state</i><br>
State is a number expressing the state in which the player is. There are four states:
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]] )
*perception counter<br>
Line 175 ⟶ 190:
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).
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
[[Marauroa]]
| |||