Breaking through limitations
Breaking through limitations
How I decided to give back control to the player in a limited playing-field.
The latest release of Brainroll, version 0.7.0 introduced the new chain mechanic which is a completely new and unique idea that creates some interesting levels that have players interested. As a developer, I am always excited to share my thoughts about the game and its design. I will provide a dive into the mechanic and how it came to be as well as what’s in store for the new version 0.8.0 as well as some exciting news for the future of Brainroll. Take a seat and grab your coffee and let’s explore.
Increasing the number of states
During the development of Brainroll I have always been aware of the very limiting movement that the ice-sliding mechanic brings to the table. If we for example look at the first level in Brainroll:
It wouldn’t be difficult for you to find all the possible states the player can end up in within this level. We know the movement is already limited by the player only stopping upon a collision and while the travel distance may be far the number of unique tiles the player can stand on becomes quite small. The rule for the movement is that the player can only stand on tiles adjacent to walls. This rule is even further reduced by the prerequisite that you need to already stand in a position where this wall is in line of sight.
Most of the states you see are even artificially created based on the positioning of the player as well as the first block that is obstructing the player’s path. Without them, we will lose 6 tiles the player can ever stand on. Even by simply moving the player’s spawn location to the top right corner we are removing those 6 states. Even with levels later on this problem is persistent.
So a problem that we quickly notice is that even though we increase the size of the levels as well as the complexity the player is very limited in what possible actions they can perform. The states can as we saw be artificially increased by positioning and adding additional walls but there is a fine line to walk between creating interesting and creative levels and creating cluttered and over-complex levels which most likely have artificial complexity embedded in them in the form of meaningless moves.
The sticky brains were one of the mechanics that I implemented in order to increase the number of states the player can end up in as well as allow the player to have some effect on the environment. This was a big success as many players have given feedback that they really do like the changes and that the state of the game today is much better than what it was a year ago.
This problem is not something new, however, I always had some awareness of the problems this type of movement would bring. In Brainroll, a game where movement is everything it is crucial for it to make sense and also mean something to the player. As I was progressing with creating new levels I found it harder and harder to keep the levels engaging as well as find the right balance between fun, interesting, and a reasonable difficulty level. I wanted to find an alternative, something that can help give the players more choice of the environment, a way the player can make the solution their own. This is how I figured out the chain mechanic.
A funny detail is that the original idea was sketched upon a napkin at the dinner table while I was visiting my in-laws, unfortunately, I didn’t keep the original sketch but it looked something like the following illustration.
The filled rectangle represents a wall while the outlined rectangles represent possible states the player can end up in.
While very simple the big revelation was for me that if I tie one of the sticky brains to a position I can alter the states that the sticky brain can end up in which in turn can alter the states the player can end up in. In addition to this, it has the same effect on the game that you notice with the differently sized logs within A Monster's Expedition because we can alter the number of tiles long a chain should be. Plus if we want to we can explore connecting the chain to something else than just one sticky brain and one wall. I’ve actually created a level like this where I instead connect two sticky brains which creates an interesting scenario for the player.
I don’t think I’ve mentioned it before but I really enjoy the part of game design where you take something simple and push it to its limits. That is how I feel like I can be creative and explore new solutions to problems. I really feel like I did that with this mechanic because it is relatively unique and it does fit the game pretty well.
Implementing this however, meant a lot of complexities. The underlying architecture of the game didn’t really support dynamic objects other than the player, this may seem confusing as the sticky brains move but in reality, they are also players that you simply don’t have control over (this maybe give you a hint of something I might do in the future). So what I had to do was rip the world logic apart in order to include not only dynamic entities but also entities that move very differently compared to the straight line the player and sticky brain move in.
My first approach was to implement the chain through A* pathfinding where the start position was a wall the tile being connected and the end position the tile the connected entity would attempt to move to. This worked okay for a while but ended up not being the correct approach to implement a chain like this because I wanted the chain to be able to wrap around walls.
The A* implementation was difficult to work with when adding these types of restrictions so I instead opted to just create my own algorithm for the movement of the chain. In very simple terms the pseudo code would look something like:
b32 Succes = TryMoveToNewTile(Sticky, TargetTile);
if (!Success)
{
// Try move rope to an adjacent tile to TargetTile
for (RopeNode : Rope)
{
vector2 TileA = TargetTile;
vector2 TileB = RopeNode->Tile;
for (AdjacentTileA : TilesInAllDirections)
{
for (AdjacentTileB : TilesInAllDirections)
{
if (IsSameTile(AdjacentTileA, AdjacentTileB)
{
// This is a potentail move as both the destination and
// rope is adjacent to this tile.
// Check if next rope node also needs to be moved and
// recursively repeat process if it does.
}
}
}
}
}You can imagine in your head the sticky brain attempting to move to a location and then attempting to pull the next chain node in line one tile towards it and then the chain nodes recursively repeat this process.
Today this works quite well, there are still some artifacts that can happen with some level designs but the overall mechanic and logic are deterministic and based on feedback more importantly also interesting.
As I learn more about creating games I want to restrict myself more and more from calling Brainroll a puzzle game but if I were to call the level’s puzzles then based on my personal judgment this mechanic doesn’t by itself make the game feel like a chore or uninteresting. There are still elegant puzzles that can be created with this mechanic, I however have not been able to find them yet as I was burnt out of creativity shortly after I finished implementing this. I play on resuming this task as the final step in the development process and only focus on levels once the game is in a “ready” state.
Version 0.8.0
The new version is going to be released right after I’ve finished composing this post. Inside this update, there have not been that many changes that will be immediately visible to the user but still important changes I had to push out in order for the game to be in a more ready state.
Internally I’ve referred to this version as the UI version as I’ve attempted to fit everything that has to do with the UI into this update. I will briefly go over the changes I made and then also talk a bit about the changes I didn’t make and will postpone to a later date.
First of all a lot of small annoying bugs and artifacts were fixed. For example, when navigating with the keyboard, the hover effect that appears was initially popping out of the top left corner, this has been fixed to not confuse anyone anymore. In addition to this something that many users have mentioned that needs fixing is the text scaling within the interface. Many of the testers have given feedback that the Brainroll title is the same size as the buttons of the interface and is sometimes confused for a button instead of just text. This has been fixed by my adding a bigger scale to the font of titles within the interface.
In doing this I also tackled a much bigger issue which is the main reason for this version taking longer than it had to. I made both my engine and Brainroll completely DPI aware. What this means is that text will be scaled based on the user’s settings within Windows which is an accessibility feature that many people including myself use. While doing this I also abstracted the entire font system of the game engine into some reusable components in the preparation for allowing programmers to choose which font backend they want to apply to their application. Right now I only support DirectWrite but in the future, I want to be able to use FreeType for example.
Just as my entire UI system I was also once again inspired by Ryan Fleury with my font system. As he has in the past displayed something that he calls “Atlas Allocator” whose responsibility is to allocate glyphs onto a texture atlas. While doing this I optimized the size of the textures that the applications need to allocate in order to fit all the glyphs by quite a lot if you look at the following before and after images.
This was an investment into myself and my engine as I will re-use the same type of abstraction idea when I later add support for more rendering backends to the engine.
Next up I also centered the UI and removed the background assets of the main menu. This was mainly because with the new bigger title font the text often was hard to see because of the snowy mountain textures around the screen, I like them so I instead just centered the text to get rid of this problem.
The last UI thing I did was some preparations for the next version which will include a move counter and score your performance based on the number of moves you use to complete a level. I will award the player up to three different trophies based on how “good” they complete the level.
A lot of the background music was removed and instead of playing one track per level I now loop the background music and divide the different tracks over several levels. This is a much needed improvement that actually allows you to hear many of the full songs which I know many people will appreciate.
Lastly I also fixed a bug with save and settings files that didn’t allow players to put the game within their Program Files directory. That directory requires administrator priviledges to write to which the game most likely doesn’t have when it is being ran and hence it would crash or not be able to produce files within the same directory as the executable. To fix this the game now uses the Save Games directory that Windows manages.
Moving on
As for the future I am proud to announce that this version will be the last early-access version of Brainroll before the full release. Right after this version is published I am going to merge in the new assets into the master branch and continue with the last set of features that needs to be fixed and once that is done all I am going to do is to look over the levels once more and focus on adding some new interesting levels.
I just yesterday of writing this post became accepted as a steam partner and have Brainroll prepared as a game on steam. I will make a new announcement once the steam page itself is publicly available for you who want to wishlist the game.
If you have any feedback I am very interested in hearing it, you can get back to me here on substack or any of my other socials. I really hope that you enjoy this version of Brainroll!