• Register
Post news RSS How We Did It - The Engine - First Part

This time we give a small glimpse into how our game engine works, how it helps us make changes in little to no time.

Posted by on

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:

Paladin - idle animation

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.


YokaiEngine export results

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

Paladin in game

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:

Flash workspace with Siegfried

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:

Flash workspace with Siegfried and a star in its helmet

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:

Siegfried in game with a star in the helmet

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?

DrGimpPimple - - 11 comments

I think it is perfectly valid to build / use your own. I might be biased though since we developed our own as well. The advantages you can gain in speed and usability are really apparent. By the time I figure out how to do something simple in Unity, I could have just pulled up my own engine and been done. Not to mention that if you hit a snag or an error with something like Unity...where do you go, how long will it take to get a fix? When you build something yourself and something goes wrong....you know where to go to fix it :)

Reply Good karma Bad karma+1 vote
basetis_io Author
basetis_io - - 26 comments

I think you're absolutely right about speed: it's YOUR engine, you know what buttons to push, to get it started, to get it working! And even if it gets really big, you can have an intuitive idea of where things are going wrong, then dive into, fix.

But we've also figured out that value comes with a price (and maybe for some people that's a too hefty price): you're on your own. No community. No support. No tutorials. No reference. No amazing scripts available for a few bucks. Nothing. Well... sure, not entirely nothing (at least in our case, we didn't start from absolute scratch), but without lots of goodies that might come handy when all you wanna do is build your game.

How have you dealt with all that? We? We struggle, but it's a good struggle (as sometimes we like to think ;) ).

Reply Good karma+1 vote
Post a comment
Sign in or join with:

Only registered members can share their thoughts. So come on! Join the community today (totally free - or sign in with your social account on the right) and join in the conversation.