SOA-RA How to apply

Applying the SOA-RA for SGs in a project

A checklist to help matching an existing game or game concept to the SOA-RA for SGs.

Purpose

This checklist gives you an overview of how the pieces of your game would fit in the SOA Reference Architecture for Serious Games and helps see points that need more clarification before going ahead with the project. It can be used as a starting point in the porting of your idea to a SOA-based architecture.

If you feel like your project does not fit at all in the SOA-RA for SGs, please tell us about it! We would really appreciate your feedback to make this reference architecture more relevant to SG developers.

Formats

You can download this document in DOCX or PDF formats.

Step 1: Overview

Users

1.1 Who are the users of the system?

[ ] Players
[ ] Instructor
[ ] Sysadmin
[ ] Others:

Game characteristics

1.2 List the 3-5 most relevant gaming actions, tools and goals in your game. (See ATMSG Taxonomy of SG Elements.)

1.3 List the 3-5 most relevant learning actions, tools and goals in your game. (See ATMSG Taxonomy of SG Elements.)

1.4 List the 3-5 most relevant instructional actions, tools and goals in your game. (See ATMSG Taxonomy of SG Elements.)

Features

1.5 Are the features below implemented in your game? Mark the appropriate column.

	Feature name	No	Partially	Yes	Future
1.	Persistent user profile
2.	Macroadaptivity (adapting to player’s preferences)
3.	Learning assessment
4.	Learning microadaptivity (in-game adaptation to player’s performance)
5.	Emotional assessment
6.	Emotional microadaptivity (in-game adaptation to player’s emotional state)
7.	Monitoring dashboard
8.	Learning analytics
9.	Social network connections (friends, leaderboards)
10.	External knowledge databases

Step 2: Desired features

Fill in only the sections for the features you marked “Partially”, “Yes” or “Desired” in question 1.5.

2.1 Persistent user profile

2.1.1 Which information about the player/learner the game needs to receive?

2.2 Macroadaptivity

2.2.1 Which player’s traits would you like your game to adapt to?

2.2.2 How will you collect the traits listed in the previous question?

2.3 Learning assessment

2.3.1 Create the knowledge and competence space of the domain of the game (see Creating a knowledge space).

2.3.2 Define desired performance indicators.

2.3.3 Map gaming and learning actions in the game to the performance indicators and to the knowledge and competence space.

2.4 Learning microadaptivity

2.4.1 Identify levels of difficulty in the game that can be adjusted, and the granularity of the difficulty adjustment.

2.5 Emotional assessment

2.5.1 Which indicators do you plan to use to evaluate the emotional state of the player?

2.5.2 How will you collect the emotional states listed in the previous question?

2.6 Emotional microadaptivity

2.6.1 How should the game react to the player’s emotional state?

2.7 Monitoring dashboard

2.7.1 Who should have access to the dashboard?

2.7.2 What information should be available in the dashboard to each group of user?

2.8 Learning analytics

2.8.1 Which traces from the game will be collected? (See Application Architecture for suggestions.)

2.9 Social network connections

2.9.1 Which elements of the game should be shared to friends in a social network?

2.9.2 Which performance indicators should be shared via social leaderboards?

2.10 External databases

2.10.1 Is the game using general knowledge that could be stored outside the game? Is there any compelling reason to do so (e.g. reuse in other applications)?

2.10.2 Are there any existing databases with the desired data?

2.10.3 Any processing needed to use the external databases listed above?

Step 3: Connection with the game

Exposing game events

3.1 Considering the answers to questions 2.3.2, 2.5.1 and 2.8.1, decide which events need to be exposed from the game.

Receiving external information

3.2 Decide which parts of the game will request external information and when.

Step 4: Application architecture

Figure 1: Components diagram.

Preliminary application architecture

Consider the application architecture in Figure 1, described in section Application Architecture.

3.1 Which modules would be needed in your project?

3.2 Are there any other modules that would be needed?

SOA layers

Consider the SOA-RA Technical specification by The Open Group, illustrated in Figure 2 below.

Figure 2: The Open Group SOA-RA Technical Specification.

3.3 Which of the layers above will you need in your project?

3.4 Visit the section Technological suggestions. Are there any existing services to fulfill your needs?

If you feel like your project does not fit at all in the SOA-RA for SGs, please tell us about it! We would really appreciate your feedback to make this reference architecture more relevant to SG developers.

Navigation in the SG SOA-RA document: