Alpha Funding on Google Play and Desura

Just published KeeYA's Alpha Funding app on Google Play. The app has got music added, and polished a little more the UI.

Now, why Alpha Funding you ask? It's really simple, i want KeeYA to be supported on a wide variety of platforms, and for that i need to have the aforementioned platforms with me. Currently, i'm targetting to get KeeYA on:

• Windows (main development rig)
• Linux (have one @ home)
• Mac (need to buy a Mac mini)
• Android (tested almost daily on my phone)
• iPhone (need to buy an iPhone)
• Windows 8 Phone (need to buy one)
• PS Vita (have the SDK already and using the emulator, but the hardware is needed to test it)
• Ouya (my console is en-route to my hands).

As you can see, there are some platforms that i must buy in order to develop for them, and they're down right expensive in my country, so i'm counting on the Internet to give me a hand here and push this little game with big aspirations to every possible platform out there.

Desura is still reviewing my publishing info (as of 2013-06-28 11:00:00 UTC), so still no alpha funding for Win/Mac/Linux.

Get it on Google Play

Icons, Dialogs and an uncomfortable finding

This week KeeYA got new Dialogs!

Indeed, although pretty crude for the moment and very inocuous, there is the chat mechanic already. The AI picks whatever dialogue it can select from the current conversation state, and whatever you say doesn't has any impact in the game (yet).

In the same spirit, indicator to transitions and activable buttons were added, to give the player feedback about their environment.

Check out a video of me jumping and initiating dialogues.

The only real bad thing this week is that i couldn't compile the Andoird demo on time because SCXML (the finite state machine i'm using for the dialogs) isn't compatibe with the system.

Got my OUYA email today!

Today, after a long long LONG wait, i've got my OUYA email!

It seems KeeYA is going to be ported to the OUYA too!

So, to anyone who preordered or kickstarted and hasn't got their confirmation email yet, here's what i did.

1. Go to https://support.ouya.tv/home and click on the BIG orange button on the top right of the page with "SUBMIT A REQUEST" text.
2. Submit your Order ID, tracking number or everything else you got when you pre-ordered or kickstarted.
3. Tweet to @OUYASupport your ticket number and your current problem.
4. Wait for your email, notifying you've got your OUYA incoming (if like me, you receive an email telling you to correct your address, go and do it now).
5. Wait for goodness to appear on your front door.

That's it, they seem like a friendly bunch, don't be a douche and use their support channels.

Fonts, text, transitions, buttons & Android

The development was fairly boring this week, but had to be done. Fonts aren't glamorous, but they are needed. I've found that i like a more spartan look to the UI of my games (like Skyrim). So, i've decided to settle on a simple UI without much clutter and let the game be the "filler".

Fonts in LibGDX

Using fonts in LibGDX is very straightforward, it even has a Freetype engine extension that lets you render the fonts on the fly using a texture atlas. To generate the bitmap font you just do:

FreeTypeFontGenerator ftfg = new FreeTypeFontGenerator(fileHandle);

And to render text use a SpriteBatch to render text like this:

font.draw(sbatch, text, X, Y);

Transitions

The transitions are fairly straightforward. There are the automatic transitions (like scrolling leftward from the game start) or pushing a button when touching a transition body (like pressing the down button whe you're touching the pipe in the dungeon).

Get the Android build on my Google Drive.

Gameplay Video

Enjoy! :-)

Animations, Actuators, Stacking and an Icon... Also, IndieDB

This week i tackled the animation problem for the first time in my engine, worked a little with the actuators (to fire animations and scripted events) and enhanced the inventory system with stacking. Also, i published the game on IndieDB, which was all in itself a nice idea.

Animations

Blender has a quirky way to store animation data when using NLA. You see, all the animations in blender are represented by what they call FCurves, those FCurves are almost always represented by 2D bezier curves with the X axis being the frame number and the Y axis the value of each component that the given FCurve modifies. The default animation of every object is represented by an action which is unfreezed, if you click on the freeze button you transform the given default animation in a Non-Linear Action or NLA for short.

"THE" freeze button

Each NLA is located in each object's "animation_data" property, which in turn has many "tracks" that contains "strips" composed by the FCurves. The real quirk here is that each strip has a property called "action" (huh? confused?) that contains the FCurves, it doesn't has the FCurves directly. So to resume, to acces the FCurve of a given NLA in an object represented by the variable "obj" you do:

track = obj.animation_data.nla_tracks[x]

fcurve = track.strip[y].action.fcurves[z]

points = [pt for pt in fcurve.keyframe_points]

There, you have it, bezier points every time of the day! Pheeew... That's a lot of trying and failing for one day. Btw, the default non-NLA of an object is on obj.animation_data.action, there you go.

Actuators

Because i spent the week bashing my head against Blender and its quirky way to implement its animations, i decided to implement the actuators in a dead simple way. So simple, it is shameful. Each "actuator" is a common collision or animation object, with a custom property which fires an animation or an event, depending on the property name. So, for instance "anim_ontouch" occurs when the player touches the object, and it fires an animation. How do you specify the object and animation to fire? "OBJECT_NAME.NLA_NAME" and if you want to fire the same object's animations, just do ".ANIMATION_NAME"... simple.

Stacking

So, if you played the demo previously, you'll know that the inventory grows endlessly big with each ammunition cartridge you pick, which is hard to handle and is a bad user experience. So i decided to implement stacking. It is in its early days, but it already looks WAY cleaner and organized.

Icon

We have a new icon, check it out!

IndieDB

And finally, i included KeeYA on IndieDB. It is looking good, stats are getting better and better with each passing day. If you're an indie dev, go NOW and publish your game there.

Also, publishing in Desura when you're listed on IndieDB is a no-brainer. Go... stop reading!

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.

Testing some ideas

Making great games is hard. Making great games that people want to throw their money at it is insanely hard. That's why I'm going to develop a series of games to test some Action RPG ideas i have in mind before continuing with Wildlands. What are some of these ideas you ask:

• Continuous experience system.
• Gesture based attacks.
• Group dynamics with warring and allied factions.
• Global economics the player can affect (pillaging caravans to make a product scarcer and force an NPC have cold turkeys, razing farms, etc).
• Complex relationships in between the NPCs and NPC-player.
• Simple politics between major factions (towns, cults, etc), including espionage, sabotage, slandering, blackmailing and other dirty practices.
• A lot of other minor ideas i'm gonna iron out later.

Here are some character and items sprites i'm going to use promptly on the first test game:

What do you think? is there any other idea you haven't seen in RPGs that you would like to see implemented?

Procedural story generation

I've been working lately on the procedural story generator, and i'm focusing right now on the scenario, not the one with props, bells and whistles, but the Point-Of-Interest scenarios and the NPCs. After coding a simple lexical generator, i've come up with a well balanced approach to the POIs and NPCs results. Check out this gist with a sample generation:


The lines starting with 'G>' are groups (possible associations of the NPCs that will drive their desires and the possible quests they'll give you). There are some TODOs (like trying not to fill quarries with NPCs to the point that they look like a small town).

Also, the NPCs (and the player) will have relations and opinions around the different groups inside the game, going from simpatizing to being a radical oppositor to a party or being an infiltrated leader of a church. Also, the opinion an NPC has about a certain group doesn't affect the relations with given group (creating cognitive dissonances in-game to spark the fire of controversy!).

Another interesting fact is that NPCs will have sexual orientations ranging an ample spectre of the real-life possibilities aside from the regular ones you see in every game out there (including homosexuality, fetishes, transgenderism, etc.)

All in all, it's looking good for now, gotta keep improving it for the time being.

I'm leaving this here...

Hi all, i'm starting a blog about the new game i'm developing in my free time, called tentatively Wildlands. I'm going to update it regularly with some info about what i'm doing and how i'm solving certain problems of the game.

Just to call out some points about the game:

• First person RPG, inspired by Delver and Fallout.
• Procedural Generation of almost everything.
• Replayability as a core value.

That's all... i'm just going to leave a screenshot of work in progress.

The dawn of a new game :-)

Follow me at G+ or on twitter @johnvillarz.