Hi! I’m Jose,

And I’ve spent a small portion of the last couple of years creating a browser-based RPG game from scratch. The goal of this blog post is to reflect on that journey and share some of the fun and challenges I encountered along the way.

First of all, the main purpose of this project was therapeutic. You know, I’m a natural-born programmer who turned into a co-founder & executive at a couple of startups (and did some time in corporate after a few exits). I was lucky enough to co-found a successful startup more than a decade ago. Anyway, while I do enjoy my daily job and still get some fulfillment from it, I feel the urge to code, to create. There’s a lot of seasonal programming I enjoy (hello, adventofcode.com), but I was looking for something more substantial / permanent. So, in addition to my quite demanding day job, family, and kids, I started developing a rather simple 2D game engine—and a sandbox game to go with it. I always wanted to create a pixel-graphics game full of exploration, puzzles and various encounters.

Note: In case you’re wondering—yes, the main purpose was achieved. I was able to relax my brain from the daily work-life in a way I find fulfilling (regardless of the actual quality of the result). More times than I can remember, I re-experienced that magical feeling of all the cogwheels clicking into place, making the next implementation or game mechanic feel like a natural progression that practically wrote itself. ❤️

Risk #1: Not using an off-the-shelf engine

Why did I choose not to use one? To have real fun! I enjoy deep-level coding as much as I can get. Writing the inner workings of the rendering and game engine sounded like a lot of fun—and it was!

I never planned to open-source the engine or reuse it for another project (althought that would be a nice bonus). That said, I still wanted it to be functional and not waste too much resources unnecessarily. It’s a pixel-art game, FFS—it should run almost everywhere these days! The resulting rendering engine is not anywhere close to computation resource intensity levels of comparable off-the-shelf engines, optimization-wise. But it gets the job done.

Note: I partially failed on this one. While the game runs fine on 10-year-old hardware I had access to, I gave up on making it accessible/playable on tablets or phones—mainly due to unoptimized GUI requirements. Yes, I’ve learnt that creating good GUI is hard (surprise surprise).

Would I do it again? I hope I wouldn’t! (More on that in #3.)

Risk #2: Sticking to Web/JS

Most of my happy coding experiments happen in JavaScript these days. That said, I’ve gone through (and still love) a bunch of technologies—from 8086 Assembly to Free Pascal and C/C++. So the natural decision was: let’s stick to what I’m actively using.

Mitigation strategy: Transfer.

Know your limits—and the limits of the tech. The engine won’t have multi-colored lighting. (Not that it wouldn’t be possible—it’s just a bit too painful to implement in the current codebase.)

Risk #3: 30-minute focus intervals are good enough for everything

Nope, they are not. Juggling kids, work, and life creates a demanding environment, and focus intervals longer than 30 minutes are rare—or come at a cost. I’m not completely naïve—I’d be lying if I said I believed those short intervals would be enough.

Mitigation strategy: Accept.

Plan accordingly. I like to think I’m relatively good at this (the world doesn’t object too often), but still—this part sucked the most. And it affected everything else (surprise surprise). During those 30-minute intervals, I had to design, draft, architect, implement and test numerous internal systems for the engine and game. Here’s a non-comprehensive list:

• Canvas rendering of multi-layered, tile-based graphics
• Physics (the engine is pseudo-3D—it has a notion of height in addition to the x/y axis; levels are vertical, too)
• Resource manager
• State manager, save/load system
• Animation engine
• Particle engine
• Lighting system
• Map editor
• Data adapters for world/game saves (using the fantastic localforage and fflate to save some headaches)
• NPC intelligence / behavior modes, daily routines
• Factions and Reputation system
• User interface, game menus
• Dialogue system
• Quest engine
• Scripting engine and event system to make the game world interconnected and reactive
• Schedule system
• RPG systems: character attributes, skills, derived stats, armor, weapons, damage types, combat, …
• Crafting: recipes/blueprints, materials, resource gathering & processing
• Sound system (j/k—I used Howler, because doing it myself seemed a bit too much hustle)
• …

Note: Even after implementing all that, you still don’t have an actual game—just some of the means and methods to make one.

Also, prepare to suffer. The architecture of the whole beast is far from ideal, and rewrites/refactors had to fit into 30-minute windows. It is what it is, and the result is very far from a well-designed, safe application. Still, I’m proud of some subsystem designs.

BTW did you know, that even in 2025, if one wants to have a perfect pixel-art font on the JS canvas, one has to render it “by hand” (meaning draw it glyph-by-glyph, deal with … pretty much everything)? It caught me by surprise!

Risk #4: Open-source (CC-x) graphics will take you all the way

Nope, they won’t. Despite the appearance of completeness in many asset sets (I’m talking LPC here), there will always be something missing—maybe minor, but crucial for you. Or something won’t be up to the same quality as the rest. This isn’t a rant at all—I think LPC is a wonderful asset library, and I deeply respect every contributor. Just don’t forget: at some points, you’ll either have to commission custom art or try creating it yourself.

Mitigation strategy: Reduce.

Be clever with your graphical assets—combine them, remix them, use generated graphics where you can. Think twice before mixing asset libraries—they might not mesh well stylistically.

Note: At the time of writing this, state-of-the-art LLM-based image generators still can’t properly grasp pixel art.

Some questions you might have

1. Is the resulting game a good one?
   1. Well, not sure. Some limited playtest was executed with relatively positive results. Up to you!
2. Is the game even finished?
   1. Its part is, and there is a meaningful end to it. I would call it Alpha release. Approx. 7-8 hours of content. Some of it quite challenging..
3. So why did you bother releasing it?
   1. I firmly believe that by completing the whole cycle one learns even more. Should I just shelve the project, I wouldn’t need to force myself to figure out what I would consider a finish line and achieving it. Also, I do believe there will be people enjoying the experience.
4. Shouldn’t you test more during the early stages / prototype more / test the mechanics more?
   1. Definitely; I wholeheartedly recommend testing early prototypes and all that jazz. The actual main goal matters though; mine was not to necessarily release a successful game.