In this long-overdue reboot of the Savage Internet blog, I talk about setting up a modern web application development environment at the City of Toronto, as part of my Code for Canada fellowship project. This is a follow-up to this less technical intro on our team Tumblr (which you should also check out!)
Let’s dive in!
My first goal was to get admin access on our City IT-issued development machine. To do that, I had to send in an Elevated Access Request, wait a week, make sure the account worked, install City certificates on the laptop for VPN access, call IT a couple of times to fix issues that popped up. (Hey, we were warned that some of this could take a while.)
While I waited, I asked around for the database access we needed. Our project involves working with 25 years of existing City collision and traffic volume data - but to work effectively with that data, we needed to understand it first! I started by requesting read-only access, which was easier for IT to grant. This gave us breathing room to build trust with stakeholders and show value through our user research process, which made it much easier 2 months later when I asked for the full access we needed.
In the meantime, I’d also bought myself valuable technical planning time.
To make an informed plan, however, I first needed to know more about the available tools, services, and technical capacity at the City. Time for some interviews! In parallel with our user interviews, I held technical interviews with key IT groups:
- Open Data: How can we help you publish more collision and traffic volume data? What do your data publishing systems look like? Do you have standards around timestamps, locations, or other fields?
- Geospatial Competency Centre: How often are your basemaps updated? How current is the centreline data on Open Data? How can we help you share more collision and traffic volume data internally?
- Big Data Innovation Team (BDIT): What tools, languages, and types of development are you familiar with? What would make it easier for you to sustain this project after our fellowship?
- Data Owners: Where would I find documentation on these datasets? What pitfalls should I be aware of in using them? Which parts of these datasets are considered sensitive?
After all, these IT groups are also users of the systems we’re building, so it’s equally important to get their input during the research process!
By this point, insights were starting to roll in from our user interviews. To combine that emerging picture with what I’d learned from technical interviews, I mapped out how data moved around the organization. The first version of this “data map” was hastily scrawled on a whiteboard:
As it turned out, this was the perfect place to put it. Whenever someone in our office noticed a problem with our map, they’d approach us to help fix it - hallway testing isn’t just for software! Eventually, we expanded this into a more polished version:
This data map proved invaluable in user research: when we went to interview users, we could situate their use case on this map and understand how they fit in with the broader technical picture.
User interviews went on, and we continued to refine our understanding of the services we’d come to improve. On the tech side, this allowed me to coalesce technical requirements, goals, and opportunities into a Tech Strategy:
As you can see, it’s a living document rather than a strict specification: I update this as requirements, goals, and opportunities change. You can read the full text on Notion. This gave us a way to clearly communicate our technical plans to our stakeholders, and it gave them something specific to provide feedback on.
We’d been discussing cloud deployment from Day 1. As it turned out, BDIT had a EC2 instance and PostgreSQL RDS, and they were looking to serve webapps from it. This led to an early win-win: I helped them set up nginx, they shared
sudo access to their EC2 instance.
This was only a temporary solution, though - fine for early prototyping, but you don’t want to be running production software on someone else’s experimental data analysis machine. On BDIT’s suggestion, we reached out to Cloud Services for an initial chat, where they explained their available AWS stack to us:
Here we have an autoscaling pool behind an Elastic Load Balancer, all backed by a PostgreSQL RDS, and all within a Virtual Private Cloud. Perfect! I updated our Tech Strategy to take this new environment into account and came up with these specific asks:
- a main stack for serving our webapp;
- a transfer EC2 instance for moving data from Oracle to PostgreSQL.
Having a clear Tech Strategy shifted this discussion from “OK, so what do you need?” to “What else can Cloud Services provide?” A lot, as it turned out:
- ready-made CloudFormation templates to provision EC2 instances;
- production-ready, City-approved SSL certificates;
- help with setting up OpenID Connect-based authentication;
- ongoing work to move to the AWS Canada (Central) region to mitigate data territoriality concerns;
- CodeDeploy / CodePipeline integration for CI / CD.
In turn, the backing of Cloud Services helped convince stakeholders that we could deploy to the cloud while preserving data privacy.
Choosing a Tech Stack
With our Tech Strategy in hand, and our City-approved AWS stack set to arrive, it was time to decide on a tech stack for the product.
This part depends on many factors:
- the development team: Who’s developing this, and what skills do they have? Which tools / frameworks are they most familiar with?
- the project: What’s the timeline and budget for the project? How robust does it have to be?
- the users: What problem do they need solved? What forms do potential solutions take? How technically savvy are they?
- the organization: What skills does the organization have access to? What will help them maintain the product? What are their requirements around security, accessibility, perfomance, open-source licensing, etc.?
- the tech ecosystem: Which tools and frameworks solve the problem? What are the tradeoffs between them? Which tradeoffs make the most sense?
You can’t answer these questions without a clear direction based on user and technical research - otherwise, you’re stabbing in the dark! Getting to that stage took several weeks, a couple dozen interviews, countless email chains, face-to-face meetings with BDIT, and enough post-it notes to put some 3M exec’s kids through school.
It took a lot of work, but we got to a working hypothesis:
We believe that by creating an integrated data platform for Data Supervisors and Traffic Ops, we’ll achieve a seamless count and collision request to warrant process as well as trust and shared understanding.
Given everything we’d learned, this likely meant a user-facing web application plus some eventual scripting work to automate data intake, validation, and publishing pipelines. From here, I could plan the webapp tech stack.
PostgreSQL was the clear choice here. BDIT has extensive experience with PostgreSQL, Cloud Services offers PostgreSQL, Open Data is using PostgreSQL already, GCC is moving onto PostgreSQL, and so on. Everywhere we looked, divisions were either already using PostgreSQL or seriously considering it.
It helps, of course, that PostgreSQL is a mature, well-tested database platform with excellent geospatial support through PostGIS.
Web Application Server
From there, it was a matter of picking a node.js-based web framework. express used to be the default choice here, but development has slowed recently to the point where its future is uncertain. I ultimately settled on hapi, initially developed by Walmart Labs to handle Black Friday traffic. It’s popular, the community is active, there’s decent documentation, it supports
async route handling, and it comes with out-of-box security header support:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
Reactive component frameworks like React and Vue take an age-old problem in webapp UI development - keeping the UI in sync with changing state - and they solve it well. They can be overkill for smaller projects, but the modularity they enforce makes it much easier to manage larger webapp projects.
I chose Vue here: I’m more familiar with it than with React, and I prefer its clear separation of HTML, JS, and CSS code. (See the above rule of thumb.)
Static Resources Toolchain
This is usually the most confusing part for new webapp developers: transpiling, minifying, bundling, preprocessing, and so on. Where to start? Which tools to pick? How to configure them?
At the same time, these tools are all valuable, as they enable the use of modern HTML, JS, and CSS features while maintaining cross-browser support:
- browserslist defines supported browsers;
- PostCSS plus postcss-nested preprocesses CSS, allowing you to use modern CSS features while maintaining compatibility with browsers defined in
postcssdoes for CSS, allowing you to use ES6+ features while maintaining browser support;
- webpack bundles static resources and helps with production tasks like minification;
- webpack-dev-server offers hot-reloading in development, so you can instantly see changes to frontend code upon save.
See our Vue webapp template for more details on configuration here.
It is easy to shoot your foot off with git,
but also easy to revert to a previous foot and merge it with your current leg.
Every development project should start with source control. In our case, the Big Data Innovation Team uses both private and public repos on Github. Our project is internal-only, so I made a private repo on Github.
Our Vue webapp template is based on that private repo, but with anything specific to the City environment (IP addresses, other credentials) removed.
Once I had the tech stack picked, I built a sample application that exercised every part of this stack.
For source code, head over to bdit-webapp-template.
There’s a login form tied to hapi-auth-cookie:
For now, the username and password are hardcoded in
lib/config.js. This file is explicitly
.gitignore’d to prevent leaking credentials through source control.
After you log in, you’re greeted with this homepage:
There’s a logout feature, to test that we can clear our authentication cookie properly. Login and logout are handled by
POST /login and
POST /logout respectively in our
hapi-based REST API server.
Clicking on “About” brings you to the truly dynamic part:
This is where the database and REST API server come in! There’s a single table
"TEST"."COUNTER" with a single row:
1 2 3 4 5
Our REST API server offers three counter-related endpoints:
GET /countergets the current value of the counter;
PUT /counteradds 1 to the counter;
DELETE /counterresets the counter to 0.
When the “About” page is loaded, we make a request to
GET /counter to initialize the counter state in our frontend. “Increment” makes a request to
PUT /counter, “Reset” makes a request to
In development, frontend static resources are served from
webpack-dev-server, which proxies requests from
https://localhost:8080/flashcrow/api/(.*) to our REST API server at
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
We serve the application at
/flashcrow, mainly so that we have the flexibility to run other applications on the same machine if needed for the project.
npm run build writes static resources to
dist. To serve those alongside our REST API server from a single port, I brought in nginx as a front-end proxy:
1 2 3 4 5 6 7 8
The combination of
proxy_pass here achieves much the same thing as
With a sample application up and running, it was time to focus on making sure we could test everything.
During the Vue CLI project initialization, I also set up Jest for unit testing and Cypress for end-to-end browser testing.
@vue/cli-plugin-unit-jest sadly isn’t compatible out-of-box with
@babel/core yet, but you can follow these instructions to get it working.
For Cypress, I ran into a well-known issue with installing Cypress binaries behind a corporate proxy. To fix this, I had to download the binaries manually, then move them into the appropriate Cypress cache directory; this causes the post-install script to skip downloading.
With @vue/test-utils, we can mount components within Jest suites:
1 2 3 4 5 6 7 8 9
You can do plenty more with
@vue/test-utils: issue mouse / keyboard events to specific elements within the component, test lifecycle methods, and so on.
CounterDAO is our data access object for handling counter fetches and updates in the sample application. To test it, we can just
import CounterDAO from a Jest suite like any other library:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
Note the call to pg-promise’s
db.$pool.end() at the end: without this, the event loop hangs forever, and the test eventually times out!
REST API Testing
And our REST API layer, which we can also test in a Jest suite using request-promise-native:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
This is set up to run against
https://localhost:8080, which means running
node server.js in development.
End-to-End UI Testing
Finally, we have end-to-end UI tests in Cypress:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
Fantastic! We can test our application from top to bottom, right out of the gate.
Always code as if the guy who ends up maintaining your code will be a
violent psychopath who knows where you live. Code for readability.
The Code for Canada fellowship is 10 short months: 4 down, 6 to go. I might be the only developer on this project right now, but what about after I’m gone? What if we get another developer on the team mid-fellowship? (This isn’t purely hypothetical: BDIT mentioned we might be able to get 1-2 more devs.) Professional software development means writing code others can read and modify.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32
Note that I’ve also added npm audit, which flags npm packages in your project with known vulnerabilities. Solid pre-commit hooks are an essential part of maintaining code readability, quality, and security!
Phew! It sounds like a lot of work, but some technical due diligence up front saves loads of effort later. It’s always easier to integrate best practices like end-to-end testing, pre-commit hooks, etc. into a fresh project than it is to shoehorn them into an existing legacy codebase. If you have the chance, why not do it when it’s easy? Your future team will thank you.
I’ve also been busy setting up a replication pipeline between Oracle and PostgreSQL, which I might explain in a future blog post (time permitting). We’ll soon be starting in on development, so look forward to more technical deep-dives!
This is the first in a series of posts where we explore the mechanical, narrative, logistical, and personal limitations of real-world gameplay. In this post, we’ll give a quick overview of the topic.
Here at Savage Internet, we love real-world games. In fact, our current main project, The Puzzling Madness of John A. Macdonald, is a blend of escape room and historical tour. Our previous project, Zombie Rendezvous, was based around paper booklets and in-person interactions.
As game designers, we find we learn just as much, if not more, from LARPs, pen-and-paper RPGs, board games, sports, card / dice games, and other real-world games as we do from video games. If you think about it, that’s not really surprising: there’s a richer history behind real-world games. Games have been part of our lives for thousands of years, while the first video game wasn’t invented until the mid-20th century.
If we love real-world games so much, why devote so much time to talking about their limitations? First off, it’s well-documented that the right kind of constraints can drive creativity. Clear, well-understood constraints are particularly useful here.
Aside from that, knowing the limitations at hand helps to focus efforts on workable designs. For instance: a design that has people walking around for 12 hours straight is likely flawed, as is one that relies on people being in two places at once. It also helps suggest areas where the right technology or tools can help make the impossible possible. Maybe the 12-hour game can be broken into stages, with progress tracked via a simple website that players sign up on. If players need to be in two places at once, maybe you can split their role among team members, and let them coordinate over SMS. (These aren’t the easiest solutions here, of course: you can often get by with carefully removing / editing content.)
Finally, there’s a bit of selfish exposition here. Our team has a lot of experience building technical things: software applications and libraries, hardware prototypes, etc. Our released games thus far, on the other hand, have been largely low-tech and in-person - so you can think of this series as a sort of braindump of what we’ve learned, often the hard way by sweat and trial-and-error and all that character-building stuff.
The Types of Limitations
Mechanical limitations are upper bounds on the complexity of a game’s rules, system, and setup. In video games, the computer handles much of the complexity for the players. Real-world game players, by comparison, must often remember and apply the rules themselves. This includes keeping track of their specific role, abilities, equipment, inventory, etc. where applicable. It also means being aware of special rules or exceptions, which are often introduced to maintain game balance. In more complicated games, that can be a lot to manage! There are, however, ways of dealing with this complexity, as we’ll discuss in Part 1.
Narrative limitations are similar to mechanical limitations, but for story complexity. Some LARP systems come with an expansive backstory, involving warring kingdoms and deities and such, that can quickly overwhelm new players unless they receive a more gradual introduction to the game world. Of course, narrative limitations exist in all storytelling media - a story has to make sense, for starters, and it helps if it’s compelling, consistent, etc. However, any game that asks its players to internalize and apply aspects of the game world - enmity between fictional races, the state of diplomatic relations, knowledge of fantastical devices - faces an additional difficulty in narrative design. Moreover, the narrative often has to be made manifest in the game through rules, props, costumes, NPC interactions, etc., and this is more difficult to do convincingly if your narrative is overly complicated. Finally, games have the unique problem of branching narratives. A negotiation might succeed or fail, a time limit might be met or missed - and all options have to lead to compelling storylines. We’ll look at narrative limitations in Part 2.
Logistical limitations are more for organizers: the more complicated a game design, the more likely it is that something will go wrong. An early version of Puzzling Madness had a mini-game where players donned blindfolds, then ran around picking up letter tiles hidden around a park. We thought it was really cool, and it was - as an idea. When we tried it out, we quickly hit snags. You can’t just leave letter tiles in a park and expect them to stay there, so we’d have to lay them out at the beginning of the mini-game. This meant one of us had to put the blindfolds on people while the other ran around placing tiles, which in turn meant the players had to be kept entertained while the mini-game was being set up. Eventually, we scrapped the mini-game altogether, mostly to save ourselves the hassle of running it. We’ll talk more about that experience, and about tools for helping manage logistical limitations, in Part 3.
Personal limitations are physical and mental limitations of the human body. Players need to eat, drink, breathe, sleep, and use the bathroom. When players place their trust in a game designer, however, they usually expect more than simply basic survival. They might expect that game tasks won’t be overly dangerous, intimidating, demeaning, or uncomfortable. Part of this is knowing who your game is for: Tough Mudder enthusiasts and cribbage players will have very different thresholds. There’s a lot of individual variance within these groups as well: one player might love blindfold mini-games, while another might be extremely apprehensive about them. Our series will end with a look at personal limitations in Part 4.
Keep posted for the next installment, “The Limitations of Real: Mechanical”!
We’ve been hard at work on The Puzzling Madness of John A. Macdonald for the last several months. This game is a blend of escape room and historical tour: it leads players to physically walk across downtown Toronto as they solve puzzles, examine historical buildings, and meet 19th-century Canadians. Ultimately, players unravel a mystery that is threatening Confederation itself!
This project came about when we were having brunch with a friend of ours, Hillary Predko, back at the very beginning of our time in Toronto. She mentioned that, since 2017 is Canada’s sesquicentennial, there is lots of funding available for Canada150-themed projects. After lunch, we sat down to brainstorm, and decided that we could make something really cool for Canada’s Big Year.
Thus, Puzzling Madness was born. We’ve been working on it on and off since November, but really put our noses to the grindstone around March. So far we have done 3 playtests, working out kinks in the system and puzzles. That’s the process I’m excited to write about today!
One of the very most important topics for running playtests like these is reassuring your players that it isn’t them that you are testing: it’s your game. You have to keep your players happy and engaged, and if they are frustrated at puzzles it’s critical that they know it’s your shortcoming and not theirs. For escape room-type games, where not everyone is supposed to succeed, this leads to an interesting conundrum: you want some of your testers to get through the puzzles, but not everyone, so you are testing for “average” ability at the same time you test for the challenge level of your puzzles.
Another key point is to know what you’re testing for each time you run a test, as this will inform extra equipment you need to bring or extra information you need to record as you go. Do you want to get timings down? Make sure you bring a watch. Do you want to see how tricky a particular puzzle is? Interview participants as they think through it. Are you focusing on characterization or storytelling? Be certain you have questions in your questionnaire dealing with that, and collect images of player reactions to “cutscenes” or other character interactions.
Playtest 1: Length
Our first playtest, way back in March, was on an unfortunately drizzly and cold day. We had 8 players out: the very first people to see any of our puzzles or storyline. Things immediately started going wrong, but ultimately everyone had fun. We spent about 5 hours with our team before calling it a day.
First off, for one of our puzzles we had players find historical plaques marked on a map. The information we used to construct the map came from an enormously helpful and awesome website: the Toronto Plaque Map. Unfortunately, we didn’t actually verify a couple of the plaque locations physically, which meant that two things happened: 1) one plaque was no longer visible due to some construction around the area, and 2) we had some transcription errors in putting the plaques on our map.
In this playtest, players wound up taking several breaks to go inside in order to solve puzzles. This pointed to a few shortcomings in the game: first off, if it’s possible to solve the puzzles while indoors at a table, then they aren’t very well tied to the physical historical locations. Second off, it drove home the point that an outdoor puzzle game really is weather-dependent. We’re crossing our fingers for a warm, sunny day.
Puzzle challenge and target market
We are big puzzlers. We have played in puzzle hunts, done escape rooms, and even designed puzzle games for each other for our birthdays (see Doc Savage: Woman of Bronze, for example). That said, we made some of our puzzles in the original version of the game… a little too sadistic. This led to a serious conversation about the kinds of people we are hoping to have play the game, whether they are serious puzzle people who know nothing of history, people curious about history who enjoy light puzzling, people who are history buffs and don’t know anything about history, or some other group entirely. At this time, we decided to split our game into two “modes”: Puzzle Mode that will cater to hardcore puzzle solvers, and “Story Mode” that will focus on delivering an interesting historical story for people less interested in puzzles.
We have to go… where??
Our initial design for the game had players begin at Union Station, walk out to the St. Lawrence Market, walk back through old town Toronto, head north through mid-town and visit the YWCA among other places, and finally wind up with a series of puzzles across the University of Toronto’s campus. Looking at a map, we could see that this amount of walking should take ~45 minutes on its own, and we figured for a 3 hour experience giving players 2h15min to solve puzzles (we had 30 in total in this version) would be plenty. Ha. Ha ha. Well, that one’s on us. Of course, between bugs in the puzzles and the enormous distances to cover, our players only managed to get through about ¼ of the material we’d written. When we decided to call it a day, we debriefed everybody on what was “supposed to” happen.
Ultimately this test was successful in that we learned a lot from it, although we felt bad about having given a pretty sucky game experience to our players. We tried to justify this by reminding ourselves that we did buy them lunch and dinner. :) We improved our playtest procedures for the following test, in addition to significantly overhauling the game itself.
Playtest 2: Puzzle Mode
After our first playtest with a group of what we determined would become “story mode”, we were eager to do a test with a group of “puzzle mode” playtesters. We managed to recruit a full team of testers who all worked together, and who had completed several escape room games together. One of the group members had also done puzzle hunts in the past. The day we ran the playtest was a little cool, but fortunately dry!
Puzzles and challenge
These players loved our puzzles. Several of the re-done puzzles in this version required leaps of logic, and there were a few pretty unusual puzzle mechanics that nobody in the group had seen before. They enjoyed exploring the city, and everyone said that they had visited or noticed something new in the process of going through the game.
One thing we did notice during the playthrough, though, was that the one player who had previously done a lot of puzzle games was “carrying the team”, in the sense that he was given control of the map and puzzle booklet, and was heavily involved in solving all of the puzzles. One mechanic we had designed to combat this was that each player takes on a character: they are a historical person with particular knowledge that applies to one or two puzzles in the game. In this way, we hoped to give everyone a chance to shine over the course of the experience. In practice, what happened was that most players gave their clue sheets to one person, who then effectively ran the show.
Another issue for teamwork was that we only printed a few of the puzzle booklets, so not enough copies of information were available for all players to be active on a puzzle at the same time. For the next test, we determined to print enough copies that each person could have all the information necessary.
While the first group simply didn’t have enough time to experience the story, the second group had no interest in it. They were fixated on the puzzles (as they should have been, since they were the puzzle mode group!), and there was no mechanic that forced them to interact with the non-player characters that we had built into the game. The next iteration would see required interaction preceding each puzzle.
This test made us realize that separating puzzle mode and story mode, while attractive in the sense that it meant we could use more of the material we had already generated, wasn’t, in fact, feasible for this game. Maintaining two totally different sets of puzzles, keeping track of minor differences in actor scripts, and all the other bookkeeping that goes along with doing two things when you should just be doing one turned out to be a little overwhelming for a 2-person team.
Playtest 3: The End!
Our major goal for this playtest was to get players to the big finale we had planned at all costs, since our original plan was to launch the full game a couple weeks after the test and none of our groups had yet made it that far. We planned to give hints, liberally if necessary, to ensure that this would happen.
Having learned from our last test, we gave everyone a copy of everything for this playtest. There was no longer secret information for each player, and there were enough copies of each sheet that everyone could collaborate on every puzzle. Or, at least, that was what we expected. What happened was that players got overwhelmed with the sheer amount of paper they had to carry, and had challenges in organizing it. Many of the hints we gave were of the form, “you have other information”, just to remind players that we had given them a clue sheet back at the beginning of the game. We are still working out what the “magic” amount of information is going to be for the game to come off smoothly.
Weather strikes again
With all the paper we were handing out, it seems like a cosmic joke that the day was also off-and-on rainy. Everything was soaked at the end of the day, and players had to find shelter under a variety of overhangs in order to even use the papers we had given them. Since we had no lamination or other waterproofing, the pencils we’d handed out also failed to work on the wet paper. Lesson learned: for the next playtest we’ll be using grease pencils and laminated sheets.
We had a fairly small group for this test: just 5 people. This gave them a lot of time to interact with each other and build up a rapport for puzzle solving, and also meant that all of them were busy most of the time: there simply wasn’t an opportunity for one person to sit idle. However, since we’re targeting groups of 12 in the final game, this gave us some pause. Even a group of 5 was able to get through the game to the finished in the amount of time we’d allotted, which meant that we needed to step our puzzle game up a little to keep it interesting for a larger group. In our next test run, we’ll be trying out parallel puzzles at each location: half the group can work on one puzzle, while half works on another, and the two parts will pop out the solution for that location.
Blindfolds aren’t for everyone
Every group we have tested with so far has completed a blindfolded activity that we designed. We really wanted this to be a part of the game (for story reasons), but it turned out to be too fiddly to set up, to take too long, and to be frightening for some players. Since we are expecting that some groups will be composed of people who don’t know each other yet, we don’t want to make them uncomfortable. After tweaking the rules of this activity for every group that we tested with, we finally decided to scrap it.
This was our most successful playtest yet, which is a good thing since generally you want to be improving each time you put something in front of people. :) We are basically at the length that we are targeting, people had fun, the puzzles weren’t too hard, and the story went smoothly. The few tweaks we are making for the next test are pretty doable, and we’re excited about it!
We’ll be running a couple of playtests in July before we finally have our launch day on August 19th. The July 15th group is already full, but if you can join us on July 30th, we’d love to have you!
We’re also putting together a trailer video that you’ll be able to share with your friends. We’ll definitely share that on here once it’s ready.
The playtesting thus far has been hard but rewarding. It’s a bit of a bummer to lose your weekends for a month to work, but we’re looking forward to the payoff.
Happy Canada Day!
Between volunteering at TCAF and with the Hand Eye Society and visiting with a friend passing through town, we spent some time this weekend at Ryerson’s Science Rendezvous, an annual science fair and festival taking place across Toronto, playing with the science of zombies.
A couple months ago, we heard that two members of SciCommTO, Toronto’s meetup for science communicators, were working on a Pandemic-style board game showcasing a zombie infection on Prince Edward Island. They had used the game to teach the basic principles of disease transmission, as well as emphasize the differences in infections caused by fungi, viruses, and bacteria.
Now, they wanted to bring the game and information to a wider audience. We met up with Amanda Veri and Elliann Fairbairn to think about how that might work. The main audience for Science Rendezvous is kids ages 4-12, which was very different from the audience their board game was designed for (high school kids and adults). The game also had to be made significantly shorter, so that it could hold the attention of a hypothetical family trying to navigate Yonge-Dundas square with science experiments and science magic shows on all sides of them. In addition, the game couldn’t really require players to sit down to learn rules, and it had to be playable outdoors.
This list of requirements rang a bell for us. On our recent drive across the US and Canada, we were lucky enough to spend time in several National Parks and -Monuments in both countries. In the US, the National Parks Service runs a junior ranger program for folks visiting: you ask for a booklet at the beginning of your visit, then you carry it around the park with you and complete activities as you hike, listen, learn, and explore. We went all the way through the booklets for Devils Tower National Monument and Yellowstone National Park.
These booklets have a range of activities, and they are built to accommodate multiple age groups within the same booklet. In general, older kids (and adults!) need to complete more activities than younger ones, and their activities are more complex. A 4-year-old might dance like a leaf, while a 12-year-old might read a few paragraphs and fill in a crossword puzzle. At all ages, junior rangers must go on a hike and listen to a ranger talk while at the park.
We all agreed that this would be a great basis for the kind of experience we wanted to develop. The final product has a collection of activities which are completed at pre-defined stops, where volunteers keep the game moving with some hands-on activities and help participants complete the related booklet pages.
Our game has four stops: zombie, doctor, pathologist, and researcher. Players are infected, then go through the process of identifying their infection type and helping develop a cure for it.
Zombies roam around the event, searching for kids and families to “infect” with zombism. Each zombie has a collection of activity booklets, which are coded to let other volunteers know which kind of infection each person has. When a zombie infects a player, they note the time (players have only 30 minutes to complete the game before they turn into zombies… forever!). Players take notes about the zombie: how it infected them, how it is behaving, and what it looks like. They are then encouraged to seek out a doctor to help them figure out what is wrong.
The doctor helps players “take a blood sample” so that they can identify things that don’t belong. In this case, players learn what a virus, bacterium, bacteriophage, and fungal spore look like: they also find out that one of these three things is causing their infection and learn more about how to prevent the spread of infections.
A pathologist can create a culture of disease agents. Our pathologist takes the player’s “blood sample” and gives them back a culture showing what that sample would look like when grown. For this, Amanda arranged real cultures of viral, bacterial, and fungal agents, which we sealed for the protection of participants (they were common agents, like bread yeast for the fungal agent, so this was mainly precautionary and not strictly necessary). Participants then had to match their culture to example cultures to determine which kind of infection they had.
With all the info about their infection in the bag, players scoot over to the researcher who helps them create a cure. In order to create something effective, it is necessary that players have correctly identified their infection, since a cure for a fungal infection does not work on a viral or bacterial infection! Players learn how drugs are designed, and complete a word search for new vocabulary learned in the course of the game.
Once players get their cure, they again note the time. If they have completed the game within 30 minutes, they are free! The researcher writes a big “WIN” in green letters, certifying that they are healthy and no longer infected with zombism. However, if not… players are now zombies! Either way, everybody gets candy.
A final pair of pages in the book can be completed by participants after they’ve gone home. It encourages them to think about what they would want in case of a real zombie infestation, in terms of supplies, shelter, and skills.
We learned a lot over the course of the day. A few of the most important lessons were about group/family dynamics, keeping things from getting scary, pre-game organization, activity design, and “advertising”.
Group and family dynamics
Most of the people at Science Rendezvous showed up as families. The people who played our game ranged from 4 to 60, though most of them were under 12. Often the younger ones showed up with Mom and/or Dad, and it was important to get everyone involved in the activity, but not too much. We started to take the tactic of kneeling down to do activities with the kids, since then they were more engaged with them and it kept Mom and Dad from being tempted to do the activities for them. We also sometimes saw kids who totally split off from their parents to play the game; this was a surprise to us, but given that our locations around the square were pretty obvious, it was never a problem.
Keeping things from getting scary
During the beginning of the day, some kids got totally scared off from playing the game because our zombies were too realistic. The zombies developed a strategy: first they asked kids if they wanted to play a game, then they would act like a zombie and bite them, and then “change back” into a non-scary person who would help them start the activity.
Since everyone who performed today was a volunteer, we didn’t really have a chance to train or even go over the game totally. In the first part of the day, many people “lost” (i.e., became zombies permanently) because we had not properly set up the pathologist’s station beforehand. The agar plates were very challenging to correctly identify visually, and we ended up labelling them with illustrations.
One of our activities is a word search, which we based off of the Yellowstone Junior Ranger book. It didn’t take us long to realize that the word search takes much too long for our game; we originally intended to have people find from 10-20 words depending on their age, but cut it down to 3-8 words to keep their interest. The Yellowstone book, of course, was designed for kids to do as they rode in the car around Yellowstone, which they must do for hours and hours in order to see all the big sights in the park. In that case, a really long activity was a bonus rather than a problem. We didn’t think about that when we borrowed their design, so we had to change some things on the fly.
Another fun thing for activity design would be to have an “accomplice package” along with the kids' game; their parents were in general just as into it as the kids were, but perhaps we could supply some more challenging activities for them to do alongside their kids!
Our goofy outfits made it more fun for us to run the game, in addition to making it more likely that people would walk up to us and ask what the heck we were doing. Definitely a plus in this situation!
People of all ages and kinds were really excited about the game. We had praise from parents, educators, kids, and adults who played even without having kids. One kid even went through the game twice. A security guard working at the event walked up to one of our zombies saying, “I heard your game is really hard… can I play?” At the end of the event when we were packing up, we were begged by a kid who had heard about “the zombie game” from someone else and desperately wanted to play. Of course we humoured him.
Overall, it was a satisfying day. While the game didn’t take a super long time to put together, and it could still use some tweaking, it was definitely well-received. Perhaps we’ll join the festival again next year. :)
Want to play?
Want to try out our game—even though you didn’t make it to Science Rendezvous—, or would you like to run Zombie Rendezvous at a similar event?
Take a look through our booklet, and feel free to use it! We’re hereby licensing it under Creative Commons CC-BY-NC-SA 4.0, which allows you to reuse it for non-commercial purposes, and even make changes to it, as long as you cite us as the source and allow other people to adapt your booklet in the same way. Here’s a printer-friendly version of hte booklet, with pages flipped for proper printing and to conserve paper.
Mental health is a difficult topic to handle in any medium, and for that reason it’s rarely addressed. So when I started playing Stardew Valley, I was surprised to find that it deals openly and inclusively with mental health issues. From depression to PTSD to alcoholism to social anxiety, you’ll get to know characters across the whole spectrum of DSM classifications, and you’ll have a really great time doing so.
Aside from its willingness to break through the stigma surrounding mental health issues, Stardew Valley is also a really great game. Of the 60 or so games that came in the Humble Freedom Bundle we purchased a while back, Stardew Valley is by far the one we’ve played the most, and I’ll get into why it keeps drawing us back.
But first, a screenshot from old SNES classic Harvest Moon):
And here’s Stardew Valley:
At first glance, Stardew Valley is Harvest Moon 2.0. Both are farming simulation games, and they share a lot of the basic mechanics. Both have you grow crops and raise animals to produce goods that are then sold to help grow the farm. Both have similar systems of time, with hours of the day and a four-season calendar complete with festivals and NPC birthdays. Speaking of NPCs, both allow you to befriend them by giving gifts and talking to them, and both allow you to marry NPCs that you’ve reached a high enough level of friendship with. Both have upgradable tools, stamina to limit how much you can do in a day, fishing, house upgrades, and so on.
So what’s different? Well, there’s the mental health thing, for starters:
This interaction, which happens once you reach the two-heart friendship level with a villager named Shane, is a strikingly open discussion of depression in an otherwise cute and colourful game world. Before you reach this level, Shane will push you away whenever you try to speak to him. You learn gradually that Shane self-medicates with alcohol, but it doesn’t help. You also come to see that he has a passion for raising chickens. It’s a great example of how, by taking a game mechanic (friendship) and raising the stakes, you make that mechanic much more compelling. You’re helping these people work through their issues as you get to know them; the flip side of that, of course, is that you can only people whom you interact with, so failure to interact takes on a moral / ethical dimension. It also encourages empathy for the characters: even if you wouldn’t normally like their personality, chances are good they’re fighting a battle you know nothing about.
The same is true of the broader community, which is being eroded both by neglect and by the appearance of mega-corporation Joja in town. Early on, you’re presented with a choice: do you help tiny Kodama-like spirits rebuild the community centre, or do you sign up for a JojaMart membership and turn that centre into a Joja warehouse? You can, of course, make either choice, and they lead to different modes of gameplay. The community centre path requires you to deliver various items, and encourages a more exploratory play style. The JojaMart path instead depends on constant infusions of money, which leads to a more optimized / micro-managed play style. Since crop seeds cost more at JojaMart, this is also cleverly balanced to double as a “hard mode” after you complete the game: most players will pick the altruistic community centre path their first time.
This “hard mode” balancing is just one example of how Stardew Valley encourages mastery learning throughout. Another great example is the fishing minigame:
Once you hook a fish, you enter a minigame where the fish bobs and jumps around this track while you try to keep the yellow bar underneath it. You gradually learn where to find different species and how they move along this track, to the point where you can guess what you’re catching before you actually catch it. If you’re following the community centre path, this knowledge becomes vital in tracking down the fish you need to deliver.
Stardew Valley also adds a combat system, where you enter a sort of roguelike dungeon-crawling mode to find precious metals and other unique resources. Some of these resources can’t be found anywhere else in the game, and the metals and resources alike help to build gadgets that improve your farm: automatic watering sprinklers, mayonnaise machines, etc. Speaking of sprinklers, those also appeared in Harvest Moon, but you simply bought them from the Tool Shop; by tying these upgrades to dungeon exploration, it really gives you that satisfying “I earned this the hard way!” feeling familiar to Survival-mode Minecraft players.
And, finally, Stardew Valley has some wonderful comedic moments, like when you find Mayor Lewis' purple underpants in Marnie’s room and decide to add them to your grange display at the Harvest Festival:
So: not that this is a review, but if it were, I’d be telling you to go out and buy this game right now. Since it’s not, though, I’ll say that it’s refreshing to see games tackling thorny subjects in increasingly approachable ways, and it’s also amazing to see another successful and engaging simulation game!
We were suuuuuper excited about the recent release of Thimbleweed Park, which bills itself as a “new classic adventure game”. From their website:
Welcome to Thimbleweed Park. Population: 80 nutcases.
A haunted hotel, an abandoned circus, a burnt-out pillow factory, a dead body pixelating under the bridge, toilets that run on vacuum tubes… you’ve never visited a place like this before.
Five people with nothing in common have been drawn to this rundown, forgotten town. They don’t know it yet, but they are all deeply connected. And they’re being watched.
In a town like Thimbleweed Park, a dead body is the least of your problems.
I’ve always been a big-time adventure game buff (to the point that I have a tattoo of King Graham’s adventurer’s cap), and I had a copy of Thimbleweed park reserved long before it came out. I followed their development blog religiously. The day the game came out, we sat down to play for several hours. We also played several more hours over the weekend that followed. We elected to try the “Hard” mode, which features all the puzzles, as opposed to the “Story” mode, which cuts many of them.
It was… kind of a bummer.
Don’t get me wrong, it isn’t a horrible game. It’s actually been extremely well-reviewed (4/5, 9/10, etc., all over their main page). It has some funny stuff in it. This is a game that recognizes that it’s carrying the banner of a lost art, and contains a healthy dose of self-referential humour to that effect. In keeping with the age-old inter-studio adventure game battle, it also pays lip service to Lucasfilm games and how they don’t allow dying (as contrasted with Sierra and other adventure game-makers). It’s got a fresh design aesthetic, though it keeps the pixels and the 9-verb interface from days of yore.
But the game designers make some assumptions that don’t seem to be true anymore. The most important one here seems to be that these sort of item-shuffling exploration games are truly the best we can do as far as simulating adventures. Another one is that dying in games is bad. Finally, there’s that 9-verb interface.
Adventuring and Item Games
Back in the 1970s and ‘80s, adventure games grew out of the booming role-playing industry and the desire that fed it: to be someone else, doing something else, for a little while. The appeal of games like Dungeons & Dragons is that you, the player, have full control over the activity of the game. However, along with this comes a management system that is still considered too complicated for most people to pick up. It didn’t take long for people to integrate this system into computer games: for obvious reasons it’s much easier to play a D&D-based game than it is to manage a tableful of dice with varying numbers of sides. This also loses out on the total freedom that can come from having a human control the game system, but role-playing-type adventure games today are really popular. Final Fantasy. Deus Ex. Persona. World of Warcraft. Neverwinter Nights. The Elder Scrolls.
So what’s the difference between a modern role-playing game and a classic adventure game? They both have “quests”, in some sense. Thimbleweed Park very helpfully tracks these in a journal held by each of its playable characters:
This is a definite interface improvement over early adventure games (I remember my grandpa’s notebooks filled with scribbles about puzzles still to solve), but it’s basically the equivalent of quest logs in modern RPGs.
Both kinds of games also tend to have a small number of types of quests: the most common one in adventure games is the “Delivery Quest” (you can see the rest enumerated, for example, on mmorpg.com). This is not a quest type I love. It basically asks a player to find a particular object and bring it to a particular person. In adventure games, this often involves some kind of intermediate processing (“I don’t want a blue catfish, you have to paint it red first!”).
So… are these kinds of quests still the best way we have to simulate adventuring?
This question seems especially sticky since we got our first chance to play The Legend of Zelda: Breath of the Wild over the weekend. It foregrounds a different kind of game system, where environments are based around physics rather than around pre-determined interactions. You can cut down a tree, and watch it roll downhill to destroy your enemies. When you’re walking up a steep slope, if it becomes too steep to walk, your character will start climbing instead. If you grab a wooden club, you can set it on fire, and this can end in tears if you are careless about swinging it in long grass (yes, we did die in the game from a wildfire of our own creation, whoopsie).
I don’t have an answer here, but with new kinds of games available it seems that the “adventure game” moniker feels a bit out of date.
Dying and The Stakes
One feature heavily pushed by in-game jokes as well as on the Thimbleweed Park development blog is that this game is designed without dead ends. The designers describe what they see as two typical problems with classic adventure games:
- it is possible to not pick up all necessary items, pass through a “gate,” and find yourself in an unfinishable game state.
- you can die.
The first issue is definitely a closely-held frustration for me. I once almost finished KQVI… only to realize that I hadn’t sent a message with a nightingale approximately 2.5 hours previously and was now unable to defeat the final boss.
But what about that second thing? Is dying really so bad?
Certainly it can be. Classic adventure games handed out the death penalty for seemingly-small things:
- walking into an inn
- eating a pie
- killing a snake
If you fell to one of these happenings, you were left to reload such saves as you might have and play on from there. That’s not very nice, but in today’s world of auto-save it’s not such a big deal (as long as you’ve already dealt with issue 1).
There has been some discussion on the web (for example, Kotaku) about whether dying in video games already means too little. The stakes are low when dying is meaningless (or even not present). Wandering around Thimbleweed Park, we found ourselves feeling a total lack of tension. Why should we be driven to solve this mystery? There isn’t time pressure of any kind. There’s no reason we shouldn’t just click on everything, or say rude things to the townspeople, or try to accomplish ridiculous feats with the chainsaw. In a game where there is no death and no way to lose… well, where’s the fun in that?
The Frustrations of 9-Verb interfaces
Adventure games started as pure text, but grew into graphical adventures as technology allowed. The original, Colossal Cave Adventure (or, simply, “Adventure”), was purely text. By the time my dear King’s Quest IV came out, interfaces mixed text and the keyboard for input. This had the cool feature that you could try a huge variety of things, and the frustrating feature that the computer didn’t understand most of them.
A bit later, developers experimented with a verb-based interface that was triggered with the mouse. In Space Quest IV (the SQXII in the screenshot is an in-game joke), input was through clicking on various objects. You could change the “verb” you employed by right clicking, or by hovering over the title bar and selecting the verb once the list appeared.
Thimbleweed Park, as you saw, uses the 9-verb interface that became more-or-less standardized around 1990. Open, Close, Give, Pick Up, Look At, Talk To, Push, Pull, and Use. Walking is triggered by clicking without selecting a verb.
Trying to use the elevator in-game is a classic “adventure game moment”. A right click opens or closes the elevator when on the doors, a right click looks at the elevator when it is open and the cursor is not on the doors, and a left click walks. Ideally, to get in the elevator, you right click, then left click. We have gotten this wrong many times, and been treated to hearing each and every character tell us what an elevator looks like. Or closing the door when we meant to get on. Etc. It wouldn’t be an adventure game without some usability problems.
But, really, why do we have this interface? With any given on-screen object, there are only a few things a player would conceivably want to do with it. I don’t want to “look at” the path offscreen to the next site. I don’t want to “pull” the hotel manager. Having more sensible defaults on mouse buttons (which could adapt per-item for maximum sensibleness) would feel liberating here. Modern console games typically get away with a single button that means “interact”. This might lose some of the subtle interaction possibilities that are part of the adventure game canon, but most of those failed interactions are just annoying, and don’t even have dedicated jokes or animation (the generics: “Why would I want to do that?”, “I’m not putting my lips on that”, “What would you do with it if you had it?”).
Adventure games aren’t sole heirs to the throne of adventure any longer. We now have better ways to feel like we’re questing, ones without deliberately obtuse quests, with more tension, and with more satisfying interfaces. I’m not sorry we picked up Thimbleweed Park, but it wasn’t all I had dreamed it would be.
We’re currently preparing for our upcoming July release of The Puzzling Madness of John A. Macdonald, a scavenger / puzzle hunt set in Confederation-era Toronto. We’ll have more information as development continues! In the meantime, those interested in playtesting the game before July can fill out our playtester signup form.
We’re also working with Toronto-area scientists to plan something exciting for Science Rendezvous Dundas Square on May 13, 2017. Until then, our lips are sealed - you’ll have to attend or wait until afterwards for the recap, which we’ll post here!