Grumpy Gamer

I think 2026 is the year of Linux for me. I know I’ve said this before, but it feels like Apple has lost it’s way. Liquid Glass is the last straw plus their draconian desire to lock everything down gives me moral pause. It is only a matter of time before we can’t run software on the Mac that wasn’t purchased from the App Store.

I use Linux on my servers so I am comfortable using it, just not in a desktop environment.

Some things I worry about:

1. A really good C++ IDE. I get a lot of advice for C++ IDEs from people who only use them now and then or just to compile, but don’t live in them all day and need to visually step into code and even ASM. I worry about CLion but am willing to give it a good try. Please don’t suggest an IDE unless you use them for hardcore C++ debugging.

2. I will still make Mac versions of my games and code signing might be a problem. I’ll have to look, but I don’t think you can do it without a Mac. I can’t do that on a CI machine because for my pipeline the CI machine only compiles the code. The .app is built locally and that is where the code signing happens. I don’t want to spin up a CI machine to make changes when the engine didn’t change. My build pipeline is a running bash script, I don’t want to be hoping between machines just to do a build (which I can do 3 or 4 times a day)

3. The only monitor I have is a Mac Studio monitor. I assume I can plug a Linux machine to it, but I worry about the webcam. It wouldn’t surprise me if Apple made it Mac only.

4. The only keyboard I have is a Mac keyboard, I really like the keyboard especially how I can unlock the computer with the touch of my finger. I assume something like this exist for Linux.

5. I have an iPhone but I only connect it to the computer to charge it. So not an issue.

6. I worry about drivers for sound, video, webcams, controllers, etc. I know this is all solvable but I’m not looking forward to it. I know from releasing games on Linux our number-one complaint is related to drivers.

7. Choosing a distro. Why is this so hard? A lot of people have said that it doesn’t really matter so just choose one. Why don’t more people use Linux on the Desktop? This is why. To a Linux desktop newbie, this is paralyzing.

8. I’m going to miss Time Machine for local backups. Maybe there is something like it for Linux.

9. I really like the Apple M processors. I might be able to install Linux on Mac hardware, but then I really worry about drivers. I just watched this video from Veronica Explains on installing Linux on Mac silicon.

10. The big big worry is that there us something big I forgot. I need this to work for my game dev. It’s not a weekend hobby computer.

I’ve said I was switching to Linux before, we’ll see if it sticks this time.

I have a Linux laptop but when I moved I didn’t turn it on for over year and now I get BIOS errors when I boot. Some battery probably went dead. I’ve played with it a bit and nothing seems to work. It was an old laptop and I’ll need a new faster one for game dev anyway.

This will be along well-thought out journey. Stay tuned for the “2027 - This Time For Sure” post.

UPDATE: It is now live at: static-hugo-comments

I’ve been cleaning up my comments script for hugo and am about ready to upload it to Github.

I added an option to use flat files or sqlite and it can notify Discord (and probably other services) when a comment is added. It’s all one php file.

The reason I’m telling you this is to force myself to actually do it. Otherwise there would be “one more thing” and I’d never do it.

I was talking to a game dev today about how to motivate yourself to get things done on your game. We both agreed publicly making promises is a good way.

This one hits a little too close to home. Like Tim Cain, I am done with making other people rich off my IP. I enjoying making small games like Death By Scrolling and I’m going to keep making games and having fun.

You may like the games, you may not, but I’m making what I want. I’m not rich but I can pay for food and rent and make what I want.

People often ask about a Thimbleweed Park 2.

Thimbleweed Park cost around $1.1M to make. $600k came from Kickstarter backers and $500k came from private investors I found later. Kickstarter for digital games is all but dead. I could not raise the money to make Thimbleweed Park 2 on Kickstarter today. I couldn’t even raise the full amount back then.

I have spoken to publishers and they have been willing to fund Thimbleweed Park 2, but they get rich and I get very little and have to do most of the work.

I am done with that.

From now on I’m going to make the small games I want and have fun doing it.

I’ve been in the games industry for 40+ years. I think I’ve earned that.

P.S.

MicroProse is publishing Death by Scrolling, but unlike other publishers they offered an very fair deal. Also, unlike a game like Thimbleweed Park 2, there wasn’t a lot of upfront money and that probably helps.

When I started using Hugu for static site generation I lost the ability to have comments and we all know now supportive the Internet can be, so why wouldn’t you have comments?

I wrote a few php scripts that I added on to Hugo and I had comments again. I decided to store the comments as flat files so I didn’t complicate things by needing the bloated MySQL. I wanted to keep it as simple and fast as possible.

When a comment is added, my PHP script created a directory (if needed) for the post and saves the comment out as a .json file with name as the current time to make sorting easy.

When the blog page was displayed, these files (already sorted thanks to the filename) were loaded and displayed.

And it all worked well until it didn’t. Flat files are simple. but they can be hard to search or maintain if they need cleaning up or dealt with after a spam attack. I figured I use commandline tools to do all of that, but it’s a lot more cumbersome than I first thought.

I missed have them in a sql database.

I didn’t want to install MySQL again, but my site doesn’t get a lot of commenting traffic so I could use Sqlite instead. The downside is Sqlite write-locks the database while a write is happening. In my case it’s a fraction of a second and wouldn’t be a issue.

The second problem I had was the version of Ubuntu my server was using is 5 years old and some of the packages I wanted wouldn’t available for it. I tried to update Ubuntu and for reasons I don’t fully understand I couldn’t.

So I spun up a new server. Since grumpygamer.com is a statics site I only had to install Apache and I was off and running. Fun times.

But the comment flat files still bugged me and I thought I’d use this as an opportunity to convert over to Sqlite. PHP/Apache comes with Sqilte already installed, so that’s easy.

A long weekend and I rewrote the code to save comments and everything is back and working.

Given that a webserver and PHP already needed to be installed, it isn’t a big deal to use Sqlite. If you’re not comfortable with SQL, it might be harder but I like SQL.

The following is a guest post by Robert Megone, the lead tester on Death by Scrolling.

Wish List today!

Testing Against a Moving Target: My Role on Death by Scrolling

Most of the games I’ve worked on over the years have been slow and deliberate. Narrative-driven adventures like Return to Monkey Island, Thimbleweed Park, Broken Sword 5 and The Darkside Detective invite you to take your time to sit with every line of dialogue, carefully piece together puzzles, and explore the world at your own pace.

That kind of work has always suited me. It gives you space to be meticulous, to catch the tiniest continuity errors or subtle logic gaps before anyone else does.

Death by Scrolling is the complete opposite of that.

A Game That Never Stops Moving

Unlike an adventure game, Death by Scrolling never gives you a moment to breathe. The screen scrolls constantly and the player must run constantly. As soon as you think you’ve found your footing the game throws something new at you.

That’s part of its charm but it’s also what makes testing it such a unique challenge.

This is a game where players can dramatically alter or buff their stats in a whole range of ways, upgrading movement speed, stacking power-ups, boosting damage and more. Each player’s setup can be wildly different from the next, which makes it impossible to test just “one version” of the game.

Instead, I’ve had to test against what feels like a moving target. Sometimes literally.

The moment I think I’ve pinned down a bug, the next run will throw me something entirely different, a new combination of buffs or modifiers that bends the rules in unexpected ways and reveals a completely new edge case to investigate.

The Need for Heavy Testing

Because of that unpredictability, Death by Scrolling demands heavy, sustained testing. There’s little room for error. A single overlooked bug can completely break the flow and ruin a run.

Where adventure games give you space to be methodical, this one forces you to be reactive to stay just as alert and fast-moving as the game itself.

A Collaborative Effort

Thankfully, I haven’t been tackling this beast alone. We’ve had a host of fantastic playtesters who’ve been instrumental in helping us track down some of the more elusive issues.

Their feedback has been invaluable not just in surfacing bugs, but in showing us how different players approach the game, what kinds of setups they gravitate towards, and where the game balance can wobble.

It’s been a collaborative effort, and the game is so much stronger for it.

Enter TesterTron3000™

With so many different level prefabs (used to randomly generate the levels that you traverse in the game), ensuring full coverage across every biome, enemy type, and powerup combo quickly became a task that I was battling to manage through manual testing alone, despite having the assistance of so many wonderful playtesters.

That’s where TesterTron3000™ came in. TesterTron3000™ is a name that may be familiar to some, it’s been a faithful helper that’s proved its worth time and time again, across Thimbleweed Park and Return to Monkey Island, albeit by name only. The underlying functionality is vastly different in this game.

TesterTron3000™ is a script that mimics player input, automatically testing many of the core game mechanics while blasting through level after level at an impressive speed. It has been most helpful in uncovering gameplay blockers and crash bugs that could take many hours to find through manual play.

It’s been especially useful during build sign off. While I’m testing one platform, TesterTron3000™ can be burning through hundreds of levels on Mac, Windows, or Steam Deck/Linux, this gives us wider test coverage and extra confidence in the stability of a build.

Stepping Outside My Comfort Zone

For me, Death by Scrolling has been a complete change of pace from my usual work. It’s chaotic, unpredictable, and relentless in all the best ways.

This has tested not just the game, but my own ability to adapt, to keep up with something that never stands still long enough to let you catch your breath.

And honestly? I’ve loved every minute of it.

– Robert Megone

October 28 on Steam

I know you’re thinking the same thing I am: “About f-ing time!”

You won’t even have to fake an illness to take the day off to play because your boss will be spending the day playing Death by Scrolling and won’t notice you’re gone.

Coming soon to Switch, Xbox, and PlayStation. We’re working as fast as we can.

Wish List today!

Who doesn’t enjoy a good history lesson? I know I do. Oh please let there be a test at the end.

Let me take you back to 2018. We had just released Thimbleweed Park, finished all the ports, done an update, and I am thinking about something new.

I was regularly going to Daniel Cook’s Seattle prototyping meet-up and trying to come with a new game to show every two weeks. It was my personal game jam.

I created a lot of odd games, one was a huge multi-screen breakout game, the other was a narrative game about someone being lost in a cave. The cave was procedurally generated and there was literately no way out. It also included a procedural swearing engine.

I was also working on a little top down pixel art rpg game, but is was missing something. I went dinner with some other game designers at PAX that year and buried in a conversation someone said something to how they try and come up with wacky ideas for their new games.

The next morning I woke thinking about the screen always scrolling, never stopping and the player needs to keep up. I hurriedly made those changes but it still didn’t feel right.

Trying to aim and run while the screen scrolled felt like cognitive overload. I switched it so the firing and targeting was all automatic and the player just had to run, avoid enemies, and grab things for upgrades.

There was a frantic energy to the game. The perfect party or steaming game.

I finished up the prototype and took it to the prototyping meet-up and it was a big hit. Lots of laughing as the death was narrowly avoided and the screen never stopped moving.

I was feeling pretty good about the game and decided to move it from a prototype to a real game. I knew I needed an artist but didn’t have the money to afford one.

By pure coincidence I was talking to a new steam-like platform just coming on a scene about Thimbleweed Park and figured I’d ask about this game. I put together a quick video and a pitch email.

You can see the video below.

To my surprise they said yes, gave me some money and I was off.

Side note: I recently did an interview for Death by Scrolling and they wanted to know if I was inspired to make Death by Scrolling after playing Vampire Survivors. Except for the auto-fire this game isn’t much like Vampire Survivors and I have to been working on it since 2018. So… I love Vampire Survivors, but no.

I worked on the game for about 9 months and really struggled with progression. The core game was still a lot of fun but everything I put onto it to make it a deeper game wasn’t working.

It was round this time that the possibility to make Return to Monkey Island came up and it seemed like an opportunity I couldn’t pass up.

I was struggling with the game I called simply called “Runner” and it made sense to returned the money I had taken and move to Return to Monkey Island.

I took all the engine improvements Derek and I had made and built Delores in prep for Return to Monkey Island all based on the Runner engine (but without the tile rendering).

«INSERT MAKING RETURN TO MONKEY ISLAND MONTAGE HERE»

Return to Monkey Island wrapped and I was once again thinking about something new. I had the idea of taking the pixel art tile engine from Runner and making an old school Zelda game (the only Zelda games I like).

I hired an artist, brought on Elissa as a designer and we were off.

A year into the game it became obvious that making an open world RPG was a lot of work and we didn’t have the resources (money) for that.

I thought about Runner, dug up the video and sent it to Elissa and said “What if we made this? We could have it done in a less than a year.”

She loved it and her epiphany was to forget about deep progression and just make it like an arcade game. In and out quickly and retain all the frantic fun of the original.

As I was thinking about the game’s name Elissa died from the scrolling and the text “Death by Scrolling” appeared and she said that should be the name of the game. Perfect.

A quick name change and Death by Scrolling was (re-)born.

The theme of the game being about stuck in purgatory and purgatory being taken over by investment bankers and corporations for profit took hold and provided a nice framework for narration.

A lot came together at the end and it all just made sense.

It’s a game about greed and the never ending grind in life and death for more and more. The absurdity of social media even make an appearance when you die.

The game is mirror into the world we live (and die) in.

Death by Scrolling

Pop quiz

1. What was the original name of Death by Scrolling?
2. What city was the prototype meet-up in?
3. Who did I bring on to help with design?
4. What game did I make between the prototype and Return to Monkey Island.

I want to talk about three things that has fundamentally changed my dev-life. There are a lot of things, like ImGUI, that are very amazing and useful but they don’t provide a general solution across many problems.

In no particular order…

Git

I’ve been using Git since 2010 and it really has changed my dev-life. I’d used version control before that, mainly Perforce, SVN and PVSC, but Git felt nice and unobtrusive and I like that everything was local until I pushed to the server.

It’s both nice and annoying that you can’t lock files (like art). You can (kind of) with LFS but that feels tacked on and not ready for primetime. Don’t think so? Try explaining installing and using it to a non-technical artist sometime.

Git can be frustrating if you’re trying to do anything but the basics.

Accidentally check in a secret file months ago and need to scrub it? Good luck with that. There are ways but it requires a lot of Git-Fu.

I mainly use a GUI for git (Fork) and that takes most of the pain away. I do use the command line, but mostly in automation scripts.

Markdown

Before Markdown became the de-facto standard, I used my own custom format. It worked but wasn’t great and only I understood it.

Markdown has it’s issues when you start using the more esoteric features. I’m also annoyed at bold and italics notation. Why is italics *italics* and bold is **bold**? Why not *bold* and _italics_. That would make a lot more sense to me.

I also have issue with it’s creator, John Gruber. He is a highly annoying smug Apple Fanboy. His writing was fine in the early days when Apple was #3, but got intolerable as Apple became the 800lb gorilla. It’s changed recently as Apple has snubbed him but I still can’t read anything he writes.

But, I like his Markdown.

JSON

I use JSON for just about every data file format in my games. JSON was created by Douglas Crockford as a notation for Javascript objects.

I worked with Doug Crockford at Lucasfilm for several years. I always had a lot of respect for Doug and was somewhat intimidated (in a good way) by him. Doug was also the producer for the Nintendo Maniac Mansion.

As much as I love JSON, there are some things about it that annoy me. I dislike that trailing commas are not allowed

"name": [
	"value1",
	"value2",  <- Opps
]

There is no need for this and it makes writing out valid JSON more complex. I also don’t like you that have to wrap keys names in quotes if they are simple ascii.

name: "value"  <- Opps

I wrote a custom JSON parser I use in all my games that relaxes these, but then general JSON readers fail on my data.

Hi there! I’m Elissa, and I’m the other designer on Death by Scrolling and doing a guest post this week. It’s technically my second project with Ron now, and when I’m not designing my own Roguelike (Dungeons of Freeport), or other games such as Deck & Conn, I’m drinking coffee and fighting drop-bears here here in the sunbaked land of Australia. If you want to follow me on social media, I’m on Mastodon primarily at @vampiress@eigenmagic.net and on Bluesky sometimes at @elissablack.com

A confession to make. I started writing this blog post, got a ways in, and then realized there was a critical problem with it: almost nobody reading the post would have any idea just how Death by Scrolling actually plays, so it’d probably wash right on over them producing a painted-on polite smile.

So here I am, back at the start, suddenly finding myself giving the elevator pitch and basic game play description of the game. It’s also easier now that some game play footage as been released.

Death by Scrolling is a vertically scrolling action-roguelike game.

TesterTron3000 playing Death by Scrolling

You select one of several different characters and progress through increasingly long and densely populated levels full of villainous nasties, treasures, gold coins, traps, collectables, and simple puzzles. At the end of each level you get a brief moment of respite at a camp where you can pick up and buy powerups, take or turn in quests, and go make another tea in the kitchen before returning to your computer before venturing ever-further into the fantastical worlds of Purgatory.

At first glance, the game doesn’t look like a Roguelike. Even in the most loose definition of the term - it’s vertically scrolling and action-driven. If anything, it seems to have more in common with something like River Raid or 1942 than a dungeon crawler. But to me, where it starts to show its lineage is when it comes to do level design in the game.

In terms of my work on the project, I’m designing & writing the game with Ron, but probably the majority of my time is spent doing the level design. As such, I felt like that was a good place to start when writing a guest blog post - I could focus on one of the only things I actually do more than Ron on the game.

In the most superficial sense, the game’s levels are top-down 2d level prefabs designed in Tiled, a very useful open-source tile-based map editor, and stitched together at run-time by the game.

The individual pieces (we refer to them as prefabs) each have different bits of meta data attached to them such as their Land (or biome), what kind of prefab they are, what other prefabs they can attach to and what the probability is that they might appear, what mobs can spawn, etc.

For instance, a very simple, short bit of green grass with a small hill and some simple decorations might be pretty common, and appear regardless of what level you’re at, where-as a more complex prefab featuring a maze may be rare, limited to higher levels only, and might be flagged to only appear once in a level.

Using this metadata we can set it up so that early levels are shorter, simpler, and contain fewer ‘puzzle’ prefabs (what we call the more complex prefabs that have optional mazes, gates or enemy ambushes in them).

If a new player starts on the first level of a run (which is always in the grassy Land), the prefabs that get chosen to assemble the level are different to, say, the 15th level for a player who’s unlocked lots of upgrades and is currently in the Swamp land.

So, to create a single Land means designing the aesthetics, the enemies that occupy its levels, the basic gameplay style, and then, finally, a good hundred or more prefabs that make it up.

Doing those first bits isn’t easy, but it isn’t as time consuming as the weeks and months spent making up all the prefabs. This process usually has three steps.

First step: drinking coffee.

Second step: coming up with basic shapes and paths. This I tend to do in batches, doodling in a notepad or on my tablet, sometimes at a cafe, on a train, or really anywhere that isn’t my work desk (for a change).

With enough of these basic shapes figured out in varying levels of detail, it’s then time for-

Third step: spend days in Tiled, creating first at first the basic layouts, then adding more aesthetic detail.

I usually alternate between doing all three of these critical steps - a few hours in Tiled, then going for a walk to clear my head, get a coffee, and come up with some more prefab ideas.

It’s this design process that to me really drives home how much the game is a Roguelike (or is at least related to them - ask two fans of roguelikes what makes something a roguelike and you will get five different answers).

Just like designing most any other Rogue-adjacent game, it also means that staring at prefabs and their metadata until your eyes go square won’t truly tell if what you’ve built plays well. Great ideas on paper don’t always work. Or maybe they do, but with a few powerups they become too easy (or too hard).

In Tiled, shown above, we have data layers that exist along with aesthetic ones. Different data types (each a unique colour for easy recognition) can be painted on that layer to allow the prefab designer to, for instance, stop a player jumping onto that square, stop power-ups from randomly spawning there, or forcing a square to be non-passible.

Which means built into this prefab design cycle is also a crap-ton of testing. From almost the very start we’ve had regular QA and play-testing done at least a few hours a week. What puzzles are too hard when you’re moving at speed? What other forms end up being fun and should be put into more prefabs?

Even the simple act of adding more prefabs can unbalance the game if we aren’t careful. Add 20 more prefabs to a given Land, and suddenly those rare ones you made might occur less frequently than you’d like.

In the end, it’s meant that designing this game has been a massively cyclic process. Adding features, prefabs, or puzzles, tinkering with them, experimenting, and even removing some if they turn out to have been better left on that scrap of napkin at the cafe down the road from my place.

“But? Wait?” I can hear you saying, “Isn’t grumpygamer.com a static site built by Hugo? What dark magic did you use to get comments on the static site?”

No dark magic. But it does involve a small php script.

You can embed php in a hugo page and since grumpygamer.com is hosted on my server and it’s running php it wasn’t that hard.

No tricky javascript and since it’s all hosted by me, no privacy issues. All your comments stay on my server and don’t feed Big Comment.

Comments are stored in flat files so no pesky SQL databases. It only took me about a day, so all in all not bad.

I may regret this.

I’m only turning on comments for future posts.

Be nice!

P.S. I will post the code and a small guide in a few days, so you too can invite the masses to critic and criticize your every word. Good times.