This was my second Dare, and it was just as fun as the last one. I learn a lot from this process, and I am proud of being part of this incredible welcoming community.
The concept
The game is based on an idea I got a few months ago. I’ve wanted to try out this idea for a while, just to see if it would turn in to an enjoyable game. After seeing the end result of the voting rounds, I immediately thought that this would be a good opportunity to try to implement this game.
The premise of the game is simple: Wolfenstein converted into a turnbased puzzle game.
What went right
1. The engine
An engine like the one used in Wolfenstein is quite easy to implement using the technology that exists today. Back in the days you had to implement it all in software on hardware that merely were fast enough to draw graphics at that speed. I went for a really easy approach where I simply put a lot of textures cubes on the screen. This works fine as long as the maps arean’t big enough. Using this method, it was easy to implement a simple tilemap loader that put the cubes at the correct position in the world with the right texture.
2. Known library
Unlike my first Dare, I used a library I’ve used before. I used the same library as I used for my entry for Mini-LD #28, Three.js. This turned out well, as I could be productive from minute one.
3. Level editor
In the middle of the implementation process I figured out I needed some way to define the levels. I figured I did not have time to write something myself, so I checked out a few tilemap editors I already knew, but none of them would export to a javascript-compatible file out of the box. Some of the editors support writing custom exporters, but I didn’t feel like brushing up on my Lua experience. I therefore went for an easy middleway where I used Mappy to build the levels. I then exported them to text format, and copied part of the text over to a custom made fileformat using json. This solved my problem completely, and worked well for my use.
4. Browser standards
For this entry I used some of the latest HTML5 technologies. It’s suprising how well the standards are defined for both WebGL and HTML5 Audio. When I’ve implemented the engines using Chrome, and then tested it using Firefox, it seemed to work with almost no changes. The only change I had to do, was some error checking for loading audio for Firefox.
What went wrong
1. Postponing sound
Once again I postponed the sound and sound implementation to the last minute. Sound creation went fast as always with the mighty powerful BFXR. Earlier I’ve used a sound library that uses Flash for sound playback for maximum browser support. But I figures as I’m using WebGL, I could as well use HTML5 sound, even though it is not that well supported yet. I’m pretty sure that if your browser supports WebGL, it will also support HTML5 sound as well. Problem is, I’ve never used HTML5 audio, so I needed to learn it as well. Turned out that is wasn’t that hard, and within an hour I’ve made a very simple sound engine for my sound and music needs. Before the next Dare I should probably create a sound library that I can use instead of having to struggle with sound once again.
2. Lack of artistic skills
This is a general problem with my entries. I lack the artist gene, and is therefore not able to draw pretty pictures. This is shown in most my entries, where I try to minimize the damage done using as simple as possible drawing. This time I needed to draw a simple character, and it turned out ok, but I think I should stick to mechanical constructs ahead to avoid having to draw organic objects. The same goes for music. I found this really nice tool before the competition that I thought I should be able to use to make simple music with, DrumCircle. When I sat down with it, however, I could not create anything that sounded like music, even though I succeded using it a lot before the competition. I therefore ended up using elevator-music generated from Wolfram Tones.
3. Difficulty level
I really misjudged how hard it would be to play the game without a minimap. I intentionally did not include a minimap just to give the game a little more challenge. After reading comments and seeing friends play the game, it seems like a minimap is a must for this game. It is also har to judge how far you’ll step using a single arrow because of the lack of a visible grid. This was also caused in part by the lack of variation in the wall graphics.
4. Level design
I had no clear idea how I should design the levels, and how I should design their challenges. With that in mind, I ended up using scare-tactics as a gameplay element. The challenge of the game became the avoidance of the guards. I initially intended to add sophisticated shooting-mechanics into the mix, but it turned out that running away from guards was enough.
5. Rough introduction
There was no tutorial in this game. You was thrown right into the frying pan, causing all kind of confusion because the player had no idea on how to play it. This could be solved by having a more sandbox-like first level with some popups appearing when the player walks over given points. As it is now, the player is greeted with a wall of text at startup, and you cannot really play the game without knowing the bare basics given there.
6. Irritating UI
I implemented the UI using JQuery and JQuery UI. These libraries aren’t really made for games, and it shows in this game. I wanted a queue of commands for the pleyer to execute. This queue could become taller than the height of the screen. Instead of allowing full window scrolling I made a smaller area with a scrollbar. It was then possible to rearrange items in the queue by dragging each command up and down. The problem with this approach was that it was possible to scroll past the horizontal and vertical edges of the queue, which made it quite hard to predict what would happen if you dropped an item at times.
The future
If I get the time, I will try to improve on the game, and maybe even add a few features.
1. Minimap
I would like to add a small minimap for the players to easily orient themselves. I’m not sure if I should place enemy markers here. I should at least mark their position if they catch you in case the camera is not in the correct direction. I should probably change the camera angle in any case.
2. Level grid
A visible grid that gives an indication on far you will step if you add one more move action to the queue.
3. Less annoying interface
An execution queue that does not scroll at its own will. I will probably implement this using a canvas where I calculate the position of the individual queue elements myself as well as accepting the input.
4. Speed of execution
Buttons to control the speed of playback. Too often it feels like it takes an eternity to make the player avatar move.
5. Conveyor belts
This is a new gameplay element. I was thinking about adding conveyor belts that you could push crates onto. This would give the possibility to kill enemies by pushing them with the crates. This idea came from reading about the board game Robo Rally.
Tags: postmortem
