Architector: Gameplay dissection

Posted by
August 23rd, 2010 10:32 pm


This is a dissection of my LD18 entry Architector which details some of my design decisions and processes, good and bad. Hopefully this can be helpful to someone.

I was the only one testing this game, and I only did very short testing sessions. This makes for a very hard game.  I didn’t see things like the player’s survivability or how hard it could be to scale a high tower. The double jump was actually a last minute addition that proved to be very necessary to facilitate climbing.

Killing enemies is what makes the game advance. This is meant to keep the player in the action and to keep them from avoiding the dumb enemy AI too much. I struggled between this and time-based block dropping which would have put an emphasis on survival, but I felt that the sudden shifts between the gun mode and the block mode needed to be under the player’s control somewhat.

The game feels a bit slow to progress; the goal is pretty high due to aesthetic decisions and the blocks are a bit short. I am considering having multiple blocks drop in a row for a post-competition version.

The camera is a frequent complaint. Due to some limitations in the framework, I could not have it zoom out, which would have been best. I instead opted to have it be under mouse control. In gun mode, this makes for difficult aiming when the player is moving, which encourages the player to stay still while shooting.

One hurdle was making the falling blocks not too confusing to control. The layered colors in the sky give a sense of height, and the camera control helps give a better sense of the surroundings. Still this is no replacement for a good zoom out.

I had to make the blocks so that the player would not get stuck too easily and could make something scalable. The blocks collide on their background tiles, which creates space between the tiles the player can interact with.

Scaling the tower is facilitated by the double jump and the dragon, which can be used as a rocket pack by firing it downwards while jumping.

A good platformer jump is a tricky thing: it needs to happen right away, but its height must be controllable. I do this by making the gravity lower on the player when the jump button is held down.

There are three kinds of enemies in this game: the flying fish, the bat and the dragon. Enemies are the first thing I programmed into the game; the blocks falling and tower making dynamics were an idea I had when I saw Lame Castle, Skyscraper and build the level you play in the suggested themes. It’s also a bit of an homage to Homestuck.

The bat homes in to a fixed distance from the player, which varies from bat to bat. Its quick scattershot is hard to avoid but deals low damage. This, coupled with the fact that it keeps its distances and that none of the weapons are good against far away targets makes the bat dangerous, hence its low damage and health. In the player’s hands, it becomes a  low damage scattershot, good against other bats and groups of enemies.

The fish fires bubbles which float upwards, making it dangerous to enemies above. It deals a lot of damage but can be difficult to use against ground targets. As enemies, they slow the player’s ascent; the floating bubbles miss often when the player is bellow, but when the player is above they are deadly. This makes it dangerous to move past the flying fishes.

The dragon is the only ground enemy. As such I made it allergic to being too far below the player. It drops from the sky like the rest. It walks towards the player, periodically jumping to navigate the terrain. When it’s near enough it locks in on the current angle towards the player and waits a moment to fire. This makes it possible to avoid it by going behind it. As a weapon, it becomes a short range flamethrower/jetpack.

Am I missing anything? I’d like to know where I am right and where I am wrong.

Leave a Reply

You must be logged in to post a comment.

[cache: storing page]