SOA-RA Business Architecture
Business architecture
This section describes objectives and processes that the software architecture is to support, gathering and analyzing information that allows informed decisions to be made.
Background
To map the business architecture of serious games, we previously employed a model called Activity Theory-based Model of Serious Games (ATMSG) and its associated taxonomy of serious games elements [1]. In ATMSG, activity theory is used to delineate a model that represents several different low-level components of an educational serious game as the game unfolds, and how these components are connected to the educational and entertainment high-level objectives of the game. In the model, educational serious games are seen as used in the context of four activities: the gaming activity, the learning activity, the intrinsic instructional activity (performed inside the game) and the extrinsic instructional activity (performed by the instructor outside of the game).
From ATMSG's taxonomy, we collected a number of relevant items based on their relevance for the effectiveness of educational serious games, and possibility of reuse across different games and learning domains. The selected items from the ATMSG taxonomy allowed us to select which elements of each activity a general reference architecture for educational serious games should contain to serve a wide variety of serious games.
Scope
- Genre-independent
- This reference architecture has the goal to serve serious games independently of their genre or learning domain.
To achieve this goal but still allow for game designers to be creative in their products, the reference architecture should consider games as "black boxes" with connectors to the rest of the architecture. The reference architecture define the kinds of connectors that can be implemented in order to connect the game to the learning and instructional components of the system.
The learning and instructional components of the architecture are less variable than game elements. For example, some learning tools follow a very well defined format, such as surveys, questionnaires and student diaries. The concept of providing formative feedback to allow self-reflection on the learning process is also general enough to be useful to a wide variety of games and topics. And, naturally, it is agreed that feedback and adaptivity are two important characteristics of successful serious games (or, in fact, any type of game). The reference architecture aims to guide developers in how they can incorporate commonly used and high-value learning and instructional elements to games.
- Single player games
- The first version of this architecture supports single games only, but which can be played simultaneously by many users, and monitored simultaneously by one or more instructors.
- Varying complexity
- The games created using this architecture are not expected to use all the elements detailed here; the reference architecture aims to provide a catalog of commonly used or desirable serious games functionalities so that game developers can choose which ones are relevant to their project.
Roles
- Player/Learner
- The person who plays the serious game. One or more player/learners can interact with the system at the same time.
- Instructor
- A teacher or instructor in charge of overseeing and managing the learning session. The instructor can also manage user profiles (invite players, edit association between profiles and games, etc).
- Admin
- The person in charge of configuring the system and/or services when creating a new system (e.g. defining the learning competences, setting up the adaptation services parameters, etc.). The admin has access to service logs. Like the instructor, an admin can manage user profiles.
Functional domains
- User profiling
- A common user profile is required in order to enable interaction, synchronization and persistent features across different games and learning settings.
- Game connectors
- Game connector services provide adapter modules and data models that link external services to the game. This is possibly a game engine plug-in responsible for implementing trigger managers that detect important in-game events and forward messages to other services. These connectors will most likely be game- or at least genre-specific.
- Information storage and retrieval
- Functionalities to allow the management and use of information about topics in the game (i.e. non-playing characters' knowledge about the game world) or about the learning domain itself. This can be especially useful when dealing with topics that can potentially be relevant in different games or learning applications. If these functionalities include descriptive metadata, resource discovery and subsequent reuse in different games are made much easier.
We also include in this category functions that can connect to knowledge databases and convert this information to different formats that can be useful in the game (e.g. adapters for natural language interaction or converters of knowledge bases to question and answer formats).
- Feedback
- Feedback functionalities provide a way to send the results of in-game assessment back to the game, in order to enable the provision of learning feedback, and to support the player's self-reflection on learning.
- Assessment
- Assessment functionalities include modules for quantitative (automatic) and qualitative (instructor-provided) assessment, in addition to usage data that can help identify patterns of usage (learning analytics). It can also include assessment of player/student's engagement, confidence and satisfaction.
- Adaptivity
- Adaptivity is responsible for consolidating information coming from several different assessments services, evaluating this information, making decisions on how the game should react, and serving this information back to the game.
- Student-instructor interaction
- Functionalities to allow instructors to query players/students, prompting for answers to questions (questions and surveys) or for reflections in their learning process (student diaries).
- Between-players interaction
- These do not include multiplayer capabilities inside the game, but rather functionalities to collect, display and compare game scores, such as social leaderboards.
Macro versus micro-adaptivity
For the purposes of this reference architecture, we distinguish between macro and micro adaptivity.
Macro-adaptivity can be seen as a type of personalization, which can happen before and after a learning/gaming session. The gameplay and/or game narrative can be configured to tailor to, for example, personality or traits of the learner, as stored by the permanent user model or informed by the instructor at the beginning of the learning session. At the end of the game, the game can send information back to the user profile to update the player/learner model.
Micro-adaptivity, on the other hand, happens during the gameplay. There is a constant communication between the game and the adaptation service to evaluate and react to the in-game performance of the player/learner.
Process
Figure 3 illustrates the basic process of a gameplay session monitored by a dashboard, including the roles of the player and the instructor.
In the game:
- Connect to profile: The first step is to establish a connection with a centralized user profile, which holds information about the player/learner. The player needs to authorize this step; he/she is informed of the data that will be shared with the game and its related services.
- Personalize game: If the game supports personalization according to the player's profile (traits and preferences), the personalization is made before the start of the game (see see previous section).
- Run game: The system starts the game, and the player interacts with the game.
- Update user profile: At the end of the gaming session, if consolidated data exists on the player's performance, the player profile is updated. The player is asked to authorize the updates.
The dashboard can be accessed at any time by the instructor to consult reports. During a gaming session (illustrated in Figure 2), a live monitoring session is available to the instructor:
- Start session: When a player logs in to a game, a monitoring session is started and can be accessed via the dashboard.
- Monitor performance: At the same time that the game is running, the system is able to display performance and interaction reports in a dashboard for instructors to follow the player/learner.
- Display reports: At the end of the gaming session, the dashboard system generates and displays reports, which then remain available to the instructors at any time.
Connect to profile
While connecting to the profile, it is crucial that the player is given explicit information about what data is being shared and with whom, and the connection between the profiles only happens after the player authorizes the exchange.
Initialize game
The gameplay session is initiated with a request to receive the player's profile. This profile contains at least basic personal data, and possibly other user profile data related to other previous gaming sessions (of the same or other games) and previous achievements.
If the game supports personalization (macroadaptivity), this is the point in which the game settings can be changed accordingly.
Once the initialization process is finalized, the game can start. The dashboard receives a message to start a monitoring session.
Gameplay
During gameplay, the following connected functionalities are possible:
- Micro-adaptivity, adjusting the level of difficulty in the game to match the player's abilities and engagement during gameplay.
- Collection of game interaction data (learning analytics).
- The game can request information from external knowledge bases.
- The game can request information from connected social network sites.
The game and the relevant supporting functionalities regularly send messages to the dashboard with information about the players' performance.
Finalize game
At the end of the gaming session, the relevant functionalities produce a consolidated report about the gaming session, which is sent to the user profile manager and displayed to the player. The system asks the player for authorization to incorporate the data into the consolidated user profile. If the player authorizes it, the user profile is updated.
The consolidated reports about the player's performance are also sent to the dashboard, where the instructor can consult them at any time.
Related functionalities
Profile manager
The player has access to his/her profile, and from this application it is possible to view and manage current authorized applications, view and edit own profile, and revoke authorizations.
References
- ↑ M. B. Carvalho, F. Bellotti, J. Hu, J. Baalsrud Hauge, R. Berta, A. De Gloria, and Matthias Rauterberg, “Towards a service oriented architecture framework for educational serious games,” in 15th IEEE international conference on advanced learning technologies (ICALT2015), Hualien, Taiwan, 2015, pp. 147-151, doi: 10.1109/ICALT.2015.145. Best full paper award.
Navigation in the SG SOA-RA document:
- Introduction
- Architecture Principles, Vision and Requirements
- Business Architecture
- Application Architecture
- Conceptual Data Architecture
- Technological Suggestions
- How to apply
