Holy Book Postmortem
Holy Book is my 12th Seven Day Roguelike (past entries).
It's playable online, including mobile, here.

The Idea
I was heavily inspired by Path of Achra. In fact, my entry last year was also inspired by PoA, but I still had the itch to work on a similar system.
What interests me about Path of Achra? Besides delightful world building and poetry (which I dare not emulate during a jam):
- Super streamlined combat inspired by DCSS's "press tab to fight" combat. In DCSS, you can only practically play this fast for some classes some of the time. In PoA it's the default.
- A rich skill system, which is built on triggered effects. It ties into #1 so well. Your build is sort of a little factory of triggers and effects and the game lets you see the outcome of your build very quickly.
I had two big ideas I wanted to add to this formula:
1) Pushing the streamlining even further. You still have normal grid based movement in PoA, you just don't need it 99.9% of the time. What if it was eliminated entirely!?
I imagined a system where you could only do 3 things: continue forward (moving or attacking), waiting, or retreating. The first two are pretty similar to commands in DCSS but I think the concept of retreating is not.
Streamlining movement in two directions lets you hold onto some basic tactics while also letting you hook into skills in different ways (when I retreat, do X).
2) Letting the player build the skills. Give the player keywords and let them rearrange into trigger+effect skills. Seems easy... right?
What went right
Art
I'm really happy with the look of this one. Constraints helped.
I chose a small grid size yet again: 16x16 pixels, but I've learned to make each sprite file slightly bigger to allow occasional details to expand beyond.
I wanted to copy the style of Downwell, which only uses 3 colors: white, black, and red. I added other colors following a similar convention: only colors that are either 0% or 100% RGB components. This results in a very unsubtle, retro look. I suspect it's really good for mobile because of the high contrast.
Walls slowly fade away and that nicely matches the lighting style you see in 2D platfomers.
I also made procedural skill icons using some reworked shader code I made last year. They look sort of like shimmering gemstones and they pulsate every time you fire off a skill.
I used a different shader for the title screen. Turns out you can make a neat fire effect very easily using two offset copies of the same image of difference clouds (generated in one button in GIMP... though you then have to tweak it so it smoothly tiles or you get unsightly artifacts).
The basic concept
The two basic ideas (streamlining + player made skills) were a big success... assuming the player understood them (more on that later).
Fun is always something I struggle with in 7DRL. I can say personally this game is a fucking blast. A short blast though. :P
Spamming the Continue button, summoning a huge horde of allies, and then lighting your enemies on fire from a distance is exactly what I had hoped for. It scratches that PoA itch a bit.
Mobile
The game was designed with mobile in mind. Specifically I really want some more quality roguelikes that can be played in portrait mode.
With the caveat that I didn't add in Continue/Wait/Retreat buttons until v1.1, this worked out. The sight radius here is pretty small (like 5 tiles), but that doesn't seem to matter because the game isn't super tactical.
What went wrong
In general, I fell into a familiar habit of not saving enough time for content and playtesting.
The skill parser
I spent days writing a pretty elaborate skill parser which supports a few dozen words. I chose a certain sentence format to simplify this. Example: when you retreat then apply 4 burning to 3 enemies.
To break that down:
when [trigger target type] [trigger verb] then [action verb] [action number] [action modifier] to [target number] [target type]
Just writing this out it's clear: THIS IDEA WAS ALWAYS GOING TO BE HOPELESSLY CONFUSING FOR PLAYERS.
I literally handed the player a compiler UI... woops.
For me as a player it worked great, but watching new players try to navigate this system was incredibly painful. First it was clear players just could not construct sentences this way, mainly because they expected (naturally) to be able to make freeform arrangements and not fit a rigid standard.
It was also unclear the difference between trigger verbs and action verbs. "Grant healing" is an action verb (I need it that way to slot a number in there, but "heal" is a trigger. Very confusing I admit.
To salvage this at the last minute, I prefilled skills instead of requiring players to write them from scratch. This was a lot better, but it still allowed players to unlock a totally valid skill and then immediately start breaking it so it did nothing.
Not enough content
I spent so much time on the skill system and arranging the skill tree UI that I had little time for content. The 7DRL version has 7 levels and only 2 status effects. I imagined that a bulk of the game's complexity would live in a variety of status effects (just like Achra), but it was pretty limited. I also didn't have time for added interesting behavior to monsters.
However, I learned in v1.1 that adding in new content is super easy. Adding in monster behavior was insanely easy. After a few small changes to accommodate monsters having their own skills, I verbatim typed "when you die then summon 3 bat" and my vampire turns into bats on death. I was shocked at how well that worked.
Confusing UI
I was surprised by feedback telling me players had no idea what to do and the game was impossible.
Players didn't always realize that the game's primary system existed. So they just didn't make skills. The game is of course impossible without doing this...
In v1.1, I made skill unlocks mandatory to eliminate the confusion.
Future plans
I still think there's a shortage of streamlined, but deep/replayable roguelikes on mobile. I am wondering if Holy Book could be one. First I would need to rewrite the skill UI to minimize confusion on which words are acceptable in each part of a skill. I guess the current system really put a damper on the enjoyment for many players.
My last couple years doing game dev have been kind of a struggle with not much visible output. I think I've dealt with the reasons why (lots of dead ends for one) and really want to buckle down and focus now. Learning Godot in the past year has been a huge confidence boost. Holy Book is the first solo Godot project I've released. :)
I'm working on another game right now... a match 3 balatro-like if you can believe that (stay tuned), but Holy Book is a strong contender for getting some love after that.
I want to thank my patrons at https://www.patreon.com/vulgat: andrew goodman, Tone, Tom Loughlin, Kawa, and zzxc
Holy Book
A roguelike about designing a religion and guiding your disciples.
Status | In development |
Author | jere |
Genre | Strategy |
Tags | Seven Day Roguelike Challenge, Roguelike, traditional-roguelike |
More posts
- v1.1 - post 7DRL patch34 days ago
Comments
Log in with itch.io to leave a comment.
I fall into the same trap a lot too. Lots of time spent on foundational stuff that would be cool to build on top of, and then not much time building on top of it.
You seem to have avoided it this year though!
Yeah, this is the smoothest I remember it having gone. It was downstream of an intentional decision to limit the number of mechanics.
It feels a bit double-edged, though, since I *like* games with lots of crunchy interactions and I maybe could have gotten away with more. I think the ideal calibration would have put things just barely inside our limits, and from that perspective I undershot it.
I guess each time it's better to go under than over, but if you never go over it's probably because of not taking enough risks.
I suppose it depends on what you want out of it. To create a complete experience (the main goal of 7drl I think)? To conduct an experiment? To build a platform to build on?
If it's the first one, undershooting and polishing instead seems correct.
It's correct in the sense that you do end up with a result that meets the goal. It also leaves potential on the table that could have gone toward "more game."
If there are two hypothetical undershot projects that both end up polished and complete but differed in level of ambition, I suspect we'd agree that the more ambitious one got the better result.