Firstly, if you’d like to play Javel-ein before reading on (there aren’t any spoilers below, but it might make for a better experience to play the game before going into the analysis), please visit my page. The updated version has a few nice improvements such as a boss, slightly improved sound, small level tweaks and a timer, but it was made afterwards. You can also find a short video of the first few levels here.
My take on this Ludum Dare’s theme was that You Only Get One Javelin. You can throw it to kill an enemy, but then you have to pick it up again. As a result you have to be careful when aiming to not just hit the enemy, but have the javelin easy to retrieve afterwards. My goal was to have a fun, fast, action-filled platformer with a plethora of levels exploring the mechanic to its full extent. I’m super happy with how it turned out but there are still things which could have gone better.
I should warn you that most of what I talk about in this post mortem is obvious stuff: falling (or not falling) for bad design/programming/planning habits.
Taking Time To Think
Before doing any coding or graphical assets, I went for a walk and gave myself plenty of time to come up with an idea. I reasoned there was no point spending the weekend making a game I wouldn’t enjoying making, or wouldn’t enjoy playing. Really cliché but also really important.
Deciding On A Style
Straight away I decided on a very particular style and stuck with it: Low color count pixel art with large blocks of the same color. No outlines, no dithering. No wasting time endlessly redoing graphical assets because I decided to completely change the style (this happens a lot). I quickly went with a color palette I’ve been eyeing for a while, and which I really hope to use again, DB’s 16 Color Palette. Immediately I started work on the tiles and the hero. My first hero designs were… not the best.
Not the best at all.
From there I built up all the art assets focusing mostly on keeping everything cohesive and I think things turned out pretty nicely in the end.
Testing Levels, THEN Tiling
This is really obvious but it’s something I’ve always done wrong in the past. Instead of:
- make a level using featureless blocks
- test it thoroughly
- add tiles, features and flourishes
I will often end up doing the following:
- make a level using featureless blocks
- add tiles, features and flourishes (wow, the level looks so good!)
- realize the level has huge problems and will need to be heavily reworked (oh.)
Like I said, really obvious. I managed to (mostly) get the order right this time.
I guess, for me at least, this is the big one.
When I began designing levels I focused mostly on exploring the mechanic of having to retrieve the javelin after each throw. I wanted to promote situations where the player would take out one enemy with the javelin, leap over a second enemy and reclaim the javelin moments before being attacked by a third enemy. While this does happen occasionally (especially in some of the later levels and the boss level), most of the time the best course of action is to aim at the enemy’s feet and quickly pick the javelin up afterwards. This led to combat being more methodical (think: jump throw kill grab jump throw kill grab) and less free form, which is what I was originally hoping for.
One solution I thought of much too late was to implement platforms through which the javelin could pass (jump-through platforms, or grates, or something similar), since having enemies on these platforms would mean the player couldn’t always simply aim at the floor underneath the enemy.
Heavily related to combat is something else I had to leave out: more interesting enemies and traps. I had originally wanted to include enemies that shot at the player, as it would be tempting to pick them off from a distance but this would mean having a hard to retrieve javelin. I also would have liked to include reactive traps, ones that shot arrows or released an enemy when you triggered them.
Not much to say here except I need much more practice and experience when it comes to producing sound effects and music. Some players (quite rightly) found the sound effects unbalanced and others found them too harsh. Creating the sound effects earlier and getting feedback on them would have been very useful. As for the music, well, there isn’t any. And its absence is deafening. I spent a good deal of time trying to create appropriately ambient music with no success, and this is something I very badly need to work on.
In some ways this point sums up the previous two. Over the entire weekend, I wrote up only one list. Here it is, reproduced:
My goals for the next few hours are (in order of urgency):
- Create ground based monsters that chase after you.
- Create and refine a plethora of levels, without tiles.
- Tile the levels and add thematic features.
- Create a better jumping animation.
- Create a title screen.
- Add sound effects.
- Add music.
Let’s see how well this plan fares.
What’s great is that I managed to get through the first six points in this list! What isn’t as great is that there were dozens of smaller things I wanted to do or should have done, but forgot or set aside because I never had them written down anywhere. I would have benefited greatly from a constantly updating list of priorities.
Overall I had a great (yet sleep deprived) time creating Javel-ein and am really happy with how things went. The points I addressed are things I plan to keep in mind for the next Ludum Dare.
Thank you so much for reading this! I hoped you enjoyed it and perhaps even found it marginally useful somehow. If you give Javel-ein a go I would love to know what you think of it!