Click! 7DRL Postmortem

Last week I made Click!, a game for the 7 Day Roguelike Challenge 2026. You can play the game in the first link.

In this game you play as a zoologist, diving into a dungeon to take pictures of rare creatures. However, a dungeon can be a dangerous place if disturbed.

Joining 7DRL

The idea for this game has been lurking in my head for a long time. However, up until now it was just one of those projects you promise yourself to get around doing someday.

Until earlier this year, when I got embroiled into a flame war on discord about "what is a roguelike". My friend Rémy sagely replied with nothing but a link to 7DRL. The challenge was clear.

7DRL, by the way, is one of the oldest Game Jams, before Game Jams were even a thing. The idea of the event is to take 7 consecutive days to program a reasonably complete roguelike game.

So, if you want to be opinionated about what makes a game "like Rogue", no better way to put your money where your mouth is than actually sitting down and making one!

The Game Idea

Since I started making games as a hobby, there are two things that I always keep in mind when designing the game. One of them is how the mechanics contribute to the feel of the game, and the other is how to avoid relying on lethal violence as a player verb.

Nothing against violent games -- I throughly enjoyed beating the hell out of people in Silksong last year. But I like making things that are a little bit unique, and non-violent, high-mechanic games feel like a good starting point.

Now put in the idea of a Roguelike, a category that is so close to the idea of fighting monsters in a dungeon, and the question of "How to make a non-violent Roguelike" becomes a real challenge! Specially if we decide to NOT leave the dungeon.

One of the things that I like most about Dungeon Crawling in RPGs is not necessarily "defeating" a dungeon, but "understanding" it. Where do the monsters live? Why do they live there? Why do they interact with each other. This starts to enter the intersection between my love of RPGs, and my interest in complex simulations. A dungeon as a living space where monsters interact with the environment and each other in surprising ways.

Here we start to imagine the player as an explorer, someone who wants to see these rare views in the first place. A person looking to obtain this knowledge, and maybe to share it with others?

For a very short while, I had a stint as a photographer - having to think about composition. The friend who thought me a lot of tricks in photography often emphasized the importance of being aware of what is going on, to capture the really interesting and unique pictures.

A photographer of monsters then. Someone who wants to capture images of these rare magical beasts as people in the cities never saw before. Everyone loves those anonymosu social media accounts that boost rare nature photos unattributed!

Now the idea takes shape. A magical dungeon, where all sorts of weird creatures live in, maybe a little bit inspired by Dungeon Meshi. But instead of eating the monsters, you want to learn where they live, how they move, and then take a picture of them when they are doing something really interesting. A dragon pouncing on a giant lizard. A gelatinous cube sweeping the corridors. A mermaid who didn't notice you yet. You will take these pictures back to the surface and, hopefully, they will bring you fame and fortune!

If you can make it without the monsters catching you first, that is.

Now, how to make the game, and how to make it fun.

The Development Process

Because of the scope of the idea (with all the simulations and complex interactions between the creatures), at first I thought about using Godot or Picotron for making this game. However, in the end, familiarity with pico-8 won out, given the time constraints.

That, however, gave me pause about how complex I would be able to make the world. This turned out to be an unfounded fear, as it turns out, but we'll get back to it later. Enough to say that time and motivation ended up being bigger constraints than any of pico-8 traditional constraints. In fact, the cartridge ended up being around 6000 tokens, before I even did any amount of serious token hunting.

(If you have no idea what I just said, pico-8 limits how big a game can be. This size is usually described in "tokens", and pico-8 allows around 8000 of them.)

I took the basics of the game engine (input, movement) from the amazing tutorial on how to make a roguelike in pico-8 by LazyDevs on Youtube. My own code (and the spagetthi) began when I started adding NPCs and other systems. NPC AI was a holy mess of chained if-then elses, and the prototype generator for NPCs was huge. Each item that the player could use was a bespoke function. Best way to create a robust roguelike, as the Caves of Qud creators show us, is to use a robust Entity Component System, but you will find none of that fancy good quality programming here.

On the other hand, I was moderately proud of the functions for displaying messages in the bottom status bar and as text boxes, and I sprinkled messages liberally through the game. The transition animation betwen levels was also pretty satisfying.

The level generation code was a holy mess. I found a good tutorial about how to carve a full tree maze in a grid, and then "enhanced" it by pasting rooms on top of the maze. The code guarantees one entrance room, and one "level appropriate" monster room, and then tries to jam as many other rooms in until it runs out of tries.

It resulted in something reasonably rogue-like-ish and chaotic, but there is no guarantee that the level is completable and, perhaps more importantly, no underlying logic that can be learned. It was the very last real system I added to the game, on the last day, before I started the final pass of polish.

The monsters were OK, although I really wanted to have the time to think and add more. The blog and the drake were the first two monsters added, more as debug tools than anything else: The blob just hangs around, doing nothing, and the drake alternates between pursuing the player (or other monsters!) to bite then, and sleeping on a full belly.

Then I added the giant cube (who follows walls and is mostly unstoppable) as a monster that is both instantly fatal, but also easy to predict and prepare for.

Next was the feared Obelisk. I wanted something to make the players afraid: The obelisk would quickly fill the map with deadly flame if the player got too close. Once this began, you had to run to the exit or be burned to a crisp. In my mind, a lot of failure states in this game would involve the player running to the exit away from an angered monster.

But what is danger without some opportunity? Early in the development I decided I wouldn't be able to program a very complex score system, so the basic way to get a high score was to photograph many monsters together. The trick here is that the flames count as monsters, so pictures of monsters surrounded by fire is a sure way to get a high score.

This is fine.

The final monster added was the spirit, and this I was a bit pround of. The spirit has two states, sleeping and awake. When awake, the spirit will teleport away from any mob or player moving close by. The trick is to try stay in one place, and wait for the spirit to teleport away from another monster and close to you.

When a drake "locked in" on a spirit, and started to chase it all over the map as it teleported away, that was a little nice emergent iteraction.

A few monsters I wanted to add was some monster that ran away from the player and could be cornered, and a monster who reacted to the camera. And probably a dozen more, but scope.

Then the items. The camera I made very early, and the binoculars, as a replacement for a "look" command. The first "real" item added after that was the meat, which is mainly used to lure drakes, but has two sneaky side effects of counting as a monster for photography scoring purposes, and being able to block the fire (?). After adding the obelisk and the fire, I added two items to help the player handle the trap: A scroll of teleport (using the same code as the spirit), and a scroll of rain (that temporarily clear all the fire, but does not actually stop the obelisk). My original idea had the player changing the lens of the camera to get wider or farther shots, but that might have been the very first thing I axed when I started to narrow the scope of the game.

Finally, no music and very sound effects. I regret it, but making music for games is something I'm really bad at, and it inevitably gets pushed to the end of the Jam and left out, unless I have Cornet Theory to help me.

Life Gets in The Way

As I mentioned earlier, mental factors (wanting to make the game) was one of the biggest limitations. The US-Israeli war on Iran started just on the weekend before 7DRL, and that got me horribly distraught. Kinda like when my Genuary streak was disrupted because of the US invation of Venezuela earlier this year.

Then there was the fact that I had planned to take PTO for the entire week of 7DRL, but academic life laughs at your feeble attemps of taking vacations. Last minute meetings from the administration, e-mails from collaborators, and fear of the huge pile of tasks looming at the end of the "vacations" meant that I actually ended up working for at least 1/3 of the time in the challenge. Besides the time that took from game dev itself, this also inflicted psychich damage as I reflected on my inability to set time away from work.

Also Slay the Spire 2 got released that week.

It is a wonder I got any gamedev done at all!

Feedback

In the first few days, the game got a surprising number of comments and ratings. That was nice! Another thing that was nice is that quite a few people were properly scared by the Obelisks and the expanding fires. Mission accomplished!

On the other hand, from watching people play I could see many little things that were hard to notice -- like how the big cubes one-shot all other creatures and the effects of the rain spell. It was also painful to see how often bugs with maze generation appeared in actual play.

However, the biggest problem observed from actual play was the final scoring system and the final screen. I knew it was an unfinished part of the game, but clearly I made things much more confusing than necessary.

My idea for scoring is that you would score only the best picture for each monster. The score for the monster is a combination of the monster type and the monster state, and a bonus for getting many monsters on the picture. However, the final score lists the total score for each photo (adding the score of all monsters), which is very unintuitive.

I should have showed a separate score for each monster in a picture. Actually, I should have added the actual photo that you tool, which was the original idea, and probably not too hard.

Last words

Everytime I finish a game on a Jam or something, I feel quite proud of the game and happy with having finished it. Not this time, though. After having finished and submitted Click!, I was just glad it was done with.

Why was that? Maybe it is the difference of how the game existend in my head for many months, and how it actually came out. Maybe it was something else.

There is clearly still a lot to do, will I come back to this game? Well, my history of coming back to my old games says the answer is probably no. This game probably deservers better though. I should at least get around to releasing it on the Lexaloffle BBS.

That's it!