Game Development

user4704

12:00 AM

Usually a higher-level abstraction (the "game itself") will synchronize all render positions to the values of the physics positions at some predetermined point in the game update loop (after the physics ticks).

TorbenC

Thank you Icy Defiance, I do see your idea but I don't know if a dictionary containing the entites would be best (yet) for my implementation.

Right

user4704

Unless a render component specifically has the "keep detached" flag set, or something.

TorbenC

What about a health component

user4704

Same thing.

TorbenC

Collision with certain objects may do damage

user4704

12:01 AM

That's not the collision systems job.

user4704

The collision system's job is to report and respond to collisions.

TorbenC

Collision is a primary problem for me, I don't know how I am supposed to get the information about which entity an entity collided with (and worse, be able to react to each one when I don't know if they have certain components, if those components are stored in the system itself).

user4704

If something else in your game needs to take action on collision, then something higher up in the abstraction chain (again, "the game itself") should attach the collision systems "these two things collided" callback to a handler in the game logic system that figured out what to do about them, damage-wise

TorbenC

Interesting

user4704

So let's say your collision system fires OnCollided(RigidBody a, RigidBody b).

user4704

12:03 AM

It can do that, it only knows about RigidBody components.

user4704

The game does collision.OnCollided += HandleCollision.

TorbenC

And oncollided would be the entity that collided with the target callback?

user4704

HandleCollision takes the two RigidBody objects and converts them to their entity GUIDs, and calls gameplay.HandleCollisionBetween(Guid entityGuidA, Guid entityGuidB).

TorbenC

That makes more sense

user4704

HandleCollisionBetween looks up Health components for those GUIDs, and any other components it knows about that might be involved in damage computations, and does the appropriate stuff.

user4704

12:05 AM

This avoids the need for gameplay to even know about physics RigidBody objects, which is better.

TorbenC

So some of these systems would fall under gameplay and will not be run unless an event happens in another system right?

user4704

Sure.

TorbenC

Interesting

user4704

Usually most of the gameplay stuff is rolled up into script componetns that run Lua or something

TorbenC

This is great :)

I only have one problem now. In this case, is it possible for two gameplay "systems" to affect the same component? It seems so now.

If they can, changes done by one system may effect the outcome of another.

user4704

12:07 AM

Ideally only one system owns a component.

user4704

But even if they don't, the primary reason to design things this way is to tick entire systems at once.

user4704

Instead of ticking entire entities at once.

TorbenC

Right

But lets say you have this

user4704

That means your change flow is always deterministic, until you introduce threads.

user4704

(Which is also a useful reason to use this design.)

user4704

12:09 AM

But at that point you just have the usual thread synchronization issues so it's a non-issue, at least, not a new issue)

TorbenC

A power up enables you to have a speed boost for a few seconds, only when you have full health. You get the powerup and that component is added to the entity, the next tick happens and you are hit by something. It is possible that the powerup will update the speed because it checked the health component before the health could be updated by the collision system's callback.

(poor off the top of my head example)

user4704

No, you avoid that by ticking entire systems or entire types of components at once.

TorbenC

What do you mean?

user4704

Per-frame, either physics will always tick before speed-boost, or the other way around.

TorbenC

Definitely

But should the speed boost effect the results of collision?

user4704

12:12 AM

Then you don't have this problem. You tick physics -> health -> speed boost.

user4704

In that order. All the time.

user4704

Then any dependencies between the data are fixed and deterministic, and if you don't like them you re-order the tick order until you do.

TorbenC

How do you determine the flow? Unless it is hard coded that seems difficult.

user4704

You pick something and live with it.

user4704

And change it when your tests suggest otherwise.

user4704

12:13 AM

This is no different from any other kind of update loop.

user4704

You have to do things in a fixed order, and sometimes that order can cause inter-frame discrepancies.

TorbenC

Okay :)

user4704

It's not a problem specific to components at all.

TorbenC

Thank you for helping me out so much! You've answered all of my questions :)

user4704

np

Transcript for