(May 2018) Monthly WIP & Screenshot thread

I have now my new missile models in action including the new obstacle avoidance behaviour…

as well added the possibility to pick any weapon including the initially default twin miniguns

And the scene is the first trial of a training ground, not yet satisfied with it, needs another couple of iterations, but to try out the weapons it is just perfect :slight_smile:


I added hit animations for when the plasma hits solid objects:

Right now plasma bullets bounce off of the metal men because I wanted to test different material hits… and it looks cool.

Nice thing about the ES is that I added this with virtually no other code changes… just one new app state to render the hits.


Yeah, just a visual reaction to a specific logic state, right?

Yep, it just watches for the same impact component that any damage system would.

This weekend I’m breaking out my Bullet-based ES integration into its own SiO2 sub-project. So far I have a simple demo app:

More to come.


Is the selection of Bullet integral to your ES integration or could other physics libraries substitute it ?

The bullet integration is the whole point of this code. Other physics libraries would follow a similar pattern but it’s all bullet-specific glue code.

Really only the handful of components are possible reusable (like Mass, Impulse, etc.)… but since bullet is float-based, I made these float based. I have similar components in my own mphys boiler plate glue code but they are all double-based.

Got a basic debug app state working… and ghost objects… but I don’t publish contacts yet so it’s not like that matters much:

Also actually checked some source code in. Still very much a work in progress.

Bullet/SiO2 integration:


It takes some finagling to get it to compile and you have to work against snapshot versions of some other simsilica stuff… that will all be resolved when it’s done.


“other”… yeah. Dyn4j is 2d, so it doesn’t count.

PhyX maybe?.. :smile:

I used the same basic pattern for dyn4j in my local stuff also.

The stuff you have done so far, looks 95% like the code I have for Dyn4j, with similar entitycomponents etc :slight_smile: I guess that’s a positive thing.

I don’t know if its a great idea to mix 2D and 3D stuff like that though. I know its just a dimension off, but it sounds really lazy. One dimension is a third of the work. I’d probably go for a separate 2d implementation tbh.

Yes, but the patterns are the same… not the code.

great work @pspeed. I have a similar approach on using Zay-ES in combination with Bullet. I keep a concurrent map of EntityId and PhysicsRigidBodys, and update the position of the model (set Position component) after the physicstick.

Really looking forward to how you will handle PhysicsCharacters. :slight_smile:

Got some little dudes randomly wandering around to show my approach to controlling mobs. I’ve never really used PhysicsCharacters so I don’t know what advantage they provide. My other physics engines never had them so I got used to doing things a different way.

Here are a few little mobs randomly wandering around:

With debug view and some debris:

Next step is to hook up contact detection so that the wanderers can also do some simple object avoidance.


Maybe the answer will be in your next step, but how will you handle a combination of steering behaviours? Now you have a wanderdriver controlling an entity. But what if you want an entity to , for example seek a target but also flee from another target?

You’d implement a different control driver that combined steering behaviors based on some goal or whatever. That’s beyond the scope of my demo.

In case you haven’t seen it already, here’s a nice tutorial on that: https://gamedevelopment.tutsplus.com/series/understanding-steering-behaviors--gamedev-12732

Basically, you calculate the different forces/steering mechanism and sum them up. That’s at least a basic combined steering (short-sighted).

1 Like

Yeah, I know about these series :slight_smile:

I am just wondering how you would fit this steering behaviour in an ECS. You could have a SteeringComponent with a type, like Seek or Arrival. But then you couldn’t combine these, since you can only have 1 component of a specific type. You could ofcourse have a SeekComponent and ArrivalComponent but then your system will get very complicated and messy since you would have to combine the forces of both goals.

As I understand and how I will probably implement it, is using the suggestion of @pspeed of having a control driver with the desired behaviour contained. You have for example a LocationDriver that would go to a location (seek and arrival behaviour combined) and in the meantime would also avoid objects or entities (evade behaviour). The list of entities to avoid can be set on the location driver component, but then again I don’t know if this is bad practice (I don’t like the idea of having list of entities somewhere)… still figuring stuff out :slight_smile:

This is a whole other topic probably not relevant to a WIP thread.

…I personally use a “Goal” object. The steering driver uses that goal to figure out which steering primitives to configure.

Edit: though to be honest there is a steering type as well that is what controlled adding the steering driver in the first place. And this steering type generally implies a specific stack of steering primitives… whether arriving or seeking or whatever.