GameDesign: Difference between revisions

(53 intermediate revisions by 6 users not shown)

Line 1:

= 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 18:

Line 22:

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 ==

NOTE: This stage has been split in 3 to allow proper secure login.

NOTE: Explain here how secure login works.

<pre>

Process C2S Login ( STATE_BEGIN_LOGIN )

Line 153:

Line 160:

* state

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 entity, by default, the state is Have to login. Once you have logged in correctly, the state changes to Login Complete and once the player has chosen a Character it changes to game begin. 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.

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

Line 183:

Line 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 ~~mahanger~~ 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.

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]]

@@ Line 1: / 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 18: / Line 22: @@
 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>
 Process C2S Login ( STATE_BEGIN_LOGIN )
@@ Line 153: / Line 160: @@
 * <i>state</i><br>
 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 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.
+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 183: / Line 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 mahanger 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.
+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]]

GameDesign: Difference between revisions

Navigation menu

Search