AirBorne (Playable)
Genre
2D Puzzle Game
Role
Designer and Writer
Location
Burbank, CA
Engine
Unity
Other Software Used
Photoshop and Final Draft
A Bit About the game...
"AirBorne" is a 2D puzzle game created for 'Mega Byte Jam 54'.This game is Inspired by the hit game "Papers, Please", AirBorne puts players in the role of an aeronaut tasked with deciding which passengers are allowed to travel aboard their hot air balloon. Every choice you make influences the social and economic balance of the destination city shaping its fate by the end of each journey.

Project Post Mortem
About the Game
AirBorne’s desired gameplay experience was to create a fun and engaging puzzle where players make moral and logical decisions about which passengers are allowed to travel to another city based on their physical appearance and health conditions.
As the Aeronaut, you are tasked with selecting the most optimal passengers for each destination city those who can make the greatest positive impact. The player must carefully balance three key stats for every city: Economy, Stability, and Infection Rate.
After each journey, players receive a report in the form of newspaper headlines, revealing how their choices have influenced these stats. Each new round presents a roster of 19 randomized citizens, and based on their traits and visual cues, the player must deduce who is healthy enough to travel and who poses a potential risk.
After five trips, the game concludes with a final report, showing whether the player’s decisions helped save the world or led it toward downfall.
Role Description
I served as the Game Designer and Writer on AirBorne. The jam’s theme and a special required item were both revealed at the very start, meaning our team began with a completely blank slate for this 40-hour marathon. As the designer, my challenge was to conceptualize a game that could be built from scratch within that limited timeframe something both fun and creatively challenging.
From the beginning, one of our main goals was to deliver a polished experience. We didn’t want AirBorne to feel like a typical rushed jam project thrown together in a few hours; we wanted it to feel deliberate, cohesive, and visually appealing something we could genuinely be proud of. Achieving that level of refinement under such constraints became one of my biggest design challenges: crafting an experience that felt complete and satisfying within just two days of development.
My second role, as the Writer, came with its own set of hurdles. I was responsible for scripting voice lines for nearly 19 different characters, all while balancing the jam’s intense time pressure. At first, the scope seemed daunting but once I stopped worrying about the workload and focused on the creative flow, the dialogue began to come alive. Each character soon had their own distinct tone and presence, adding personality and depth to the world of AirBorne.
Documentation for this game was crucial. However, due to our time constraints, we decided to abandon our traditional documentation process of using Google Docs and instead began working on a shared Miro Board.
This shift allowed us to visualize gameplay flow more effectively and quickly build tables and flowcharts that outlined character roles, interactions, and systems. Using Miro also helped us create a pseudo-paper prototype online, ensuring that every team member was on the same page throughout development.
Documentation
Miro Board Documentation
What have I learned?
Working on this game has been an incredible learning experience. As my first project with complete creative control, it taught me how to communicate effectively with other talents. I also expanded my network beyond my team and school by attending meetups, where I invited people to playtest the game. This experience gave me valuable insight into networking and collaboration.
Working on this game has been an incredible learning experience. As my first project with complete creative control, it taught me how to communicate effectively with other talents. I also expanded my network beyond my team and school by attending meetups, where I invited people to playtest the game. This experience gave me valuable insight into networking and collaboration.
One of the biggest lessons this game jam taught me was how to direct and guide my teammates effectively, and to truly understand the importance of having a clear design vision and the process of turning that vision into reality. As a designer, I realized how essential it is to lead with intent and ensure that every team member understands the creative direction.
Another major takeaway was that this experience wasn’t a sprint it was a marathon. Even though the jam included a ranking system, it felt more like a test of endurance and creativity under pressure. It wasn’t about who could finish first , it was about who could push their limits to create something meaningful within the constraints and that’s exactly what we did.
One of my biggest takeaways from this game jam was a shift in my attitude toward problem-solving. We had very little time to create a fully functional puzzle game, and instead of stressing over how we were going to achieve it and wasting time over it, we simply rolled up our sleeve and started tackling each problem as it came. Piece by piece, one solution led to another, and before we knew it, we had a finished, polished product ,the very game we had envisioned at the starting line.
Day - 0:
As we registered for the game jam, we were presented with three potential themes: Virus, The More, The Better, and Illuminate. These were revealed ahead of the official start, giving us a brief window to brainstorm ideas before the jam began.
We formed our Discord group and began discussing potential game concepts, keeping in mind the limited timeframe and the scope we could realistically achieve within 40 hours. As shown in the brainstorming list on the right, the idea of curing or managing a virus emerged early as a strong direction for our game.
The only uncertainty was how we would incorporate the special item, which was to be revealed once the final theme was officially announced.
Developement Experience
(Dev Diary)

(Photo Provided by Lucas Crain)
Dev Diary
(Day 1)

(Discord Chat)
Day - 1:
Our first official day began at 4 a.m., as we tuned into the 'Jame Gam' Discord server to catch the announcement of the final prompt. The chosen theme was “Virus,” and the special object we had to incorporate was “Balloon.”
To our surprise, none of us had anticipated balloon being the special item, which meant we had to return to the drawing board and rethink our concept from scratch.
Even so, we were still excited about the idea of a game centered around curing a virus. We decided to build upon that foundation and reshape it to fit the new constraint. We immediately jumped onto our Miro board, sketching out ideas and connecting systems. Concepts began forming rapidly, one after another, and soon the shape of our game started to come together.
We gave ourselves a hard deadline of 8 a.m. to finalize conceptualization, so we quickly fleshed out the core mechanics and sent reference notes to our teammate responsible for art and music. Meanwhile, we opened a fresh Unity project and began prototyping gameplay systems to test whether the idea was genuinely fun to play.
Fun was our top priority. We didn’t just want to make a game for the contest, we wanted players to enjoy it and have a memorable experience. Once the base mechanics were in progress under our Unity developer’s guidance, I shifted focus to designing characters, defining their roles, and writing voice lines. I also prepared short briefs for our artist to reference when illustrating each character.
We ended our day around 3 a.m. the following morning we had a solid foundation in place: working systems, a healthy batch of written dialogue ready for recording, and a good amount of art completed.

Voice Line Script for our characters.
Day - 2:
The second day began at 7 a.m., after barely four hours of sleep and a Starbucks run. We brought in voice actors to record the dialogue for our game, which, in hindsight, turned out to be an ambitious and time-costly decision.
Initially, we were thrilled about adding voice lines it felt like the perfect touch to bring our characters to life. However, we hadn’t accounted for the sheer amount of time it would take to record, review, and select the best takes from hundreds of clips. By the time we wrapped up recording, it was already late afternoon, and we had lost valuable production hours.
Thankfully, our producer, who was also serving as a Unity developer, stepped in to assist with coding tasks, helping us make up for the lost time. As we began implementing the voice lines into the game, hearing one of the first characters I had written finally speak was a surreal moment. It was emotional the characters I had imagined were now alive and speaking back to us. That moment reignited our motivation and reminded us why we were pushing through the exhaustion.
With most of my writing work wrapping up, I shifted gears to assist our artist with asset creation. I quickly studied his art style to maintain visual consistency and produced additional assets to divide the workload and prevent burnout, even though another sleepless night awaited us.
Toward the end of the day, I also volunteered to create the tutorial handbook, as it allowed me to shape the onboarding experience exactly how I envisioned it. I wanted the tutorial to feel like notes written by the Aeronaut himself, personal reflections from his years of travel that players could refer to while making their decisions.
Dev Diary
(Day 2)

Asset I created.

Tutorial Handbook
Dev Diary
(Day 3)

Final Screenshot of the game
Day - 3:
I stayed up all night working on the art assets and replaying the game repeatedly, making lists of bugs and improvements to hand over to the developer for the final polish.
The finish line was just a few hours away all it needed was one last push. As the rest of the team hopped back onto our Discord call, we chugged through the final stretch. We implemented the soundtracks, created the opening cinematic to set the tone of the world, fine-tuned the UI, and as the clock struck 12 p.m., we submitted the game at the very last minute of the jam.
That moment marked the end of production. Looking back, I couldn’t believe that in just 40 hours, we took a wild idea scribbled on a Miro board and turned it into a fully realized game.
My Primary focus was that each profession in the game was carefully balanced to have a defining strength and a slight drawback, creating a dynamic city ecosystem. For instance, Doctors and Scientists excel at reducing infection rates but can strain the economy, while Sanitation Workers improve stability at the cost of economic growth. Conversely, figures like Economists and Mobsters influence the market and stability in opposing ways, forcing players to make deliberate trade-offs when choosing NPCs to travel with.
To add depth, I introduced a sickness mechanic when an NPC falls ill, they increase the city’s infection rate by +3, except for Doctors, who continue to help reduce the spread even when infected. This created a strategic layer of risk management for players, encouraging them to monitor NPC health closely before travelling with them to cities.
The city’s three main stats ,Infection Rate, Economy, and Stability are integer-based and interlinked. Each stat reacts to the others, forming a living system. Low infection rates boost both economy and stability, while high infection rates erode them over time. A strong economy can raise stability, but economic collapse leads to civil unrest and instability. Meanwhile, stability determines how resilient a city is to disease and disorder; when it drops too low, mobsters begin to appear, reflecting the city’s descent into chaos.
These mechanics combined to form a self-sustaining stat economy ,a system where every action, NPC assignment, or moment of neglect had tangible consequences. Balancing these interdependencies was one of the most challenging yet rewarding parts of development, ensuring that every decision the player made carried meaningful weight.
(Please click on one of the image to view the descriptions on our Notion Page screenshots ->)
Implemented Mechanics
(Design)

Character table (Click to Enlarge)

City Stat Infection Description
(Click to Enlarge)

City Stat Economy Description
(Click to Enlarge)

City Stat Stability Description
(Click to Enlarge)
Communication as a team

Our primary mode of communication was Discord. Since the entire team was working remotely, we relied heavily on Discord, Miro, and Notion to stay connected and organized. We were constantly on voice calls, sharing assets, and pinging teammates whenever collaboration was needed. One of the biggest hurdles we faced was the time zone difference. While most of us were based in Los Angeles, our artist and sound designer worked from the East Coast. This often made coordination challenging during the later parts of the day. To overcome this, we adapted by planning tasks ahead of time and providing clear directions early in the morning so he could start working as soon as his day began.
Equally important were our collaborations on Miro and Notion, where we documented every key aspect of the design process. This ensured that anyone on the team could refer back to notes, assets, and systems at any point, keeping development efficient and transparent across all time zones.
One of the major problems we ran into was managing the GitHub repository. For most of our previous projects, I had been using GitHub Desktop to control the repository, but this time was different. Since we were all working simultaneously and remotely in the Unity engine, we decided to create separate branches for each department and merge them as progress was made.
Initially, everything went smoothly a few merges worked perfectly but soon we began facing merge conflicts and overlapping branches, which caused significant delays. At one point, we had to pause development entirely to ensure all files and the project version were synchronized cleanly across every teammate’s system.
This minor technical setback cost us valuable hours, but we didn’t lose focus. Instead of panicking, we kept asset production and system developing moving forward while our producer and project manager took charge of resolving the repository issue. Once everything was back on track, we set up a backup workflow through Discord, directly sharing art assets and builds there to keep the pipeline running smoothly.
What went wrong?
Git Hub Branch merge...

GitHub Commit History.
Voice Acting...
The other major challenge we faced during development was implementing voice lines and dialogues. While this feature ultimately elevated the game’s polish and player experience, it turned out to be one of the most time-consuming tasks of the entire production.
We initially assumed it would be a quick process record a few lines, pick the best takes, and drop them into the game. But what we didn’t account for was the time needed to direct each voice line to match the intended tone and emotion. As the writer, I knew how the dialogue should sound, but the actors needed clear direction and context to deliver the performances we envisioned. This meant explaining character motivations, adjusting delivery, and re-recording multiple takes until we got it right.
Once recording was complete, editing and preparing the audio files for integration into our web-based build took additional effort. After several intense hours of refining and testing, we finally implemented the voice lines and while it significantly enhanced the overall experience, it also consumed a major portion of our production time.
The other major issue, as I mentioned earlier, was crunch. While working on this game, we genuinely enjoyed the creative process, but at the same time, we were also fueling our progress with midnight energy as the submission deadline drew closer.
Over the course of three days, we got very little sleep and kept pushing ourselves to get the game across the finish line. It was exhausting, but it also tested our endurance and determination to their absolute limits.
Crunch
Post Launch
After a well-deserved rest and recovery from the Game Jam, we decided to continue developing AirBorne beyond the initial submission. Even though the competition had ended, our team felt that the project still had more potential to explore. So, we regrouped and pushed one final update that included six new characters added to the passenger roster, each with their own unique attributes and voice lines to further enrich the gameplay experience.
In addition to expanding the character pool, we also updated several art assets and refined the game’s overall presentation. This included polishing UI elements, enhancing the readability of stats, and improving the color palette to make the world feel more cohesive and visually appealing.
This post-jam update was our way of celebrating the hard work we had put into the project and making sure the final version of AirBorne was something we could proudly share with others.
Click on one of the images to view the next project
Gallery
Some of the assets I created while working on this game.
Cities

City 1 : Brasshaven

City 2 : Ironweld

City 3 : Gearsport

City 4: Copperfell

City 5: Aetherforge
Maps and Journal

Journal First Page

Journal Second Page

Map








