Suckers of life juices, manglers of unprotected flesh. They are the Scrifines!

The idea was to use this as one as a monster type for the JR game project. It definitely lacks in aggression, so I don’t know :). You can also see it in higher resolution in the gallery.

This will be a post about JR 3D Adventure, my indie game project. Here I want to outline some ideas about the future development of the project. It’s probably not the most exciting read, so if you’re not into game development, or not interested in my approach to it, then you can skip the following lines.

2010 So Far…

Brace yourself, this part is fairly technical. For the first half of 2010 I focused mainly on cubicEngine, the beating heart of the game. The most important work I’ve been doing so far is monster AI, optimization of the engine architecture, and a lot of debugging.

I decided to implement the AI as a separate library, that interfaces with the main engine via an abstract interface. Behaviours are instantiated by class name, so the rest of the engine doesn’t have to know anything about the contents of the AI library; This makes life easy.

The behaviours are parametrized with data-files looking pretty much like XML. Except, they are not exactly XML, but my ad-hoc implementation of it. I plan to phase out my data parser and integrate a more robust XML parser. This way I’ll save myself a lot of debugging effort; I’d be wise to do that before my data files become big.

So far I have implemented 3 core behaviours – patrolling AI, flyer AI, and lava AI. The flyer and patrolling AI have an “engage” option (aggressiveness), and a couple of other parameters. The lava AI is basically a creature that jumps perpetually – and tries to land only inside a lava trap. The last one is quite flexible, it has some timing and randomness parameters that can be tweaked. I also amused myself to implement a trail behind lava creatures, which inherits the parameters of the lava trap they touch. (Note – “lava” traps are not necessarily filled with lava, it can be some other hazard).

Originally I designed the AI library to work with FSA behaviours, allowing the “client” monster to assemble a complex behaviour based on a couple of simple ones. However, I’m not using this functionality for the currently implemented behaviours; They are all 1-state, maybe I’ll take advantage of the FSA for boss AI.

•

Another major achievement in cubicEngine was the RPG system. The basic parameters are HP, AP, and DP (for each attack type). Each creature inherits a RPG-sheet class (aptly named rpgSheet) which stores these properties. There is also an attack class (rpgAttack) and a modifier class (rpgModifiers). The last one is interesting – modifiers change the parameters of an RPG sheet, either permanently or temporarily. This is the basis for implementing special attacks and potions.

Generally, when monsters attack each other they invoke the methods of the RPG-sheet, instead of doing the calculations directly in the level object, or the AI object. This is good, because it allows me to minimize the code doing these calculations, and to concentrate it into a single class (the rpgSheet).

I implemented this in March, if memory serves, and it’s still not very robust. In any case, I will not extend it, but rather will try to simplify. I only want a streamlined RPG element in the game.

•

I also did lots of debugging this winter, I really hate that part. The collision detection behaves quite decently now. In addition to this, the architecture of the engine also saw some improvement, some general tiding up of the code.

•

Finally I released a new website for JR, hopefully with a much better design. I haven’t updated it since, simply because I haven’t had the time. I also don’t have anything glamorous to show – most of my recent work is coding, not art.

The Rest of 2010

The whole long thing above was a summary of my commendable programming efforts, and my sustained bravery in the face of chaos and gloom. What about the master plan? The master plan is actually quite simple, and it is based on two practical observation.

•

First, I no longer have the luxury of time to spend whole weeks on the JR project; I’ll be able to dedicate 1 day per week on average. Happily, I’m done with the challenging programming tasks, and this should be enough if I’m smart about it.

•

Second, I have to be smart about it. I’m done with the programming, or nearly so. What I have to start doing immediately is making levels and creating tons of artwork.

Art is fun. I can’t wait to get my hands on it again, so expect some art updates here on the blog and also on the neglected JR website.

More importantly, there is no game without levels. My mistake, hopefully not a fatal one, was that I’ve been too theoretical in my approach so far. I was trying to make the design document crystal clear, thinking about stuff, thinking more, and more – trying to keep the whole thing in my head. It’s not easy, and my brain hurts.

According to the new master plan, I will start with level design immediately. The levels will be improved progressively, very much the same way I improve the code. I will put aside my perfectionism (and obsession with order – I’m a control freak you know), and will leave the design documents in their current state of messiness.

This means there will be a lot of reworking of levels.  However, the alternative is even more daunting – keeping the whole thing in my head without any tangible outcome; That makes me feel uneasy.

•

To sum up, for the rest of the year I plan to do some level design and redesign. I will work on the campaign as a whole, the storyline – and will fills gaps in the code and artwork as I go. This way even if I don’t end up with a perfectly polished game, which I will definitely try to, at least I’ll have something playable; And that’s nice.

Squids hopping around the “lava” traps. I’m not quite sure how a lava trap can be the home of an irradiated squid. More like a fire-resistant quid. Oh, well… it doesn’t really matter. I’ll try to be more consistent in the future.