Postmortem MiniLD #31

Posted by
January 24th, 2012 5:56 am

Over all, the development of this game went a lot quicker than my December entry. I had a partner and we knew pretty early on that we wanted a game that used the uncanny valley and time to create fear. Our design called for the people on each floor to slowly turn into … something else, while a darkness creeped around you, even starting to turn the player. A puzzle game with a time limit.


We used ImpactJS, JavaScript, Canvas, HTML5 to develop this game. I used it in December and really like the engine. It takes care of the details involved in a game engine while still giving me the source and power to bend it to my will. We ended up not changing anything with the engine it’s self and just focused on creating entities.


What went right:

The entity system worked really well with my partner. We split up the entities we thought we needed and we each developed them independently in our own little test level.

ImpactJS has a great level editor that let us quickly build some prototype levels. We realized that we wouldn’t have time to create the changing co-workers or even the dark cloud taking over the tower. We reduced the game to just a puzzle platformer.


What went wrong:

I over abstracted and complicated the puzzle logic. During the planning stage the idea was to create an itemGoal entity that could be configured to activate when the player has specific items in the inventory. It could block the player’s way or even give the player new inventory items. Sounds simple enough. But then we needed an entity that allows the player to only move though it in one direction (so you can jump up though an object and stand on the top.) So we made the itemGoal inherit from the oneWay entity so it could use that behaviour. But as we developed the actual level, setting up the configuration for each itemGoal was troublesome. Items started to become inconsistent, like filing cabinets that you can stand on in one level but not in the next level.

It would have been better to create specific entities for each item instead of a generic itemGoal. We ended up needing to do this anyway for some items like the door, grate, and fire. I’m sure there is some logic that could be in a base like checking the player’s inventory, but all that configuration only got in the way.



I think the game turned out pretty well. It’s better than my December entry and the programming only took about 12 hours. Creating the levels took another 12 hours but that includes creating the art. I think the game has promise so I’m going to refactor it and continue development.

Leave a Reply

You must be logged in to post a comment.

[cache: storing page]