The Thief Pre-Post-Mortem

Now that the ratings, reviews, feedback and comments are quieting down, I’ll jot some conclusions I’ve come up with. I call this the pre-post-mortem because The Thief is not dead just yet. But first a very important link: http://www.ludumdare.com/compo/ludum-dare-27/?action=preview&uid=5344

The Bad

Last minute sound effects

I wasn’t planning on adding any kind of sound effects, because I don’t how to properly create sound effects. I’ve used bfxr before, so I thought, why not use it to make simple sounds. All sounds are cool, except for the footstep sounds.

They were placed in the game 15 or 30 minutes before the deadline. And, at first, the footstep sounds sounded nice. That is, until they stopped sounding nice. The footstep sounds have two major flaws: they are loud and repetitive. Of course, one can mute or lower the volume of his or her sound producing device, but when developing a game, that option should be considered.

So yeah, people seem to dislike the footstep part.

Bad difficulty curve

The game turned out harder than I expected it to be. I didn’t set out to make the next Super Meat Boy, Biding of Isaac, Dark Souls or [insert hard game here] like many Ludum Dariums I’ve seen… I wanted to make an acessible, fun and challenging stealth/rush to the exit game for all ages and all kind of gamers.

My goal was to make the game harder as levels went by, but on a linear scale, not on an exponential-ish scale. You can see what I mean on the super accurate and scientifically proven graph of level vs difficulty displayed above. It has labels and everything!

Could use better levels

The phantomed and feared third level

There were only four levels. And I was planning to make eight. The problem? I haven’t any real practice on level design. Seriously.

I’ve made levels for Counter-Strike, sure, but those are 3D levels. And those levels were based on some real live enviroments (I made a CS map based on my high school). I tried the same approach with this, but somehow my mind got blocked when designing levels.

The third level (the “hard” level) is where my mind started to block. I spent too much time on it, trying to “balance” it. But in the end, I messed it up. The player hasn’t much places to escape, he/she can get spawn killed (as featured on this video).

Rough corners

Well this is Ludum Dare. People make games by themselves in 48 hours. Some rough corners are expected to exist.

But not that I said some. For instace, the guard collision detection could be much more forgiving (by that I mean less frustrating) if instead of using corner based detection, I used a radius (or circle) based collision detection.

Other rough corner is the inability to turn off sound effects. They were an after tought, and there was no time to implement a menu system, nor will to add a simple clickable/touchable button to mute.

But the biggest rough corner of them all, is the title screen. That was the last big thing to be made. And was made from scratch in 5 minutes, within 30 minutes before the deadline. I am not proud of it.

The end screen, for the few who have seen it, has been a bit rushed.

And finally, the fades between screens weren’t made in the best possible way.

The Good

It’s finished and people seem to like it

Yay! I finished something! It’s a rare feat from a person such as myself, but with its flaws and everything, I think this is a complete game. All it needs now is more levels… (Really, I am pretty happy with the “engine” I developed from scratch in 48 hours).

I’ve been receiving mostly positive feedback. People seem to like the game, and most of all are having fun with it.

Runs and controls smoothly

My first priority was the game “smoothness”. The game had to run smooth everywhere and be responsive anywhere.

To do that, I tested (and requested people to test) on a variety of browsers and devices. I read some documentation on how to optimize rendering and javascript execution (without minification, and other stuff that obscures code). I am proud of some of the simple optimizations I made: drawing to a invisible canvas (acting as a framebuffer), and after all that draw to the visible canvas (making a flip of the framebuffer). Other simple trick that sped up rendering was drawing the background layer to a “framebuffer”, and then render from there.

I made sure that I had a control scheme for everyone:

• Arrow keys, WASD (my favourite), ZQSD (for AZERTY keyboards)
• Mouse clicks and drags
• Touch and drags (on mobile devices)

Enemy AI

At first, the guards were just dumb NPCs, moving randomly. They chose how much time were they walking and on how much time would they do it. If they bumped a wall, they would change direction and their walk time again. Simple algorithm, but too chaotic. I was impossible to strategize any move.

Then I realized they needed some guidance. Some predefined paths would really help. This way, the player would watch them, and then, without any kind of luck involved, he/she could plan their moves. So I created an AI system that is explained here: http://www.ludumdare.com/compo/2013/08/24/the-guards-have-a-will-of-their-own/

But after that, they were still dumb. They would just follow the orders that were on the AI tile layer. So, two hours or so before the dealine I wrote code that sums to this:

if (distance(guard, player) < guard.aifollowdist) {
   guard.order = "follow";
}

With these lines of code, the guard follows the player if he is in his radius. This rather simple change made the game more fun, and so I tweaked the existing level designs to somehow work with this new mechanic. Finally, I added a little exclamation on top the guards when they started chasing the player.

Camera movement

The camera movement was way to simple. It just followed the player (well, now it still does), and it was a fixed camera. It lacked some dynamics to it. But that was about to change, when Aurel300 responded my plea on IRC to test my game, and noted how much my camera movement sucked. So as good man that he is, Aurel300 provided me with a simple algorithm to improve the way the camera moved. In my mind, it radically gave the game a better “feeling” to it.

Reviewers and Raters Wishlist

I read every single comment posted on IRC, on my livestream and on the game page. Every piece of feedback was noted and stored. So here’s the compilation of what people seem to want on my game:

• More levels;
• More guard types with consistent behauviour;
• Better footstep sounds;
• More ways to hide (for instance, hiding in the shadow, behind the walls);
• Add line of sight detection to the guards instead of using zone detection;
• Make guards unable to see through walls;
• Better graphics.

And I throw more bullet points:

• Add a radar (small screens can see the enemy movement as easily);
• Fix enemy chasing (use proper algorithms to find the shortest path);
• Add music;
• Add cameras, spotlights and lasers to detect the player;
• Some way to save progress.

I’ll do my best, in my spare time to implement all this.

Conclusion

I hope, once in my life, to make a game (however simple) from beginning to end. It will take a lot of code refactoring (believe me, that code is ugly). I need to learn how to draw more properly. Or maybe get some help to properly finish this game (any volunteers)?

I am pretty happy with how this game turned out. It’s a nice piece of software that I can add to my portfolio. The project will live on, to the public on https://github.com/N0NamedGuy/The_Thief

So, if you haven’t played The Thief, you still can check it out at http://www.ludumdare.com/compo/ludum-dare-27/?action=preview&uid=5344

N0_Named_Guy signing out.