How We Did It - The Engine - Third Part news - Sticks & Stones Game

Last time we had a post about our engine, we talked about what we call Real Time Object Transformation. This time we're gonna talk about what we call Object Auto-Casting.

Again, we use our little character Siegfried and a Paladin symbol in Flash:

As we said before, the engine is able to replicate every Flash object (and their animations) into C#. We only need to define a Screen with a CustomSprite (one of the engine's own classes) variable with the same name that it has in the Flash file.

public class Screen : PlayableScreen
{
      public CustomSprite paladin; 
}

to get:

Now, if we wanted to do something with, let's say, the Sword animation, we'd only have to:

1. Give a name to the Flash object (the sword, in this case "weapon").
2. Replicate the same Parent-Children class hierarchy from the Flash file.

As in:

(Note that neither the layers nor the symbol names make any difference whatsoever :). They're important though in keeping order within your files, which is actually pretty important for the whole game-making thing—or even the programming-in-general thing!—. Keep your room always tidy and clean kids! That's the only way you can really really have fun...).

But of course, it becomes evident that if you were to use the CustomSprite class for the Paladin, you wouldn't be able to reach further down in the hierarchy. For that, then, we use typed classes.

Typed Classes

If we wanted to have the same structure as in Flash, we would need our character to not be a CustomSprite, but to have it's own custom class to allow us to define content within:

public class Screen : PlayableScreen
{
      public PaladinCharacter paladin; 
}

And then, inside that new PaladinCharacter class, we would reference the weapon:

public class PaladinCharacter : CustomSprite
{
      public CustomSprite weapon;
}
That way we can now access the weapon through the character, make it disappear for example:

public class Screen : PlayableScreen
{
    public void RemoveWeapon()
    {
        paladin.weapon.Visible = false;
    }
...
}

Getting then:

What that means is that YokaiEngine maps automatically the same structure given by class definitions. In our case:

• Paladin is cast into PaladinCharacter.
• Sword is cast into CustomSprite.

What happens is that the engine recursively goes down through all levels, allowing for as many as we would like:

public class PaladinCharacter : CustomSprite
{
      public Weapon weapon;
      public Helmet helmet;
      public Shield shield;
}

public class Weapon : CustomSprite
{
      public Blade blade;
      public Grid grip;    
      public CrossGuard crossGuard;
}

public class Grip: CustomSprite
{
      public Handle handle;
      public Jewel jewel;    
}

Better yet: it allows lists! If, by any chance, we own to objects of the same type (arms, legs...), we only need to append a number to the symbol instance name. Right arm becomes arm0, left arm becomes arm1. Easy as summer breeze, as lover's touch:

public class PaladinCharacter : CustomSprite
{
      public Weapon weapon;
      public Helmet helmet;
      public Shield shield;
      public List arm;
}

And that's it! Having a hierarchy class structure is very useful, not only for code simplicity and ease of development but for having control over objects when they're out there being used by the player.

Thanks for reading!