Ninjah 2 is back in active development

So recently I’ve been working on Ninjah 2 again. I last worked on it properly about 18 months ago and while there was a lot that I liked about how it was going, I see now that there are plenty of areas for improvement, which I have now done! As an example I had been storing levels in a weird clunky CSV style format that I made made myself, not because I thought I knew best, more because I didn’t know enough about what was out there. It seems crazy now, but I hadn’t really used JSON at all back then and now with my day job I use it daily so it makes sense that I use it for Ninjah 2.

This will also lend itself well to supplying and sharing levels through the internet. I had hoped to do this through Steamworks, but as I need to have my game Greenlit before I can even test Steamworks, I’m making my own API which I probably intend on making freely available so people can host their own servers if they’re in to that. This then got me thinking about how I could have a master server, that these servers could register with and allow people to connect to (if they wish obviously!). I’m waffling on a bit, but it got me thinking of the days of Quake and Tribes master servers, I never really saw the point back then, but now I’ve stumbled upon it!

The information I was storing within these level files has also been overhauled, I was trying to get a bit too clever and allow for completely unrestricted data and values. On face value this seems like a good thing, but in reflection it could probably lead to issues in the long run. Each level can have it’s own values that manipulate the in game experience, for example, gravity, jump force, shot force etc. Previously I had been storing the exact float value for each of these, but now I’ve just opted for a range of integers between 0-20 that are converted to the relevant values at run time.

I had also been doing some pretty pointless things in relation to how the information was being stored. I had multiple lists, each one consisting of each type of object in the game. Now I just store a 2D array of everything, in the level files and in the editor. This is only converted to the relevant lists during run time, which is much much better and more elegant.

I had mentioned that I intend to add more in game objects other than the rope, gun, colour change and coin mechanics included in the first Ninjah game. I think I intend on staggering this by releasing a new in game item every X weeks, we’ll see!

Ludum Dare 31 – WASD

Hi all,

at the last minute I decided to enter Ludum Dare 31 “Entire Game on One Screen”. In the end I was barely able to find 12 hours for it but some what surprisingly I managed to actually finish something!

I present WASD!

Ninjah out on OSX

Evening, long time no say anything at all.

You can now download Ninjah for OSX for free from the Ninjah page.

I recently received an email asking if there was any particular reason why Ninjah wasn’t out on OSX. Literally the only reason was that I didn’t have easy access to a Mac (which is required to compile for Mac).

A client I am doing some work for has a Mac and I was kindly allowed to use it this weekend to build stuff. So over a really shaky remote desktop connection and I managed to compile it.

I’ve had one person test it for me (thanks Maarten) and I believe it works OK


You Only Get Won – LD28

Hi all!

Here is my entry for the Ludum Dare 28 competition themed “You Only Get One”: You Only Get Won (hah! Word play!!!)

You Only Get Won

Currently it’s just a flash version (sorry 18mb as well…), but I hope to have it ported to Android as well in the near future.

I’ve really enjoyed myself this time. It’s a collection of three mini games. The aim of the game is to NOT get won. Oh yeah, you’re a stuffed toy prize at a travelling fair.

Here’s a timelapse of me making it too!

Making a game with a 6 year old

One of my most personal bonds with my six year old step daughter is computer games. I’ve always loved computer games since before I can remember and I am very happy to see Faye really enjoys them too. In early 2012 I finally bought a computer capable of playing games and one of the first games I tried was Minecraft. I had played it before having bought it in 2010 but the rate at which it was updating soon made it unplayable on my modest Thinkpad.

I knew it would be exactly the type of thing Faye would enjoy (she loves organising things, opening things, putting things in things, taking things out of things, building things, destroying things, things) so one morning when I was looking after her I showed her. She fell in love instantly and it’s still something we come back to at least once a week (usually more often), from my experience this kind of longevity is unheard of when it comes to entertaining kids! I could go on about what other things she enjoys playing but I am getting past my point.

Faye knows I use a program called Monkey to make games and she is well aware I made the You Are The Yeti game during an LD48 competition. She had lots of suggestions that I just didn’t have time to implement, but I loved the fact she was interested.

I’m not sure how it came about but a couple of weeks a go I asked her if she had any game ideas and she launched into a 10-15 minute non stop game ideas pitch. She was genuinely excited and enthusiastic about it, so I made a point of writing as much of it as possible in a Google document. And so was born the design doc for NIMBLE BAT! The name is very much inspired by the game Nimble Quest, but that’s where the similarities end. I don’t want to go in to too much detail, but there are bats, there is a pet shop, people steal things at night and you collect things at day (plus 50 other ideas).

The plan has no cohesion, no real structure, is full of half baked ideas but honestly, who cares? I get the impression that’s kind of how Minecraft got started and that worked. I say “who cares?” but I think the game designer in me would probably scoff at it had an adult presented it to me. I’m trying to get on with a “proper” game, Ninjah 2, and this will no doubt get in the way, but I think I’d have to be pretty dead inside to ignore the chance to work on a game Faye can feel she has had some input on. My hope is to work on it between now and Ludum Dare 28 and finish some form of game by the end of that weekend. I consider it a jam entry that will almost certainly have nothing to do with the theme.

There is a problem though, game design to most people, is boring. Especially 6 year olds. I certainly don’t want to force Faye to be involved “You wanted to make a game, now SIT and watch me struggle to fix this memory leak!” but at the same time, I would like to make enough of the process open to Faye so she can have an active involvement.

Nimble Bat Start

The start of Nimble bat

I’ve not started coding yet, but I have started on the graphics. I am using Aseprite, because it’s a brilliant, simple to use, yet powerful pixel art/animation tool. Katy (my girlfriend) showed Faye the above picture and she instinctively knew that it was “drawing pictures one square at a time”. Last night Faye sat with me and started drawing too, and again, she was drawing one pixel at a time, every pixel she was drawing counted. I’m happy to see Aseprite supports Linux, so I will install that on the Ubuntu running Thinkpad (something Faye already uses a lot) and let her get on with things there too!

To go back to the point about trying to keep interest going, I think graphics are probably the quickest way of generating some form of immediate feedback to the work that’s being done. I will aim to made sure that if I don’t have anything playable to show, at the very least I can say “Hey, I drew the acorns (a requested feature)”. Eventually I would like to make a simple level editor that allows Faye to be involved with the actual game design as well, but that’s for another day (I am aware that Unity now has 2d specific tools and while I am tempted to give it a try, I’m a bit apprehensive about using it for this project, maybe I will reconsider if it helps keep interest!). As I write this, I have just got thinking about sound effects. I’d love to have a small handheld recorder so we can quickly and easily make our own sound effects for the game too.

Anyway, to summarise, Ninjah 2 maybe on hold for a bit, and hopefully this won’t be the last post about making a game with a 6 year old!

Ninjah 2 Yet More Editor


Over a month ago I posted about making good progress with the level editor. I’ve been working on it on and off for the past month and I would say I am still making good progress. However, at the same time I have to admit that i am slightly surprised to find that I am still working on it.

Nothing has been particularly difficult (expect for my previous attempts to code like a complete muppet) and progress has been steady, but it just seems like I keep finding new things that need coding. I am only just getting round to implementing a system that lets you modify the settings of items (in the image below, a spring)Spring controls


Once I am happy with the editor I intend on working on each game object one by one to get it to a state where I am happy. There’s nothing worse than putting a game play feature in, making a load of levels (which I still hate doing)  and then changing said game item, screwing up all of the levels.

I will be trying my hardest to be patient with these things because I know it will help me out in the long run.

But I am getting ahead of myself, I still have plenty of editor stuff I want to add (as an example, you can’t currently move active items once they’ve been placed, or reselect them… ahem) so I will get those out of the way first.

On a slight tangent I’ve bought and am expecting delivery of a PS Vita soonish. HUKD has been bullying me into it for what seems like years now and on Friday a deal finally showed up that I thought was good enough, so there we go!

I mentioned this because it was always my intention to eventually get a PS Vita to develop games for it. Monkey already has a (halted but functional) target for PSM, so I anticipate getting Ninjah working on the Vita won’t actually be THAT difficult. I’m hopeful and excited to see where it goes.

Ninjah 2 Editor

This week I have been concentrating on making the editor a bit easier to use. This involved me creating a various GUI widgets and learning a lot about it in the process!

I had considered using a prebuilt GUI system for monkey but disregarded it because it seemed too complicated. I started working on my own and after 6-7 hours I realised I was basically making what I had originally complained about as too complicated… still, I’ve learnt a lot about it and it has actually been really enjoyable.

Ninjah 2 Editor

Before now I had the various elements all over the place and it looked like garbage, I’ve now got things structured in a tab view which sits on the left hand side of the screen (and can be toggled with the tab key). In wanting to bring in this more structured approach I ended up rewriting pretty much the whole editor screen and I am glad I did.

I’ve restructured how everything is coded, instead of repeating code because it seems easier at the time, I’ve quite strictly implemented “Never Write The Same Code Twice” and I have to say it’s really paying off. I’m even commenting my code properly, get me!

I am really enjoying this at the moment. Once I am happy with how the editor works, I am going to complete each in game item one at a time. I know it’s not the most interesting of game items, but the first one will be the springs.

Game structure and being dumb

A while back I decided that instead of packaging the levels as individual items, they could be packaged as level packs. The level packs COULD contain just a single level if required, but the option would be there to expand if necessary. This makes a  lot of sense, so what did I do to implement it? Stored the level as an individual file and completely disregarded the whole level pack thing.

I’m sure my logic was “ahhhh whatever, I will deal with that later” before moving on to the fun part of testing game mechanics. As mentioned I recently started concentrating on the level editor and it was at this stage that I decided that I really needed to get on top of the whole level pack thing again.

This was a pain in the arse because I had already started building upon something that I knew was a temporary thing. Why did I let this happen? Because I am (was) lazy and am (am) dumb. This meant I had to spend about an hour trying to sort it all out. Nothing too taxing but it was quite time consuming and each source code change was a slap based reminder to stop being stupid.

The thing that makes me feel really dumb is, this wasn’t even the worst of it. For whatever reason I made some pretty stupid decisions that I KNOW I thought were quite clever at the time. I won’t go into any detail because it’s boring and long winded but I can’t help but wonder if other developers do stuff like this too?

I am pretty happy with the structure of things now. I am quite confident it’s all very logical and makes a lot of sense, but what if 3 months down the line I look at it all again and think “how the hell are you so dumb, seriously?”

I guess we will have to wait and see.

Making Level Editors is difficult

I am currently in the process of making the editor for Ninjah 2, while I will be using the editor to make the levels for the game myself, I also intend (hope) others will use it to make their own level packs too. With this in mind I figure I have to put quite a lot of effort into making the editor as user friendly as possible.

The level editor for the original Ninjah game was fine, but the actual game mechanics were very simple so you didn’t need anything clever editor wise. N2 is going to be a bit different because there will be lots of different active objects. The only active objects from the original game were coins (that needed collecting to open the level exit) and they didn’t actually need much in the way of configuring. I’ve already got about 10 different items for N2 and I’ve no doubt I will add more.

Anyway, I spent a fair bit of last week working on the level editor and it’s difficult. Making level editors is difficult. My intentions were good, months ago I had left myself a message on my whiteboard (well, a google document I call the whiteboard) telling me to use Gridpapr to build layout templates. When it came to actually  using it for the tools I needed it quickly became obvious that it wasn’t going to help.

For whatever reason I was completely reluctant to use some sort of Button class to handle … well, clicking on buttons. I was doing some really stupid and pointless mathematical checks to determine “well if they clicked here, they were clicking row 3 column 7 which means…”. If I wanted to move these “buttons” I’d have to do a lot of recoding. It wasn’t flexible at all either, it was stupid, actually stupid.

I am quite happy to say that I now have a proper button system that lets me have text buttons, image buttons and whatever else I want to extend from that. It’s such a minor thing that I am sure pretty much every other developer does without thinking, but it’s a first for me.

It has opened my eyes some what to other people who have made brilliant fully functioning GUI systems. I’ve always given them a go but quickly determined that they are overkill for whatever it is I need. I am now convinced they are not overkill but I was in fact just way too open to dismissing them. Shame on me.

I still haven’t given the layout too much thought, but now that all of the GUI elements can be moved around whenever, it really isn’t that much of a problem.