That would take too much performance
No, Iâm saying at runtime, or when you make your tracks in studio, use a spline curve with a high definition (lots of waypoints) and move between those instead of moving using the spline math. It will look nearly identical if you have a high resolution on your spline curve and youâll have much more control over it, not to mention that a interpolation calculation is far less computationally expensive than calculating the position of an entity along a curve.
Also why not use bulkmoveto as its good for performance i think
For example, see this path?
This is a series of spline curves, and if you understand how spline curve math works then youâll know that you provide it with a time t and it gives a point along the curve. Iâm simply saying, sample your spline curve at runtime or when you build your maps, store these yellow points, and move in a straight line between each of the yellow points.
I recommend using Bones to offset your entities rather than moving a part. Bones donât update physics information and are far faster to move. I did some testing around this as well:
Bones always took 0.002ms, CFrame was roughly 0.023-0.03ms and BulkMoveTo was around 0.012-0.16ms
In general, bones are about 7.5x faster to move than BulkMoveTo.
Hereâs the logic I used to test this:
local Cube = workspace.Cube.Bone
local Cube2 = workspace.Cube2
local Cube3 = workspace.Cube3
local bulk = {Cube3}
game:GetService('RunService').Heartbeat:Connect(function()
local cframe = CFrame.new(math.random(-100, 100), 0, math.random(-100, 100))
Cube.Transform = cframe
Cube2.CFrame = cframe
workspace:BulkMoveTo(bulk, {cframe}, Enum.BulkMoveMode.FireCFrameChanged)
end)
2 Likes
I kinda feel like Iâm being ignored though, so Iâm just gonna let you guys hash this one out. Enjoy!
I read your post, and its interesting. But do beta features work when the game is published
i am sorry but i am doing home work soo i canât answer that fast.
i have tried using bulkmoveto but i couldnât figure it out.
Beta features are generally only enabled in studio, but itâs only a short time until thatâs released. But the main performance improvement over the traditional method is the use of Bones.
I will look into it, as I am too trying to create a TD game
1 Like
Also, Will one script manage everything for the enemy, or client-sided rendering? I am looking for the better one
I would run the same simulation on the client and the server separately. The client could handle bone updates, while the server can do more important work, like checking for things in tower range, etc.
If your entity has a SpawnedTime value which is the same on the client and the server it should be trivial to interpolate it to the correct position, and maintain near perfect sync between client and server.
The added advantage of this method is that the client only needs to be notified of entities which have spawned in and entities which have died.
I was thinking bout the server calculating the cframe and tower stuff, then the client does the movement too. But wont heartbeat functions take a lot of server bandwidth
If youâre talking about what I wrote in the other post, that simulation can be run at any step rate, within reason. It could be 10/s if you wanted, obviously that causes a delay in when things like towers would recognize that theyâre in range. But for 2k entities, with moving body parts, and towers which detect them in real time I was able to run that simulation in 1.2ms all on the server. So if you took bone sim out of the equation (which is roughly 50% of the work in my code) you should see sub millisecond simulation at 60 FPS.
The position calculation takes roughly 0.0005ms per entity in my example.
I am sorry, but I didnât understand fully. Can you explain a bit further?
But wont heartbeat functions take a lot of server bandwidth
In the example I provided in the post I linked, for 2,000 entities (enemies) on screen at once, (in my case, the server was doing all of the work, but thatâs only an example of how to make a high-performance entity system) my system was able to update all 2,000 entities at 60 FPS with 79 towers in 1.2ms. You have about 16.667ms per frame to maintain 60 FPS. If we were to only simulate the entityâs position without updating any character models on the server, I would imagine that simulation time would drop to <1ms easily. So I donât think that âserver bandwidthâ is a concern here.
Does that help?
Yes that helps more, But imagine you got to send some other properties like:
health,ID of the enemy, name of the enemy, etcâŚ
health is used to show the health by hovering over the enemy
You have to use tables, which send slightly more data
why would you send the health? when you can send a number and on the client search in your dictionary?