Can't get pooled particle effects to follow their Entity - libGDX

Newbie & Debugging Questions
#1

I’m having trouble getting my pooled particle effects to follow their intended targets. My issue is that the particle effects fire off at stationary positions without updating their x/y coordinates. I’m working with a 2D game where players fire projectiles at each other, and I need the particles to stick to the origins of the “hit” player objects throughout the particle effects entire duration.

  • My setup is a World class which handles all object creation, and keeps track of object locations and status updates. The world class also handles collision detection between objects.

  • I also have a Render class which just works to render all animations for every object from the World class. The particle effects are updated here.

My issue right now is that when I detect collision in my World class, I need to fire off a particle effect from my Render class. To do this I send the coordinates of the collision from my World class, to my Render class, and have the Render class fire off the particle effects. Because of this setup I only get a single instance position of where the particle effects need to be, but not the updated location of the players location. This effectively makes it look like the particle effect is lagging behind the players updated location. What I’d like is for the particle effect to follow the updated location of the player, but I’m having trouble brainstorming of a way to do this.

Any suggestions?

#2

Hi, I think I might be able to offer a bit of assistance here…

First, to make sure I got this right. You have different entities in your game, and you have a world class that holds all the objects and loops through them.

Then, you have a render class to handle the drawing of all the objects?

Why not have the world handle the rendering also, since it already has the objects, the update could sort the render order if needed, no?

Anyway, the way I would look to solve this issue is to add a “creator” member of the particle class, which would be the updated position where you want the effect to follow. Might be easier to do if the world also acted as a container for the particle effects, and then it would be easier to share the data, I think.

#3

The reason I separated my world and render class is because I was trying my hardest to keep a MVC pattern. I’m starting to realize that a few things I need would be a lot easier if I had allowed my world class to render objects as well, which I may do. I think adding the “creator” member to a newly extended particle class would probably be the best way to solve my issue. It seems that doing that may add an additional step in memory that may not be optimal, since it’s like copy pasting an entire object just to have it do one small thing.

Whether or not people should stick to MVC is a personal decision. I found an interesting post about it: http://gamedev.stackexchange.com/questions/3426/why-are-mvc-tdd-not-employed-more-in-game-architecture

I’d be interested in hearing what you guys think! Retaining MVC would mean that you’re going to be making lots of object copies. Breaking a MVC would allow you to keep your code more simple and technically more optimal, however organization might be difficult.

#4

I am somewhat of a noob, so, I would not be surprised if others disagree here…

Before I started with libgdx, I was working on simple projects with c++ and directx, and at that point I was trying to stick with more standard patters, once things got somewhat more complex than tetris, the code became increasingly difficult to manage.

That’s why I shifted to the entity based system… because then every object becomes an entity that gets updated with the world, and the world sends its results for rendering. I don’t necessarily think it would require copying the entire object, but just something so that you can draw out the coordinates that you want the effect to track…

An alternative option might be to have each entity create / destroy its own particle effects, and in this way the coordinates would be provided directly when the conditions are met…

#5

“This effectively makes it look like the particle effect is lagging behind the players updated location”

A work around and not fixing the problem, but could you just render the particles in front of the player’s location? Or you know, “Particle’sXLocation + 25” or something like that?

#6

@bmanmcfly, that makes sense and seems to be the popular approach to making games. My current setup is that I have arrays of objects in my world class, and I copy those arrays into my render class, which polls for object updates while rendering graphics. This seems to be an inferior setup, because I can benefit more from making my world arrays public, and directly accessing those arrays from my render class instead. Doing this would eliminate the ‘duplicating objects’ part that I was referring too. Also this would retain a MVC look, instead of putting entity + rendering into one giant class. I guess my goal here is to retain code cleanliness, but this could also help me by allowing me to get direct access to the object for my original particle problem.

@FabulousFellini, that’s another possible solution, thanks :slight_smile: It might get a little hairy with variable velocity and rotation, but it’s a possibility.

#7

Again, keeping in mind my being a noob…

To me, it seems that by having the world class responsible for updating and drawing all game entities, it seems that it overall keeps things simpler than having a world for updating objects and a renderer for putting objects to the screen…

Seems to me its easier if you just go :
world.update();
world.render();

where update is:

  • for (object o: objects){
    switch (o.entityIs){
    case (OBJECT TYPE):
    o.update();
    break;
    }

So, if your objects create their own effects, then the effects will be updated along with the entity that created them, seems to me, this would make it so that you’re not having to do extra tracking of all the effects and locations…

That’s still a few milestones ahead of where I’m at though, and haven’t done that specifically yet…

#8

I agree with you. After reading into the MVC pattern for games and how little people use it, I’m leaning towards what you mentioned except with a slight twist. Instead of using:

world.update();
world.render();

I would prefer to put world.render() logic into another class, however make objects in world publicly accessible so that render can use the same objects that are in world. There is no benefit to this besides keeping the code separated and ‘cleaner’ in my opinion. My project is several thousands of lines and it’s getting to the point where I really appreciate Model being separated from View. As I add more and more logic to my game it just makes things easier to find. It would look something like this:


Game {

    public void update() {
        world.update();        // All entities are created and stored in public arrays
        render.render();       // Accesses public arrays in world class to render them
   }
}

Let me know if you see any flaws in that design.

Also to aid my original question, when I get home I’ll try applying this implementation with additional salt to fix my particle issue. I wanted to assign a boolean to my entity classes that is switched to true when I want a certain particle effects applied to that entity. For example:


class Enemy {

    boolean showExplosion;
    boolean showDeathAnimation;

    public Enemy() {
        ...
    }

    ...
}

Since I’ll have all my entities stored publicly in my World class, I can iterate all those entities in my Render class to check these boolean flags. If the flags are true I will fire off the effect in the location of that entity. As long as my particle effects “attached” attribute is true, the animation will follow the entity. Which should solve my original issue.

#9

I have one or two spare minutes, so I’d like to talk a bit about software design, design patterns and MVC:

One good article about MVC is this one: https://msdn.microsoft.com/en-us/library/ff649643.aspx
Compared to the Wikipedia article the MSDN one for once explains the WHY. Why do people use MVC? What is the problem it solves?
And, even though being marked “Retired”, it is very valid.

Once you discover the essence of why certain architecture styles and design patterns exist, you can forget about patterns at all, and only have to ask yourself one single question which will lead you to the right design: “What parts of the system are likely to change and which parts are unlikely to change?”
It has always been that question driving all designs and it will always be just about: Change.
We design for change.

When things can change, we want to isolate them, so that once they change, they do not lead to substantial other parts of the system having to change, too, which would increase rigidity and fragility of the software.
When, on the other side, something doesn’t change, we can tie it to the rest of the system as strongly as possible, so as to reduce complexity and likely increase performance.

About every behavioural and structural design pattern I know, is just driven by how to handle change, be it adaptation or extension.

If it wasn’t for change, then every system could be implemented using a single file, module, class, compilation unit, etc.
Because we would never have to maintain, extend, adapt, transform, or otherwise manipulate it ever again.
But in our world, such constancy does not exist. Every software needs to be changed in one way or the other. Always.
The trick about good software design is to try to know which parts change in which ways, and then design the system to make such changes easy to do. This is the pure essence of the Software Engineering field.

There is one great article by Martin Fowler, called Who Needs An Architect?, which has influenced me a lot. In it, Martin Fowler also quotes Ralph Johnson as he explains what he thinks “Architecture” is and how it relates to change. One great paragraph about “change” is this:

That was just what came to my mind when I read this thread about MVC. So, sorry if it was too long and boring. :slight_smile:

#10

Thanks for that article and the explanation, it hits the bullet on the head for me. I feel there needs to be a balance that is found, and it’s on a case to case basis depending on your project. Google searches will show that MVC is not a preferable way to design a game, and can actually lead to inefficiencies. Instead of following a strict pattern, you can attempt to follow the basis of a pattern like MVC as per my previous post.

#11

Just a quick update for anyone that might see this in the future. Entities having a boolean flag on whether or not a particle effect should be used was a bad idea. You’ll have graphical issues while you’re waiting for your effect to complete, because only then can you reset the boolean flags on the entities.

Setting off the pooled particle effects during collision detection is the easiest way to fix my issue, which is when you’ll have direct access to the entities that need particle effects.

#12

I actually went through something of the same process, while I was still coding in c++ for directx. I tried to keep everything to the patterns I learned were ideal for windows type programs…

It was surprisingly quick before I started running into issues where objects could not effectively trade data, and other sources of grief, that’s when I built an entity type system for myself because then at least the problems surrounding what objects need to communicate with what and how would be more easily tackled.

Ya, that makes sense. I would think there’s a way you could use the flags like that, but at least it’s good to hear you worked through the problem…

How did you get the collision to get the effect to follow the player? I would have thought that would be better for example, landing from a jump and seeing the puff of dust push away from the feet, I could see getting the effect to follow after to be a bit trickier…

#13

The quick answer is simply selecting the “attached” option when configuring a new particle effect with the LibGDX 2D Particle Editor tool.

In my case I selected that option, but the problem stemmed through passing a copy of my target(passing by value) entity to be graphically rendered. Since that particular copies position was not being updated, my particle effect remained stationary. However if you apply the particle effect directly on an object who’s position is being updated, the “attached” option works as it should. I would assume this is the same issue whether or not you use the editor tool for your effects – either applying effects to a copy, or the real object in question.