A New Begining

As always, TLDR at the bottom if you don't have the time to ingest this wall of text.

Been A While

Lowrunner has been my main focus of hobbyist development for over a year now. But, I haven't posted any updates regarding it for quite a long time. I wish I could say that it's only because have been very busy with my life and other priorities. I have been, but that's not the entire reason for the lack of progress. I found myself in a development rut where I continuously reworked the UI over and over and wasn't accomplishing anything meaningful. The more I reworked it, the more I thought about how I don't want to keep working with it and just to rework it again after finding new problems. So, I put it down and did nothing with it. I had some time to mull it over and come up with a new plan, and I got back at it strong. I am glad to be working with it again and I feel that the game is better than ever and poised more properly to grow. This is the tale of my struggle, the solution, and the promising future ahead. 

Those Woes

I believe the main reason I was unhappy with the way Lowrunner was progressing was that it wasn't holding up with some of the design constraints I had placed upon it conceptually. I've talked about some of them before and I intend to write a more in-depth post about Lowrunner and it's design constraints, and about design constraints more broadly, in the future. Some constraints that I wanted to implement were conflicting and confusing, and causing more headaches to attempt to incorporate than they were bringing anything meaningful to the game.

There were two design constraints in particular that I wanted to implement that were causing me so much trouble. The first was that I wanted the game to be controllable with only 4 directional movements. I am developing the game with mobile in mind (because I have an Android phone and the means to create apps for it, and I always have my phone on me to playtest and theorycraft in my free time) and swiping directional inputs feels so intuitive on a phone screen. That, and I had an easier time with coding the game with swipe tracking than I did with tracking button presses from a phone (a bit on this later, but, spoiler alert: I figured it out). With that first one in mind, the second design constraint that I wanted to implement was that I wanted it to be in portait mode. With only directional swipes for controls, why not make the game playable while holding the phone vertically so you can play with only one hand? Both of these ideas seemingly went together in my brain, and I couldn't let either go because they needed one another.

"Just make the user interface laid out in such a way that the relevant information is displayed intuitively and make it as easy as possible to control." This was this thought path that I kept travelling down until I got lost and disheartened. I tried countless combinations of UI layout and directional swipe-only control, but revised versious would solve a handful of problems and uncover a handful of other problems. I would re-do the UI so that the inventory was easier to nagivate with the swipe controls, but then the health bars and status effects for enemies couldn't display how i'd want them to. Then I'd rework the UI for the health bars, but the controls potion now doesn't have as much room to display information for contextual actions that needed more detail to prevent confusion. 

Also, it felt I was just nagivating through a web of nested menus rather than actually playing a game. I spent more time looking at the controls display to remember what I was doing than looking at the actual game map and my character's situation, and it was getting less fun as I was implementing more game complexity.

Back To The Drawing Board

After taking a break from development and letting it simmer in my mind on the back burner, I finally came to the conclusion that those particular constraints were preventing me from proceeding with the my vision for the game. I reviewed their necessity and my intention for including them, and decided that they don't actually need to be a part of this game. 

"Why even have constraints?" I place constaints upon my games when designing them because it helps me shape and differentiate them. But, I had placed too many constraints on Lowrunner, such as the map being 1-dimensional and the sprites being super low res, and I decided to evaluate the importance and necessity of each one. I came to the conclusion that the directional input was hurting the game the most and completely unncessary. As I said, it barely felt like a game with all the sub menus, so my first order of business was to rework this.

Another Approach

"Well, now what to I do about the controls?" As I alluded to earlier, I was having trouble coding buttons, which led me away from it initially. I switched phones, and my new phone's resolution and lack of notch were causing hell with my input calculations between it and test devices on an Emulator. I decided that I needed to just take the time to work through it, because I was avoiding the problem instead of looking for a solution. I spent a while researching problem and looking up code and trying new things until I eventually landed on something that worked for me again. But now how do I lay them out? And, what functions to they serve?

Well, since the map is one-dimensional, there are only so many "inputs" that we need to interface with it. You can only move forward or backward through the map, and this also handles bump attacks and basic map feature interaction. So, two buttons for those inputs. You can also make use of contextual abilities based on your neighbors in the map, like drinking a neighboring fountain or lighting a neighboring campfire. Another two buttons for those. And, you have a small inventory that I arbitrarily capped (design constraint?) at 4, so I need 8 buttons total. Where do I put them?

At this point I realized that the portait mode constraint was also a bit too limiting, and was mostly put in initially to pair with the directional control scheme. I made myself a new mock up of what the game would look like with buttons and in landscape mode and everything that I wanted to display clicked magically. I made a few more mock ups trying to showcase different states of the game, and I was satisfied with how it all fit together in every case. The interface was heavily integrated with the old code, so I had to spend a while re-working the code for the controls system, and the interface, and many things that they touched.

Second Wind

So, had I spent another chunk of time developing in silence, but I felt that I was doing meaningful work and enjoying it again. I now have more systems implemented in the game than I ever had with any revision. And, many of them are implemented a lot more cleanly than before. But, most importantly, I have much more insight regarding the game after working through some of these design issues. I have a better understanding over some of the systems and features that I've implemented, and its leading to more natural game devlopment and affording me new ideas of how much more can be possible within this design space, despite the limitations that remained.

The Banana: A Case Study 

"Hey guy, you keep mentioning these game systems, and your story is sad and relatable, but can you actually talk about the game now?" Fair enough. Allow me to illustrate some of the design and intentions by studying one item that touches on many of the game's systems.

The Banana is an item. Items exist within the game map and can be picked up to add to your inventory, or left on the floor. If it's left on the floor, it may get affected by other things around it in the map. If you pick it up, it takes a turn, and it competes with the limited space in your inventory with other items. Once in your inventory, most items confer an ability, which usually uses up your turn and affects some of the other game systems. It is a special type of item called Food. Food items always restore health when used, and are the primary source of healing in the game. But, food items have additional properties that differentiate them from one another and add some *ahem* flavor. 

When you use the Banana, you spend your turn to eat it to heal, and it is replaced in your inventory with a Banana Peel item. The Banana Peel can be used to spend your turn to place a Slippery Peel on open ground next to you to affect enemies' approaches (a bit silly, but it gives the Banana more uniqueness).

All of this means that the Banana touches upon almost every crucial game system: map, inventory, ability, health and time. But, the item has several interactions in these systems that allow it for conditionally better or worse usage (if an enemy can pick up food, it may go for it instead of approaching you if its on the floor and this could potentially rearrange the map to be worse for you or deny you the heal/abilities it would provide; picking it up, eating it and placing the peel all require actions, so they may be used just to pass turns even if you don't need their intented abilities; you can still use it when at full health even though it heals to make use of the other properties it has; the peel can be held on to and made use of later when it can be more beneficial; the peel gets placed on the ground, so it won't affect flying enemies; etc...).

Where To Now?

Writing this actually took a lot longer than I expected, but I felt that I needed to get this out. It was cathartic and informative, and just articulating these thoughts helps keep me focused on what's to come. I wanted to showcase the new UI and some gameplay, but that will have to wait a bit still.

I intend to keep a dev blog for my development process and game design thoughts, mostly about things as they relate to Lowrunner, but also potentially about other roguelikes or design in general. Stay tuned for updates in the future and debut of the new interface with screenshots and gifs/video of some real gameplay.

TLDR: I developed myself into a hole, but realized it was because of design constraints I insisted upon implementing that weren't necessary for the game. After reworking the control scheme and UI to complement it, I have the game in the best state it's ever been in, and am excited to continue working on it. Gameplay preview to come shortly, along with hopefully more additional in-depth design information and my journey's documentation.