Sign in to follow this  

Physics inside ECS Architecture or Separate Physics Engine?

Recommended Posts

Do not put your physics in your ECS.

Game object architectures are part of the game logic framework.

Your ECS isn't going to be a good data structure for your physics. Nor is it going to be the best data structure for rendering. Nor for AI. Even if you intimately tie your engine modules and your ECS together you're still going to have to end up creating separate data structures and glue code anyway to do efficient ray casts, frustrum culling, path finding, etc.

Build your main modules to be as independent as possible. Make them testable and usable on their own, depending on no more than your core code like allocators or containers. Then use the object architecture to do glue objects together and to handle your level serialization, prefabs, UI integration, etc. Build your actual game logic over that glue layer.

Heck, if you build an _actual_ ECS then the "gluing" is basically free and almost implicit, in the simpler cases at least (since the "E" in an ECS is just an integer, all it would require is that your physics module support fast O(1) lookup and retrieval of an integer associated with each body).

Share this post


Link to post
Share on other sites

Don't both of your options count as making a physics engine, just that one uses the ECS pattern for the engine, and the other glues the end result into the ECS pattern?

 

You could always use PhysX / Bullet / Newton / etc instead of reinventing the wheel. Writing a physics engine is an extremely huge and complex task requiring a hell of a lot of research (depending on requirements / quality desired).

 

What is the purpose of your ECS framework? Is it so that non-programmers can construct new entities from data files, or so gameplay effects can dynamically tag entities with modifier-components, or because you like relational design theory in general? There's a lot of ways to do ECS, which completely depends on what your purpose is.

Share this post


Link to post
Share on other sites

I think, think of your ECS as proxy to your modules. The components take the data (in this case, related to physics, in a way your artists/game designers could understand) and then the data is processed by whichever module through the related systems. This makes it easier to attach any 3rd party library. In this case, your physics module/library/engine/whatever. Just a quick thought.

Share this post


Link to post
Share on other sites
Physics engines are usually both collision detection and resolution. Resolution involves the difficult mathematics. If you want really simple resolution, then I'm sure you could figure out a way to get colliders into your ECS. So yeah, you can, but whenever someone comes in here to write a response we aren't thinking about "can you", but instead are thinking about "should you". Then answer to should you, is probably a no.

Share this post


Link to post
Share on other sites

Then they defer physics calculations to the client and periodically inspect the clients state for unlikely or impossible (e.g., teleportation) events?

 

 

 

Not at all (usually; some do).

 

For many games, there's no need for a real physics engine. e.g., the game might just require that characters stay on top of a navigation mesh, and the most "physics" that the game logic ever requires is a raycast to determine where on the navmesh the player clicked. The AI/server then calculates a path along the mesh (likely using A*) and moves the character along that path. No collision detection and no physics resolution required, because characters just stay glued to the mesh. There might be some really simple animation-level hacks on the client to make it look like characters shuffle around each other rather than ghosting through each other.

 

These games might also have a physics engine on the client, but it'll then only be used for visual "fluff" that doesn't affect the gameplay. For example, if a wall can be broken, the server would just mark if the wall is present (blocks a navigation edge) or not present (the edge can be traversed). The client might spawn a bunch of rock chunk objects when the wall is broken that collide with nearby geometry so they bounce around and look vaguely realistic. The physics bodies on the client exist only on the client and server doesn't care about them; if the little rocks bounce differently and end up in different places on each client, nobody cares because it has no effect on the actual game.

 

A number of big MMOs do use _some_ server "physics" but not much; again, it'll often be little more than ray casts against some simple geometry (e.g., wall occluders to know if an NPC can see a player). There are online games that make extensive use of physics, like World of Tanks or other more simulation-oriented games, but they are an exception to the norm; physics is expensive and when you're trying to support millions of players, you typically want to minimize the server costs per player so you make more net profits.

 

Now, all that said, there are still games that do a good deal of client-side movement with some level of server validation. The server validation may or may not include physics. An example here is a multiplayer 2D sidescroller game, say like Terraria - getting good platforming mechanics with a round-trip to the server is damn near impossible so the client is given a lot of authority. However, these games also typically have _very_ simple physics requirements (the world is a simple tilemap) so they don't tend to use an off-the-shelf physics engine.

 

And with a simple enough physics engine, my previous advice about separating it from the ECS is much safer to ignore. :)

Share this post


Link to post
Share on other sites

since you are not doing ECS as a data oriented optimization, a separate physics module at a lower level than the ECS system would probably be the best approach.

 

if you were doing ECS as a data oriented optimization, then you'd want your physics methods to operate on your physics components just like any other data oriented ECS system. and the form of the data structures involved would be dictated by cache friendly design.

Share this post


Link to post
Share on other sites

The way I have Bullet setup into my ECS is fairly straightforward:

 

I got two component types: DynamicPhysics and StaticPhysics. Dynamic is something that moves, which requires a copy-back of the transform after stepping the simulation. Static is something like the floor, or a building, which only needs its world transform to be computed once.

 

In my ECS, systems are essentially filters for entities, so I got one PhysicsSystem, that has Bullet's world object, this one steps the simulation, processes no entities and has a bunch of utility methods to add/remove objects from the simulation. Then I got a DynamicPhysicsSystem and a StaticPhysicsSystem, each filtering for their respective entities, doing some plumbing to setup the transforms/rigid bodies, and adding them to the physics simulation via a reference to PhysicsSystem.

 

Either component can have whatever data you need, ie collider tipe, size, collision mask, etc.

 

I wouldn't advice to make your own physics engine. Unlike say, rendering engines, physics engines tend to have similar APIs and similar functionality, and its quite easy to integrate them into your code, they're designed for that. Moreover that kind of programming gets really difficult really fast, you got all sort of complex algorithms, data structures, and stuff like float numerical stability starts to matter much more than usual.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this