nyaomaru

Posted on Mar 18

I Built a “Run Away From Work” Browser Game with React and TypeScript

#gamedev #webdev #react #typescript

Click Game Button 👇

Hi there!

I’m @nyaomaru, a frontend engineer who got a cold after getting way too excited about spring and spending too much time in the sun. ☀️

Thanks to AI, we can get work done faster than ever and handle a huge number of tasks in parallel.

But at the same time… dealing with more and more work can get exhausting, right? 😿

So I made a small browser game about running away from work as a little break.

Here’s what it looks like 👇

👉 Play here

It runs in the browser, so you can play it on both desktop and mobile.

It takes about 1 minute to play.

Hope it gives you a small break 🙏

🎮 How to play

The controls are simple.

On desktop, press Space or Click to jump.

On mobile, just Tap.

You can even double jump, so try to dodge everything nicely.

Action	Description
Space / Click	Jump
Tap	Jump
Double Jump	Jump once more in the air

🐟 If you collect fish, something good might happen... maybe!!!???

🤔 Why I made this

There were two main reasons:

I wanted to study UI/UX
I wanted to see how far I could go using the technologies I’m already good at

I’m planning to get more serious about game development with Unity in the future, but before that, I wanted to try making a browser game with my current stack: React × TypeScript.

Also, do you know Google’s 404 Dinosaur T-Rex Game?

I’ve always liked how simple and fun it is.

That made me want to build my own fun little runner game.

That’s basically it.

⚙️ How I built it

I had previously built my portfolio with Remix × FSD, so this game was made as an extension of that idea.

https://dev.to/nyaomaru/building-a-portfolio-site-with-fsd-langchain-remix-ai-c9h

So the stack is basically:

Remix
React
TypeScript
FSD

Why this structure?

Games tend to have a lot of state, so I wanted to test how far I could manage things with hooks
I wanted the codebase to stay type-safe and maintainable
I wanted to test the scalability of FSD
I wanted to include it in my portfolio

I’ll probably write another article later about the detailed implementation, but these were my main impressions after building it:

FSD helped me clearly separate UI and model responsibilities
- That made it easier to add new features without affecting existing ones too much
I used is-kit to build user-defined type guards in a type-safe way
- Adding tests made the code more robust
Extracting magic numbers into constants made debugging much easier
- Separating config and constants helped me tune game-related values much more comfortably

By the way, is-kit is a small utility library for building type guards more easily. Feel free to check it out 😸

https://github.com/nyaomaru/is-kit

https://dev.to/nyaomaru/building-type-guards-like-lego-blocks-making-reusable-logic-with-is-kit-48e4

🤖 What it was like building a game with AI

In my daily work I usually use Claude Code, but for this experiment I decided to try building the game with codex.

While working on a browser game, I got the impression that this kind of UI is still pretty tricky for AI.

What was difficult 😅

For example:

When I asked it to create CSS animations, the result was often completely off
It couldn’t really think through things like hit detection
Sometimes the visual motion created through DOM manipulation did not match what I actually wanted

So I had to move forward while debugging and adjusting things manually.

In many cases, I could fix things by giving more specific instructions.

But for CSS animation and collision-related behavior, I often had to tweak things myself while watching how the game actually moved.

Because of that, my impression was:

it’s still difficult to leave UI/UX entirely to generative AI, especially when the interface is unusual.

Of course, for something like a standard CRUD UI, AI can already do a decent job because there are many common patterns. In real-world work, I usually don’t struggle that much. And if there’s already a mockup in Figma, the output can be quite accurate.

But for games or unfamiliar UI/UX, human adjustment is still very necessary.

That said, AI is evolving at absurd speed — faster than bamboo shoots grow.

So who knows what it’ll look like soon.

What worked well 🙌

Because this was a more unusual implementation, I tried to help codex learn from previous mistakes ahead of time.

To do that, I prepared a learn skill, along with AGENTS.md and LEARNED_INDEX.md so it could keep referring back to what had already gone wrong and how it had been fixed.

During development, whenever an instruction didn’t work well, I extracted the lesson and saved it into files. Then I made AGENTS.md load those references.

LEARNED_INDEX.md worked as a summary of those learned notes.

.codex/
  skills/
    learn/
      learned/
        xxx.md       # learned notes are stored here
        yyy.md
        zzz.md
    LEARNED_INDEX.md # index for referencing files under learned
    SKILL.md         # a skill for summarizing what went wrong in the session

This structure turned out to be really helpful for preserving instructions that normally wouldn’t appear in everyday development.

For example, things like: