I’m working on a game built entirely around Data-Oriented Design using ECS. On the server, everything is just data — no Instances at all. Players, mobs, and world entities are all tables: Position, Hitbox, etc. The only Instances exist on the client for rendering, and even that’s just visuals.
To support this, I’m building a custom physics & collision system for my entities. Think Minecraft-style: AABB checks, no Rigidbody physics, and only static collision data for the environment (terrain, walls, etc.).
Here’s my concern:
Is it worth continuing down this road, or am I setting myself up for performance bottlenecks?
I already have basic AABB collision for entity-entity working. The challenge now is entity-world collisions. Roblox’s built-in physics is obviously way faster (C++), but it doesn’t fit my architecture. My world is static, so I can optimize, but Roblox Instances aren’t part of my ECS — they’re just visual props.
Some context:
Max ~100 entities active, usually 10–20.
Static environment collision only (walls, floors, etc.).
No moving Instances — just entities interacting with the world and each other.
I’m genuinely enjoying building this (taking a lot of inspiration from Minecraft’s architecture), but wondering if I’m overengineering when Roblox already has physics built in.
Has anyone else tried this approach? Is it sustainable at scale? Or should I lean back into Roblox’s native systems?
On the topic of performance, be sure to make your code statically type correctly, enable Native Code Generation and use vector instead of Vector3. These can all give better performance.
In Roblox, vector and Vector3 are mostly functionally identical, except that Vector3 has a bunch of namecall functions and other metatable stuff (such as :Cross, :Dot, .Magnitude and .Unit), which are slower to access than if they were part of a library instead, which is what vector.dot and vector.cross are for. There’s also probably some other performance improvements, but they are interchangeable with Roblox APIs (and typeof returns Vector3 for both for backwards-compatiblity, while type returns vector for both).
This is only useful for code that does a lot of vector math. Because Vector3 is essentially just a proxy with an added layer to a vector, skipping that proxy can improve performance in those scenarios.
However, it can make your code more verbose, and it shouldn’t matter in most cases.
So essentially, its better in every way, other than adding a couple extra characters per use? I think i’d just rather use that always, however I feel like this is a new library, I didnt see it in the Library section of the documentation a couple months ago when I checked
It’s been on the Roblox Documentation too, I’m not sure since when however.
I mean, it is your choice ¯\_(ツ)_/¯ Some people might consider less “idiomatic” because Roblox has, for all these decades, used Vector3, and Vector3 is the one mentioned in API reference pages (i.e. .Position is typed as Vector3 and not vector), it might make your code more difficult to share with others because the types still mismatch with the typechecker
ALSO it appears I was slightly mistaken. You will get type checking warnings when assigning a vector to a Vector3 due to typechecker limitations, even though it does function and won’t error:
your physic engine will never be close by performance than roblox engine because its written on lower level, but making a custom engine is a interesting way to make your game more unique, answer relies on you
