This week in Sidescroller: Changing the script engine, multidrops, using your inventory and shenanigans.

The script engine

This week i decided to change the scripting engine to a much more useful backend, and i was torn between Javascript and Python. I did considered both because they are runtime evaluated, functional, weakly typed and very well documented. Also, as a matter of fact, both languages have engines that have been tested in real usage scenarios and are very efficient. Both have semi-lightweight implementations in pure Java, but the Javascript implementation doesn't need a huge standard library to be useful and i only need the bare language.

So, i went with Javascript with the Rhino engine. Works like a charm, is way simpler to implement because it uses reflection for the public properties and methods of the classes or objects you want to use on the script side and is a product of the Mozilla foundation, what else could i ask for. Also, before anyone tells me, i also perused Jython, but i liked Rhino's Javascript a bit more.

Take a look at the autoload script being edited in Eclipse (which has a lot of things in spanish, yes that's my native language). The API is accesed by a sole facade in a variable called "api". Neat.

Why not Lua, may you ask?... Well, it's a matter of taste, and i couldn't find a pure Java implementation which was active (there are Java Lua implementations, but the projects seem rather dead). Also, the excuse that Lua has became a industry standard isn't valid to me, because i'm investigating non-traditional ideas for game development.

Multidrops

Till now, crates could only drop a single item when you broke'em. No more, i present to you "multidrops"!!!

The only problem i'm facing with multidrops is that they act like springs when dropping from a crate underneath several crates, unstabilazing any setup of crates, but i think i'll leave it that way because it seems funny when you destroy a container and the contents fall from a cliff and you have to rush down to pick them up; maybe this can be a way for the player to explore areas he/she wouldn't visit.
The only downside, is that this is being implemented as custom properties on my Python exporter for Blender, Nasty! those custom properties are easily forgetted.

Using your inventory

The first problem i saw when introducing multidrops was that i couldn't see if they were getting correctly organized on the inventory, and i had to implement it just to switch weapons and check what i picked up, thus finding and horrendous amount of bugs my code had and still has in some places.

The next thing in my list is Text and UI, probably the most annoying part of game development, but one that is truly neccesary that separates the good games from the bad ones. I was trying to implement a custom font handler using sfntly and OpenType fonts but that library seems not to work for my intents, seems to handle the enclosing file format very well, but the vectorial data must be parsed manually, a no-no for my project because i code in my spare time.

So, i'm going with the intelligent option, and use the included LibGDX widget engine TWL which has a nice editor and seems pretty capable.

This week could have been a little more productive, but i had some personal shenanigans which had to be manly manhandled... go figure.