As always, TLDR at the bottom if you don't have the time to ingest this wall of text.
I intended to write a short article showcasing design constraints and those I've intended with Lowrunner, but as I was writing it, more information wanted to come out. I've written about some of this before, but I wanted to condense it all here in one place. So instead, here's the full history of Lowrunner and insight into it's design and gameplay. Gameplay visuals, too!
The 1-Dimensional Map
This is perhaps the single most defining characteristic of the game now, but it didn't start out this way. I had been working with and constantly redesigning a small roguelike for quite some time. When it first began, I only wanted to make a traditional 2D grid-based turn-based dungeon crawler roguelike that was easily playable on my phone. But, as it progressed, I felt that what I had first designed was too complex. So, I began squashing the numbers and the size of the map and trying to simplify it where I could. Then, I kept doing it, and kept doing it. I realized I wanted to see how much I could trim from it and still retain the feel of the gameplay. In the fall of 2020, I had a playable 2D version of this game on a 5x7 grid, and it felt pretty good.
Keep Shrinking
Then I watched Lee Tausman's talk at the 2020 Roguelike Celebration about lower dimensional games and got to thinking: what if I compacted my game even more so it plays on a 1D map? What would that look like? What would that play like? So, I began brainstorming, and soon realized that it could work with only a few minor modifications and it could still prominately feature the same gameplay. I started prototyping it, and I was surprised: the 1D version could be as fun, if not more fun, than the small grid 2D version. That's when I fully embraced this design constraint and Lowrunner was truly born in concept (but not name, that came later).
Don't Block Me, Bro
The biggest issue (not the most difficult issue, but the most important one) I had when designing the 1D version of this game was: how do I handle map features that may block the player? In the 2D version of the game I had these features, and you could just move around them. But, if you just take the same gameplay on a 1D map, your character would get stuck when coming across these objects. I was prototyping with physical cards laid out in a line and I would move a coin from card to card to simulate movement, but I couldn't figure out how to keep the player from being blocked by obstructions on the map. I knew I wanted to implement these features, I just had to come up with a different way to keep them in the map without blocking the player.
Swap It Out
In most roguelikes, the map is a series of floors and walls and your character is an entity which occupies the same space as a floor and can't move past walls. Also, items can be in the same spaces as entities, or the spaces could be filled with other obstructions that may or may not impede movement. I knew I didn't want to add the programming and UI complexity of having too many layers of "stuff" in a single map space. I came up with an idea that, instead of a map that you can occupy, what if every "map space" was just a single object and "moving" would swap the two objects' positions? I kept prototyping with cards, but instead of moving a coin from card to card, I kept the coin on a single card and would just swap that card with its neighbor to move. Instead of the cards being spaces in the map to move on, the cards themselves are the map.
Kinda Weird... But I'll Allow it
I implemented the movement object swapping and I was happy that I could now "walk by" solid obstructions by swapping with them, but I noticed that it was sometimes weird how the map would end up after things moved. It's not so noticeable when its just the player and one object, but when there are multiple entities that also move it can sometimes seem to send a nearby object very far away from you. However, I decided I was okay with this, as it gives the game a pretty unique feel and a sense of abstract weirdness, and it allows for the rest of the gameplay to be implemented how I envisioned it.
Save Me A Spot
Another issue I came across early in testing was: how do I handle enemies dying, objects being destroyed or items being picked up from the map? My first idea was to just remove them and collapse the rest of the map to fill the gap. But, I realized that this wouldn't work, as it would exacerbate the "weird movement swapping" and it was much more confusing how the map would end up after your turn. I decided that if an object gets destroyed, it should leave a "placeholder" floor space where it had been on the map. This allows entities to retain their relative position and makes it feel more like a traditional roguelike map with entities and items on map spaces (instead of the "everything is an object and only one object per map space" that it is). It still may seem a little weird, but I decided that it's within the amount of wierdness I was willing to allow.
"Low" Numbers
Early on, the project featured a lot of text and numbers, but I wanted to simplify those aspects as well. Somewhere in development I decided that, if I could make it work, 9 should be the largest number for everything. For things that have ever-increasing counters, such as statistics and gold aquired, this is allowed to be broken. But, I am still trying to have the vast majority of all things retain low numbers (health, damage, field of view, inventory spaces, cooldowns, wand charges, buff/debuff duration, etc.). Many of these numbers I've landed on were chosen at random (such as the maximum inventory item limit of 4), but some needed to be worked out in playtesting (such as items' cooldowns).
Everything, Including The Kitchen Sink
I have been considering aspects of this game (to some extent) for many years. I came up with a lot of weapons, items, objects and enemies that I could implement into the game's systems, and my goal is to incorporate as many of them as possible. But, to keep things from becoming obsolete or overshadowed, I decided to try to make the design as wide as possible. By that I mean: I wanted everything to have a relative average power and usefulness, but situationality would determine if things were better/worse in that moment. I decided arbitrarily that the average enemy should have 2 health and the average weapon should have 2 damage. However, they go about achieving this in different ways (for example, one enemy can have 2 health, but another enemy can have 1 health and 1 armor. For most purposes these two are effectively the same, but if you have damage that bypasses armor, the second enemy will be easier).
Lights?
I don't really mind playing roguelikes in ASCII mode, but I generally prefer to play with tilesets. However, I do believe that ingesting information may be quicker in ASCII mode versus tiles, and it also can entice player to use their own imagination to envision the situation they are in instead of absorbing the graphics provided. As such, my favorite tilests are the ones that can provide a little bit of graphical design and can still be quickly read like ASCII. My favorite tileset that does this is Retro Days from C:DDA. My low-resolution pixel sprites attempt to be as minimal and as easy to distinguish from one another as possible. The most important constraint that I've stuck with regarding the sprites is: everything should be on a black background and, aside from black, no other two colors can touch. This keeps the sprites from looking blurry because they are so low-resolution, and gives it a similar vibe to ASCII and that Cataclysm tileset.
Camera?
Because the sprites are at an odd resolution, I knew I had to handle their drawing on the screen closely. I wanted to be able to have some sprites at smaller sizes as well, so they needed to be able to be laid out in a grid nicely, almost "console-like." I have to calculate the screen size and do some math to make sure the bitmaps get drawn pixel perfect so there aren't any weird display issues. And, because the map is 1D it needs to be displayed in a rectangle that is substantially longer on one side than the other. Based on my sprites, the phone and emulator I used to test, and some gameplay trial and error, I decided that the map should center on the player and the field of view would be 8 additional spaces in either direction. I used to have the map displayed vertically, but I believe it works best when laid out horizontally.
Actions!
Because the map is only 1D, youre movement options are limited to only 2 directions. Most of these kinds of roguelikes feature 8, 6 or 4 directions for movement, so here the amount of choices for how to act on your turn get greatly limited. Because of that, I wanted to add additional ways to spend your turn. Items are a large part of this, but I also came up with the idea of contextual actions in the map. I often gamble my runs in DCSS and Nethack by praying at every unknown altar and drinking from every fountain. I wanted to add similar such interactable map objects to Lowrunner. So, in addition to moving or using an item on your turn, you can sometimes interact with nearby objects, such as fountains or chests, to spend your action with different effects. Also, picking items and weapons up off the floor is handled as such a contextual action.
The True Gameplay Emerges
It became apparent that parity would play a huge role in the game. It was a prominent feature in the early 2D version, but it really comes to the forefront now. In this context, parity means whether or not two objects have an even number of spaces between them or an odd number of spaces between them. On your turn, if an enemy is one space away from you, you can attack them first. If an enemy is two spaces away and you move toward them, you will get put into melee range with them before their turn and they will get a chance to attack you first. But, if an enemy is three spaces away and you move toward them, they will move toward you, and then you can attack first again. Essentially, the entire gameplay revolves around using weapons, items and object interaction to change your parity with harmful things to be more beneficial to you. In testing, I decided that allowing the player to "wait" on their turn (pass the turn without performing another action while remaining stationary) would be too strong, because they could change their parity at will, so it had to be removed.
Automatic Transmutation
Another part of my desired simplification also extended to weapon and inventory management. I didn't want to have to add more commands for dropping or selling items, and I wasn't sure I even wanted dropping items to be allowed at all because of how actions/turns/parity worked. So, I just decided that new weapons and items would replace old ones and the old ones would be automatically "transmuted" into currency for the player (and a lot of games do something similar for similar reasons). There is still a little interface complexity here to allow for player intent confirmation ("Are you SURE you're sure you want to pick this new one up and lose this old one?"), but I think this is necessary to prevent accidental happenings and a bad experience.
Everybody Bumps
Using "bump attacks" (attempting to move toward an enemy in range of your melee weapon causes an attack instead of a move) is a staple in turn-based grid-based roguelikes. In attempt to simplify how weapons worked in the game, I decided that all weapons should bump when in range, so that: a) I didn't need to add separate attacking commands, b) variance in weapon range, damage and properties will be more apparent in gameplay, and c) I just particularly enjoy the way that playing melee characters in roguelikes feels, so I wanted to heavily feature it.
Wait, Ranged OP
I had designed many thrown and ranged weapons that I wanted to implement. I first treated these the same way as the melee weapons (allowing them to become your main equipped weapon), but it bacame very quickly apparent that weapons with long range were way too strong, trivializing difficulty and making shorter-range weapons obsolete. So, I decided that equipped "weapons" should be melee-only (but some do have larger range, such as polearms) and ranged "weapons" should be go into your inventory so they compete with other items for space and can be managed differently.
Limited Uses
With the large emphasis on parity in the gameplay, I didn't want to implement too many items that the player could have that allowed for repeat and frequent use. Many items are consumable, so they are removed from your inventory upon use. Some are consumable, but can be used several times before being destroyed, such as charges in a wand. However, some items didn't make sense to be consumable, and I wanted to add more skills and abilities in the guise of items. Also, I didn't want the player to have to continuously cycle through new items and strategies- I wanted some of this, but not to the extreme, so some items need to be reusable to give the character a sense of an "ability loadout" or "character build." So, item cooldowns made sense in this scenario to allow the player to reuse items, but with the caveat of having to wait for a period of time between uses.
Food And Hunger
I understand the need for "hunger clock" systems in games to push the player forward and keep them from lingering for an advantage, but I generally dislike how they're implemented in most games. I did want to implement food items (mostly because I had thought up some sprites for them), but I didn't want to tie the system around hunger. I decided that food items would provide healing and also provide some additional benefits to help differentiate themselves (I wrote about this in my last article). But, I still needed some system to prevent the player from lingering for cooldowns to resolve or retreating way far back to a safer part of the map.
Add Some Mystery
I was struggling with a theme for the game. Most of the sprites are generic fantasy, but not all of them, and I wanted to consider the possibilty of blending genres to add everything because of the "kitchen sink" mentality that I had. I decided I should set it in it's own sort of universe (or... dimension?) that's only vaguely described and allowed to be weird and mysterious to allow for players to fill in the gaps in their own mind however they wished.
...And Some Magic
I also wanted to implement magic to retain the fantasy dungeon crawler feel and have a means of expressing some otherwise-unexplainable ability effects easily. I decided to try to kill two birds with one stone: link together the magic and "hunger clock" systems thematically. I decided that the player's retreat needed to be limited and the game should force you to move forward through the map. I wanted something along the same lines as the ghost in Spelunky or the darkness in One Way Heroics. I decided that some deadly magical wall of energy was constantly approaching behind you and you needed to keep running away from it while dealing with the other dangers the game threw ahead of you. I also decided that magic in this universe could be powered by this same mysterious energy, that I arbitratily and vaguely named ether. This dangerous wall of ether is compelling you forward, but what if you could also use it to your advantage? I decided that casting spells should affect the ether wall somehow, like bringing it closer to you- simultaneously making magic risky to use while allowing you to potentially manipulate it for your own use (such as using it to deal with an enemy near it). This system works pretty well, but still needs a little tweaking as it still may allow for a little too much lingering freedom for the player.
But, Where The Heck Are We?
The theme still needed a little more flesh, so I decided I should name the weird magical universe that it is set in. I didn't have any good ideas, but I just kept referring to it in my mind vaguely as "the lower dimension" and eventually just "the Low Realm" or just "the Low". I also wanted to rename it, to distinguish it from it's 2D predecessors it was starting to drift further from. What is the game even about? Well, it's a roguelike about dungeon-crawling while moving quickly along a low-dimensional map. It's a game about running through the Low Realm. It's... Lowrunner.
What's Your Endgame?
Alas, this is the one major feature of the game I've yet to solidify an idea on. I have several ideas of where to take this, but I haven't settled upon one yet that really resonated with me, so for now I'm continuously mulling this over while playtesting to decide what feels best. I know I want to have several locations within the game (such as a dungeon, a cave, a forest, etc.) to bring some flavor into the procedurally-generated surroundings, but I wasn't exactly sure in which way I wanted to use them. I can make dungeon branches, such as they exist in Nethack, or I can make many environments you can pick your way through at will, such as they are in HyperRogue. I can make it so you have to make your way through several of these and collect X special items. Or, defeat Y unique enemies. Or, travel Z distance. Still many ways it can go here.
What Now?
I have many of the game's systems implemented, at least at a base functionality. I have the interface and UI in states that I am happy with. I have many ideas of new items/enemies/weapons/objects I can add. But, I think the procedural map generation needs a little love, and I think that spending some time to polish this will aid in deciding how to proceed with the overall gameplay and endgame implementation. For testing, I just have it spawn things at random so I can playtest features and see some random interactions. But, I think I want to have it spawn features and enemies in distributed groups in an attempt to simulate how flowing through a 2D dungeon would play: groups of enemies (often similarly themed) followed by short a short stint of exploration (to offer respite and reduce critical decisionmaking overload) followed by more enemies, and so on. Stay tuned!
Show Us Some Something, Please!
Okay, okay. Here is a gif of the interface and some gameplay. On the top of the UI there are buttons for the menu and log, along with some information for your character that isn't strictly needed on a turn by turn basis (such as statistics and currencies). On the bottom is the row of action buttons (movement left and right, contextual actions left and right and 4 inventory spaces) which have differing borders depending on their current uses. And, in the middle is the player with the map on either side. Entities' health is displayed underneath them and temporary effects are displayed above them. The player's weapon is drawn inder it's health.
In the gif our player has 3 health, is equipped with a spear and has a banana in his bag. The ether wall is approaching behind. We defeat some rats, pass by a statue and open a door to see some stairs and a honeycomb. A spider comes into view and begins spinning movement-hindering webs, but gets quickly dispatched. Then comes a warrior, but it gets taken down with the help of the webs the spider left, and we obtain the honeycomb. We also grab a water potion as a priest and beholder approach, but they get dealt with confidently. We decide to stick with our spear and leave a trident and whip laying on the ground, and bypass another staircase. We take a bite of the banana to get a peel for future use. Next we see another banana, some gold and a crab. We decide to drop the banana peel on the ground to hinder the crab's approach, and deal with the crab easily after it slips. Next, we would likely grab the new banana and the gold and continue onwards, through the Low Realm.
TLDR: I have been designing this game for quite some time, trying to condense it while retaining as much as possible. The result is a "kitchen sink" style dungeon crawler roguelike on a 1-dimensional map set in a vague magical universe. Many systems have been implemented, and there is much more room to expand in the future, even within it's seemingly-limited design scope.
