videogame

Runs the day-to-day operations of Residencia Canina Ecocan. A booking calendar with a room-assignment algorithm, client and pet records with medical history, payment tracking, and targeted email campaigns.

The part I find most interesting is the OCR pipeline: staff photograph a client’s ID card or a pet’s vaccination book, and Google Cloud Vision extracts the DNI, microchip number, and vaccine dates automatically instead of someone retyping them.

Firebase handles authentication while Supabase provides the Postgres database with row-level security, and Deno edge functions sync bookings in from Google Forms.

Ember is a young rancher who takes a wrong turn coming home through a dark winter forest. She sees lights between the trees and follows them, thinking they are lanterns. They are will-o’-the-wisps, and they are leading her the wrong way on purpose.

The forest takes pity on her and sends fireflies. They are her light, her tools, and her protection — and if she loses them, the wisps come back for her.

Two hands, two jobs

The central idea is asymmetrical control. Your left hand walks Ember with WASD; your right hand commands the fireflies with the mouse. Left click and they hold position, right click and they come back to you.

That split is what makes the puzzles work. You have to park your light somewhere to solve something, which means walking away from it — and the forest is not safe in the dark. Vikings and snowmen patrol it, and there is a runestone that will only open the way home once you feed it enough fireflies.

What I built

The game is called Lumos and I owned the light. Lighting and colour across every scene were mine, which in a game where light is the mechanic meant tuning readability as much as mood — dark enough to feel lost in, legible enough to solve a puzzle in.

Around that I did the animation work: rigging and animating Ember, then modelling, rigging and animating the enemies, and the boss model alongside Yen-Shuo (Andrew) Hsu. I paired with Ian on enemy AI movement and with Phung and Andrew on firefly behaviour, then implemented both puzzles — one with Ian, one with Andrew — and the boss fight with Andrew. I added the map. The start menu and the end-game screens were mine too.

What playtesting broke

The most useful part of the project was the bug list that came out of playtesting, because most of the gameplay-feel bugs landed on me.

The camera clipped through geometry. Getting hit by a snowman twice launched Ember upward and then dropped her through the floor into the void. The offering runestone would sometimes refuse fireflies even when it wasn’t full. Viking behaviour was erratic. Ember stopped leaving footprints in the new end scene.

And the one that mattered most: testers told us the game was simply confusing. No bug report, no crash — they just didn’t know what they were supposed to do. That became tutorials and tooltips, and it was a better lesson than any of the crashes. A mechanic you find elegant is not the same as a mechanic anyone can read.

I also cut the trailer and the gameplay video, and stripped the unused assets before we shipped.

Built with Firefly Rancher — Andrew, Winnie, Phung, Ian, and me.

Early work in progress. Playable systems, one real zone, no game around them yet.

You are alone in a frozen open world and five things are trying to kill you at once: hunger, thirst, cold, exhaustion, and whatever those add up to in your health bar. You scavenge, you find shelter, and you piece the story together from documents you find lying around.

Everything drains

Every survival stat inherits from one base class that handles draining, a critical threshold, and the events that fire when you cross it. What each stat does with that is its own business — warmth is multiplied by weather and reduced by shelter, fatigue slows you down and locks out sprinting and puts a sway on the camera, and health drains steadily for each other stat currently in the red.

That last one is the design in miniature. Nothing kills you directly. Being cold does not kill you; being cold while thirsty and exhausted does.

Nothing knows about anything else

Systems never hold references to each other. They talk through a static event bus — subscribe on enable, unsubscribe on disable — so the HUD does not know the survival system exists, and the shelter zone does not know what warmth is.

That decision is doing a lot of work as the project grows. Adding a status effect or a new interactable does not mean touching anything that already works.

Tested, because I could not tell otherwise

There are 64 test files across EditMode and PlayMode, and CI runs both on every pull request through game-ci.

The reason is practical rather than principled. Survival balance is invisible — a drain rate that is slightly wrong feels fine for ten minutes and ruins the game at forty. Tests are how I find out I broke the pacing without playing for forty minutes.

Where it actually is

Movement, interaction, all five survival stats, status effects, save and load, readable documents, the journal, and one built zone: the bunker. Inventory and skill trees are next.

A free, deliberately simple way to keep a record of the films you have seen — when you saw them, who you saw them with, which actors you keep coming back to.

Written in Flutter so one codebase covers iOS, Android, web, and desktop, with Firebase behind it for storage and cloud functions.

Oscars data is the kind of thing that sounds easy to get hold of and isn’t. This is a free, public API that serves it, so anyone building something that needs award history can query it instead of scraping for it.

Built on Firebase — Cloud Functions for the API surface, Firestore for storage, and Firebase Hosting to serve it.

People with congestive heart failure retain fluid when their condition worsens, and a sudden jump in weight is often the first warning sign. Catching it early can prevent a hospital visit.

Patients log their weight each day on a mobile app. Providers get a dashboard of everyone under their care, and an alert the moment someone crosses a danger threshold — which can be tuned per patient, since “normal” differs from person to person. Alerts deliberately carry no personal information; they just tell the provider to go look.

Three codebases: a Django REST API on Elastic Beanstalk, a React Native patient app, and a React and TypeScript provider dashboard. I worked across all three and wrote about 38% of the commits.

Talking to the scale

The part I like most is the Bluetooth integration, because asking a heart failure patient to type a number every morning is exactly the step they will skip.

The app scans for BLE devices, connects to the scale, and subscribes to the characteristic it broadcasts readings on. The weight arrives as raw bytes — a sixteen-bit integer that has to be pulled out of the payload and divided by a hundred to get kilograms, then converted if the patient prefers pounds.

Android made it harder than the parsing did. Version 31 replaced the old location permission with separate scan and connect permissions, so the app has to branch on OS version before it can even look for a device.

Knowing when to worry

The alerting runs server-side. When a reading lands, the API compares it against that patient’s configured threshold, writes a notification record, emails the provider, and sends an SMS through Twilio if they have text alerts on.

Getting the content right mattered more than the plumbing. The message says enough to make someone act — how much the weight moved, and when — without putting patient details in an inbox or a text message.

I also built the email verification flow that gates provider accounts, and an export that bundles a patient’s records into three CSVs in a zip, since the people using this need their data somewhere other than our database.

Built with Jonathan Hopkins, Duy Nguyen, and Nate Fritchley.

Our entry for the Google Solution Challenge 2023. You collect creatures by photographing real plants — the game runs the photo through a plant recognition API, identifies the species, and rewards you for it. Quests exist to get children outside and looking at things.

I built two scenes: the Avatar Activity screen and the Village level, plus the navigation between them. A smaller slice of this one than the rest — most of the gameplay and the API work was Yen-Shuo (Andrew) Hsu and Robin Kim.

Worth noting what the team found when it was tested with thirty students: about eighty percent said it made them want to photograph plants, ninety percent would read about a plant to earn a reward, and sixty percent said they would go outside more because of it. For a game whose entire premise is “get kids to look at plants”, that is the number that matters.

Built with Robin Kim, Sindy Aum, and Andrew.

Our entry for the IBM Call for Code, Fall 2022. You tell it the size of your bed and your zip code, and it works out what will grow there and what should be planted next to what. Plant hardiness zones come from the USDA API, so the suggestions match your actual climate rather than a generic calendar.

I built the front end.

Drawing a garden

The core screen is a canvas editor. You draw your beds directly — rectangles you can size and move — and the app reads the dimensions back out of the canvas into the form, so the two stay in step whichever one you touch.

That two-way sync was the fiddly part. A canvas library and a set of form inputs each want to own the truth about how big a bed is, and reconciling them is more work than either alone.

Around it sits the multi-step flow for creating a garden, the sidebar that switches between beds, seeds and the planting calendar, and the layout and icon set the whole app uses.

Built with Phil Daum and Yen-Shuo (Andrew) Hsu.

Our entry for the Google Solution Challenge 2022. Hygea has two halves: a Flutter app for elderly patients with emergency calling, voice-controlled appointments and medication reminders, and a web dashboard for the doctors looking after them. Firebase sits between the two.

I built the doctor’s side.

Prescribing is a scheduling problem

The interesting part was medication. A doctor does not prescribe “a pill” — they prescribe something like twice daily on weekdays for three weeks, and the patient’s app has to turn that into the right reminder on the right morning.

So the dashboard stores prescriptions as recurrence rules — frequency, interval, which weekdays, how many repeats — rather than as a list of dates. The patient app reads the rule and works out the schedule itself. Writing that meant writing the parser too, so a doctor editing an existing prescription sees it back in plain language instead of the encoded form.

The rest is what you would expect: Firebase auth, creating patients, booking appointments, and a list showing at a glance who is doing fine and who needs attention.

Built with Yen-Shuo (Andrew) Hsu.

A native Windows app for managing a local film collection. SQLite keeps everything offline and fast, and TMDb fills in posters and cast when you want it to.

It watches folders for new files, handles moves and renames atomically, and launches a film in your default player. The point was that it should keep working with no network at all — the metadata is a bonus, not a dependency.