Postmortem

Every year, I volunteer at the Code in the Schools Game Jam in Baltimore, Maryland.  It's an exhilarating experience.  Making a game with creative and talented students is one of the highlights of my year, and is always a reminder of the reasons I got into game development in the first place.  This year, the jam was different.  Instead of the whirlwind eight hours, the jam extended over four weeks, and of course, the whole event was conducted virtually.  Also different from previous years, teams were not assigned adult team leaders, so as a volunteer, I was not as hands-on as usual.  

Given this adjusted format and an inspiring theme (Home, Justice, Time and Masks), I decided to make a game myself this year, unofficially of course, but under the same constraints as our students.

Concept

The theme this year made me think of conversations I've had with my parents back in Mississippi, cloistered in their home, riding out the pandemic by themselves.  Their lives shrank into a much smaller footprint, and I wanted to make a game that spoke to their feelings of isolation and loneliness.  As a game designer, I'm fascinated by what I like to call "Poly Pocket" gameplay - games that exist in very small spaces, or that take tiny stories and stretch them into something bigger.  This sparked the idea for Gran.

The game's main character is a grandmother quarantined in her small row home in downtown Baltimore.  Her entire world is her small home, and the letters she receives from her three children.  The player completes Gran's chores around the house, and responds to letters from her children, which slowly tell a story of how the family is coping with the pandemic.

Mechanically, Gran is a small-scale inventory management game.  The player has a small number of inventory slots to store objects, which various things consume.  Gran can only do so much per day, and when her energy runs out, she must sleep.  She also has health, which depletes if she doesn't complete tasks before the day is over, or when she has to write a difficult response to one of her children.

Development

I developed Gran in Unreal Engine 4.26.  I use UE4 at work, and am the most comfortable with it.  I built the game using blueprint initially, but nativized several systems as they got more complex.  The final game is probably 30% C++ and 70% blueprint.  This split let me stay looser with my design longer, but got unwieldy at the end.  Were I to do this again, I'd start with a better native foundation.

Art Pipeline

I created all of the art in Gran using Blender.  I knew that I wasn't going to have any art help, so a fast pipeline was extremely important.  Fortunately, Epic's Blender to Unreal plugin works like a charm.  While sending animated characters to UE4 from Blender took a little figuring out, once all set up, everything was as easy as pressing a button.  I made all of the game's props and foliage in a single Blender file, and the animated pieces in separate files.

Level Setup

There are four main areas (which I called boards) in Gran: the front yard, back yard, kitchen and bedroom (there was also a basement at one point, but I cut it).  These areas all exist in the same map, spaced far enough apart that one isn't visible from another.  When the player walks through a door, the game fades out, switches cameras to a new board, and turns light sets on and off.  The trickiest part of this setup was moving the player pawn to the correct start location based on the door they used.  There are several markup actors I used to specify these points.

Narrative Systems

During the game, the player receives a series of letters in the mail, which they respond to at Gran's writing desk.  The narrative that plays out through these letters is fairly simple, but still had several dependencies.  I split the narrative up into three acts (called "parts" in the final game).  Each act has a bucket of letters (data assets) that may show up in the mailbox when a new day begins.  Additionally, a Story Manager object, implemented as a World Subsystem, manages a collection of gameplay tags which represent the story's state.  Letters conditionalize on these gameplay tags, and when a letter is delivered, tags may be added and removed.  Using this simple system, I was able to create a corpus of letters with arbitrary dependencies.

In addition to letters, the player sees quotes from the fictive future (Gran's children speaking about her in the past tense), which I used for narrative flavor and sometimes to give hints to the player.  I organized these quotes (called barks in my code) into sets, and wrote a simple class that would voice a random bark from a set.

The Inventory

The game's central mechanics revolve around inventory management.  The player has a limited number of inventory slots, and once they pick up an item, the only way to get rid of it is to use it somewhere, which costs energy.  I implemented the inventory system as an actor component which manages a fixed number of items (data assets).  This allowed more things than just the player to have inventories.  The Trash, for example, has an inventory, and putting things in the trash is simply moving an item from one inventory to another.  UE4's drag and drop API made the UI part of this simple.

Interactables and Pickups

Everything the player interacts with are interactables or pickups (which is a specialization of interactable).  Even doors are interactables.  These actors receive clicks, then set themselves as a target in the player pawn's AI blackboard.  When he player pawn reaches the interactable, the player pawn's behavior tree invokes a method on the interactable which performs its business logic.  Once I made this basic setup, creating new interactable objects was simple to do in blueprint.

AI

It may not be obvious, but there was some AI work in this game.  The player pawn setup in Gran isn't conventional.  The player controller possesses the current board's stage camera as its pawn.  Gran herself is an AI-driven pawn whose behavior tree handles pathing to new locations based on player clicks and invokes interactables at the appropriate time.  The whole thing fits in a single screenshot:

Conclusion

This game was a blast to make.  As a professional game designer working in a large studio, my development timeframes are in years, not weeks or days, and it's refreshing to see a game through from start to finish so quickly.  Really, though, my favorite part of the Code in the Schools Game Jam is working with students.  This game was great fun to make, but I look forward to helping teams make their own games again next year.