AI, sounds, a new inventory and a Name

This week i finally introduced simple AIs, simple sound effects and a new inventory which is more pleasing to the eyes. Also, i decided to name this game "KeeYA: Keep Yourself Alive" (no relationship with Queen).

AIs

Javascript is a great language for AI programming. I've always loved it and the functional aspects of it make it dead easy to implement semi-emergent behaviors. I decided that to keep things easy, the heavy lifting will be implemented natively (native as "inside java") and expose API calls inside javascript to keep it snappy.

Sounds

Sounds are very important to a game, so much that this little game has gotten more interesting and enjoyable. I decided to include a sound called Willhelm Scream because i did find about it this week and was amused by it. LibGDX has a quirky behavior with sounds, sometimes the gunfire sounds get muted by the death sounds.

Inventory

The previous inventory was ugly and didn't have the style i want for the game. I decided to get rid of complicated UI elements and go along with a Skyrim-style inventory which is simpler to implement and has a cleaner look.

As comparision, here's the old inventory, suggested by +Olivio Sarikas

Ugly, indeed :-)

New name: KeeYA, Keep Yourself Alive

Because i included AIs with a simple firing pattern, i had to keep avoiding getting shot by them. My 6 y/o daughter loves to test my game and she was frustrated by the AI so i told her "keep yourself alive!!" and voila! a name was born.

Want to keep posted about the progress of KeeYA? Subscribe on the sidebar, there's a mailing list.

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.

Particles and item drops.... Ooh also Scripting!

This week on the Wildlands' Sidescroller subproject, i implemented the features on the title of this post.

Particles

Although Libgdx includes a particle editor and a particle engine, there's a major bugging problem with their particle system: No 3rd axis.

That means that my particles won't have parallax scrolling and that the code won't be capable of being ported to my main project.

So i went and coded my own particle system. The system had some requirements, namely:

• Possibility to change the generator shape.
• Possibility to change the particle shape.
• Simple file format, capable of being edited with a notepad.
• Fast and memory efficient.

So basically what i implemented was a 4 class system, that loaded the information from a JSON file the classes are responsible of each requirement:

• Factory: Responsible of loading the particle system file, and generating the aforementioned systems.
• Generator: Abstract class responsible of generating the particles, must accomodate to different needs when a different shape is required.
• Particle: Responsible of maintaining the information of shape and properties of a generic particle, which don't change over time.
• System: Responsible of maintaining a memory pool of the particles and handling them. Also, this class handles the rendering of the particle system.

As you can see, i mixed the rendering of the particle system with the logic handling it, that's an intentional mix up because i'm letting each class handle the responsability of not only storing their data, but also of representing it. This could be enhanced by adding representation classes for each class, but i'm not coding that way because this project is meant to test a lot of productivity and fun ideas.

Item drops

No good Action-RPG works without item drops and mine is no exception. The item drops must be simple enough for the level designer and flexible enough to the programmer to adjust to the player level. This lead me to asign the drop probability to a simple float value between 0 and 1. Also, it is planned to add more than 1 item drop from each container, but that's a to-do. In the game side, the drop is handled as almost any other dynamic object, having a mesh rendered with an attached physics body. Simple stuff.

BUT... the item pick up must be handled correctly, that's where Box2D enters in action, they have this nice class named ContactListener which lets you know when a body touches another, basically you must check that your contacts are valid and take action accordingly.

But the drops must be handled somehow, with some flexibility to add different item drops in the future, that's where comes the...

Scripting

For the scripting part i was entertaining the idea of using Javascript with the Rhino engine, but that would bloat my game. I also tried to use Lua, but almost everything i found needed native libraries (a no-no, i'm trying to maximize portability). So i went with a nice little scripting engine i found some time ago called FScript (from Fast Script).

The pros and cons of using FScript are:

Pros

• Fast.
• Small.
• Efficient.
• Simple.
• Easy to embed.
• Easy to create an API for.
• LGPL License.

Cons

• Almost non-existant support library
• Everything must be made from scratch
• No code editor with syntax highlighting.
• Extremely strongly typed. (Not necessarily a con).
• No debugging.
• Project seems dead.
• LGPL License. :-)

So, using it has some very serious problems and risks but, as you can guess, i used it anyways, because it is small and portable. However, i'm going to change it because of the license (i want to be able to embed everything in my code to minimize downloads and be able to use GWT with Libgdx as backend).

I'm probably embedding another language in the coming week. What engine do you think would meet my requirements?

Physics are very much f***ing hard

Implementing physics has been a pain in the ass.

First, you must learn to use a new library for each project (Box2D in this case, Bullet in my previous/main project), and then you must adjust your frame of reference to the objects on the graphical representation side.

Turns out, it was easier to leave out all my preconceived notions and follow development naively, and it has became easier to implement thanks to this new view.

Also, this week i refactored a lot of old code, for example, previously all my graphical representation was manually rendered like this:



But after refactoring, it became a three class system, with a very much needed separation of concerns:

It is a nice change of classes, and although it generated more boilerplate, it derives on good, readable code, which is a must for a project that will probably take a whole year.

What do you think? what is the most common problem to solve when refactoring?

Implementing Physics

This week i decided to implement physics in my sidescroller. The game map is a Blender scene exported with a custom python script i coded. One problem i ran through was when i tried to implement correct coordinate handling.

Usually, when exporting geometry outside blender, it is a common practice to use XZY ordered vectors when using OpenGL as backend. It turns out, this over-complicates things on the physics side, because you're mixing and matching coordinates incorrectly.

It is a LOT easier to just use whatever Blender exports and adapt your work to it, i.e. using Positive Y as your forward vector instead of Positive Z (as Blender does).

Why is this? It turns out Blender interprets the Z coordinate as the axis going upwards from a cartesian plane, which is a little different to what you're used to in OpenGL, where the Z coordinate is the forward axis.

Well, enough text, here's a video of the game in action:

As you can see, the graphics are somewhat simple right now, but it is just test art right now. More is coming in the future, but i'm focused right now exclusively in the gameplay, which is what is fun in the long run.