Hey, folks! As many of you may already know, I proposed to my girlfriend on, exactly, this year’s May 7. And, in order to do that, I made a game! *shouts and jumps frenetically*

This is the first postmortem I ever wrote, so I don’t even know if the information here will be THAT relevant for anyone. Hope my memory doesn’t fail me! Let’s see how it goes.

If you want to play the game, check it out on Game Jolt.

Evolution

The Dame And The Tower is evidently the result of my previous experiences. Many of the elements you see while playing are improved versions of a feature built for another game, often made in a jam, and I don’t think this is something I can be ashamed of.

The game is also the one I invested more time on the visuals. By comparison, when working on Caste Break, which uses some Game Boy limitations, most of the time was spent on mechanics, and I regret that a bit. Making efforts for a better presentation can help catching the player’s attention, so we should always aim for a good balance between the characteristics of our game.

Schedule and focus

The entire scope was defined very early, when still prototyping the game (around mid January): 5 levels filled with puzzles (each representing a subject that the tower would talk about with the dame), 3 extra areas for “plot” development and the final scene. I imagined a deadline to 6 months ahead, but then the proposal date would be near my girlfriend’s birthday. I didn’t want that, but also didn’t want to wait even more, so I had to hurry up a little.

Fortunately, the work on the previous games paid off in more than just having features to use as a base. My workflow was mature, and I had all the tools I needed to create content for the game. This allowed me to focus on the fun part, as I love creating levels. I could take my time and think about them calmly.

To be honest, when starting the project, I had a more polished game in mind. Torches with simulated lighting, moving curtains, different animations when holding items, a better hair for the dame. I even tried hard to do this last one, but designing hair on pixel art, especially when trying to replicate a real person… well, let’s say I’d have a long path ahead if I wanted to make art for a living! In any way, when I shifted my focus to the levels and to create the complete experience, my motivation to improve the game graphics, beyond the point it already was, dwarfed a bit.

Feedback

Through most of the 4 months of development, I wrote a devlog in a forum (in portuguese, too bad some of the screenshots are down), and that encouraged me more than anything. Having honest feedback and absorbing the constructive criticism is the most important thing you can do. That thread, along with my closest friends and family, were responsible for spotting many issues (bugs and gameplay quirks) that I wouldn’t find otherwise.

The problem that keeps popping up on my games is the elevated difficulty, and this one was no exception. I toned it down, little by little, but people still complained about some parts. My girlfriend even handed the controller to me in specific points. There were some puzzles I was sure she would get stuck and she solved them without thinking much, and that made me think that, as a game designer, I have a lot to improve. However, I also believe that, no matter how much you grow and learn about game design, player feedback will always be essential, and you will hardly get enough.

Framework quirks

I have been using cocos2d-js for quite some time, but when developing a somewhat more robust game than before, some problems arose. The HTML5 version of cocos2d is relatively new, and in some parts it can be seen as poor port. There were many inconsistencies between rendering on canvas and on WebGL, especially when scaling elements and using particles. Because of that, the final version of the game supports only WebGL. I’m sure the framework is constantly evolving and will get better in these aspects, but that caused me some headaches during the development.

Alongside of that, there’s audio! The used cocos2d-js version lacked a proper modern audio interface, and browser support is still a bit shaky these days. To workaround that fact, I’ve been using a custom integration between cocos2d-js and Howler.js, made by myself, but that’s far from perfect. Near the end of the project, a Chrome update broke the audio looping functionally. Fortunately, it was an easy fix, but this goes to show how targeting a single platform (or worst, a single browser, in my case) can be dangerous.

Box2D and platform physics

If you google about Box2d and platform games, what’s the general advice? DON’T DO IT. Stubborn that I am, I kept using it for almost all my games, and now I’m one of the guys that recommend against this particular use case. I went through a lot of trouble to support slopes, moving platforms, movable crates, among other small things. Not to mention this pretty common issue. If you like the precision offered by oldschool games, you should probably rely on something else, or even code your own library.

The proposal

I didn’t tell my girlfriend I was making a game, so when she came into my home and I said that I wanted her to test something, she was surprised. She found very strange that the game was apparently complete, but didn’t have a clue of what was going on. Seeing one of the easter eggs I included in the last stage, she only suspected something and still didn’t knew how it would end.

When the big moment came, and she said “Yes” to me, I responded: “it will only be valid if you accept it in-game”!

=D