Rogule: Tales From the Dungeon of a Web Based Rogulelike

Rate this content
Bookmark

Rogule is an emoji based open source online roguelike game that started life as a 7DRL game jam entry. It has now grown to around 1,500 games per day. In this talk I'll cover the weird tech (ClojureScript), the motivation, game mechanics, and the future of Rogule.

19 min
28 Sep, 2023

AI Generated Video Summary

Chris McCormick, an independent software developer, discusses his latest game Rogl, a minimalist online roguelike game. He shares the story of how Rogl gained popularity and emphasizes the importance of marketing and giving your creations a chance. McCormick highlights the value of frugality and underengineering, as well as the power of finding the best tech for efficiency. He explains why ClojureScript is the best tech for him and discusses deployment strategies using Piku. Overall, the talk emphasizes the importance of informing people about your project, prioritizing fast development, and user feedback.

1. Introduction to Rogl

Short description:

My name is Chris McCormick, an independent software developer. I've been making web-based games, and today I'm here to talk about my latest game, Rogl. It's a minimalist online roguelike game played in the browser. The game features turn-based strategic gameplay, grid-based movement, and permanent death of the player character.

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.

2. The Story of Roguel

Short description:

Roguel is a different kind of roguelike game with emojis, fast gameplay, and a simple user experience. It started as a seven-day project inspired by Wordle and gained popularity after being shared on the web game subreddit, attracting 135,000 players. The first takeaway from this talk is that sometimes even good projects may not gain traction online, but it's still valid to build something you personally want.

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.

3. Marketing and Giving Your Creations a Chance

Short description:

Fundamentally, I built Roguel to address the problem of the right people not hearing about it. It's important to give your creations a chance by telling the people who might need them about it. Marketing is simply about informing people, not in a spammy or annoying way, but to those who may be interested. If you've done that and still nobody wants it, it's okay to move on, but at least give it a chance.

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.

4. Frugality and Underengineering

Short description:

Frugality is important when it comes to our own time. Roguel, with 130,000 games played over two days, runs on a single cheap digital ocean BPS. I build things small and fast to see what sticks. Ruthlessly minimalizing features and participating in game jams are strategies for frugality.

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.

5. Building Strategies and Frugality

Short description:

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.

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.

6. Finding the Best Tech for Efficiency

Short description:

The meme that the tech doesn't matter is quite controversial. While it's true that you can build anything with the tech you already know, investing time in finding the best tech for you can save you time and avoid unnecessary complexity. The key is to find tech that lets you move fast.

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.

7. The Power of ClojureScript

Short description:

The best tech for me is ClojureScript. Despite its initial challenges with Lisp syntax and immutability, I found that after a few weeks of building in this language, I was able to move much faster than before. Compared to PHP, Python, and JavaScript, ClojureScript was significantly faster, allowing me to even build my own web framework. The cost of building and maintaining my own ClojureScript web framework is lower than using Python and Django. ClojureScript is the best tech for me to move fast.

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.

8. ClojureScript: Speed and Deployment

Short description:

ClojureScript is faster due to its Lisp syntax, restricted mutation, and emphasis on live reloading. The browser provides free graphics, fonts, sound, input, networking, and easy access. Reusing assets, game mechanics, and code in ClosureScript makes development faster. Deployment to a single VPS can be a pain due to configuration and dependency installation.

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.

9. Using Piku as a Cost-effective Solution

Short description:

If your project becomes successful, using a platform as a service like Netlify can become expensive. That's why I recommend using Piku, an open source platform as a service that you can run on your own server. It's fast, light, and easy to use. I'm a core contributor to Piku and I also provide a service to provision and maintain Piku VPS boxes.

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.

10. Deployment, Maintenance, and Low-Cost Strategies

Short description:

One way to ease deployment is to run SQLite in production, which requires no setup and eliminates the need for a separate database server. Maintenance can be kept low-cost by leaving what works working and focusing on fixing bugs and adding new features at your own pace. Making the app front-end heavy and performing client-side computation can also reduce maintenance costs. In summary, it's important to inform people about your project and prioritize fast development and user feedback.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

JS GameDev Summit 2022JS GameDev Summit 2022
33 min
Building Fun Experiments with WebXR & Babylon.js
During this session, we’ll see a couple of demos of what you can do using WebXR, with Babylon.js. From VR audio experiments, to casual gaming in VR on an arcade machine up to more serious usage to create new ways of collaboration using either AR or VR, you should have a pretty good understanding of what you can do today.
Check the article as well to see the full content including code samples: article. 
React Summit 2023React Summit 2023
32 min
How Not to Build a Video Game
In this talk we'll delve into the art of creating something meaningful and fulfilling. Through the lens of my own journey of rediscovering my passion for coding and building a video game from the ground up with JavaScript and React, we will explore the trade-offs between easy solutions and fast performance. You will gain valuable insights into rapid prototyping, test infrastructure, and a range of CSS tricks that can be applied to both game development and your day-to-day work.

Workshops on related topic

JSNation 2023JSNation 2023
116 min
Make a Game With PlayCanvas in 2 Hours
Featured WorkshopFree
In this workshop, we’ll build a game using the PlayCanvas WebGL engine from start to finish. From development to publishing, we’ll cover the most crucial features such as scripting, UI creation and much more.
Table of the content:- Introduction- Intro to PlayCanvas- What we will be building- Adding a character model and animation- Making the character move with scripts- 'Fake' running- Adding obstacles- Detecting collisions- Adding a score counter- Game over and restarting- Wrap up!- Questions
Workshop levelFamiliarity with game engines and game development aspects is recommended, but not required.
JS GameDev Summit 2022JS GameDev Summit 2022
121 min
PlayCanvas End-to-End : the quick version
WorkshopFree
In this workshop, we’ll build a complete game using the PlayCanvas engine while learning the best practices for project management. From development to publishing, we’ll cover the most crucial features such as asset management, scripting, audio, debugging, and much more.
Node Congress 2023Node Congress 2023
85 min
Node.js: Landing your first Open Source contribution & how the Node.js project works
Workshop
This workshop aims to give you an introductory module on the general aspects of Open Source. Follow Claudio Wunder from the OpenJS Foundation to guide you on how the governance model of Node.js work, how high-level decisions are made, and how to land your very first contribution. At the end of the workshop, you'll have a general understanding of all the kinds of work that the Node.js project does (From Bug triage to deciding the Next-10 years of Node.js) and how you can be part of the bigger picture of the JavaScript ecosystem.

The following technologies and soft skills might be needed):
  - Basic understanding of Git & GitHub interface
  - Professional/Intermediate English knowledge for communication and for allowing you to contribute to the Node.js org (As all contributions require communication within GitHub Issues/PRs)
  - The workshop requires you to have a computer (Otherwise, it becomes difficult to collaborate, but tablets are also OK) with an IDE setup, and we recommend VS Code and we recommend the GitHub Pull Requests & Issues Extension for collaborating with Issues and Pull Requests straight from the IDE.

The following themes will be covered during the workshop:
- A recap of some of GitHub UI features, such as GitHub projects and GitHub Issues
- We will cover the basics of Open Source and go through Open Source Guide
- We will recap Markdown
- We will cover Open Source governance and how the Node.js project works and talk about the OpenJS Foundation
  - Including all the ways one might contribute to the Node.js project and how their contributions can be valued
- During this Workshop, we will cover Issues from the nodejs/nodejs.dev as most of them are entry-level and do not require C++ or deep technical knowledge of Node.js.
  - Having that said, we still recommend enthusiast attendees that want to challenge themselves to "Good First Issues" from the nodejs/node (core repository) if they wish.
  - We're going to allow each attendee to choose an issue or to sit together with other attendees and tackle issues together with Pair Programming through VS Code Live Share feature
    - We can also do Zoom breakrooms for people that want to collaborate together
  - Claudio will be there to give support to all attendees and, of course, answer any questions regarding Issues and technical challenges they might face
  - The technologies used within nodejs/nodejs.dev are React/JSX, Markdown, MDX and Gatsby. (No need any knowledge of Gatsby, as most of the issues are platform agnostic)
- By the end of the Workshop, we'll collect all (make a list) the contributors who successfully opened a Pull Request (even if it's a draft) and recognise their participation on Social media.
JS GameDev Summit 2022JS GameDev Summit 2022
86 min
Introduction to WebXR with Babylon.js
Workshop
In this workshop, we'll introduce you to the core concepts of building Mixed Reality experiences with WebXR and Balon.js.
You'll learn the following:- How to add 3D mesh objects and buttons to a scene- How to use procedural textures- How to add actions to objects- How to take advantage of the default Cross Reality (XR) experience- How to add physics to a scene
For the first project in this workshop, you'll create an interactive Mixed Reality experience that'll display basketball player stats to fans and coaches. For the second project in this workshop, you'll create a voice activated WebXR app using Balon.js and Azure Speech-to-Text. You'll then deploy the web app using Static Website Hosting provided Azure Blob Storage.