Tuesday, 30 November 2010

Designing and Evaluating Games and Simulations, Margaret Gredler (1992).

Although the technological advances of the last 20 years have revolutionised the development of games and simulations, Gredler’s book is still worth a look. The dazzling possibilities offered by technology can sometimes distract from fundamental design issues but Gredler, writing at a time when the Apple II was cutting edge, keeps her focus on learning objectives rather than the enabling technologies.

Gredler begins as she intends to go on, asserting a clear distinction between games and simulations and then proceeds to sub-divide simulations into 2 major types, and then 6 sub-types as she doggedly follows her categorising agenda. A comprehensive listing of the resulting hierarchy would be exhausting, so here‘s the short version:

Games and Simulations

Game: a world unto itself, determined by rules that are not replications of real life; involves winning by taking any course of action allowed by the rules; consequences experienced as a player do not extend to real life (so any skills developed would help only in playing the game better)

Simulation: based on real life; problem-based unit of learning; problems without easily determined solutions; participants carry out functions associated with their defined roles and circumstances; participants experience “reality of function” (given bona fide roles, address problems seriously and conscientiously); outcomes primarily determined by actions of participants – not by chance or luck.

Types of Simulation

Tactical-Decision Simulation: The primary interactions are with a complex problem in which participants, in executing their roles, use their skills in interpreting data, organising findings and managing a solution strategy to the problem. There are 3 sub-types – diagnostic (define nature of a complex problem and implement strategies), crisis management (allocate resources to avert or minimise an impending threat) and data management (manage a set of data to fulfil defined goals).

Social-Process Simulation: The primary interactions are among participants as they try to achieve a social or political goal. Again there are 3 sub-types – social system (participants engage in the social or political processes that form the fabric of organised social groups), language skills/communication (participants placed in a challenging situation requires participants to stretch their communication skills) and empathy/insight (participants undergo a frustrating or traumatic event and struggle to function in this changed environment).

I think Gredler’s definition of a simulation is more successful than her take on games (why can’t the rules of a game be replications of real life?) and maybe simply “not a simulation” would have been a better definition. I think the participants intent or attitude is also a factor worth mentioning here. And although she accepts that a simulation may have elements of more than one type, I suspect that in practice some simulations may sit uneasily between categories. Gredler goes on to devote chapters to academic games and then to each major simulation type and subtype.

Green Revolution seems to fit best in the ‘Data Management simulation' (DMS) sub-type of Gredler’s taxonomy, though with elements of the ‘empathy/insight’ sub-type. In DMSs participants are required to allocate resources to achieve a particular goal and the main focus is on the interrelationships and trade-offs among variables.

Gredler offers some general guidelines in designing simulations of this type:

  • problem and variables must be meaningful to the participants – otherwise it will be treated as a game (so don’t ask the average primary school kid to run the World Bank)
  • participants in their roles must feel compelled to address the problem
  • defined roles must allow maximum opportunity to engage with the problem (don’t create roles peripheral to the main task)
  • participants are empowered to address the problem (they have the expertise and authority to act)
  • participants decisions and actions (not random events) are the major determinants in the outcome (they feel some measure of control)
  • underlying model should be logical and credible to participants (make sense and be consistent)
  • variables must be quantifiable (as simulation based on a mathematical model that calculates the outcomes) - but avoid trying to quantify the unquantifiable

Gredler suggests that a sufficiently comprehensive array of variables and a wide range of decision options be made available to the participants to make the simulation realistic and engaging. She also suggests thinking through a range of action/decision scenarios and about the information the participants need be given (what and when).

Gredler has clear views on to evaluating performance. She believes that judging participants as winners or losers is counterproductive for several reasons:

  • it can encourage unhelpful behaviours e.g. desperation plays (huge gambles) and end of activity plays (focusing on very short-term goals)
  • it can encourage excessive competitiveness which may lead some participants to treat the simulation as a simply a game where the only object is to ‘beat everyone else’.
  • some participants may simply disengage physically or mentally if the focus is simply on winning.
  • in the post-simulation discussion, winners tend not to question their own decisions or acknowledge the help they received from others.
Gredler acknowledges that there are ways to curb excessive competitiveness (e.g. making the model adaptive or introducing computer run teams that prevent any single participant from cornering the market) but argues that it is best simply to avoid identifying participants as winners or losers – in her view it is strategy rather than outcomes that should be evaluated.

This all seems well and good but raises questions regarding simulations of real-world situations in which there are winners and losers and where life is anything but equitable. (Gredler, perhaps failing to recognise the empathy/insight aspect of the simulation, takes a swipe at the original Green Revolution Game because the social inequalities modelled in the game led some participants feeling humiliated when they had to ask wealthier players for a loan). There’s clearly a balance to be struck when designing a simulation which gives the participants a positive learning experience but doesn’t shy away from reflecting real-life inequalities.

To be effective the simulation should lead to reflection on the experience and to new patterns of thinking and so Gredler devotes a chapter to post-simulation activities, which she sees as a crucial to the learning process. She suggests that the post-simulation discussion should be given as much time as the simulation itself, but notes (in the chapter on empathy/insight simulations) it may take several weeks for participants to fully process the impact of the simulation. Therefore several activities should be planned to give them opportunities to explore their experience. She applies both Lewin’s and Piaget’s models of experiential learning in her discussions. Here’s one possible composite scheme pulled from her various notes:

  • immediately after the simulation give participants a short informal break (without co-ordinators) to give them space to release any pent up feelings
  • participants then complete a questionnaire that focuses on their memories of the experience.
  • co-ordinator then invites participants to make any immediate comments.
  • discussion proceeds to more orderly discussion of the simulation:

+ determine what actually took place

+ identify participants thoughts and feelings about the events and the perceptions that led to decisions

+ explore possible alternative actions

+ develop generalisations

  • discussion broadens to include wider implications of experience
  • a second meeting should be scheduled for 1 or 2 weeks later to revisit the experience.

In all this she emphasises that the co-ordinator's role is that of facilitator, not “expert”.

In summary - the book does feel a bit dated and Gredler's relentlessly systematic and prescriptive approach to her subject can be irritating. However she has produced a well-structured book that succeeds in it's stated aim of addressing the core issues involved in the design of games and simulations.

Friday, 26 November 2010

Hamlet on the Holodeck, Janet H. Murray

ISBN-13 978-0-262-63187-7 (paperback 1998)

Thoroughly interesting book on where the computer might be able to take narrative in the future. Lots of examples of changes in narrative style in other media, and how time and experience with the medium leads to different forms of expression with them.

It ties in with the 'Persuasive Games' (Ian Bogost) view of the strength of the computer being the procedural nature, allowing for the scripting of the rules by which a story can be performed without necessarily dictating the full story - leaving that to the interactors.

I focussed more on what might be useful or interesting for our game and my multiplayer/singleplayer research.

The chapter on immersion had some useful insights that a simulation without other characters or some form of task to perform can be a really empty and lonely place that quickly gets boring (pg 109). There is some discussion about a chatterbot used in MUDs called Julia, where simple rules of engagement allowed her to pass on relevant information (e.g. whether a player is currently online, or so on) as well as 'conversing' (pg 215 - 219). Players seem bothered about whether she is 'real' or not. However, the presence of others is noted as something that potentially makes story-immersion more difficult. It's fine when the conversations that take place remain 'in character' but a non-scripted player may break character in such a way as to throw the other player out of the story too. (pg 115-116) Intriguing that apparently what keeps LARP cooperative (i.e. the story keeps moving in a sensible direction and players stay in-character more) is out of game connections and operate face-to-face. (pg 151)

The other interesting thing about LARP that I noted was that they have a wrap-up session after the simulation ends. That chimed (for me) with the post-game discussion on Green Revolution. Apparently with LARP the wrap up allows the players to see how their part fitted into the whole, as well as feeding back on their experiences within the simulation. (pg 180-181)

Puzzles within any game are thought to be most dramatically satisfying and reinforce the belief in the virtual world when they encourage the application of real-world thinking to the virtual world. The example given is of a moment in Zork II where to solve the problem of a dragon and a wall of ice you have to apply the knowledge that dragons breath fire and that the ice can be melted by the fire. (pg 139-140) So the world feels more real because of the application of 'real' knowledge. I'm not entirely sure if that's true, or if it's more internal consistency that's needed. In the Zork example you could argue that rather than build their own set of rules the game writers have 'borrowed' from real-world physics - not to say that isn't valid, but if they had previously established some rule that the character could melt ice in a different way it would still have been satisfying to solve it using this different rule.

Murray draws on the bardic oral traditions to point out that traditionally each telling of the story is different in detail, whilst providing the same overall story. (pg 188) That tallies with the idea of playing a game differently every time (whether with different companions, or with a subtly different goal) and still being able to pull out the same overall plot or experience. Could be potentially interesting. Equally interesting is the suggestion that digital narrative is potentially more powerful than other forms because it allows you to enact the narrative and experience it more personally (pg. 170-171). So enacting looking after a small-holding in Africa leaves a deeper inprint than reading about looking after a small-holding in Africa.

I found it was particularly interesting (because this book was first published in 1997) that a lot of the mechanisms she talks about can already be seen. E.g. on-going TV series that provide chatrooms shaped like parts of the TV world. Equally something like Second Life could be seen as an arena for co-authoring digital stories or the maturation of the MUDs where the players can make up their own artifacts and rules. Also very interesting to consider this as the infancy of the medium, and that maturity will only come as the medium becomes more familiar and the 'rules' for understanding/interpreting it become fixed.

Transitional Objects and Potential Spaces, ed. P.L. Rudnytsky

This book is a collection of essays exploring the application of D.W. Winnicott’s concept of potential space in the literature and the wider cultural arena.

The volume begins with a chapter ‘The Location of Cultural Experience’ from Winnicott’s seminal book ‘Playing and Reality’. Here Winnicott sets our his ideas on "potential space", an intermediate area of experiencing that lies between the inner psychic reality and the external world (originally the space between the infant and mother). Transitional objects and transitional phenomena link these inner and outer worlds. Transitional objects originally symbolised the union between mother and baby, when the mother is in transition from being (in the baby’s mind) merged with the infant and being experienced as a separate object. In the potential space these objects can be used symbolically, imaginatively manipulated and transformed in play to represent parts of the mother or the external world.

These ideas have been widely applied beyond the world of psychoanalysis, as is attested in the diverse essays that comprise the remainder of the book. In particular I enjoyed Bollas’ essay ‘The Aesthetic Moment and the Search for Transformation’ where he suggests that an aesthetic moment, experienced in potential space, takes us back to "the most most profound occasion where the content of the self is formed and transformed by the environment". I also found Hopkins’ analysis of the Christian resurrection myth ‘Jesus and Object Use’ very interesting. Hopkins' essay includes a lucid account of Winnicott’s ideas on the transition from object-relating (where the object is related to as a bundle of projections) to object-use (where the object is experienced as an external reality) - "the most difficult thing, perhaps, in human development" - through acceptance of our own aggressive and destructive impulses. It is through our destruction of objects (in fantasy) that they become real to us.

So what has this to do with game design (beyond a spurious justification for FOTW allowing players to obliterate the world)? OK... probably nothing directly, but I still think Winnicott really was on to something. He believed that our adult abilities for play, creativity and cultural experience are grounded in our experience of potential space - we need to enter this potential space in order to be creative. This intermediate space is a world of ambiguity and duality, a space where the boundary between “me” and “not me” can dissolve, a place where we both blend and separate inner and outer realities, the place where our subjectivity engages with objective reality (the transitional object represents both our connection to the external world but also our separateness from it). So in a gaming context we could see the game as framing a potential space within which the player is able to creatively engage with the game environment and game elements to form his or her own connections and meanings.

Thursday, 25 November 2010

Linking SmartFoxServer and MySQL

How to get a zone set up to use a specific database is actually rather well covered in the documentation. Here's my set up after doing that:
The important bits to change are the connection string, which will need the right port for the MySQL instance that you want, and the database name (test_db in the example above). The username and password are for the database. I have used the oh-so-insecure root with no password, but normally you would want to create a specific user with a strong password who only has access to that database.

The test SQL is used by the server when it sets up the zone to check that the server connection is good. If your test SQL is broken it will refuse to connect, but it doesn't really matter what the result of your test is. Short and sweet might be good! It will need to be specific for each database.

The code side of talking to the database is more convoluted and we will probably end up wrapping some of our common actions. It is dealt with in the server-side code. It relies on us having access to the Zone object,  which has a DBManager property that can access the database using the connection settings above.

This is an example of the code that could be used in a request handler class that extends the BaseClientRequestHandler:

    SFSExtension parentExtension = this.getParentExtension();
    Zone parentZone = parentExtension.getParentZone();
    IDBManager dbManager = parentZone.getDBManager();
    try {
        dbManager.executeUpdate("INSERT  INTO log VALUES ('"+sender.getName()+"',     
        'input two numbers to add')");
    } catch (SQLException e) {
        // TODO Auto-generated catch block
That will successfully write data to the table in the database linked to in the zone manager when that request handler is fired. 

Monday, 22 November 2010

Review - Collaborative games: Lessons learned from board games

Authors: Jose P. Zagal, Jochen Rick, Idris Hsi.
DOI: 10.1177/1046878105282279.
Downloaded from http://facsrv.cs.depaul.edu/~jzagal/Papers/Zagal%20et%20al%20-%20Collaborative%20Games%20-%20Lessons%20learned%20from%20boardgames.pdf

The paper talks about the difference in game theory between competitive, cooperative and collaborative games:

  • Competitive is a game where you are pitted against your fellow players. 
  • Cooperative means that there is scope for working together, but not all are rewarded/punished equally for doing so and the aim of the game is still to come out 'best'. 
  • Collaborative games only reward collaboration, and all players gain or suffer equally. 
The writers are focussing on collaborative games because the 'design space for computer collaborative games remains largely unexplored', and in fact the collaborative mechanisms in some cooperative games don't really seem to result in collaboration. They use board games to explore what works in collaborative game design because board games are easier to understand than the few collaborative electronic games. (Interestingly they do say that RPGs tend to be good examples of collaborative games but are mostly considered to be described by narrative theory not game theory - I'd quite like to follow that up!)

They examine a really successful game: 'Lord of the Rings' designed by Reiner Knizia in 2001. By analysing the game play, they come up with four lessons:

  1. Lesson 1: To highlight problems of competitiveness, a collaborative gameshould introduce a tension between perceived individual utility and team utility.
  2. Lesson 2: To further highlight problems of competitiveness, individual players should be allowed to make decisions and take actions without the consent of the team.
  3. Lesson 3: Players must be able to trace payoffs back to their decisions.
  4. Lesson 4: To encourage team members to make selfless decisions, a collaborative game should bestow different abilities or responsibilities upon the players.
Three pitfalls are also identified: 
  1. Pitfall 1: To avoid the game degenerating into one player making the decisions for the team, collaborative games have to provide a sufficient rationale for collaboration.
  2. Pitfall 2: For a game to be engaging, players need to care about the outcome and that out- come should have a satisfying result.
  3. Pitfall 3: For a collaborative game to be enjoyable multiple times, the experience needs to be different each time and the presented challenge needs to evolve.
They then consider the implications for computer games, including a very interesting section looking at the communication differences between online and board (or face-to-face) games. They include positives and negatives for the lack of face-to-face communication, such as the flexibility of not being co-located, and the power of restricting some types of communication while supporting other types, vs. the loss of cues like identity, personality etc, and the increased risk of deceptive practices. I think this section could be particularly relevant to our game design!

I don't feel that we are designing a purely collaborative game; our game probably allows for all three types of strategy depending on the players concerned. However, some of the discussions around in-game communication could be extremely relevant, and going from board game to computer game is useful too. 

I reached this paper from a discussion on a blog post on Lost Garden: Cooperation War Challenge. One of the writers chipped in on the comments stream. Actually, the article is worth reading (it's a game design to teach collaboration to 10 year olds), but the discussion in the comments is equally worth reading. Lost Garden has a small section of essays on Serious Games, which might bear more reading although they are kind of old (2007, 2005 ish). 

Review - GameFlow: A Model for Evaluating Player Enjoyment in Games

Authors: Penelope Sweetser and Peta Wyeth, DOI: 10.1145/1077246.1077253. PDF downloaded from http://portal.acm.org/citation.cfm?doid=1077246.1077253.

This paper examines the concept of flow as described by Csikszentmihalyi, and looks at how the areas that are supposed to make experiences enjoyable and induce flow could be translated into the experience of a game. They use this translation as a basis for evaluating two real-time strategy games that had wildly differing commercial reviews, and attempt to draw a link between their findings and the different reviews.

There is a very interesting table on page 4 mapping the game elements to the elements of flow, reproduced below:

Games LiteratureFlow
The GameA task that can be completed
ConcentrationAbility to concentrate on the task
Challenge Player SkillsPerceived skills should match challenges and both must exceed a certain threshold
ControlAllowed to exercise a sense of control over actions
Clear goalsThe task has clear goals
FeedbackThe task provides immediate feedback
ImmersionDeep but effortless involvement, reduced concern for self and sense of time
Social Interactionn/a

The paper goes on to define these a little more closely, particularly going into a great deal more detail on what each element in the games literature side would be composed of. For me it was interesting to see that 'Social Interaction' does appear on the games side, but not in flow conditions:

- "Social interaction is not an element of flow, and often can even interrupt immersion in games, as real people provide a link to the real world that can knock players out of their fantasy game worlds."
- "Therefore, social interaction is not a property of the task as are the other elements of flow, but the task is a means to allow social interaction."

This suggests to me that the elements of flow are all innate properties of the task that you are embarked on, while social interaction is more of a by-product. 

The reviews of the two games then go through each of the eight categories and describe how the game meets (or fails to meet) the criteria. They are assigned a numerical value (which must be subjective to some extent) and that is used to compare them. They found that the more popular game out-performed the less popular game in almost every area. 

The conclusions reached were that some of the GameFlow criteria were genre specific, and some were difficult to judge without performing user studies (they used expert review to evaluate). It was concluded that the criteria did provide a good way to identify which areas of the game were less successful, with the overall scores achieved similar to the aggregated review scores of the two games. I couldn't find any reference to whether the expert reviewers were aware of the professional reviews, and I do wonder if that coloured their decisions at all (e.g. this game was less popular, what flaws can I find? vs. this game should be brilliant, where are the good points?).

I found this to be a much more dictatorial paper than many we've been reading, with lots of 'to be x the game must have y' statements - with appropriate citations! And interesting read, and might be worth following up as guidelines for expert review of our game? 

Thursday, 18 November 2010

A PAT model of flow antecedents in CMEs. C.M. Finneran, P. Zhang.

Csikszentmihalyi’s ideas on flow theory have been widely applied in studies of user experiences in computer-mediated environments (CMEs). In this paper the authors assert that a failure to reassess the original conceptualizations of flow theory when applying it to CMEs has resulted in inconsistency and ambiguity. The authors focus on the distinction between task (the main goal of the activity) and artefact (the tool for accomplishing the activity). Speaking of existing studies the authors note:

“The tools or artefacts were not taken into much consideration in studying flow because it is assumed that they are well mastered by the people who experience flow."

Of course this observation need not be restricted to CMEs – it is equally applicable to any activity where an individual has not mastered the use of the required tools. The authors propose a Person, Artefact, Task (PAT) framework to encapsulate this distinction and address the added complexity introduced by CMEs. They further divide personal characteristics into trait (effectively unchanging characteristics) and state (dynamically changing ‘mood’).

In their discussion of person-task, the authors observe:

“Whether flow occurs may have to do with at which level of granularity the person is focused and what their attitude and skills are toward that level.”

Therefore, like the concepts of skill and challenge in flow theory, task is also a matter of individual perception. Thus to maximise the possibility of flow, the environment must be tailored to the individual (re. learning environments – to what extent do externally defined learning outcomes “the task” match the learner’s perception of the task?).

Based on their model, the authors construct a set of propositions:

1) Assuming all of the other components are the same, a person is more likely to experience flow if s/he has traits of an autotelic (internally driven) nature and high exploratory behaviour, playfulness and absorption.

2) Assuming all of the other components are the same, a person is more likely to experience flow if his/her current state is conducive to absorption, time distortion, and loss of self-consciousness.

3) Assuming all of the other components are the same, a person is more likely to experience flow if the artefact has certain characteristics leading to telepresence (experience of presence in the CME), such as vividness (the breadth or the number of senses involved and the depth or the degree of involvement) and responsiveness.

4) Assuming all of the other components are the same, a person is more likely to experience flow if the task is more goal-oriented, autonomous (the user determines how to accomplish the task), enables more variety (has many ways to be completed), and at the appropriate level of complexity.

5) Assuming all of the other components are the same, a person is more likely to experience flow if there is a clear fit between task and the artefact (cognitive fit and task-technology fit).

6) Assuming all of the other components are the same, a person is more likely to experience flow if s/he has clear task goals, a balance between challenge and the skills of the task, a sense of control of doing the task, and adequate feedback on the task.

7) Assuming all of the other components are the same, a person is more likely to experience flow if s/he has high PEOU (perceived ease of use) of the artefact.

8) Assuming all of the other components are the same, with complex tasks, it is more likely that a person experiences flow when the artefact supporting the tasks has high PEOU, or is transparent. With less complex tasks, it is more likely that if a person experiences flow, s/he will perceive the artefact as having a high challenge.

Educational Game Models: Conceptualization and Evaluation

Alan Amory and Robert Seagram, University of Natal. http://www.coulthard.com/library/Files/amory_2003_educationalgamemodels.pdf

Looks at linking educational theories to game design. The only educational model discussed is contructivism. 

They describe three models:
Game Object Model (GOM) which describes game components and links them to the educational objectives (either promoting them or realising them). This allows the particular areas of focus of the pedagogy concerned to be outlined in terms of the game model. 

Persona Outlining Model (POM) creates a model of a the user, containing each of the educational objectives outlined in the GOM along with some bits of personal data. This can be used to then tailor the personas used when designing the game by assigning different values to each objective (I'm kind of assuming these are levels of competency, but I could be wrong). These levels change depending on the learning objectives that are being portrayed, so the persona will then reflect the both the situation and the pedagogy required. 

Game Achievement Model (GAM) is based on the learning objectives and a basic storyline. This paper suggests that the GAM gets broken down into 'Acts', each of which can have a different learning outcome. The story for each act is refined to improve the game play, but is also checked against the learning objectives. 

I have to admit, I got a bit confused by what the three things were, how they linked, and what they were useful for. The only examples given relate to the GAM, the POM seems to have been pretty much discarded (reflected in the conclusions actually, which only mention the GAM). 

There is also a discussion of games as story-telling medium. Conclusion is that games are much more than a story-telling medium, although the discussion actually seems to suggest that they are useful ways to tell non-linear stories. 

Client-side code for SmartFoxServer

At the moment, we're writing our client-side code in ActionScript 3.0. How to access the libraries in your swf is covered in a different blog post.

I'm intending to wrap the calls to the SmartFox client API in a set of local classes. This is a bit of insurance, so that if we decide to change our server part way through most of our code will be left unchanged.

What I've done is create a server class, that has functions such as login and sendRequest that can be accessed by the main game. Behind the scenes, this class then deals with connection and all the SmartFox classes. It then dispatches custom server events as required. These can be listened for in the rest of the game, with no dependancy on the SmartFox events.

The other part of this is to dress up the request parameters so they can be sent in the required format. I've defined a RequestParam class, that holds a name, a type (e.g. Int, String etc) and a value. The server class can then interpret these to add them to the proper SFSObject and send them to the server. I've actually started creating subclasses of the RequestParam class for each type of parameter, so initially there's a RequestParamInt. This sets the type of the parameter automatically, and hopefully keeps the code pretty clear and a bit more free of constants than otherwise.

Logging in
To create a connection to the SmartFoxServer, the game creates an instance of Server.as, starts listening for the ServerEvent.LOGIN_SUCCESSFUL event, and calls server.login with the appropriate parameters.

The server class checks to see if the client is already connected to the server, and if so it performs the login. If the client is not connected to the server it calls the connection code, listens for the connected event, and when that event happens successfully triggers the login code again.

When the response to the login is received, if that login was successful the Server class dispatches the ServerEvent.LOGIN_SUCCESSFUL event that the game is listening for, and the game can carry on with whatever it needs to do next.

Extension Requests
Sending an extension request is similar. Walking through the add example given in the Server side extension doc  the client creates two instances of RequestParamInt. One has a name of 'n1' and an integer value (e.g. 3), the other has a name of 'n2' and an integer value (e.g. 4). These are added to an array. The client calls on the server object to sendRequest. SendRequest takes a string parameter of 'add' as the request name (which matches the string name given in the server-side extension when the request handler is added) and the array of parameters.

Even if there is only one parameter, the server object is still expecting an array!

The server class goes through the array of parameters and adds them to an SFSObject, using the type parameter to work out which of the SFSObject methods to call (e.g. putInt, putString etc.) and creates a new request which is an instance of ExtensionRequest. This uses the request name and the SFSObject as parameters. This request is then sent to the server and we wait for a response event that gets bubbled up to the main game structure.

Server Responses
The request that comes back includes a params object. Each type of event uses the params object slightly differently, and a full description can be found in the Client API Javadoc under com.smartfoxserver.v2.core -> SFSEvent. I think we might want to set up some kind of response handler structure for the Extension responses in a similar way to the server side does - each response is sent back with a command name to allow different things to happen with the results, so it may be useful to use that.

This structure will get added to, as needed!