GameDesign: Difference between revisions
Jump to navigation
Jump to search
Content deleted Content added
No edit summary |
imported>StephenIerodiaconou |
||
| Line 160: | Line 160: | ||
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 :) |
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> |
*perception counter<br> |
||
| Line 184: | Line 184: | ||
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 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. |
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 |
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. |
||