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!
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)
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.
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.
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.
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 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.
I am currently in the process of developing Ninjah 2 so have decided to release Ninjah, originally for Xbox 360 for free for Windows and Linux. To those who bought it on the Xbox or the few who bought it for PC a while back I am eternally thankful