Ninja Flare Post Mortem

Posted by
April 30th, 2013 6:08 am

So A full day on from the deadline, it might be a good time to reflect on the process and lessons learned through development of Ninja Flare.

First off, I compiled a little footage made looking at some of the backups I made of the game during development. This might give an interesting insight into the way the game was put together, and the order that things appeared in the game.

When the first list of final themes was put together, I tried to come up with a plan for each of the games, all 25 or however many there were. Some ideas spanned multiple themes so it made sense to try and cover as many as possible. I was really happy when ‘minimalism’ was chosen because Ninja Flare was a game I really wanted to have a go and make. The idea I originally had was very different to what was produced however and there were a few lessons to be learned from that.

My original idea was that you would play a ninja, in a run and jump setting. The loose storyline was that you were an assassin sent to kill the emperor because he has neglected his people and was corrupt. The game would start with you killing the emperor and then being chased by his elite guards, thus satisfying the need to run in this game. If you would be too slow then they would catch you and kill you, game over, try again. I also knew that for this kind of game to really work, the levels would need to be procedural, so that was on my list of things to do, although I didn’t yet have an idea for the full setting. My loose idea was that it might take place in the city and you would be running over roof tops.

Thinking back this was not really a strong enough game concept or plan, since there was still too much to decide upon, and I had no idea how most of the systems in the game would actually be implemented. I was panicking due to the deadline and I just wanted to get something running and start developing, so in future it would be better to remember that planning properly saves time in the end.


My first step was to create the player sprite since this would be one of the most important elements of the game. I also wanted to make a mockup of  the backgrounds etc to really get a feel for the aesthetic of the game. You can see the original mockup above. At the same time I started to program the player code and render him just as a rectangle, focusing only on the physics themselves. Pretty quickly the ninja sprite was integrated and tweaked to look right. Next the camera system was implemented. This was first done by giving the camera physical properties and accelerating it towards the player character, but in the end this changed to make it more stable and responsive.

I started to avoid thinking about the hard things and instead opted to add quick things to make it feel fuller, such as particle effects for his sliding feet, and leaves that fall across the screen to give a sense of the speed of movement and some depth to the world. In an artistic sense I wanted to avoid that it feels like everything is happening on one plane, so I wanted a foreground, mid and background with appropriate parallax.

Eventually I pulled out my sketch pad an came up with the idea for how to procedurally generate the levels in the game. This is essential the concept I used:


The width of the ledges are random but they are bound to have a minimum and a maximum size to keep the level progressing, and to avoid super tiny ledges. The space between each new ledge is random, but can also be zero, since that is not a problem. The height of each new ledge is calculated as the height of the last ledge plus a random factor. The ledge height is then bound by a preset maximum and minimum to avoid this randomness taking the player slow way up into the sky or way down load with each new platform they jump on. It might not seem necessary but the way I implemented the parallax for the foreground and background, I needed the player to stay in a known region in the Y axis for best effect.

The ledges were stored in an ordered array from left to right of the screen, and as soon as the rightmost tip of the first ledge went off screen, I would pull that ledge out of the array, shuffle them all down, and generate a new ledge at the end of the array. This gave an infinite supply of ledges for the player, and is quick and simple. We just care about the level as much as what can be seen by the player, and they don’t care that the level doesn’t actualy exist behind or infront of you, thats realy just an illusion.

After this was implemented, I still had little idea of how to implement any form of enemies, or the enemies that would chase you across the level as I originally planned. I opted instead to fill my time adding little visual features like the clouds in the background, the sun, the grass, trees and pigeons, etc. Looking back that was really just because I wanted to avoid thinking about the difficult part.

I did however come up with a really nice effect for the sun in my opinion and it was super simple to achieve. I started with a fast circle drawing algorithm and decided that to create the heat ripples I wanted I would need to disturb the X location of each row in this circle as it was drawn. By storing the disturbance values as an array, the height of the sun, I could store these offsets and easily modify them to create the animation. I employed a very similar technique to that used in my level generator. Each frame I move the array up one place, and add in a new value in the space created. This new value, is just the value one place ahead of it in the array, plus a small random value. This then gets limited to avoid the sun being able to drift by accumulated randomness. In signal processing this acts like a form of high pass filter.

I also realized that I needed to add in objects to the platforms since they manage to convey the players speed and location and give the player some kind of reference for where the player is in the world. With solid blocks of colour, the only reference the player has is the gaps between the platforms as they move across the screen. It is crucial that the player knows exactly where they are and how their character is moving during the game. I added the grass and trees and such things to try and help this situation.

The enemies were the last thing that I put in and this was done when there was only around 6 or 7 hours of time left. This was a huge mistake to not give myself enough time in this respect because the enemies are the challenge to the game. Without some kind of obstacle for the player to overcome or any challenge to have to navigate, there really isn’t a ‘game’ in my opinion. In Ninja Flare, the baddies were added without much thought to their purpose or the challenge they would provide.  These enemies were quickly drawn up with the player sprite as a base. There is a pool of 6 enemies that is reused through out the level. Dead enemies are taken from the pool and inserted randomly on top of the first platform that is currently  still off screen to the right. They are removed as soon as they are off screen to the left and added back to the pool of enemies, waiting to be recirculated again. There are about 6 possible enemies in the pool, so that is the maximum number that may be generated by the game. They follow a simple state machine, so that if the player is on their platform and in range of them then they must run towards him. If they are very close to him, then they should swipe at him. If he is past them then they sit idle, because I didn’t want to have to mirror the sprite to have them running to the right.

Unfortunately the last few hours of development were rushed into creating a menu, and making the player able to kill these enemies and also be killed by them too. I wasn’t able to tweak anything to create a real challenge in the time I had left. So they exist in the game as an unfinished challenge. There wasn’t enough time left in the end to even implement some form of scoring, so the players don’t really feel like the game is rating and challenging them. But lots of people seem to like the time I spent on the graphics and not on the game play so it want necessarily wasted, just misplaced I feel, in the challenge to create a game.

The main lessons that I take away from this, my first Ludum Dare is this:

  1. Proper planning is essential, since without it time will be spent in the wrong areas without a clear goal of what must be done.
  2. Only focus on the most important elements of the ‘gameplay’ first. The ‘gameplay’ IS the game so that must be focused upon.
  3. When designing, really try to understand how each feature should be implemented, to check if it is feasible in the time available.
  4. Don’t plan around things that you don’t have a plan of :)
  5. Ludum Dare is fun as hell 😀

Ninja Flare can be found here:

Leave a Reply

You must be logged in to post a comment.

[cache: storing page]