Transcript
1
The current state of development and operability of Magos Classic
This section gives an overview of the current version of Magos Classic (MC v02) seen from the viewpoint of the end user. For more details on Magos Lite, see the tool online at http://magos.pori.tut.fi/. The game editor in MC v02 can be used by a single author but it also allows multiple authors, working remotely, to edit a single game online simultaneously. The main editing screen is shown below in fig 4, with the different features highlighted for description purposes.
1.1.1
Control panel of Magos Classic v02 game editor
Toolbar (1) Contains buttons for game management and UI settings
Preview - launches the current game in preview mode Public/Private - switches access to the game (available to other users or only to game authors) Grid button - toggles display/hiding of the game area grid Light/Dark buttons - toggles UI theme to light or dark
Game Area (2) Displays the game being edited. The gamespace a tile-based grid made up of cells. The number of cell rows and columns is defined when the game is first created. The game is constructed by dragging elements into
the desired positions in the game area; items can be removed by clicking them. Only one item can reside in a cell. Item List (3) A palette containing the items (objects) that users have defined for this game, e.g. platform blocks, player avatar, collectibles, hazards, etc. To include an item instance in the game, the corresponding icon must be dragged from the palette onto the game space grid. This action can be repeated in order to add multiple instances of the same item to the game space, e.g. for building a platform. There are two special icons in the palette for managing the list:
Add new item (a green plus sign) adds an empty item slot onto the list. By default, this new item is completely blank until the user some property is associated to it. Remove item (a grey trashcan) removes an item from the game palette. The item is cleared from the list and is no longer usable. Note that an item cannot be removed if it is used anywhere on the game grid.
Element information (4) Displays the properties of the selected item. An item is selected by clicking on in the item list; it is then highlighted. This information is mostly read-only, but for some properties a red trashcan button appears allowing that property to be removed from the selected item. Tools list (5) This tool palette displays all the properties that can be attributed to a game item. To define an item, the user first drags a tool icon onto an item on the item list. This activates the tool, and its properties can now be set. Dragging a tool onto an item temporarily locks out other authors, preventing them from inadvertently overwriting each other’s work. Shoutbox (6) The Shoutbox enables member of the game’s authoring team to communicate with each other via textbased chat.
1.1.2 Tools (game element properties) Controls Used for determining how an item, typically the player character item, can be moved in the game space. Comprises:
Method - sets movement type either to Twoway (walk with left and right arrow keys and jump with up key) or Fourway (walk left, right, up and down with the respective arrow keys). Speed - determines how fast the item will move; the higher the number, the faster the item moves. Jump height - determines how high the item jumps. Only available with Twoway movement.
Collision Used to determine what happens when one item hits another (trigger and target). Multiple collision rules can be associated to the same item, allowing multiple trigger-target relations. When this element hits - defines the target item of the collision. All the items included in the item list are available for selection. Then – defines the consequence of the collision, i.e. Destroy Self (destroys the trigger item), Destroy Target (destroy the target item) or Finish Game (game over). Score. A collision can also drive point scoring: points gained for positive values, points lost for negative values.
Gravitation Determines whether and how an item will fall when not “sitting” directly on top of another item or on the bottom row of the game grid. Strength sets how fast the item falls, the higher the number, the faster the fall. Zero value (the default setting) means that gravity has no affect on this item.
Type Can be used to change the item type, which the user sets when first creating an item. Type determines the item’s mode/scope of behaviour in the game. The options available are:
Pushable – item moves in correspondence with an adjacent item moving towards it. Solid - item does not move in correspondence with an adjacent item moving towards it. Adjacent item stops.
Images Changes the visual appearance of the item. Instead of opening a control panel like the rest of the tools the images tool opens a popup box. The box displays all the available images. By selecting one of the images the item now looks like that on the item list and on the game area.
In the approach to game making that it embodies, ML diverges from MC in several significant areas (a detailed comparison of tool characteristics is provides in xxxxx, which compares the Magos tools with the Sploder tool used in some MAGICAL activities). As a result, ML offers less scope for autonomous, open-ended design than does MC, in which users build a tile-based game space and produce mechanics by attributing properties to the elements thet include in that space. That said, a simpler, more guided/scaffolded design process has some advantages in educational contexts. It can: lower the learner entry threshold, rendering game making accessible to a younger - and potentially more inclusive – target;
render game making more attractive to practitioners who are less confident with digital tools and/or with open-ended student-driven activities; help to streamline presentation and explanation of the tool to practitioners and learners alike, leaving more net time to dedicate to the game making process; tighten the focus on specific game elements, like scoring mechanisms; reduce the time needed to produce a finished game, thus reducing the squeeze on class time earmarked for peer review, development iteration and reflection; reduce demands made on the teacher to provide learners with on-the-fly support and guidance.
ML embodies a template approach, whereby users choose between pre-set game types and formats, with predefined game space and mechanics. So the game-making task essentially revolves around selecting the elements to include, defining key game behaviour parameters, and packaging the completed game for the player/s.
The next main difference between the two editors is that ML is essentially a single-user tool: the only specific features it offers for collaboration in game making are (a) the possibility to assign asynchronous coauthoring rights to peers and (b) to post star ratings on peers’ games. Consequently, the locus for
collaboration in game making largely shifts out of the digital domain, residing instead in the classroom and in classroom practice, even when ML is used jointly by a group on a tablet. The last noticeable difference is that ML embeds explicit functions for integrating domain-based learning content into games, in the form of numbers (for maths-based games) or text. This can be seen as an added value that helps address the open issue of reconciling game making with curriculum demands. As a consequence, it may also boosts the likelihood of take up among teachers, not to mention (critical) acceptance from the wider stakeholder community, from parents to administrators. These advantages are nonetheless counterbalanced by the template-based, “instructional” approach to games and game making, which some practitioners may find restrictive and some leaners may find less appealing. Clearly, some of the above-mentioned differences between MC and ML are significant, having general implications for game making as an approach to learning and more specific implications concerning MAGICAL project objectives. In some cases they called for adjustments in field experiments (reported in D5.2), and these were duly implemented without undermining the project’s overall ambitions. Certainly, they have left some open questions that could not be immediately answered within the scope of the project (see D6.4 – Open Issues). However, it is the authors’ hope that these may be addressed and eventually answered after the conclusion of MAGICAL, be it by the authors themselves or by others recognising the potential of game making for enhancing learning.
Clearly, the characteristics of ML had implications for the type and scope of game making activities deployed in the MAGICAL experiments, and hence for the research design that was implemented. Suitable adjustments were made to the field experiments to account for ML use (reported in D5.2), but these did not undermine the project’s overall ambitions unduly.
Certainly, a number of questions remain (see D6.4 – Open Issues), particularly concerning the impact that the adopted authoring tool may have on game making as a learning approach. However, it is the authors’ hope that these may be addressed and eventually answered after the conclusion of MAGICAL, be it by the authors themselves or by others recognising the potential of game making for enhancing learning. Clearly, some of the above-mentioned differences between MC and ML are significant, having general implications for game making as an approach to learning and more specific implications concerning MAGICAL project objectives. In some cases they called for adjustments in field experiments (reported in D5.2), and these were duly implemented without undermining the project’s overall ambitions. Certainly, they have left some open questions that could not be immediately answered within the scope of the project (see D6.4 – Open Issues). However, it is the authors’ hope that these may be addressed and eventually answered after the conclusion of MAGICAL, be it by the authors themselves or by others recognising the potential of game making for enhancing learning.
