• Editor

  • All instances of an enemy subclass using the same skeleton?

Hi,

I've got an Enemy super class which also has an associated EnemyView class. I am subclassing that Enemy to create different types of Enemies; so Rifle and Mortar extend Enemy and RifleView and MortarView extend EnemyView, for example. Or that's the idea anyway. I'm starting at trying to put 3 Rifle class guys on the screen. So far so good, the characters line up, the spine animations are correct. I've got my box2D bodies built and they line up well

so long as I only instantiate one Rifle. But if I put more than one Rifle then only the last set of box2D bodies get updated. It appears that every RifleView is using the same skeleton. I don't get it, because in the RifleView class the skeleton is instantiated thus:

skeleton = new Skeleton(Assets.instance.enemySkeletonData);

which seem like it should create a new skeleton, unique to this RifleView class, no? The Skeleton variable is in the EnemyView class. (I did try putting it in the RifleView instead, with no luck.) When I create all this, in RifleView constructor, I can output the attachment.body for each slot and get a unique address. But then I only see one set of box2D bodies lining up correctly, and the attachment.body address for the slots are all the same, for each RifleView. If I turn on the box2D bounding boxes I see one Rifle with his box2D bodies all lined up perfectly, the rest of the Rifles' bodies are all in the same place they were created, not moving or updating.

I think part of the issue may be the structure of my project, so a few details: I have a main class, worldController, and a worldRenderer, which handles display. worldRenderer invokes the skeletonRenderer thus:

for(Enemy e: worldController.enemies) {
            skeletonRenderer.draw(batch, e.view.skeleton);
}

The renderer is iterating through an ArrayList of Enemies in the main worldController, not of Rifles. (I may be little Java-confused?: each Rifle has a 'range' variable, defined in Enemy, but set in Rifle, which when output to console proves unique to each instance of Rifle. Why is the same not true of the skeleton attachment.bodies then?)

This is probably a Java problem, but I am very stumped right now. I've tried a number of different things, all without success. Any help or direction would be greatly appreciated.

thanks,
Richard

Related Discussions
...

In this diagram, note the section labeled "Instance Data", which is the data stored by each instance of Skeleton (and friends):

Image removed due to the lack of support for HTTPS. | Show Anyway

The skeleton instances share the stuff from section "Setup Pose Data", which includes all attachments. You haven't shown how you do your Box2D stuff, but I'm guessing you store something on the attachment itself, like Box2DExample. Since all the skeletons share the same attachment instances, you get the behavior you described.

You'll need to store your Box2D bodies along with the skeleton instance, not in each attachment. Keep in mind the attachments for the skeleton's slots can change by keying the attachment changes or writing code to change the attachments, so you may want to create all Box2D bodies for all possible attachments up front, or maybe create/delete them on the fly. To iterate all attachments, go through the attachments in each skin in the SkeletonData (which includes the default skin). I added a Skin attachments method just now to make this easier. If you know a skeleton will only ever use one skin, you probably only need to create bodies for that skin and the default skin (which contains all attachments not in a skin in the editor).

FWIW, Super Spineboy uses a similar MVC pattern (but no Box2D):
spine-superspineboy/src/com/esotericsoftware/spine/superspineboy at master · EsotericSoftware/spine-superspineboy · GitHub

Nate, thank you. Got it, by saving the bodies separately. I am keeping them in an ArrayList in my extended Enemy Class. Please feel free to tell me why that is a suboptimal and completely noob maneuver...

I sincerely appreciate the detailed answer, it was informative beyond just my initial question.

Thanks,
R.

Keeping them in a list is probably perfectly fine.

Glad you got past that problem. Onward, to the next! 🙂