I’m going to DevLearn 2019 in Las Vegas to take part in DemoFest. Here’s what I’m showing off there.

Tower Hacker game splash screen, with the logo in the front and a cyberpunk city skyline in the background

Tower Hacker

I’ll be demoing Tower Hacker, a 2D side-scrolling platformer. Tower Hacker was developed in a game design class last year. It uses 2D art from Ansimuz for the characters and backgrounds. I wanted to do something a little different than the typical side-scroller, so Tower Hacker uses a vertical gamespace, not a horizontal one. I felt that this would fit nicely with the cyberpunk theme, and create a unique hook as a concept. The game follows Pixxie, a hacker tasked with scaling a skyscraper from the outside to hack a radio tower at the very top of the building. 

I also wanted to create a game that took place in the game environment, and not in menus and overlays. I wanted to make a game that got faster as you progressed, and felt more dangerous. Menus and overlays pull the player out of that experience, so I needed to find ways to guide the player through the environment in the game.

I wanted to make good use of the vertical space, which meant making something very tall that also didn’t feel overly long to scale. I ended up with a gamespace that is 2160 x 3840 pixels. That provided me the space to create two 27-story buildings in the game space. It also provided a lot of ways to use the verticality in interesting ways.

Height Matters

For a typical side-scroller, the main danger in the game comes from enemies. For Tower Hacker, I wanted the danger to come from the environment. Falls do damage. Flying cars can hit Pixxie, which causes damage, and also push her off ledges, which also causes damage. 

Fall damage is calculated using Construct’s built in Platform conditions. First I created a variable, FallDamage, and set it to 0. Then I set up an event that adds 10 to FallDamage every 0.5 seconds Pixxie is considered falling by Construct. That’s good for giving damage when Pixxie falls from somewhere high up, but it also gives Pixxie damage on the little jumps that make up the core of the gameplay.

To solve that problem, I added an event that checks if FallDamage is greater than 15. If FallDamage is not, then no damage is applied to Pixxie’s health. If it is, then the FallDamage value is subtracted from Pixxie’s health variable. This creates a feeling that Pixxie is tough, and has some experience jumping gaps and moving through urban terrain. It’s also the first place where I started thinking about using the game to instruct the player through its systems and environment, and not menus and overlays.

Image of the code to create falling damage in Tower HackerLearning To Explore

I wanted a game that felt like it encouraged players to explore and feel ready to take risky jumps, while also feeling that those jumps matter. Damage from falling gave me the negative consequence that added the importance to the jumps. A bad jump means taking damage from falling. A well-executed jump, however, results in no damage in most cases. 

Creating that damage threshold opens the idea of trying jumps. There’s a positive reward to a well-executed jump, in that the players have advanced their position on the tower, and they performed what feels like a risky jump without taking damage. Using the fall damage system, I can teach players that it’s not only okay to make risky jumps, but that those jumps matter.

I also knew that very early I had to find a way to teach players about going up to explore, not right or left, as is expected by players in a 2D platformer. To achieve this, I added a solid piece of machinery and a vent that blocks player movement at the base of the second building. While the player can see that there are things to discover above and beyond this barrier, they can’t reach it – yet.

A barrier that blocks the player from exploring further in Tower Hacker

This does create a more immediate and short-term objective for the player, as opposed to the very broad and long-term goal of reaching the top of the tower. By teasing more content that the player can see, but not reach, and blocking the most obvious path to that content, I force the player to consider that they have to explore up in order to get into new areas, even ones below or at the same level as their current position.

Learning The Rhythm

Tower Hacker isn’t a rhythm game, but platformers do have a rhythm to them. There’s a spacing and timing to the jumps that can be taught, then recalled later. I approached this by applying a bit of music theory to the game. A song evolves throughout, remixing familiar sounds and patterns as it goes. Just as a pattern of notes set up early in a song may be called back again and again, with additional notes or a modified pattern, games can do a similar thing. 

I created a series of platform sizes early on. I also created spacing sizes based on how far Pixxie can jump to a platform on the same level as her jumping point. Down at street level, and up through the first 6 stories of the game, I used large platforms and more forgiving gaps.

This is a bit of a training ground for the player. There is still a risk of falling, but the fall is not very harmful. I also placed the larger platforms in a way that it was more like one of them would catch a player if they missed a jump, reducing the amount of falling they can do, and the amount of falling damage they will take.

By using larger platforms, even when I use the larger gaps between them, I can instruct the player to take riskier jumps. Not only is this encouraging the player to be bold in their choices, it is building trust in the game system. The player is learning what is expected, but also how the game will handle their failings.

Here, players see falling damage for the first time. They see a variety of gap sizes they will have to jump across, and they learn the timing for jumps. As they progress up the towers, the platform sizes change, but the gaps remain the same.

The difficulty rises due to the shortened platforms. First, there is less run-up to a jump, so the game quickens as the player moves up the towers. Second, smaller platforms are less capable of catching a falling player. Now, the risk of triggering a Game Over state is higher. Third, the perception of the landing area changes. A wider platform feels safer than a smaller one, even if the distance from the jumping off point is the same.

I am also using the environment to instruct players about the danger of their next moves. The player has also moved through the space below them, which provides them with information about their fall risk. At lower levels, they know if they fall, there is likely something to catch them. At higher levels, the player will have jumped through some very empty spaces, so they know if they are falling, it will be a significant fall. 

The rhythm of the jumps hasn’t changed in the higher levels, but the game is faster and more dangerous. By the time the player has progressed to the top levels, they will have learned the game’s rhythm. They must recall that rhythm and modify the pacing of it as they go to successfully navigate the towers.

Learning Blind Faith

Earlier I mentioned that Tower Hacker has 2 towers for Pixxie to scale. Moving between them isn’t as simple as walking between them on the ground or taking a pedestrian bridge across. This is a game all about jumping and calculating risk, afterall, so that just wouldn’t feel right. The earliest way between towers is to make a jump between buildings from 6 stories up. After that, there are similar jumps spaced all the way up the game space, with a final jump from the top of one building to the other.

There are two considerations that had to be made for these jumps. First, I have gravity working in the game, so Pixxie doesn’t jump horizontally like a superhero. She jumps out, then falls in a downward arc, although one that is exaggerated a bit to increase fun. Second, the space between the jumps is great enough that you have to jump out blind. The player cannot see where they will land when jumping.

Instructing players to take these jumps is a difficult challenge. The first thing that I did was to ensure that Pixxie couldn’t make a jump to a higher story. I did this by not placing platforms on the story about the jump. Pixxie cannot vertically jump high enough to reach anything above her, but the next level of platforms is visible when she jumps from the 6th floor platforms. 

This creates an objective for the player, and a puzzle to be solved. They know they need to go up, and they see the platforms above them. They also know there is a second tower, which is blocked off to them at ground level. Here, the player may piece together that they can find the solution to both of their current objectives by jumping out to the other tower. 

In my playtests, this wasn’t the case. Players assumed the game was broken, because the solution was not obvious and the vertical design is antithetical enough to player assumptions about 2D platformers that the next action was not clear. My solution was to create an arrow that flashes on the side of the building above the platform from where the player would make their blind jump to the other tower. This is glaringly obvious, but it works, and more importantly, it keeps the player out of menus searching for answers.

Learning To Dodge

Platforming is fun, but there is an expectation that there will be some sort of external threats for the player to overcome. Using art assets that are available for free had some limitations, but I found some interesting assets to use. 

First, I added flamethrower turrets. They don’t rotate and track the player, because I wanted a static type of challenge to be overcome. They are timed to fire for a specific chunk of time. Each turret is timed the same way, so there is a specific way to time the jumps around them. Just as with the platforms, I placed the first one the player encounters early on a wide platform, so that the player can easily escape the flames and learn the timings of when it fires. In later levels, the flamethrowers are on much smaller platforms, and are trickier to move through.

The second enemy type are flying cars and bikes. I found these listed as background objects, and I put them all over the background of the game. Then I had the idea that they would be fun enemy type, not unlike Bullet Bill in the Mario Series. They move at various speeds, and can come from either side of the screen. This creates a variable challenge to be overcome. As before, I introduced the first flying car early, where if it knocks the player off a platform, the fall damage is still relatively minimal. By the time players reach a height from which a fall could end the game, they are prepared to deal with the challenge.

Putting It Together

Tower Hacker is my first attempt at merging the learning required of a game into the actual experience itself. I tried to use the environment and game assets to create an immersive experience, but one that doesn’t feel directionless. This led me to consider alternative ways that a player can experience learning, and the way that a designer can communicate to a player through design choices.

You can see Tower Hacker at DevLearn 2019’s DemoFest on Thursday, October 24, 2019.