Within almost any game there are actions that players take that are repeated. These can be as simple as moving from one room to another or can be as complex as repeat enemy encounters when walking through a dungeon. In role-playing games, these will often scale in difficulty or complexity depending on the player items, level, or other variables. Recently, this has been the focus of development for Stories of a GeoFarmer. With these repeatable, scalable actions there are three main components: player experience, development architecture, and interacting variables.
Player Experience
How players will respond to having to repeat actions first piece to consider when deciding which events to focus on. This is especially important in learning games (A.K.A. serious games) as the actions should be aligned with the learning objective, contribute to the understanding of the system, and scaffold as the learning objectives move up Bloom’s Taxonomy. Requiring players to repeat tedious actions or actions that are not related to the learning objective may cause players to lose engagement or become confused. For Stories of a GeoFarmer, we chose three main actions to be repeated (with some sub-actions for each). The first action we have players repeat is a logging function. Logging is an important piece of the story and is important to the region that the game is teaching about with regards to expansion of agriculture and environmentalism. Farming is another function that is baked into the story and provides an environmental context within the region that the class is focusing on when they play through this game. Lastly, the game goal is for the player to rebuild their farm after it burns down. While the class does not focus on homesteading or housing construction, the game goal aligns well with the last action that is repeated: building and designing a house.
Development Architecture
After deciding on the main actions to be repeated and scaled throughout the game, the next step is to architect the events in a sustainable way. This means that the actions should be easy for a developer to implement over and over along with having the game engine be able to process the events with crashing. Continuity of development should also be considered when developing repeatable events as there are many instances where an additional developer will need to be able to troubleshoot, modify, or build upon the work that has been done. Within RPG Maker MV (the game engine running Stories of a GeoFarmer) processing events and variables dynamically is not as straightforward as it would seem. Normally, variables,switches, and events would be created by the developer per event. This means that for a single tree to be cut down, variables for health and collision of the player weapon, switches based on conditions of cut or not, and tracking of progress would all be designed one at a time per tree. This creates a large development burden and does not follow the “write once, deploy everywhere” mantra that is used often in development. Instead of pre-defining variables, by using JavaScript to assign variables based on the unique ID of the event (tree) dynamic assignment of variables was easy to implement. This means that trees could be copied and pasted without interfering with other variables and causing errors in events.
// Conditional Script 1: Check X&Y for machete
$gameVariables.value(this.eventId()+100) == $gameVariables.value(36) && $gameVariables.value(this.eventId()+200) == $gameVariables.value(35)// Increment the health of the tree
$gameVariables.setValue(this.eventId()+300,$gameVariables.value(this.eventId()+300)+1)// Conditional Script 2: Check the “health” of the tree is over 6
$gameVariables.value(this.eventId()+300) >= 6
The first line of code uses the event ID as the X and Y coordinates to check if the machete (or chainsaw/torch) is colliding with the tree. The variables are numbered within RPG Maker MV and the range of 100-199 is used for X coordinates and the range of 200-299 is used for Y coordinates. Given that each event ID within a scene has a unique event ID, this allows for the variables to be managed individually while also being manipulated dynamically. The second line of code uses the 300-399 range of variables to handle the “tree health” and increments the variable each time the try is “hit” by the player. Lastly, the third line checks to see if the “tree health” is above 6 (which is the cutoff for the tree being cut down). This provides players with the feeling of hacking away at a tree to cut it down. It also allows for different tools to increment the tree health faster or slower. The machete takes 6 hits to cut down a tree, the chainsaw takes 3 hits, and the drip torch takes 1 hit to burn the tree down. This approach is easy to copy for both farming and homesteading and will save hours of development effort.
Interacting Variables
The last component, and arguably the hardest piece, is the implementation of modifying variables when actions are repeated. This can be done at a linear progression or exponential progression depending on what is appropriate for the interacting variables. In Stories of a GeoFarmer, the most basic implementation of the interacting variables of repeated actions is the drip torch. When players use the drip torch to get rid of trees, there is a variable that tracks the number of trees burned down. To emulate the dangers of slash and burn agriculture, after the player burns down 3 trees the forest catches on fire. When implementing additional interactions with the repeated actions, careful consideration to the amount of times that the player will repeat the action should be taken. For example, the “Envirometer,” or in-game measure of the approximate health of the environment, will likely go down each time a tree is burned down. If a player is expected to burn down many trees, or even is presented with the option of burning down many trees, it would imprudent to set the variable interaction to lower the meter to 0 after a single tree is burned down. Instead, having the meter drop every 5 trees may be more appropriate. Either way, the implementation of the modification of variables on repeated actions will be much easier as the player interaction and development architecture was carefully designed.