Rogule: Tales From the Dungeon of a Web Based Rogulelike

My name is Chris McCormick, and I'm an independent software developer. I've been working freelance most of my life, and recently I've been building online micro businesses. I also like making games and procedurally generated music and music apps.

Today I'm here to talk about Rogl. The first computer program I ever wrote was a turn-based game of catch on the Apple IIe in 1980 something. I was about eight years old and I soon discovered I liked making games more than I liked playing them, so I kept making games. And today I make web-based games.

Rogl's my latest game and that's what I'm here to talk about today. It's a minimalist online roguelike game you play in your browser. You play an elf moving around a dungeon, hacking at monsters, picking up items, and you try to find a shrine so you can ascend. Everyone gets the same dungeon each day and you get one chance to be each day's dungeon. There have been about 350,000 roguelike games played since 2022 and about 1,000 to 2,000 games are played every day. If you search for the roguel hashtag on social media you'll probably see people sharing their games.

I've been playing roguelikes since the Intel 286 was a fast computer. The word roguelike comes from the game Rogue which was released in 1980. It's a dungeon crawl through procedurally generated levels with turn-based gameplay, grid-based movement and permanent death of the player character. These days many games have entered the roguelike genre and its meaning has become diluted. For me these features are what make roguelikes great and my game Roguel sticks with them. Turn-based strategic gameplay is particularly important. It gives you space to think and removes the stress of having to act for a calmer game experience.

There are a couple of things that make roguelike different from traditional roguelikes. The first obvious thing is the emojis and it's a fast game with most sessions lasting around one minute. Secondly it doesn't have any inventory management. All items you pick up are used automatically. Thirdly it only has one level and there's no descending deeper into the dungeon. The depth and complexity of roguelikes is exchanged for fast user friendly sessions. I think this, as well as being web-based, is what makes it accessible to wider audiences.

I also spent quite a lot of time making the user experience super simple. Roguel started life in a seven day roguelike jam in early 2022. I had been thinking about making an emoji-based roguelike for a while. Around that time I heard a great interview with the Wordle creator Josh Wardle. I started thinking about how to apply some of the principles from Wordle to a roguelike game. So I built the game in one week for 70 RL. And when it was done, I was fairly satisfied with what I'd built. It was fun to play, had a win condition, a lose condition, and a little social media shareable at the end of the game. After release I put the game online and it had about 30 regular players per day. People even shared the game logs so that was pretty nice.

Fast forward about 1 year during which I changed very little about Roguel. About 30 people a day were still playing it and not much else had happened. Then one day I discovered the web game subreddit. I thought this is pretty cool, I guess I'll post about Roguel there. So I put it up and I went to sleep. Over the next couple of days, 135,000 people played Roguel. It hit number 1 on Hacker News, the Github Twitter account re-tweeted it, it got written up in a popular Japanese online magazine, all of which was quite surprising. None of that would have happened if I hadn't shared it on reddit web games. So I think this is the first takeaway from my talk. All of us have had that experience of making something we think is pretty good and then we put it online and it seems like the world just doesn't really want it. Well there are 2 possible reasons why that happens. The first reason is if your thing sucks or it sucks for everybody except you, which is fine. Building something because you only want it is a perfectly valid reason to build something.

Fundamentally, that's why I built Roguel. And not everything has to be popular. But the second reason, the second possible reason is the important one for geeks like us, which is that maybe nobody heard about it or the right people didn't hear about it. So the right people to hear about it are the people who need the thing that you've made but don't yet know it exists. If you want to give the things you make a chance, it's really important that the people who might need them get to see them. If they never see it, they're never going to know it exists and they'll never use it. I think geeks tend to assume our thing fails because it sucks, when often the second reason is why it doesn't work out. The right people never learned about it. So Roguel taught me this lesson in a really obvious way, because it was the perfect experiment in marketing. It sat there for one year unchanged and then as soon as I did some low key marketing, it gave it a chance. It blew up. So what is marketing? It's basically just telling people about what you've made. So not in a spammy way or an annoying way or a way where you're telling people who don't care, but you find the people who you think it's for and you tell them about it. And at the very minimum, you have to give your thing a chance to thrive. If you tell the right people about it and still nobody wants it, then that's cool. You can let go and move on. But now you should at least give it a chance.

Okay, so that's the first takeaway from my talk. My second point is about frugality and underengineering. Frugality is the quality of being frugal, sparing, thrifty, prudent, or economical in the consumption of resources, such as food, time, or money. And avoiding waste, lavishness, or extravagance. So what's the most valuable thing we have as human beings? It's our time. So for me, frugality is most important when it comes to our own time.

If you recall earlier, I said Roguel had 130,000 games played over two days. The number of individual requests hitting the server went into the millions, and it had zero downtime during that period. So you might be surprised to learn it doesn't run on any kind of auto-scaling platform. It doesn't have a Kubernetes cluster, it doesn't use Docker images, and it doesn't even have a CDN. It might surprise you to learn it runs on a single cheap digital ocean BPS. Maybe even more surprising is that I have around 30 apps running on that $12 a month BPS. And like Roguel, some of those web apps also get tens of thousands of visitors per month. Like Roguel, most of those web apps also run SQLite in production.

So I mean, I build a lot of stuff because I like to experiment with different ideas. My basic development strategy is to build things small and fast and get them online, get them in front of people and see what sticks. To do this, I have to run things exceptionally cheaply because most things fail. So now I'm going to tell you about my tech stuff and how I run things cheaply. The first part is low cost during the development phase. When I have an idea, I don't want to spend months or years seeing if it's any good. Because that wastes precious time. I want to know as soon as possible. So I build things cheaply using four basic strategies. Strategy number one is ruthlessly minimalizing features. So engineers love complexity, but it's really the enemy. You need to stop and ask yourself which of my zero users actually wants this feature. Chop away literally everything that's, until all that's left, is the core mechanic or the one thing that the Apple game is supposed to do. There are all kinds of things I could have added to Robo, but I didn't. And I think that allowed me to actually ship it. So of course game jams are a great way to train yourself in frugality.

A game jam is the perfect frugality dojo. My second strategy is to build by myself. Some people are good at working in a team, but I've always found it holds me back. Communication naturally adds friction. Having to check technical or artistic decisions with someone else slows the process down. I don't think this is a hard and fast rule. Some people have great partnerships with lots of trust and understanding. I've done game jams with friends before and it's fun. I think if you find the right people who understand how to build things and work well together, then it's possible to team up. For me it's always been easy to build faster by myself.

So my third strategy for building as frugally, is probably quite controversial. There's this meme in there that the tech doesn't matter. Just use what you know. You can build anything with any tech and this is true with the famous example being Peter Levels building his million-dollar startups with PHP and JQuery. So it's true that you can build anything with whatever tech you already know. Especially if you're a marketing genius like Peter. But I'm here to say that you can also waste less time if you invest some time finding the best tech for you. I don't mean the best tech for Silicon Valley startups or the best tech for nerds on Hack News, or even the most complicated latest extravagance, somebody uploaded to NBN. What I mean is finding the best tech that lets you move fast. So don't stack the odds against yourself by using tech that slows you down. Avoid complexity at all costs.

So for me, the best tech happens to be ClojureScript. I was introduced to Clojure by a friend of mine during a game jam a few years ago. And at first I found it quite challenging. The Lisp syntax was different from anything I'd coded before. The immutability was weird and restrictive. The functional programming I liked, but it was pretty hardcore. What happened was I found after a few weeks building in this language, I was moving much faster than before. Because I like to build a lot of things, this was very impressive. So, you know, I've used PHP and Python and JavaScript in production for decades. But ClojureScript, by comparison, was so much faster than all of them that I could even build my own web framework, so I didn't have to use Django and Python anymore. I never would have attempted building my own web framework in a different language. The cost of building and maintaining my own ClojureScript web framework turns out to be lower than sticking with Python and Django. So ClojureScript's the best tech for me to move fast.

So what makes ClojureScript faster? First of all is the Lisp syntax. Because your text editor understands the syntax it's able to help you manipulate and refactor code much faster. So you can use single keystrokes to move code around and because there's way less syntax and boilerplate altogether it's faster because you write less bugs.

Mutation is restricted in the language and you must write in a very functional style, which inherently leads to less bugs. It's faster because the Clojure community places a high emphasis on live reloading and interactive development. The tooling allows you to hot reload code on a function level. Practically speaking that means when you write a game like Roguel I really have to hit refresh. If I update the AI of a monster, the monster simply changes their behaviour at that moment in time. I don't have to reload the page and recreate the game state to test change. The state and the page remain the same and only the monster behaviour updates.

So the best tech for me is also the browser. I know everyone is using Unity to build games but you get so much for free in the browser. You get graphics, fonts, sound, input, networking, easy access for users, simple updates, and platform portability all for free. The dev console is amazing. You can attach data to a DOM element, hit inspect and see in real-time what is going on with your game entity. I love working in the browser and I guess that's why we're all at this conference so I don't need to convince you of that.

Finally, to build faster try to reuse existing assets, game mechanics and code wherever I can. ClosureScript makes code reuse particularly easy. The functional nature and editor integration mean I can copy and paste functions and behaviours and they just work in my new code base because functional code can be largely context-free. I used the emoji graphics and this asset repurposing took away a huge part of what's time-consuming about game jams. I also leaned on online fonts, free open source online fonts. I reused game mechanics because I've built a few roguelikes in the past. I was able to really hone in on the core roguelike game mechanics by copying my previous games and reading the source code of other games. If I tried to invent a completely new game mechanic from scratch the project would have taken much longer.

So that's the building part of frugal development. Cut features, minimize team size, use the best tech for you to move fast and reuse assets code in game mechanics. The second part of frugal development is the deployment story. So I told you about how I run everything on one VPS. Well everybody knows deploying to your own VPS is a pain. You always have to spend ages making nginx configs and sorting out SSL certificates and installing dependencies.

And all that sometimes you have to do this every time you push a change. Sure you could use Netlify or another platform as a service and that's a great solution if you want to move fast but what if your thing blows up like Rogal and some of my other projects you have you get those big AWS or firebase bills or Netlify bills and hosting starts to get very expensive especially when you're talking about running like 30 prototype apps.

So I was lucky enough to find Piku a few years back. Piku is made by a guy called Rui Kamo. It's an open source platform as a service that you run on your own bps. It's like a pocket heroku where you have root. It's fast and light and the source code is super simple. I deploy all my apps with it. Installing Piku is as simple as running one command as root and then it takes care of setting up environments, installing dependencies, provisioning ssl certificates and proxying nginx to your app. Adding a new app is as simple as adding a git remote and all of the deployment etc is accomplished with one simple git push command to deploy just like on Netlify or Heroku. So I'm now a core contributor to Piku so if you need any help with it hit me up. I also run a service provisioning and maintaining Piku VPS boxes so if you or your team are looking for a fully managed private platform as a service where you get your own dedicated VPS you can get in contact at pikuvps.com. I've deployed this for a couple of clients and they really like it.

One other thing to do to ease deployment is run SQLite in production. There's no setup at all and you don't have to keep a separate database server running to examine the live database you can just copy it down to local. Yeah it's very simple to work with. I use a package called KEYV, K-E-Y-V, from npm which sets it up like a no SQL database so you get a key value table. It works like local storage in the browser but on the server side it's very nice.

The third part of frugal development is maintenance. Of course your game will have bugs. If it gets any traction of course people will ask for features. My solution is pretty simple just don't talk to anybody and don't fix anything. My issue tracker is full of tumbleweeds. I mean I'm only kidding but I've done and have done a bit of maintenance on frugal to keep the site healthy but there are actually quite a lot of old bugs in there and people still play it every day. So I think you can go far with just leaving what works working. I'm planning to a dev push soon to go back and fix some of these things and add some new features but I can do it when I'm ready. Because I build and run it cheaply I can do this on my own time and schedule without any kind of urgency to it. I've got forever basically.

The other way to keep maintenance cheap is to make your app front-end heavy. Maybe I'm preaching to the converted here. I generally try to build things completely static so no server is required. If I do need a server side for user accounts or storage I try to make it a dumb authenticated store without much backend logic. So keep everything in the front end. All computation should be client-side because the cheapest compute of all is the user's own compute. If the computation is happening in the browser then you don't have to pay for it. So these are the three ways I keep things low cost. Low cost development by minimizing features and using closed script to develop fast. Low cost deployment by using Pico and SQLLightingprod. Low cost maintenance by going front-end heavy and only changing things at their own pace.

So to summarize the two main points from my talk. Number one is make sure you tell people about what you're building and number two is spend some time figuring out tooling and techniques to move fast and get your ideas in front of users as soon as possible so you can get feedback. All right that's it.