Good start of the decade, huh? In February I was enjoying a break from game development outside of patches for Gemstone Keeper, as well as spending a nice holiday in Sweden. Then March hits, and a virus that started in the Wuhan province of China spread to pandemic proportions and every country was starting to lock down and encourage people to either quarantine or distance themselves from others. For the last six weeks, I’ve been mostly working from home, my only travels are our long hikes around the local countryside and I’ve only been able to communicate with family and friends online in video calls or online games (Jackbox and Animal Crossing have been godsends during this pandemic).

It’s still a good time as any to work on some smaller games, and I’ve been wanting to get back into a few game jams, so during this pandemic, I took part in two big ones: The Seven Day Roguelike and Ludum Dare 46. This post goes over Seven Day Roguelike’s submission: KALQL8TR

UPDATE: The results for 7DRL were just released earlier today. Each of the 166 games were ranked in various categories. KALQL8TR was able to get into the Top 50 for all but one category, including 8th place for Innovation!

Seven Day Roguelike (or 7DRL) is a long-running annual games jam dedicated entirely to the traditional roguelike genre. Running every year since 2005, the task is to make a traditional roguelike game in exactly seven days. When the jam moved over from Roguebasin/Roguetemple to Itch.io, one change they made was allowing developers the flexibility of choosing which seven days to take part from a 10-day block. This meant you could start on either the Friday/Saturday/Sunday as long as you finished and submitted your entry on the following Friday/Saturday/Sunday, which is a nice way of factoring in people’s work-life outside of the challenge.

Funnily enough, a few days before it officially started I gave a microtalk on Roguelikes at the Birmingham Indies Meetup Talks night (BITs), where I (hastily) talked about the history of roguelikes, how they have evolved over the years and described the community that revolves around them, including an (unofficial) promotion of the jam.

So the idea I went with for this jam actually came from a TV series, The Amazing World of Gumball. One of my other keen interests outside of video games has been animation, both TV and film, and I’m a huge fan of this British made show from Cartoon Network with a large mixture of character designs and visual styles, some of the most creative fourth-wall breaks and a tonne of comedy. One of the more (surprisingly) minimal episodes featured this scene of Richard Watterson (the father of the main character, Gumball Watterson) reviewing what he thinks it’s a game when it’s just a calculator app on his computer.

The idea became clear: A roguelike where you have to operate it as a calculator.

As it already had a lot of the basics of a traditional roguelike in place, I used my previous entry RDDL as a base. It wasn’t going to be a full reskin, instead intending on having each level being larger than the main screen, as well as change up the level generator to use a random-walk algorithm as opposed to cellular automata. The Vigilante Framework had also changed a bit in the last two years, so it wasn’t going to be an exact copy.

How was the game concept going to work? Using the numerical keypad on most standard desktop keyboards as a reference, each number would correspond with a movement action (i.e. 8 for Up, 2 for Down, 4 for Left and 6 for Right) with 5 and 0 acting like no movement was taking place. The player’s goal would be to reach the end of each level to move to the next one, but each movement action costed a hit-point and running out of HP ended the game.

How to regain hitpoints? Each level had monsters, represented by the numbers 1 to 9 (because 0 would be too easy). Defeating monsters would regain HP, and the only way to defeat monsters is to calculate the exact number of said monster. The equals operator (=) was the attack button, with other mathematical operators (+, -, /, *, and %) giving free moves to aide your calculation, so if a monster had the number 4, then your calculation had to give the exact result of 4 when pressing equals in order to defeat the monster. Any errors in the calculation will mean losing hitpoints to the monster. It’s because of this mathematical combat mechanic that roguelike devs in the Discord described the game as a “Mathlike“.

Emulating a basic mathematical calculator was surprisingly easy, only requiring two integer variables as well as a single char variable to keep track of the current operator. It’s even possible to chain operations by keeping track of the current operator and numbers and keep your current result in memory for a new attack by simply not clearing the first integer. I started developing on Saturday afternoon and by the end of the first day I got the calculator functions working, and the day after implemented the combat and basic level and visual layout.

The next big feature was going to be the GUI, which to fit the theme we’re going to be giant calculator buttons. The button graphics themselves are single graphic sprites with text on top of them, but as a whole, one key feature was that each button corresponded to both mouse inputs and keyboard inputs. This is because each button had a corresponding key-value, so the GUI responded to both key-event presses, but also mouse button event presses (which in turn sent a key-event press if the mouse was over a button sprite).

It was when designing this calculator GUI that I got an idea for an additional challenge: CURSES! Getting hurt by a monster will give the player a random chance of being cursed, which will randomly disable up to half of the buttons for either 20 moves (or until an antidote was found in the level).

As far as gameplay goes, that was pretty much it. I could have found ways to add bosses or an end screen, but when it comes to game jams, endless works best for me. Visual Effects and presentation were the next priority by the end of day two.

So the two main visual effects to explain use honestly very simple methods of approach.

Starting off with the shadows, this effect was achieved by simply drawing the scene twice, with the bottom layer being at a slight offset from the top layer. This is possible in Vigilante thanks to the VRenderGroup, which is a group object that renders game objects to a specific texture but can also render game objects to the main screen as well. It’s true that drawing the same scene twice can be costly compared to a post-processed shader, but with a game this visually simple and how superficial it is in system performance it does the job remarkably well.

The other one is the line of sight, and it’s fading effect. While it looks like the game uses one tilemap on a basic observation, KALQL8TR actually uses three. The first tilemap is the game level itself, the second tilemap represents the game’s darkness, with each tile in the map being a fully opaque tile. On start-up and after each move, tiles in this tilemap are changed to fully clear tiles based on the player’s position and line of sight, which is calculated using the Bresenham’s Line Algorithm in all directions. You can see this in action from the previous tweet.

The final tilemap is a copy of the darkness tilemap’s previous state. On initialisation, it is completely transparent and before each move is performed, the tilemap data from the darkness tilemap is copied to the final tilemap. Then when the darkness tilemap is updated, the final tilemap is made opaque, showing all the dark and clear tiles from the earlier state, and fades out until it’s transparent. This results in the map gradually appearing each time you move, and like with the previous visual effect is remarkably simple for how good to appears.

The only other features I added to the game outside of gameplay was sound and the menu, with the calculator GUI having a visual makeover before release. I was partially inspired by how Monolith‘s menu had each selector bounce when designing the titlescreen menu for this one.

One thing I’m particularly happy about this one is how stable it is. Game Jams have a tendency of being rushed, so bugs will eventually crop up. With KALQL8TR, I haven’t heard or encountered any game-breaking bugs or crashes. Embarrassingly, there was a glaring mistake in the game’s instructions where I gave a factually wrong maths equation as an in-game example, which I managed to fix with a slight change in the code (the game also displays randomized maths equations).

One of the popular aspects of 7DRL is length. The majority of the short game jams tend to be around the 48 or 72-hour mark, which I feel adds to the excitement and motivation but can also add a lot of pressure. Stretching it out to a week manages to keep that motivation and excitement going while also making it manageable to get something good made around your day-to-day life.