Defining layers.

Knolan

Hi everyone, I am currently doing some experiments with creating a base top down networked game.

I am in the process of writting the characters animations and I ran into a problem of defining the Z coord of the character's itens.

Basicaly if a character is using an armor, the armor must be rendered in a layer bigger than the character itself, but what is a good way to define it?

Should I use the code and manually set it? Should I set it in the Config (probably using heritage)? Is there any other resource that I am unware of to determine the layer?

Is there any way to set in config something like:

[ShootingRightArmor4@ShotingRight]
TextureCorner = @ShotingRight.TextureCorner + (0, 0, 0.1)

Thanks in advance.

iarwain

Hi!

Well, there are two separate ways of dealing with "layers". One more general and one more suited to your present problem, as far as I understand it.

1. For the general approach: you can separate objects in groups. A camera will only render the groups you specify in its GroupList property, in the order of their declaration. Ex:

[MyCamera]
GroupList = Background # Game # Foreground # UI

All the objects in the group Background will be rendered first, then the Game ones, etc...
Objects' Z value will still define in which order they'll get rendered within a group but not globally.

By default, if you don't specify a group for an object, it'll be part of the group "default". Same for cameras, by default they render objects in the "default" group.

In addition to rendering, groups can be used for picking. So for example if you only want to be able to pick objects that are part of the UI group, you can simply pass it to the orxObject_Pick() function and it'll ignore any non-UI objects, even if they are above (like particles, fade effects, etc...).

2. You can use a relative Z position to your armor and set it as a child of your character. In addition to always having the right rendering order, if your character moves, scales or rotates, so will your armor. Remember that the Z axis grows when getting further from the viewer. Ex:

[MyArmor]Position = (0, 0, -0.1) ; Making sure the armor will be displayed on top of whichever its parent is

orxOBJECT *pstCharacter = orxObject_CreateFromConfig("MyCharacter");
orxOBJECT *pstArmor = orxObject_CreateFromConfig("MyArmor");
orxObject_SetParent(pstArmor, pstCharacter);

In addition to setting armor's parent, you can also set its owner. Ownership defines the life scope of an object. If an object gets deleted, all the objects it "owns" will get deleted as well. Ex:

orxObject_SetOwner(pstArmor, pstCharacter);
orxObject_Delete(pstCharacter); // This will end up to the armor deletion as well

Note that when using the config property Object.ChildList, both ownership and parenting are set for created children.

Lemme know if you have any other questions.

Knolan

Thanks for the answer iarwain. I guess I will use the camera groups.

The armors spritesheets are in the position as the character, so I don't think it is a good idea to set them as children. Also, how would the animation run? Would the children be animated along with the parent if all the animations have the same name?

Edit:
In case people don't know about the Universal-LPC-Spritesheet:

Sprite animated with js:
http://gaurav.munjal.us/Universal-LPC-Spritesheet-Character-Generator/#

Github:
https://github.com/jrconway3/Universal-LPC-spritesheet

jim

What do you mean by bigger layer than the character? In many frameworks layer is a sort of grouping objects, there is nothing like layer size what we see in gimp/photoshop.

And regarding the armor/shield animations you see in LPC, in games they use different animations like walk, walk-with-armor, walk-with-sword, walk-with-sword-and-armor etc etc. So, when your character picks up a weapon you change all animations. Yes, you have to do same animations for different object but that's how they normally do in this type of games.

So, for each item your player can pick, you have to provide different walk animations. Hope I could make myself clear

Knolan

By bigger I meant a higher Z.

Also, I think I understand what I have to do, my idea (what I am currently working at the moment) is to create one object with all the texture-corners set and then just use the heritage system to copy all the mappings. So in the end all I have to do is overload the graphic.

iarwain

Knolan wrote:

The armors spritesheets are in the position as the character, so I don't think it is a good idea to set them as children.

Mmh, I'm not sure I follow you here. How your sprites are organized in the textures has nothing to do with the object hierarchy itself. That reminds me I didn't understand the intent behind your first example either:

[ShootingRightArmor4@ShotingRight]
TextureCorner = @ShotingRight.TextureCorner + (0, 0, 0.1)

A texture doesn't have any depth, it's 2D only (ie. it's the UV mapping applied on your object's surface). Only objects themselves in the world (3D) have a depth.

What I propose is simply attach one object to the other, making it easy to attach/detach gears to a given character.

Also, how would the animation run? Would the children be animated along with the parent if all the animations have the same name?

There isn't any transfer of animation through a hierarchy. The hierarchy is only about position/scale/rotation in the world (it's a 3D scene graph).

That being said, there are tricks to generate AnimationSets programmatically based on a template in order to "duplicate" the same anim graph on different objects: in your case you would end up with a similar anim graph for a character, its armor, its weapon, etc, but using a different base texture.
No need to duplicate all the graphs manually in config, you can write some code to generate all the config data at runtime based on a single one you made manually in a config file.

In case people don't know about the Universal-LPC-Spritesheet:
Sprite animated with js:
http://gaurav.munjal.us/Universal-LPC-Spritesheet-Character-Generator/#
Github:
https://github.com/jrconway3/Universal-LPC-spritesheet

Thanks. I, for one, didn't know about it. Who knows, maybe I'll use it for some tutorial one day.