CONCEPT

OBJECTIVE

As a studio that makes educational experiences, Simcoach Games was quickly approached during the COVID-19 pandemic to help find ways to teach people about it. We made a COVID-19 safety training app in 2020 and continued to update it for different associations. However, this training tool was designed for workforce training. It’s also called a training tool, not a training game. So, we decided to create a game for general audiences that could teach in a more engaging way.

Our goal was to make an experience that could be quickly accessed and played. Its transformational goal would be to give people a novel way to review masking and distance guidelines because the basic effects of both had become muddled. We just wanted people to play in a set of rules where avoiding people and wearing a mask meant less infections!

Our initial brainstorm session generated some “interesting” ideas (as any good brainstorm will.) We pulled the following ideas from it to inform the experience:

-- “Status meter that builds at different rates according to conditions”

-- “Play through a game without knowing there is a virus in the world, later learn that as you played you spread a virus through the entire game.”

-- “Navigate 6 feet apart”

-- “Juggle COVID rules while doing some other task”

--“Understanding that rules are preventative, some impossible game where you can’t get risk factor down to 0”

To work toward our goal of quickly making a game that could be simple to play, we chose a "runner" as the type of game that we would make. We thought it was a game type that needed little instruction and could provide context for a virus spreading; people are the equivalent of obstacles and running into a person would result in someone getting sick.

To achieve our goal of making the game easy to access, we decided to use Construct 3 so that it would work in-browser on desktop and mobile.

I put together a quick concept in Photoshop using free images from the web:

The story is silly but serves its purpose. You are a time traveler. Your mission is to go back in time and warn the people of 2020 about the impending pandemic. However, you accidentally warp to a location that’s some distance away from the top secret facility that you’re trying to contact. You need to run the rest of the way. But, as you run through the normally isolated mountain terrain you encounter large groups of people. It turns out that these people are spring breakers who needed to find a new party spot after the public beaches were closed. Can you reach the facility in time?

This scenario gave us solutions to certain questions such as:

-- Why is the player running in and out of indoor spaces?
-- Why are there so many people around when things are locked down?
-- Why are so many people near a supposedly secret lab?
-- Why are there big objects in the way that need to be avoided?

Admittedly, when trying to think of a story to resolve contrivances there are many possibilities, but we chose this one because we thought it was interesting how the bizarre (real) occurrence of spring breakers in the mountains could be used here to add to some of the strangeness of the experience.

The artist on the team (Matt) explored different ways that we could think about the perspective and gameplay based on the concept and our discussions:

These images generated productive discussions (and even a golf concept somehow.) A big question that we realized we needed to answer quickly was, “What happens when you run into something? Below is a discussion in which I helped inform the checkpoint system that ultimately made it into the game:

Next I began to work on level design. I felt that this would enable me to encounter design questions and force me to think through how they might be answered. I started to make mockups in Photoshop of single screens that the player would encounter when they start the game. I treated these as a tutorial where mechanics are introduced one at a time.

As I continued to make these, I quickly realized that it would be easier to follow them if I could stitch them all together into one continuous image. I decided to use a simple Google Doc for this because I thought it would be the most accessible to everyone:

This “paper prototype” introduced enough ideas about the types of obstacles and interactions that could appear to generate a meaningful discussion. Having something tangible to look at enabled the team to come to realizations about how we were actually going to make the game work.

Things like:
Is player movement limited? How?
What actions can the player perform? Can they attack, jump, and slide?
How many obstacles can be on the screen? How do we define those?
Should the game be in portrait or landscape?

So, even though several of the elements in this initial mockup were redundant and potentially confusing, it pushed us to realize these things before putting anything into code or art. 

RULES & MECHANICS

For various reasons (from the above discussion) we decided that the game would be landscape and based around “lane switching” (with a single input, the player moves to a different row.) I got to work thinking more about the mechanics and rules of the game. I made a mockup in Photoshop that explained some basic rules based on the team’s discussions. This mockup also explored the infection rules for the first time. In this experience, we wanted to simulate risk factors without worrying too much about the actual rates at which infections spread.

The original idea for this was to have the player hold a base infection rate, that is, a value that determines how likely they are to infect others when they come into contact with them. Then, this number would increase if the player entered risky spaces and decrease if the player avoided risky spaces for a certain amount of time. So, it was a system in which it was possible for an encounter with an NPC early in the run to affect NPCs at the end of the run (and thus simulating how an infection can grow and spread.)

This system seemed promising, but after presenting it to the team it was felt that it was overly complicated for something that would ultimately be mostly invisible to the player (as an actual spreading virus would be.) It was then proposed after several discussions to simplify the rules in such a way that the player’s chance of infecting others is static and and only determined by mask states, proximity, and location (indoors vs outdoors.) 

After clarifying these ideas with the team, I came up with the following:

At this point, though I was still deep in the primordial goo of what would become the game’s systems, we had put together a prototype that represented most of the core mechanics and systems, such as running, jumping, lane switching, losing, and “random” object generation.

With the infection rules defined for now, I began working on the level design rules. We wanted the game to be different every time to encourage replayability and to make the level-building process more modular for us. To do this, we thought up a system that we referred to as “chunks.” A chunk is basically a single 16x9 screen of gameplay. Every certain number of spaces the game would generate a new “chunk” and attach it to the previous one via an empty patch of spaces.

With this idea defined, I got to work on the actual rules for generating obstacles. Because we wanted to randomly generate them, we needed to have rules to prevent unsolvable scenarios and unfair situations.

The objects in the game and their properties regarding movement are:

-- The player character - can move from lane to lane and jump, loses health if they run into a rock, log, pit, furnishing, or wall.
-- NPCs - can be run through
-- Masks -  can be run through
-- Rocks/Furniture - need to be dodged by switching lanes
-- Logs - can be dodged or jumped over
-- Pits - need to be jumped over
-- Walls - need to be dodged, always has a door
-- Doors - can be run through, always part of a wall

I made a Photoshop file with approximations of the current assets:

I used this file to easily move all of the elements around and play with configurations until I found a set of rules that might prevent object spawning issues:

This rule sheet led to interesting ideas, such as the “double rock,” and gave us a good basis on which to discuss level generation. Having a visual guide to refer to makes communicating ideas so much easier. With this I began to think about how the difficulty of the game might change as players progress. I started with a “very easy” set of level rules, but realized that as I was making it, I was inadvertently making a tutorial.

With this understanding of how players might be introduced to the game’s obstacles, I got back to thinking about the progression of difficulty across the game. To do this, I visualized a potential difficulty curve of the experience in various graphs:

It wasn't immediately clear if this exercise was helpful, but it was still interesting to think about the game in this different way. This general curve made it into the final game in some way, as each run always starts a little slow and then becomes difficult at about 75% of the way through before easing into an easy run toward the end.

I made some more images that defined what easy, medium, hard, and very hard screens could look like. I defined difficulty as the number of objects and people that could spawn in one chunk.

The last remaining part of the level design to complete was the “indoor space” which we decided would be resort cabins. Cabins would have a certain chance to spawn and would take up an entire chunk, and each cabin would have an entrance and an exit, but beyond that we weren’t sure how we wanted to generate the contents. The cabins seemed especially prone to generating unfair (and for some reason buggy) layouts due their restricted nature, but with more constraints all of the layouts seemed too similar.

We decided that it would make sense to manually define the cabin layouts. To do this, the programmer set up a system that would read arrays and gave me a few example layouts in a Google sheet. From there, I organized the sheet and began to generate cabins.

However, I quickly realized that working only in the sheet was making it difficult to really visualize the cabins. To help with this, I used the game assets in a Photoshop file to define the cabins before making an array. This helped reduce a lot of the errors that I was making.

As I made layouts, I began to realize that some rules might help the player navigate cabins more successfully.

For example, I placed Mask pickups in such a way that they were always part of the optimal path through the cabin (the optimal path being the one that generates the least risk of infection by avoiding contact with people.) So if players run toward the mask (which is something we want them to do) they’re more likely to make it through the cabin without issue.

I also used some visual elements such as rugs to give observant players more information about the entrance and exit locations.

Additionally, I tried to make at least two variations of each combination of door locations, so that it wouldn’t be possible to have a cabin memorized based on where the entrance is.

I made 93 cabins, which accomplished the goal of preventing players from easily memorizing cabin layouts.

In addition to this, each cabin is a little pathfinding puzzle to solve, "How quickly can you see the optimal path?" and their hand-built nature provides an interesting contrast to the more random layouts found outside the cabins.

PLAYTESTING

Due to the pandemic our studio was fully remote and so playtesting chose to conduct playtests in a way that was still relatively new to me. My preferred method of playtesting is to watch the person play the game in person so that I can make observations, dig deeper into observations during and after, and provide support for the person playing.

For this game, we distributed playtest builds to friends and peers of the team who we reached out to (these people still fell into our intended audience and were generally good at providing honest feedback) and asked them to play the game a few times or until they felt they had completed it. We also sent a survey that I created in Google Forms and asked them to complete it. We collected feedback from about 12 different people in this way across three different builds. Though I’m certain valuable feedback was lost through a lack of direct observation, we were still able to confirm the overall fun factor, see how difficult people found the game, gain insight into how well people understood the rules and point of the game, gather common requests, identify favorite moments and points of confusion, discover bugs, and learn about performance across different platforms. In hindsight, I wish we had met with people virtually through a streaming platform and possibly recorded their gameplay. We had agreed as a team that the informal nature of the playtests, simply sending someone a link and asking them to play it whenever they wanted as opposed to setting up a virtual meeting, would yield more results and be more respectful of people’s time. But, I still think that some people would have been willing to meet virtually and commit more time if they were asked to.

One of the most interesting playtest outcomes was the result of the only in-person playtests that I was able to conduct. My younger sibling (whom I consider an all star playtester) played an early version of the game with me. Unfortunately, she experiences barriers related to her vision. However, this has given me a lot of firsthand experience designing with vision-related accessibility as a goal. While she was playing, we realized that she couldn’t see the rocks at all, though she could generally see everything else well enough to dodge obstacles and collect masks. I made several test images for her with numerous rocks on different backgrounds and we found the potential issue:

This observation ended up being reported by a different player in their form! I took this image and info back to the artist and after some discussion he modified the assets like so:

When my all-star playtester tried the next build with the updated art, the issue had been resolved! She was amazed at how many rocks there were in the game and couldn’t believe that she was able to get as far into the level as she was before.

This process has had a lasting impact on me, and I think it highlights some of my unique abilities as an experienced game designer with an art background.

DEBUGGING

As we approached the end of the project, I still felt like I didn’t have a good grasp of how difficult the game really was to players. Both experienced action game players and people who never touch action games were able to reach the end of the game, but I didn’t see any indication of increasing scores. In COVID Courier, the player’s first primary goal is to simply survive the run and reach the end. Then, the intended goal for players is to drive their final number of infected people down as much as they can. This final value is what I consider to be their “score” as it’s the culmination of their gameplay execution.

However, as I continued to play the game for quality I began to notice that the ‘infected’ score sometimes fell far outside of the probable ranges that they should be according to the infection rules that I had defined. Even if I purposefully played the game poorly, I would sometimes achieve a good score. The artist on the team had a similar experience when he played the game, where he would post a score and say that he felt good about how he played but he must have just had really bad luck.

Because of the randomized nature of the game and chance-based infection rules, it was easy to think that this was all just probability being its usual counterintuitive self. Besides, everything in the game was functioning, you could run and dodge procedurally-generated obstacles, get to the end, and get your score. In spite of this, I decided to dig in and figure out if there was some deeper issue. I played the game about 15 times and recorded the results:

For the first ten runs, I was playing as well as I could to see what kind of range the infected numbers would have when someone was skilled at the game. After that, to experiment and get a more random range I played several more runs in which I only changed lanes to avoid obstacles (essentially ignoring all of the game rules.) However, these results ended up being better than when I was trying!

I forget why exactly, but I suspected this issue was related to something not being reset properly when pressing the ‘retry’ button at the end of a run. So I tested another set of runs, this time using the same strategy mentioned earlier (of only moving as little as possible and focusing only on reaching the end.) This time however, instead of pressing the ‘retry’ button, I cleared my browser cache and cookies each time to fully reset the game.

The results confirmed what I had suspected. I communicated this to the team and also mocked up a potential testing environment, so that no one would need to play the game so much just to check if things are working as intended.

In my example, I thought about how I would test the game if I were making it myself in Game Maker. I could create a room for each type of NPC interaction and place 100 NPCs in there. Then, I would have the game run and record the numbers to see if they match up with the intended probability.

The programmer took my suggestion and rooted out the issue with the game not resetting properly. He also set up a test environment to support future testing that I would be doing.

With the new testing level, I got to work checking that all of the probabilities in the game were being calculated as intended. I discovered that all of the rates of infection were double their intended rate! 

The left half of the columns are the intended infection probabilities. The right half of the columns are results from the testing environment.

This led us to find a second critical bug, which was that each collision was being counted twice!

Thankfully, both of these issues were straightforward to resolve once discovered and afterwards I was able to verify that the game’s rules were working as intended. 

RELEASE

After a few more bug fixes and polish, we were ready to release the game. We published it on several websites:

covidcourier.run

itch.io

ModDB

Game Jolt

RETROSPECTIVE

I find the game to be fun mechanically as an action game, though I think its rules and message could be communicated more clearly through some more iteration. Here are some additional thoughts about the project:

-- In the initial brainstorm we recorded this item, “visualization of something invisible.” I wish we had explored this idea as it might have led us to discovering a way to more clearly communicate the infectious nature of aerosol spread.

-- We received a lot of feedback about the game feeling unfair because it’s impossible to avoid contact with people. While this supports the learning goal, I wish we had included another less luck-based mode, maybe an endless mode of some kind, in which it is possible to focus purely on avoiding obstacles and people. As the game is, even though it’s fun to try to push your infected rate lower and lower, you quickly find that it isn’t possible to achieve certain scores.

-- With the above in mind, we could do more to communicate what the differences between a good and bad run are, and reward players who do achieve certain scores. Unlockable modes and game modifiers would go a long way toward giving players an incentive to pursue skillful play.

-- I pushed to include a game speed slider, that is, an option in the menu that controls how quickly the game scrolls. While it was an amount of work for the programmer to implement, I’m proud that we included a more open-ended accessibility option like this. I think there are opportunities in every game to find ways to help people who want to play the game. In addition to this mode, I think we could have included a health slider, a no-obstacles mode (so people only), and maybe even a “step-based” mode, in which the player only moves when an input is made.

-- After the issues with discovering the bugs related to the game’s core rules, I wish I had thought more about helping to design debug tools and finding ways to speed up our testing abilities. As a result of this project I’ve been much more proactive in working with programmers to build helpful debug features.

-- I would probably try changing the bottomless pit into a fallen tree so that the visual language of the game is simplified and more consistent.

CREDITS

CEO
Brian Kaleida

Chief Games Officer
Jessica Trybus

Designer
Bryon Lagania

Programmer
Garrett Kimball

Artist
Matt Denton

Back to top (Reloads the page)

HOME

RESUME

ABOUT


CONTACT

blagania@gmail.com
LinkedIn