Ascend is an atmospheric game in which you control a little square dashing around several maps, each with a different theme.

You can play it HERE. It requires a PC, a mouse, and about 10 minutes.

The twist here is that you can move at instant speed, but need to wait a brief delay before doing so. This creates a very short tension-release cycle, keeping the player on their toes.

The game was developed in 40 days by me alone, with music from external contributors.

What was the idea

After several raw prototypes, i wanted to try my hand at making a polished, complete game. I figured that I needed to go for very simple mechanics, so that I could focus on the execution.

A simple avoider seemed the best choice, keeping it simple while leaving a lot of room for level design. I didn’t want another follow-the-cursor, though, so i designed the game to have the square move istantly.

Once that was settled, I needed to put a constraint to the players movement, so I decided for a time restriction. At first, I thought to put a short cooldown after the movement, but that seemed artificial and counter-intuitive.

Putting a short charge time upfront, instead, proved to be an instant winner. With a few sound and visual effect, I was soon able to convey the experience I wanted.

What worked

The game has a nice atmosphere, and I was especially lucky in finding the right music reasonably quickly. This, combined with the text and the carefully paced gameplay, forms an experience of which I am rather proud.

As I mentioned before, I focused the execution this time around, and dug deeply in all the subtle ways in which I cou

ld affect gameplay without changing the mechanics. Animations, visual effects, sound and music all work together to improve the experience.

What did not work

The weakest link of the game was the way I chose to convey the narrative. The hovering text is often distracting to the player, while other times it’s simply ignored.
Better positioning could probably help, but I suspect I might need to rethink this feature from scratch.

What I learned

Mechanics are important, but the aesthetics alone can make or break a game. Small details and tweaks can go a long way and often have an impact on the gameplay.

The right music is especially important, and goes miles towards setting the desired mood. I was very lucky to find a great fit for the game.

Execution can be as important as innovation, if not more so. A well made game can be successful even if not particularly novel, while the converse is less true.

A few challenges and my attempts at solving them

The first bump was the sheer difficulty of the game. Even before asking others to playtest it, I had noticed that it was not easy to understand and predict the movement of the moving obstacles.

That, combined with the screen always scrolling down, proved to be challenging even for me, and I knew all the patterns since i made them.

The solve that, I started by adding several checkpoints, very close to each other. This allowed me more freedom to experiment with the difficulty, having short iteration cycles for the player.

This did not reduce the difficulty itself, though. What i needed was a more immediate way to help the player navigate the map.

 

Putting an afterimage on the moving elements worked like
a charm. The players (and I as well) were able to notice “safe spots” where they could land. This created an interesting “find the safe spot” gameplay, which worked really well throughout the levels.

As I said earlier, I tried to focus on the execution of the game. For this reason, I added a couple of visual and audio effects to the little square during the “charging up” phase, to help build up the tension up to the moment of release, when the square zips away (hopefully without crashing).

 

One of these effects has the square rotate on the spot while getting smaller. This caused some small problems as sometimes player landed very close to the walls, in spots where they were doomed to lose.
Even though they were still technically in the game, as soon as they clicked to move, the rotation would cause the square’s corners to contact the wall, resulting in a game over.
It was almost a pixel perfect situation, but it was perceived as extremely unfair by the players. In their eyes, they nailed a clutch landing and were rewarded with a game over.

I killed two birds with one stone by adding a “landing” animation to the little square. having the sprite stretch and squeeze in all directions ensured that close landings always triggered a game over, while also adding a bit of character to the game.

Another thing I did to sneakily tone down the difficulty of the game is the collision system itself. During movement, the collision is calculated on the blue dash trail, rather than the white square.
Since the trail is narrower than the square, it is often possible to pass through openings which should logically be too narrow. This way, the players feel very smart and competent even though they didn’t do anything too fancy.

For the same reason, I deliberately left in some “cheat routes”, especially in the first few levels. Some tricky sections can be passed easily by going around them, which is both an “escape route” if the players get stuck, and a way for them to feel clever, thinking they have defeated the game.