Game Design
PAWS Agency by Motivum Games started as a serious games game jam game that was conceived to be a mobile exergame. During that time I contributed only with character models. After the gamejam we decided to continue development, I continued as 3D modeler and animator but I also spearheaded the game design area. From personal experience when I considered my main role to be more of a game designer, I would divide the whole process so far into three epochs when I and we all as a team, after some downtime, have had more intense sprints of development and when we each time arrived to a more detailed and thought through design of the whole game. Our work has been fully online from the start. During the design process there has been constant ideation for all areas of the game by all the team members but on this page I will describe results and the work process that could be more directly attributed to my personal time and effort.
Epoch 1
This is perhaps the time where we all had the highest amount of motivation but the game design area was attended to very superficially. The game jam version was supposed to utilise GPS tracking that would measure the users speed, the faster the user moved the closer to the pet animal, that was running away, the user would get and when the pet was "caught" then it could be "stroked" or "pet" and it would gain happiness. In reality it is a really bad idea to make the player actually run in the real world and at the same time constantly look at a smartphone. So the game jam version was scrapped entirely, but still the main concept of doing a game that would motivate the player to exercise (hopefully in in clean air) by using a digital pet, kind of like a Tamagochi, remained.
There were 5 people in the team and starting from zero, there was lots to do: game architecture planning, deciding a visual and music style, UI, sound, business model canvas. I was mainly on environment and character visuals, oh, but wait, what about game design? Well, we all knew that we were making a mobile exercise game with a digital pet. At least initially we used Miro for online collaboration, it is still good for certain things but also other tools came in time.
We of course looked at various games from this genre from multiple angles, deep game design analysis was perhaps a bit lacking. Nevertheless in regards of game design I generated an extremely high level game loop concept focusing on players activity levels which in turn would set the tone for the following user experience discussions. Another important part of the equation was of course the digital pet, our main motivator for the player to do exercise. When looking at Tamagochi-like games and articles about them, then one keyword seemed to be "the illusion of life", the pet was our main motivation driver so the player had to feel at least to some levels of empathy and attachment towards it, the player had to feel some need to take care of their digital pet. Very quickly we had a ton of feature ideas for the pet and story that would give some context and reason for the whole undertaking. Changes keep games interesting, so in similar vein to Tamagochis I deemed it necessary for also our digital pet to have different stages or ages that it goes through, visual customisations options and also ideally some internal states that it changes that in turn are expressed in various ways, for example mood states that could be reflected on the animations and different stats and parameters. We had lots of ideas but were still quite unsure in which way to actually implement all, some or any of them.
Epoch 2
We were getting closer to a point where we had to figure out what exactly and how we were going to implement. The main focus was on our main motivator - the pet. We had some ideas in regards of the gameplay loop but I finally tried to condense down all our drafts and really think about which are the main resources and tokens the game should have. I also lobbied for a shorter gameplay loop with a concrete win and lose state for diversity and also to pull players with interest about what would happen next and in the other hand to push players a little bit from losing, though the losing state was formated as more like a reset than an actual loss of something.
Based on the gameplay loop flowchart I made a wireframe for the actual screens for the game - how many and in what order the screens should appear and what should they contain. It gave the bases on which the UI should be designed. It featured 4 parameters for the pet which were supposed to represent and to give feedback to the player about the progress that is being made at different temporal scales and also to give a sense of progress through the different stages that the pet goes through. This was the first iteration of the game that programmers could take and put real numbers and calculations behind. And we did have an actual prototype of sorts with this system. From the user experience perspective, the main focus for the user was the "wellness" parameter that had to be managed. The parameter would constantly be reduced that would affect the pet's "health" in the long run. When the "health" dropped below a certain level then the player's progress would be reset. To keep the "wellness" parameter at an optimal level the player would have to do some physical activities that would be tracked either with a pedometer or GPS. For players who liked to do more than was needed and to reward some extra effort from the player side, extra willpower points could be gained after willpower was full that could be used to unlock some cosmetic items for the pet. So there was a short-term feedback/motivator in the form of "wellness" and longer term consequences in the form of "health". Overall game progress could be observed by the pet's age parameter. When the pet reached a certain age, then it was "released" into the wild, the game session was considered a success and the player could start over with a new pet, perhaps with one that would require more physical activity from the player.
Epoch 3
In the case of games with serious goals, for us: "to raise the player's health by making them more physically active", one must always start design process from the serious goal and expand from that. We did have a skeleton of a game of sorts, we could test it in theoretical bases, meaning we had a working Unity prototype but the activity tracker was just a timer that the player could start and stop by a click of a button. We also had tons of ideas ranging from the pet development, parameters, overall game progression, customisation, monetization etc. I cannot be sure what it was exactly: probably the combination of the plethora of ideas we had but could not make specific selections among them, the push from the business development guys to have some sort of in-game currency system and the feeling that the game was perhaps not rewarding enough to the player, but I felt the need to start over with design process. well not entirely from scratch, we had learned a lot from everything that came before. But still, this time properly from the first principles we definitely could rely upon and to really thoroughly think about the game design in a wholistic manner that would take into account all areas of the game.
So this time I took a more methodological approach to the design process - which of course starts form the theory. I started by trying to frame really precisely what it exactly was that we were trying to do. Just "to make users healthy" was not precise goal enough in order to make good game design decisions. So I took on quite a big undertaking of trying to map out different theories used in serious games design that could serve our main goal. The approach went from broad to narrow - from our main goal to theories and ideally would end with specific game mechanics we should implement directly basing their choice in theory. The main challenge is of course the question of motivation - how to make our game enjoyable and engaging thereby making the players physically healthier.
As mentioned, we had tons of ideas for game mechanics and features but the more ideas we had the fewer decisions we could make about which to include and which not to. Feature creep started creeping! We had done small playtests that gave some feedback, but our big issue was the vetting process. After I put all the main areas of the motivation theories into the schematic, we finally had a tool that hinted at which features might work and what would not fit into the system we had. I could place all the mechanics into the schematic and those that did not fit we should probably discard because they do not help with player motivation. During the process of making this "motivation theory of everything" it really illustrated how little we had thought about all the minute details of the whole game flow and user experience. It really brought out all the loopholes we previously just didn't see. And most importantly it helped to generate the appropriate feature ideas. Also the question of our main target audience was getting more prominent, the schematic helped to get an overview to which types of players we would cater to and how broad we would go - how many different types of activities there would be for the players.
There were many theories to choose from. Interesting part is that many of them tend to have large areas of overlap, they just use different words to describe similar concepts and emphasise different areas. I mainly focused on Self determination and Expectancy-value theories, but also to mark down what we know from basic human psychology and what I tried to rationalise further, included pure aesthetic enjoyment and affordances (the enjoyment of operating the game controls) into the grand scheme.
The whole schematic expanded quite a bit so in here I will focus only on one branch of the Self determination theory. From that follows the need of competence - overcoming challenges and finally, what constitutes as a challenge. There I saw an opportunity to tie in the types of uncertainty described by Greg Costikyan. Then I could really appreciate which features would fit with our type of game and could generate more of those. The dark yellow labels on the schematic are features and mechanics.
However, the massive schematic I ended up with was not very palatable for other team members to follow, so to make it more concrete and easy to follow I made a screen-by-screen mock-up of the whole game including all the features we had and flow of the game. This time I used Figma, it features many quick and easy tools for UI mock-ups.
The mock-up really helped to drive our discussions and gave a nice overview of what were the most promising ideas we had.
Another enormous discussion piece was the question of which tokens, parameters, resources we should include, which features they enabled and which features we needed for various purposes that would require certain parameters to be tracked. The main goal is to have some sort of representations for the player of game states, measuring progress, helping with goal setting and giving feedback. In the previous versions we had the wellness parameter that was being reduced most of the time, thereby motivating the player to do different activities which would raise the wellness, in order to avoid the consequences of pet's health dropping to zero.
We wanted the player have options to customise the pet and it's environment, and also for monetization purposes, the most common way of doing this is by having some sort of in-game currency system. Initially I leaned towards not having concrete tokens as rewards which might drive the player towards extrinsic motivation targets, but rather have the gameplay experience itself to be more of a reward in it's own right and perhaps guiding the player to find enjoyment from just being physically active in the real world, that would have longer term effects on player habits even if the game is not played any more.
This however is quite hard to pull off as it turns out. Relying purely on autonomous motivation from the get-go might seem out of place when considering what experiences the players have had with other mobile games that are hyper gamified and mostly rely on handing out exponentially growing amounts of various tokens for quick extrinsic rewards. The players might initially miss the enjoyment of doing various physical activities, so perhaps a more appropriate approach would be to guide players towards that end goal starting from more of a controlled motivation perspective. So I devised another resource system featuring the mechanic of gathering tokens that could be used in various ways and that in turn would give the player feedback about the progress being made. It was a more tangible and visual way for the player to observe the gains inside and by proxy also outside the game.
The idea was to make "Wellness tokens" that also from user experience angle would make the player feel that something is constantly gained rather than something is constantly lost in the form of wellness that has to be maintained.
Also I tried to think through what effects could different resource systems have on both of the approaches - either a game loop with a concrete start and end states, infinity or perhaps even some hybrid solution where the player can decide.
Another consideration was also the game loop in the biggest scale, concerning the start and end of the game. More precisely how severe the lose state would be and perhaps we could implement infinite pet progression so there really would not be a precise end. Both had ups and downs, so I plotted out both of the systems.
So we had two resource systems that serve a similar purpose but from the game feel side gave different impressions to the player. But before just changing the whole system and building the new one, we needed to validate it at least to some extent. There were much theorising but we definitely lacked the appropriate amount of testing. So I took one game mode we were planning and did a higher fidelity mock-up of it with the two different systems. We put it in a questionnaire and started gathering feedback.
The responders gave us lots of useful feedback that included some useful arguments. The new token system did turn out to be somewhat more preferred and it also simplified the whole system a bit, eliminated the need to deal with some loopholes with the previous system and gave new idea for some new features so we went with the new token system.
My other tasks that were game design related included maintaining the game design document, generate concepts for game modes, the flow of visual and conceptual environments that the player could change and just to keep track of how different mechanics and systems would interact with each other overall.
Currently we have reached a minimal viable product that we can start testing on a wider audience.
