How We Did It - The Engine - First Part news

Every time we talk to somebody how knows more or less about game developing, they ask us about what engine are we using? Unity right?

Well... No. The reasons why are varied and complex and involve politics and decision making and risk analysis and lot's of other stuff which I really don't wanna get into.

We know that in the indie field, Unity is by far the most used engine, be it because of its ease of use, documentation, support community, assets store, etc... In our case we're using one built of our own sweat and tears (and pretty effective given our limitations in money) based on XNA. We like to call this engine, this little monster, YokaiEngine.

Adobe Flash and YokaiEngine

The main idea behind the engine is to be able to use Flash objects as if they were native C# objects. It's whole potential resides in that sole factor, which we'll see later how it can be of great help.

As an example, I've recovered an old character animation I used a while ago, which I call Siegfried:

To use Siegfried in our game, we will only need to add the compiled (.swf) file to our C# project, and create a static class to inject all the swf components into. Something like:

public Siegfried(bool isPersistant) : base("swf/siegfried", "", isPersistant) { }

YokaiEngine will notice that there's a reference to a .swf file, and will automatically do the following:

1. Read out all the objects embedded in the .swf.
2. Generate textures for each object.
3. Create a xml file with all the instances, animation configurations and necessary metadata.

Like:

That's it! Once you run the game, you'll get this:

As you can see, setting up animations is quite easy, but, quite frankly, not too awesome. Let's take a look at what is really interesting about YokaiEngine.

The Key Strenghts of YokaiEngine

With YokaiEngine, we're capable of four things, basically:

1. We can easily adjust the art at any development stage.
2. We can transform objects in real time (and we'll talk about that in the next entry).
3. We can forget about casting objects to a given animation component (it's all auto-casted).
4. We can group assets and textures in as many files as we like (one file per character, one file for the Forest environment and one file for the Desert, for example).

Let me explain what the first part means: to be able to easily adjust the art at any development stage.

Art changes are a FACT in any development stage. Maybe we drew a character too big for the stage he's gonna be killing minions, maybe the color palette has changed from the happy-bubblegum we thought in the beginning to a somber-creepy now that we have a better idea of the game we're making. Etc. Changes are a fact.

Let's suppose that we have some animations for Siegfried: Running, Jumping, Attacking, and that, for some reason, we have to change Siegfried's helmet. Can you imagine having to change each and every one of the animations (keyframes and all)? In our case, thankfully, it will only take us a couple of seconds, mostly because of how Flash handles symbols and objects:

We will only need to go into the Helmet element, change what we have to change and generate our new .swf. Here we've made the helmet a bit bigger and added a nice little star:

When running the game, YokaiEngine will automatically detect the changes and generate the new texture files, as in:

And we'll be getting Siegfried as a playable character with his new helmet on:

To make any art adjustment at any stage of development, and with so much speed is a key aspect of YokaiEngine. Furthermore the engine gives us a bit of free space for tweaking and playing around, given that we're new in all this game development business and that we're not 100% sure of how the final product will look like (so: win-win). Even better, given that it's vector graphics, we can scale, rotate and change any texture without losing any quality (double win-win!)

So. What do you think about it? Do you think it's a good idea to be using our own engine?