I Am Bolus
Serious Game
Audience:
High school biology students /
introductory anatomy undergrad students
Purpose:
Teach core GI tract anatomy & physiology concepts
Tools:
Figma, Illustrator, Procreate, Maya, Unity Engine
Intended dimensions:
1920px x 1080px, WebGL build
Project Description:
I Am Bolus is an educational game that teaches gastrointestinal (GI) anatomy and physiology through immersive, game-based learning. Players guide 'Bolus' through seven levels representing the organs of the GI tract, completing a series of minigames to progress. Designed around Canadian curricular objectives, the game integrates core concepts of GI structure and functions (mechanical and chemical digestion, secretion, absorption). Grounded in a serious game design framework, the game weaves learning objectives directly into its game mechanics— narrative immersion, task-driven motivation, and immediate
feedback. A “play-until-you-win” structure reinforces content mastery, while hidden “fail conditions” unlock educational content on GI pathologies.
This case describes the creative process for developing a proof-of-concept demo, which features the stomach level and its gastric secretion minigame. This demo demonstrates basic game UI and shows how core learning objectives are embedded into gameplay to create an engaging educational experience. The playable game can be accessed here: I Am Bolus Demo Game.
This is a team project. All members were involved in creating preproduction documentation and running usability testing with test users. Other creative credits are roughly as follows:
-
Athena Li — Creative Direction, Project Management, 3D Modelling, Game Design Lead, Dev Lead
-
Beverly Ng — Project Management, Set Design, 3D Modelling, Promo/Compilation Videography
-
Eve Higgins — Script Support, Interactive Storyboard Lead, 3D Modelling, Dev Support
-
Qingyue Guo — Set Design Lead, 2D Illustration Lead
-
Raymond Zhang — Voice, Script Support, 3D Modelling, Dev Support
-
Roy Kulananthan — Game Design Support, Script Lead, Sound Direction/Technician, SFX, Dev Support
-
Vicky Lin — Character Design Lead, UX/UI Design Lead
My personal goals for this project were to explore advance interactive media design, learn more about practical gamification principles, acquire new skillsets for dev-ing interactive media (coding in C Sharp for Unity), recap old poly-modelling skills, and appreciate role management, project organization, and workflow when working in such a large team.
(Media credits— thumbnail mockup: Vicky Lin, trailer video: Athena Li, Beverly Ng, Raymond Zhang, Roy Kulananthan)
At a Glance Documentation
Pre-production Document:
User Testing Document:
Pre-production Process
Idea Generation — Parameters, Group Interests, Contraints:
This project was created as part of an Advance Interactive Media course. As a group, we started off with the following bottom lines:
-
Wanted it to not be a scrolly-telly
-
Wanted to focus on human health
-
Initially aimed for concepts that were traditionally thought of as "boring" or undercommunicated. Explored immunology before landing on digestion.
-
Aimed for concepts that could be more or less linearized, in order to simplify game design for the sake of the course.
We ended up with a digestive physiology concept, which was first pitched by its title "I Am Bolus". The idea, which is still true to the current version of the game, was to have the player play as the bolus and escape the GI tract, and this was the first idea that got the energy up in the room. Though the GI tract is not particularly undercommunicated, it was utilitarian in a different way; since it is taught routinely as part of formal curricula in both highscool science and undergraduate intro anatomy courses, we would have a lot of course outline and textbook resources to help structure our content and game design.
Group Interests and Role Distribution
We also wanted to make sure the making of this game aligned with our individual learning interests and strengths. We had a discussion about our own goals for the course and assigned tentative roles early on. Everyone took on at least one role that they were interested in, and were voluntold for at least one role that they were thought to be good at. I signed up to take on the dev role to learn a little bit about programming and the script design role to participate in developing the actual game mechanics, and was assigned to project admin to help with organizational tasks and timelines.
Group Ideation and Consolidation
We then broke off to independently generate prelimiary ideas for the overall game, without any constraints in mind. At this early stage we wanted the whole group to have input on the direction the game would go in. After coming back to share in a roundtable format and comparing similarities and differences between our visions, we had the following structure:
-
A 7-levelled game, with each level representing a different digestive organ: mouth, esophagus, stomach, accessory organs, small intestine, large intestine, and rectum/anus.
-
Each level contains 2-3 minigames that reinforce the core learning concepts for that organ.
-
The possibility to play as different food types, which would have different stats to influence the game outcome... but we later scrapped that due to forseeable complexity and time contraints.
We consolidated our individual research ideas, made some more granular decisions about the game structure as a group, and shared it to the class in our Project Pitch. To keep the scope realistic, we decided we will script and storyboard only one organ level, and dev only the interface + one minigame for that level.
Gameplay Design and Literature Research
I was part of a small task force that looked into game-design literature to help figure out how to develop game mechanics and set up an engaging reward/motivation system for the player. Other members also separately began media auditting some educational games for inspiration for game mechanics and identification of what makes games interesting or boring. In our Project Pitch, the game had the following features:
-
Game Structure - Overarching game goal to pass from level to level + level-specific minigames to inforce organ-specific learning outcomes.
-
Performance - Each level will be pass/fail, without too many mechnisms or consequences for tiered performance. In alignment with serious game design principles, the goal is to have a simple and clear evaluation system: completed learning task = pass game, failed learning task = fail game.
-
Motivation - Dual learning through success AND failure. If player succeeds at the games, they get to move to the next level, providing intrinsic motivation. We came up with a pathology stamp collection idea to motivate players through failure; if they trigger particular fail conditions, they will earn a pathology badge relating to failed digestion. They can then click on to learn more about that pathology. This turns failure from a demotivator into a learning opportunity, and the collectibles help increase replayability value.
From here, we will break off to continue in our assigned roles, rather than as a large group. The first next step is to solve the kinks/inconsistencies in the overall game design and work out the specific game mechanics, which fell to the script team.
Core Gameloop Design
The script team began working on game mechanic details for the stomach level. We brainstormed ideas on a whiteboard, circling closer to final game design. The main challenge was to make sure learning objectives were built into the gameplay without it being too didactic, too linear, too convoluted, or too abstract. We tried to find a balance between having each learning objective be distinct gameplay elements for clarity and maintaining continuity of learning throughout the level.
Eventually these sketches were translated into a written document and a core game loop diagram that shows how the player successfully progresses through the level or fails. We began outlining rough ideations for the three stomach minigames as well at this stage. (Image creds: Raymond and Roy)
Narrative, Setting, and Script
The scripting team begins working on stylizing and embellishing the storyline for the game and comes up with the following:
-
Our narrator NPC character, Elder Corn, who guides the player through the game and also explicitly connects game actions to learning concepts. Update: Elder Corn was changed to Elder Enoki to have a more distinct sillouette from the Bolus.
-
A narrative and setting for the game that would be engaging and also allow us to meet our learning objectives.
-
Attempt 1 — Escape the Sentient House... The stomach as a sentient bath room with an AI voice that is trying to mash you up and kill you. Escape but at what cost? ... This idea was eventually vetoed for being too horror-themed.
-
Attempt 2 — A Monk's Journey... The stomach as a region of transformation. To pass on, you must shed your physical form... This idea was kept but modified for potential cultural insensitivity towards certain religions. We removed any explicit references to religious figures, titles, and practices.
-
With these ideas in place, a working script was developed and passed to the visual design team for iterative world and character design. The visual team, in trying to map out the game room, identified gaps in the scripts and non-viable aspects of initial mini-game gameplay. The gameplay issue led to confusion about how many game objects needed to be present in the environment. The script team came back and reworked the minigame designs for the final version. The final minigames are:
-
Gastric Gland Secretion Statues - 4 statues each representing a cell type of the gastric gland. The player interacts in sequence to learn what each cell type secretes and how the secretions interact with each other. (Image: left)
-
Chemical Digestion Pool - A space-shooter type pop-up game where players use gastric lipase and pepsin to breakdown the approariate nutrients as they fall from the bolus. (Image: middle, Creds: Raymond)
-
Mechanical Digestion Pool — A piano keys type pop-up game where the player controls the stomach muscle layers to mash the bolus into chyme. (Image: middle, Creds: Vicky)
Storyboarding
Once the script was finalized, the storyboard team divvied up the scenes to visualize the game flow, using Boords to collaborate. (Image creds: Storyboard team)
Character Designs
Concurrently, the visual design team began finalizing character designs and color palette decisions to fit the narrative. (Image creds: Vicky and Beverly)
Content Inventory
Separately, we made a content inventory spreadsheet to keep track of all the assets we need to make for the game, and who is responsible for making each one. This was helpful for organization and also for identifying any gaps in our asset production plan.
Production: Assets and Game Dev
Character, Game Object, and Background Modelling
We divided up all of the 3D assets among the 3D team members. I modelled the two characters in Maya, trying to stay true to the low-poly style while maintaining as much of the original character designs as possible.
Game Dev in Unity
We had a very truncated dev schedule: two weeks from start to finish. To get us started, I created a basic Unity project and shared it with the rest of the dev team via GitHub. To protect against potential conflict, the project I set up contained three scenes for the actual bolus game: landing page, tutorial, and main gameplay. It also contained four playground scenes, one for each dev member.
The dev team met and listed out all the possible basic functionalities we needed to tackle using script, and divvied those functionalities up amongst ourselves to experiment with. The idea was that each member could run their own script experimentation in their respective playground scenes, without interfereing with each other's files when pushing to and pulling from GitHub. I created a set of Setup Instructions that everyone worked with, to maximize smooth collaboration. One appointed team member was responsible for assembling final assets into the final game scene.
As a non-coder with zero programing experience, there was a lot of begging and pleading and ChatGPTing involved in trying to make code work. In the timespan that was had, my learning goal was code recognition and understanding, rather than fully generating original code. What I needed to be able to do is to understand what parts of the code is leading to error/bugs, and to efficiently point available AI tools to the parts of my code I needed to fix. At the same time, a big part of my learning curve was figuring out how the Unity Inspector interacted with script elements, and how to access functions through either or both methods. Often times, both methods would work, but with one being much more efficient than the other. Quickly learning how to maximize efficiency was key for the tight delivery schedule.
After a 5-day sprint of intense learning and production, the game was complete. After fixing final bugs, we built the game out for WebGL desktop and hosted it on GitHub for public access. This was the same version of the game that we later ran user testing on. The playable game can be accessed here: I Am Bolus Demo Game.
Post-Mortem: Tensions and Reflections
Thoughts on Groupwork and Leadership
This is my first time working in, and managing, such a large group. Navigating team strengths and weaknesses is an intriguing challenge. As our group is composed of many type-B personalities, I figured organization and structure will be key to our ability to complete our ambitious project on time moving forwards. Our first meetings were not very structured and therefor were not very time efficient, though they were productive. It took a long time to have everyone be on the same page about ideas, even on basic concepts, simply due to ambiguities in language and differences in perspective. For example, we initially had different mental models about what a "game" even is. The gamers in the group immediately pictured complex first-person type video games, while the non-gamers imagined simpler arcade-style or board game-style games. This simple difference in perspective led to many points of miscommunication which we eventually identified and resolved. (The final version of the game idea ended up being a bit of both; a first-person game with embedded arcade-style minigames.)
Another challenge of working with such a large team with defined roles and sub-teams was figuring out how the tasks of the different teams fit together. For example, gameplay mechanics influenced the visual design of the game room because it determined the number and design of the game objects. The storyboard team relied on the visual team for character and environmental design and proportions. The 3D team could not model any assets until character designs were finalized, where there was some dev elements that could be started without needing to wait for the final assets. Because the workflow was so interdependent, communication between teams became crucial and at times frustrating. The delivery schedule for all teams had to be tight and required constant coordination. Since the timeline was so tight, thinking through what parts could and could not be done while waiting for different sub-teams to complete the next stage became crucial for maintaining workflow efficiency.
As much as we tried our best to stay organized and communicative as a team, when the time pressure started, it became very hard to keep track of everything. Note for the future: get started on a robust content inventory early on and set up a team workflow in which that content inventory is constantly updated and checked off as we go.
Scoping and Content
We had some challenges with scoping down initially, since we wanted to do everything. In order to facilitate decision making, we first stepped back and identified some of the higher-order issues with our group decision-making process and the gaps in our plan that still need to be addressed (primarily, too many voices in the original ideations and we were all using different language to describe the same thing, or the same language to describe different things, which lead to confusion).
To solve this we went back and summarized/organized all the content and game ideas we had generated into cohesive language. We simplified the possible digestive functions into 4 groups: propulsion, secretion, digestion, and absorption. From there, we met again as the whole group and picked out one level to focus on for the prototype, which ended up being the stomach level since it representatively covered the greatest number of digestive functions out of all the levels.
We also summarized all the structural game-design inconsistencies in our previous ideations for later resolution. The main theme for concern was how far we wanted to rely on game metaphors, personifications, and abstractions vs how true we wanted to stay to realistic anatomy/physiology. The former risks perpetuating misconceptions and unmet learning objectives, but the latter limits the creative benefits of gamification in the first place. In the end we decided we were okay with abstracting the anatomy as long as we stayed true to the physiology.
Dev and Coding Learning Curve
The bad and scary:
-
The frustration of CONSTANT bugs. Even with carefully though out systems that work internally, every time a new element is added, the old system breaks. Points to the importance of thinking through systemic design and code architecture early on, and also the importance of having a strong grasp of the code base and how different elements interact with each other. Scalable code is a beast.
-
MERGE CONFLICTS... GitHub hates Unity, and Unity hates GitHub. Especially Unity scene files, as they are binary files. As soon as two people touch it at the same time, everything implodes. And GitHub does not allow you to see what the external changes are or who made them, before forcing you to pull them. Pulling a file then overwrites your version of that file. Collectively we might have lost about 15-20hrs of progress due to merge conflicts. Eventually we became so paranoid, we backed up our work to several clone locations before pushing or pulling the main file. Git merges requires more reading-up.
The good:
-
When building UI, we developed a really nice workflow where, in knowing how the interface looks/works in Unity, we were able to ask UI to make assets in explicit dimensions and positions that made them really easy to hook up.
-
That beautiful moment when you finally get code to work after hours of it not working. It's like solving a puzzle, and the satisfaction is unmatched.
-
The illusion of mastery of having built a function thing, despite not being able to independently generate a single piece of code. The help of AI became a necessary evil (and I hate to admit it, but it is very useful for coding syntax)
-
The power of friendship! Especially when you are struggling with code and hate everything and want to give up but your team keeps supporting you.