Perita’s Blog

← Return to blog index

Seven Days, One Roguelike

This week took place the 2021 edition of the Seven-Day Roguelike Challenge (7DRL). 7DRL is a yearly event in which developers are challenged to create a roguelike game in seven days. Although we did not sign up to officially participate in the challenge, nonetheless we tried our best to make a new roguelike in seven days, from Saturday March 6 to Friday March 12.

We asked ourselves: What would a roguelike designed for touch screens be like? More specifically, we wanted to avoid the virtual D-pad that we used in My Little Roguelike and design a game that could be played while holding the phone with one hand. A bit like the Nintendo game “Commuter Single Stroke” (通勤ヒトフデ, also known as Polarium Advance) but with a roguelike and touch screens, so i guess we could call it a “commuter roguelike” (通勤ローグライクゲーム)?

Anyway, this is what our “commuter roguelike” plays like. You can also play it in our website.

Gameplay video of Sisyphus’ Loop.

While trying to simplify as much as possible what we feel are the essential elements of a roguelike — exploration, turn-based combats, and permadeath —, we seem to have designed a kind of an idle or a clicker game. To be honest, i do not know how much this is like Rogue, and that is one of the reasons that we did not submit it.

Another reason is, of course, that some of the submitted games from other participants put ours in shame.

Be that as it may, my personal reason to make this game was to try to get my feet wet with the Heaps game engine written in Haxe, a strictly-typed programming language with a fast optimizing cross-compiler. I have heard of Haxe being used in many game programming competitions, specially in Ludum Dare, but never actually tried it myself. Until now, that is.

I think i like Haxe. It is one of those “boring” languages, in the sense that it uses very familiar concepts and syntax that are easy to pick up. I specially liked that it has pattern matching features like those of Kotlin and the unification between classes and interfaces, reminiscent of how Go handles interfaces. My only complain for now is the lack of documentation, both in the language and the libraries we have used.

We need more experience with it, however, to decide whether to keep it in our toolbox.