First time entering an LD and I’m finally done! Strengthen your wall of doom and see how much of the city you can destroy.

There are a few glitches but none that would be game breaking and also there’s no sound. If the game doesn’t run you may need to use flash player 10.

Play Game in a browser

Download Source:
gzip
zip

Tags: final, flash

My original concept for this game was to make a metroidvania type game with at least one normal enemy(a bat; every cavern game needs a bat) and one boss. The end result was much different than the original concept but things seemed to work out in the end even after dropping a few elements.

The game

What went right

• The language chosen(haXe)
  Learning to use haXe and using haXe for the game worked well. The language is very similar to actionscript 3 so there weren’t many times where I had to search for documentation while programming the game. This made porting my as3 framework much easier.
• Dealing with game assets
  I had an asset loader written in perl so that would run before the game built. Any asset that I wanted to add could just be placed in an image and sound folder and used in haXe with all the needed classes set up. This saved a lot of time and let me see how things looked in game instantly without having to change any code or playing around in FlashDevelop.
• The removal of original game concepts
  At roughly six hours before the end of the compo, I only had the player art and code done. If I tried to add an enemy and a boss, I would probably have gotten stuck on the art portion and would have had a game with just a player walking around. Adding the relics made the game a little less empty with some sort of objective to reach while keeping the implementation time low.

What went wrong

• Collision detection
  Implementing collision detection took almost a day to get somewhat right. Additionally, I never added the collision for ramps so walking on those tiles may have seemed a little odd. Jumping into a tile from the bottom sometimes warped the player to the left or right edges of a tile.
• Music
  There was actually music in the game. If you turn your volume up enough you might just be able to hear it. The music was originally much louder than it was now but it was repetitive so I turned it down so that no one would notice it.
• Art
  I only had one set of tiles done and no background tiles in the game. If you look closely at the player, he never alternates the foot that steps forward when walking.

• Game length
  The game was very short. Originally, it was only about collecting three relics and the player would win. Even after adding in the secret path, the game still felt like it should have had some more things in it.

How the relics came to be

• The double jump relic was planned for in the original metroidvania concept.
• The ability to look backwards was made due to not having backwards implementation done yet. I originally decided to just have the player moonwalk backwards due to time constraints before I changed my concept.
• The sight beyond sight relic was really just enabling the user to see the debugging hitboxes on the player. The white rectangle represents the player hitbox, the yellow boxes represents the tiles checked and their hitboxes, and the red represents colliding tiles.

Overall, I was pretty happy with how the game turned out. I was planning on moving from as3 to haXe on newer projects and this compo gave me a crash course on it.

Day 1

This was my first time creating a game in javascript so I kept the game design simple.
On the first day of LD27 I made notes on what the game will be like and drew a simple view of the playing area.

Day 2
I did not work too much on the game during day 2. Most of the time was spent working on the game design and learning javascript. I added some basic javascript and HTML/CSS for the layout and very little game logic.

Changed Mechanics
Some of the mechanics were changed or dropped as the game was being made.
Some notable differences are the store, running away action, disappearing skills, stalling, and popularity.

The store was changed to allow healing and refilling all skills.
Healing gives the player another decision on what to spend money on. With how random the final game is, buying healing felt too punishing. A full heal after each round may be able to stabilize the randomness more.
Disappearing skills was removed in favor of skill refills. Refills allow the player to decide if they wanted to reroll or keep their skills.

Stalling changed from adding turns to being a stun. Adding turns went against the theme and it would have made the player’s skill usage choice in combat trivial. A stun allows players to heal up or ignore healing skills so that turns are not used by them whereas adding turns would allow the player do everything unless the client damage was very high.

Popularity was originally going to be used as another way to lose the game and get stronger clients. Different levels of clients would show up based on the popularity which would allow the player to choose which client to work for. Popularity would be decaying after each client and more after each failure. I could not think of a way to balance this in time so I went with a simpler route and had the game be level based. Popularity is now just a way for the player to level up their maximum random skill limit for rerolls.

Day 3
Day 3 was when I added in most of the game logic. When implementing game logic I also refined the design a bit more.
Some attempt at balance was done with client stats and costs. Due to the randomness of the game and how little skills were involved in playing, balancing with just those parameters was difficult. A more fair rerolling method would probably have had a greater effect on game balance.
Polish was added to the game such as attack messages and descriptions for each client. Colors were added during the last two hours of LD27.

Closing Thoughts
Javascript/HTML/CSS turned out to be a good fit for a game that’s text and buttons. Changing states in the game was as simple as setting the display to none and resetting displays when changing back. All the core objects in the game were global and public which is good for prototyping but does become harder to maintain. Having everything public caused some problems during the end. I sometimes set variables directly instead of through a method that updates the variable and the display at the same time.

I did not like how reliant the player was on getting good rolls. Money is too limited to allow players who got bad rolls to reroll again due to the costs of healing and popularity increasing. Having a longer game would have allowed the player to build up skills. A longer game would prevent a single strong roll from winning the game because the player would still have to level up to get even stronger skills.

Here’s a link to the game – LD27 – Sleep Consultant
The LD27 page – LD27 Submission

Tags: postmortem