The Master Dissertation
This was the culmination of my Master's Degree. In it I learned about previous gaming research, conceptualized, designed, developed, playtested, did a user study, analysed data and wrote my dissertation on Shared Gameplay Loops. The Shared gameplay loops example I created were two highly asymmetric modular game roles, linked together with another shared game role, shared between users. Think of it as if the typical game hubs various companies use such as Ubisoft Connect and its point system was a game in and of itself.
For most of the project duration I was granted 3 scholarships. The first was a master's student scholarship from FCT, and the other two were awarded by the FCT as part of the project "Plug n' Play: Explorando Assimetria e Modularidade no Design de Jogos Inclusivos". For the full dissertation click here. [Note: This is a compressed version of the PDF, for the best version contact me directly!]
For the defense presentation slides click the following link: Dissertation Defense Slides.
The repositories (one for each game) are private as of now, but access can be requested. Simply contact me. For a showcase video look here:
The Shared Gameplay Loops Games
In terms of the concept itself, it came as a possible solution to the problem of people wanting to play together, but having different gaming preferences.
Me and the games research team defined Shared Gameplay Loops as individual games, linked together in some way (but not directly such as interconnected games are), and where that link comes in the form of an interaction loop, that could be a game in and of itself.
To explore that concept I developed three game roles, catering to different player motivation (following Quantic Foundry's Gamer Motivation Model motivations and spectrums). A role focused on having high excitement (thrilling), the slasher game. A role focused on the opposite, low excitement (calm), the farming game. And the shared interaction loop game role (with both sides of the excitement spectrum, and additionally some competitive aspects), a tower defense game.
Concept and Design Choices
The player motivations then drove part of the design of each game. For the Slasher the focus was on a fast-paced, action-based game, with as much pressure as possible. For the Farming the focus was the opposite, so no pressure, no action, and slow-paced with the ability to pause at any time. The shared role, the Tower Defense was a bit trickier. Sure, making it competitive was not hard (scoring and leaderboard did the trick), but how to make it both thrilling and calm? After some decision-making I came up with making the tower placement, upgrades, and a lot of the decision-making have unlimited time allowing for no pressure. Then for the part of the game with the waves, the player needed to have more real-time input, so I created additional enemy types and abilities outside of the traditional tower defense towers for the player to place directly in the enemies' path. All games were developed within Unity, using More Mountains' Top Down Engine, and Firebase Realtime Database (and authentication for the registration and user logins).
The Cross-Game Interaction Loop & Daily Structure
And how exactly does the "shared role" make players interact? Well, not directly within the shared role. Since it was decided for this to be a game played across multiple days, with tracking leaderboards and different daily maps, while making players want to play both their individual and shared role, the cross-game interaction come in the form of the enemies you send to fight your opponent (and vice-versa, the units your opponent sent to fight you) in the tower defense. These units are generated within each player's individual role. Given the daily structure this means, playing the individual role creates units for your opponent to fight off the following day (in addition to the daily enemy presets).
Iteration, Playtesting and Evolution
Throughout the whole development process the scope changed multiple times, builds were frequently tested and altered, features were added, features were removed, and the following was the end product.
The Slasher
The thrilling game role I created boils down to going into a hub, choosing the room difficulty you want (with higher difficulties typically having either less time, more enemies of harder types, harder to locate enemies, or a mix of all three; plus the higher difficulty rooms generated harder to fight against enemies), with a timer in each room (which is chosen at random, with 5 different room types, and variety of patterns per difficulty) and enemies to kill with a sword, with basic movement and dashes.
To add to the thrilling nature and make it a more skill-based game, room attempts were limited. So if you went into a room and failed, you sent no additional enemies for your opponent to fight, and you had no way to get those "blanks" back. There are two main enemy types, a shooting enemy and an exploding enemy (two variants, one patrols, one if fixed, both of which follow the player if they detect them and blow up after a short time if in close proximity to the player).
Examples of early development, an early map (before they became all set shapes with set enemies, and had randomly spawning enemies), and one of the final maps can be seen here.
Farming
The calm game role went in the complete opposite direction. One larger map, and a resource system. It contains plant seeds, used to make plants (with their own evolution system), resources needed to upkeep plants and build additional map assets (such as additional planting locations since they have limited plant space in each, and additional water sources in the form of wells). Then the plants themselves which come in multiple types. Each type requires different seed types to be planted in a planting zone, and each type has a different color and size. Then for each plant to fully grow and be gathered it needs to go through two evolution stages, however it has a thirst meter as well and if it dries up it stops growing and the growth timer for that evolution resets (at the beginning plants could dry up but it was found to be too punishing of a mechanic given the amount of resources that could be spent on a single plant). Then once the plant was picked up it was added to the inventory and multiple plant combinations can be combined and spent as recipes and turned into additional enemies for the opponent to fight against.
Finally, to make it fair against the thrilling role player, there was a max move cap per each real day. This was although there was no time pressure, if I player went around using moves without a care for the world they would also not be able to gather more plants and create recipes meaning they would also no longer be able to send additional units, however unlike the thrilling game role it is more strategy based given the recipes available and not skill based. Note: At the beginning there was one big map with randomly-generated plants, trees, lakes, etc, but due to scope changes and to make the game sessions shorter for this role it was changed to a set map per day with static environment locations.
An example of early UI and map can be seen here.
The Tower Defense
The enemies sent by an opponent were always capped at 15 (rooms entered/recipes), with each always awarding 2 enemies (for a total of 30 possible additional enemies) of varying quality. In here there was one basic enemy type (dies to everything), and three types that each took damage from 2 of the available 3 turret types, each using Unity's navMesh for pathing. Then there were warrior enemies (only killable by the warrior ability or the bomb ability) and the bomb enemies (only killable by the bomb ability). However, due to the complete upgrade system, some abilities can be upgraded to be more efficient in some way (be faster, do more damage or cost less) or to target more enemies. These abilities also carry over across the game days. Each day the player has 1 attempt (although they can replay it at will after) to beat the day's set map, with preset unit combinations plus the additional enemies sent by their opponent across five waves (the additional units are spread around in sets of 6 per wave).
They also have an initial starting currency (points) that is always the same, and can be spent on turrets (to be placed on set nodes across the map, with more nodes spawning each round), and on upgrades within the planning (calm) phase.
Then players manually activate the wave start and can use their active abilities throughout (also spending points).
The only way to gain points back is by hovering over the floating coins that spawn when enemies die. To achieve the best score possible they must have the most points remaining and the least amount of damage taken (each enemy that makes it across the map does the same 10 points of damage).
Some examples of other maps, and an early development map can be seen here.
The Shared Database
In terms of the database modelling it was split into user locations and game sessions for each game pair (through the use of a shared partner code). User data included the essential player data, the partnerCode and the logs for each game played. Then within the partnerCode, I have both users within by their ID, and then per role (tower defense, slasher, farming) and enemies sent, then the day played (given the choice to have a daily structure), and then the data pertaining to each. This is made so that people can play whatever role they want in a given day (needed for our study conditions of having players either play the same games - symmetrical condition; or different ones - asymmetrical condition). Within each game per day there is either just the daily data (calm and thrilling role games) or the the data pertaining to the both last day played (accounting for days not played between sessions, to add data to the current day data), the current day data and the daily score (the shared role game).
Study session
Following the full game development since it was changed from an in-the-wild study to a lab setting, the day structure was also changed late in the process and not really used in the study (although fully functional and robust), and was commented and simply used executables with set days to make the lab session smaller (with the participants experiencing only 2 of the 7 days of content developed). Yes, the system could be changed to simply making the day cycles 10 or 20 minutes for example, but since we didn't want any added time pressure on the participants our approach was that of different executables with set days (the participants were not made aware of this and had no idea this was the case). Before the lab session participants filled out surveys and the Gamer Motivation Model questionnaire and placed them into groups of two (they were incentivized to suggest someone since we were interested in both people acquainted with one another, of which we had 15 pairs, and strangers, of which we only had two pairs). Then they were randomly assigned to one of two study conditions. Forced asymmetric gameplay (to evaluate whether the supposed individual roles that catered to them - given their excitement spectrum had an impact on the experience) or choice-based symmetric gameplay (mirroring traditional gameplay between people who choose what game to both play together). For the study session within the lab after a demographics and gaming habits questionnaire they played the shared module without any impact from their opponent, then the individual role impacting their opponent, and then the shared role (now being impacted by their opponent's actions in their individual role games). They then filled out both the miniPXI (measuring psychological and functional constructs as well as enjoyment) and the Social Presence (measuring psychological and behavioural involvement) in gaming questionnaires. Finally a group interview was conducted to ascertain the player's feelings and thoughts, in which, around halfway through they were told of the concept of shared gameplay loops and what they had experienced.
Data Collection and Analysis
The data collected included survey data, and logs obtained directly from player game actions logged into firebase. Although pretty much every action is logged as an action type, time, action cost, action reward, the logs were only used in analysis to determine play times for each player within each role. Full audio interviews following the game session were also conducted with both participants, then full transcripts of each were written, and then analysed through a mixed deductive-inductive coding process, creating a codebook. From that classification through the interviews, the questionnaire responses and the game data we proceeded with the analysis. We had a total of 16 game pairs with no game development experience and 1 game pair with 2 game developers, 8 of which were in the symmetric condition and 9 in the asymmetric condition, from ages between 18 and 35. Most participants were frequent gamers (playing daily or almost).
Dissertation Writing
From previous investigation done into related work (which I had, for the most part, already been written as part of my preliminary report for my dissertation), the detailing of the design and implementation, the data analysis data and results, the full dissertation was written and finished in September/October. Then I defended my master dissertation on December 10, 2024.
Findings
The findings showed that there seems to be a potential in shared gameplay loops as an inclusive option to tackle some gaming barriers, it was an enjoyable experience, but the roles felt somewhat disjointed and there seemed to be a need for more direct feedback on their opponent's actions (especially within the individual role). Additionally, the possibilities of promoting play through choice and variety through the shared gameplay loops model seem promising.
For a full breakdown of the research work and development done, please check out my Master Dissertation.
Conclusion
This was my most formative work as of yet, and with it I learned about longer development procedures, more in-depth game design, and a whole lot about conducting research. It was a pleasure to work on this project, and my main regret with it was not prioritizing UI and cohesion between the games as much until the tail-end of the development, which definitelly impacted the user experience and made them feel more separate (which they indeed were) and a bit less cohesive. I had the chance to develop 3 completely different games and both designing for specific motivations and developing games I wouldn't typically find myself developing (especially the Farming game) was a great learning experience. For now my focus is on the commercial games industry as more of a designer and developer, but this whole experience certainly left a mark on me and created a bug in me for games research and more exploratory games.