Software engineering is a field of increasing interest. One of the field’s subgenres is Software Architecture and Design.
Software architecture is the specification of the structure of a software system, and it carries a net positive effect on the software systems it is implemented in. Software architecture develop- ment is very expansive, with a considerable number of essential factors surrounding it. Different software architectures can also operate in a different manner.
Although it does not play a major role in the field of SAD, software design is still worthy of note.
Serious games often operate by the same game design rules as regular games, and they tend to follow various game design patterns. A noticeable number of examples of serious games for SE can be found.
Serious Game for Learning About
Software Architecture and Design
There is no doubt that traditional software engineering education models employed by educa- tional institutions have been efficient at teaching people about various software engineering topics. However, there are also some problems with these models that are worth addressing.
In particular, these models can sometimes be hard to put in practice, less efficient than self- paced learning, and/or have information that is too complex for the students to effectively absorb. Furthermore, these models can also be established in a way that fails to motivate the students to pay attention to what is being taught. The interest in building a serious game is that it manages to effectively educate students while simultaneously solving (or at least minimizing) these issues.
In page25, various examples of serious games were addressed, each one of them focusing on a certain SE topic. However, there have not been any educational games found for our topic of interest, which is Software Architecture and Design (at least when it comes to digital games).
Since there are no digital games based around Software Architecture and Design, it is yet to be determined whether the GDPs particular to SE topics (previously discussed inSerious Game Design Patterns) function for that specific topic. In order to solve that problem, we proved that premise to be true by using the GDPs relative to SE topics to design and implement a serious game for the SAD topic, and then validated that game using an ESWS that tested how much of the topic the test subjects managed to learn through the game itself.
Before talking about that study, it is necessary to describe the serious game in question. It is a 2D platformer called Codebase Escape, developed using the Unity game engine and the C# scripting language. It has versions for Windows, Mac and Linux, respectively. In terms of core functionalities, the game works like the prototypical 2D platformer, where the main character can navigate by moving left or right and jumping from platform to platform. The game also includes outsourced graphics and audio. Figure3.1shows the game’s logo.
Figure 3.1: Codebase Escape Logo
The plot of the game is as follows: an anthropomorphized piece of source code keeps increas- ing itself while trying not to become a mess - in other words, a ’big ball of mud’, or BBOM for short.
The game follows a ’butterfly’ analogy, where the code keeps maturing so that it can ’escape the codebase’ and, in the process, become a fully realized piece of code that can be used as the ’fuel’ of a program (or possibly more programs), in a similar fashion to a butterfly trying to escape its cocoon. The three stages the main character goes through as the game continues is shown in Figure3.2. The player also takes the role of the ’programmer’, essentially controlling the code, making it grow and leading it to the end.
(a) Initial Version (b) Intermediate Version
(c) Matured Version Figure 3.2: The Main Character The game’s default controls are shown in Table3.1a:
Action Keyboard Controls Joystick Controls (a) Moving left A or left arrow Joystick horizontal axis (left) Moving right D or right arrow Joystick horizontal axis
(right)
Jumping W, space or up arrow Joystick vertical axis (up) Performing a specific con-
text-dependent action
Left Ctrl or mouse left-click Joystick button 2 Checking inventory Left Alt or mouse right-click None
Pausing Enter Joystick button 0
Restarting the level (only works in certain scenarios)
Left Shift or mouse wheel click
Joystick button 3
Exiting the game Esc Joystick button 1
Table 3.1: Default Game Controls
(a) Specific joystick controls depend on the joystick being used.
When the player starts the game, they will be taken to a ’Configuration’ window, where they can configure the game’s graphics and controls (although it is recommended that they do not alter the custom resolution on each version).
3.1
Success State
There are two types of items that are scattered around each of the 5 levels and the player will need to pay attention to in order to advance. These items are:
Lines of code (LOCs) Pieces of code that the player collects in order to unlock the quiz at the end of each level (example shown in Figure3.3). There are 5 LOCs in Level 1, 6 in Level 2, 7 in Level 3, 8 in Level 4 and 1 in Level 5;
Documentation files (DOCs) Pieces of information around the topic of SAD that the player will need to consult in order to solve each quiz (example shown in Figure3.4). The first level has only one DOC while all the other levels have two.
Figure 3.4: Documentation File
In this game, each quiz is shown as a door that takes the player to the quiz. Before collecting all the LOCs in a level, the door is locked; and after collecting all those LOCs, the door is unlocked. Both the locked and unlocked versions of the door can be seen in Figure3.5:
(a) Locked Quiz Door
(b) Unlocked Quiz Door Figure 3.5: Quiz Door
After the player solves the quiz, the level is cleared. If the player clears all 5 levels, they clear the game.
Before and after each level there is a transitional scene, known as a ’tome of knowledge’, which includes additional information that is not essential to solve any of the quizzes, but is relevant to the empirical study with students this game was used in.
The game also has a scoring system, which works as such:
• The score starts at 5000 and keeps decreasing as the player plays the level;
• The score decreases in a slower rate when the player either reads a DOC or attempts to solve a quiz, which is done to help players focus while simultaneously testing their mental agility; • The score stops decreasing when it gets to 0;
• Successfully clearing a level grants the player with a score boost, which gets higher as the player becomes increasingly closer to the end:
– Clearing level 1 will lead the player to start level 2 with the score they ended level 1 with plus 5000;
– Clearing level 2 will lead the player to start level 3 with the score they ended level 2 with plus 10000;
– Clearing level 3 will lead the player to start level 4 with the score they ended level 3 with plus 15000;
– Clearing level 4 will lead the player to start level 5 with the score they ended level 4 with plus 20000;
– Clearing level 5 will lead the player to finish the game with the score they ended level 5 with plus 50000;
• This all means that the player scores higher the faster the player can clear each level (making 50000 the minimum score the player can end the game with).
As an added bonus to incentivize players not to guess the correct answer by trial and error (without reading the DOCs), players also get an extra health point (HP) if they answer the quiz correctly in their first attempt. The HP count is represented by a health image, with a number on top that represents the amount of HPs the main character has left at each point in the game. The HP is illustrated in Figure3.6:
Figure 3.6: Health Point