How to not lag if there are 1000 parts in your game?

[wild sandal]

Let's say I make a tycoon game where there are 1000 parts that collide with the convoyer then move to the cash collector. I heard that I could set the networkowner of the parts to nil and that would help everyone's fps and lag. Is that true? Thanks

[ruby birch]

Setting the network owner to nil switches to the server, and that will lag the server

[wild sandal]

Oh

Okok

[ruby birch]

but you can turn off CanCollide or use CollisionGroup so there is less physics lag

[wild sandal]

What would you recommand me to do? I set the collision fidelity to box a least lol

[wild sandal]

Do you think 1000 part is excessive?

[warm pewter]

no, this is not true

[warm pewter]

1000 parts is nothing. 1000 moving parts is something else entirely. most of the lag is going to come from the network. simply sending physics data for that many parts takes up a lot of bandwidth.

so no, setting network ownership isn't going to really change anything.

[barren pumice]

agree

if you were want to do 1000 parts

visualize it on client

[warm pewter]

ya have to do some shenanigans to make the moving parts client only

[wild sandal]

Thought about that but it's cooler if everyone sees it

[wild sandal]

What if they only move on the x asis. I mean on a conveyor

[ruby birch]

perfect

[warm pewter]

no. they're still subject to physics

[ruby birch]

that makes it easier to visualize on the client

[barren pumice]

then send it on all client

simply enough

8 clients, 1000 parts per client

done it server, it'd choke your network

[wild sandal]

I mean max 1000 on all the servee

[barren pumice]

still the same tho

[warm pewter]

clients should simulate the moving parts for themselves

bunch of different ways you can do this, like firing a remote to all clients to make them spawn a part.

[wild sandal]

So only the client would see theie part

[warm pewter]

yes, every client would see a different part, but they would see it in approximately the same location

[barren pumice]

yes

[wild sandal]

Hmmm

[barren pumice]

1000 parts is a lot

probably 300kb/s

or even more

[warm pewter]

then to have the server simulate the actual part's movement, you could make one on the server and parent it to the server's camera.

[wild sandal]

Yeah lol I was looking for the worst case

[warm pewter]

stuff parented to servers camera doesn't replicate, but is still subject to physics

so you can still physically simulate the part moving along the conveyor without it replicating

[barren pumice]

server'd see it , right?

[wild sandal]

That's intresting

[barren pumice]

just for, visualization on the server

?

[warm pewter]

ya so the server knows when the part touches the seller

[wild sandal]

What about 200 moving parts?

[barren pumice]

thats possible? wow.

[warm pewter]

otherwise you'd have to calculate how long it should take for the part to reach the seller at the end

[barren pumice]

yes i do this

all the time

using maths

[warm pewter]

ya that's the hard way. it's probably the better way, but also much more difficult.

[barren pumice]

theres server camera?

[wild sandal]

Preorganised path could work too right?

[warm pewter]

yes

[barren pumice]

i'd look more into this

[warm pewter]

ya if you move the part along fixed rails, like a path you know beforehand, then you should be able to calculate the duration very easily

[barren pumice]

so parts on client, parent it to server camera?

[warm pewter]

having the server physically simulate the part is lazy method and works about as well

[barren pumice]

but doesnt that will increase physics on server?

[warm pewter]

who cares

it's the server

roblox servers are surprisingly beefy

the only real bottleneck is networking

[barren pumice]

you're right

[warm pewter]

if you wanted it done "right", you'd do this method, because you can guarantee things. if you instead rely on physics, well occasionally parts can fall off the conveyor.

but maybe you want that

[wild sandal]

So overall would you recommend me to create preorganised path or the server simulating the part moving?

[warm pewter]

one of the two, ya

neither is inherently better. the premade path is more physically reliable but harder to make (parts wont fall off, duration of journey to end of conveyors is definite and known in advance, easier to sync all clients with where the part actually is), vs physically simulating a copy on all clients and the server (parts can fall off, duration of journey is unknown, parts can desync between client and server appearing in different locations, but is significantly easier to make for a beginner)

[wild sandal]

Then I'll go with the second option lol

1 month of scripting

😅

[warm pewter]

ya there's always more than one way to do anything in code, and the decisions always ends up a balance of difficulty vs what you're trying to do vs what you're comfortable letting slide

[wild sandal]

Yess

[minor geyser]

** You are now Level 10! **

[ruby birch]

english premium at its finest

[warm pewter]

i.e the desync between client and server in this situation is largely negligible

[wild sandal]

Yes

I'm not sure I get the second option

How is it called, so I can watch tutorials and get better 😅

[warm pewter]

if you need a tutorial then i suggest you watch beginner dropper/tycoon tutorials and disregard everything in this thread

and accept that you won't be dealing with the 1000 parts situation at all.

if it lags your game, it lags your game 🤷

[wild sandal]

Yep I can also reduce the ammount of parts for now it's maximum 100 parts per server

[warm pewter]

at least until you know enough about scripting that you can understand what you need to do to accomplish a technique just by hearing its description like here.

[wild sandal]

Yes

[warm pewter]

most established scripters can do this no problem

all scripters ranked s1+ can do this also

[wild sandal]

Oh

Yeah I'm pretty new

You seem really good

[warm pewter]

so you got work ahead of you if you want to be a scripter for now tho best advice is just keep making bad stuff until you get good enough to make good stuff. considering problems like 'wat if i had 1000 parts' is a good sign, but solving problems like this takes skill, and that can take a while to develop - there are no ai shortcuts unfortunately 👍

[wild sandal]

Yesss! 🫡 I will try my best to get better. Thanks a lot for the tips 😁

[wild sandal]

So it's better and less laggy that everyone spawn their part and the other's people part on their device(local) than if the server spawn 1 for everyone?

Because FireAllClient is easy and fast to change lol

[warm pewter]

wat no the bottleneck is bandwidth so spawning the parts on each client = 0 bandwidth

otherwise the server (or a client with network ownership) needs to send the physics to every client

for 1000 parts this is easily over 300kB/sec

ideally a game should be under 50kB/sec

[wild sandal]

So local is better?

[warm pewter]

100kB/sec if you're being generous

press ctrl+f7 for a basic net graph. Sent/Recv combined should be under 100kB/sec at all times if you can help it.

for reference

[wild sandal]

But if I do it local people's phone calculating all the parts physics will make reduce their fps ?

[warm pewter]

try spawning 1000 parts just on their own, and the only special thing is they are unanchored.

then look at the graph

[wild sandal]

😂

Yes

So everything that I can do local I must do?

[warm pewter]

bruh

[warm pewter]

there's always more than 1 way to skin a cat, in fact with programming there's usually infinite ways to do anything

[wild sandal]

I think I'm not catching something

[warm pewter]

you're not catching the fact there is almost never an ultimate final "correct" solution.

there is no "it's always better to do X"

[wild sandal]

Oh yeah

[warm pewter]

it always depends.

[wild sandal]

But spawning parts on server or spawning parts on local?

Or Each have their weakness

[warm pewter]

it depends. each have their pros and cons, strengths and weaknesses.

[wild sandal]

If everyone had a rtx 5090 then I would do it on local?

[warm pewter]

graphics is not the bottleneck

[wild sandal]

Then why wouldn't local be always better?

[warm pewter]

you lose net sync

that meaning, the part exists in the same condition and location on both client and server at the same time, and is responsive to physics i.e walking your character into a part to push it.

when its client only, there is no net sync. the part is unique to that client.

usually reserved for parts that are purely visual in nature, which an item on your conveyors would be.

[wild sandal]

Thats exactly my case

[warm pewter]

e.g when you do a downslam and prop debris goes flying everywhere, most of the time those parts are on the client, there's no reason for them to exist on server since they are purely visual

it does mean it looks different for every client, but if that's not important then it doesnt matter

[wild sandal]

Yes

It's not important

As long as they see it

[warm pewter]

e.g if you had an ability that spawned a bridge in front of you that other players can walk on, you'd want to either do that on the server, or do some shenanigans where it spawns a copy on all clients

so it has a mix of the purely visual while having some net sync

[wild sandal]

So I will make a FireAllClient() to spawn parts

Do you know if any device could run 1000 moving parts on local(their phone or tablet)?

[warm pewter]

this is not good enough on its own for a dropper/seller/conveyor thing like a tycoon

[warm pewter]

ya most phones should be able to do 1000 moving parts particularly if their collisions are trivial

[wild sandal]

I don't get what you mean

[warm pewter]

i.e, the 1000 parts do not collide with each other and are only colliding with the world or anchored parts only. collisions are non-trivial when its between 2 or more moving parts, emphasis on the more.

1000 unanchored parts in a small pile in the center of your baseplate has wildly different physics costs compared to scattering all the 1000 parts across the baseplate so none of them are touching each other.

[wild sandal]

Yeah I will make collision groups so the parts dont collide with eachother but only eith the conveyor

[boreal spire]

atp just make them have a predetermined path so you skip the physics processing

[warm pewter]

either or, they both work 🤷

[wild sandal]

But @warm pewter for a yes no question, would you put dropper parts on client or server?

[warm pewter]

im not making a game with droppers so idk

i would pick whichever suited my game the best compared to the effort im willing to put in

[boreal spire]

if its on client other players wouldnt see your droppers dropping anything, are you sure you want that?

i mean

i guess if it works it works

[warm pewter]

fireallclients, not just one

[wild sandal]

On clienr for everyone

[boreal spire]

yeah but then they would only be able to see their own dropper no?

[wild sandal]

No

For example My device would load all your parts and mine

You would load them too

[boreal spire]

i see wym

[warm pewter]

i think bro just figured out client/server architecture

[wild sandal]

Client? 😂

[boreal spire]

nah

[wild sandal]

😂

[boreal spire]

i just didnt get what he meant

[warm pewter]

the step to realize the server is singular, and the clients are many and each have their own version of the world, is one that a lot of beginners struggle to make.

[wild sandal]

I know the difference

I just don't see the downside of using client to spawn dropepr part

Since you said graphics aren't the bottle neck

[warm pewter]

ya for a tycoon game in this situation there isn't too much downside

but there is one: the server still needs to know when the part touches the seller at the end.

otherwise it's just a part moving along a conveyor and the player gets no money from it

[wild sandal]

Touched wouldnt work?

Since its not server hmmm

[warm pewter]

well its on the client, what is .touched going to do?

client cannot give itself money, that's a bad idea

[wild sandal]

Right lol

Couldnt i just put another remote

To give the money on server

[warm pewter]

that's the client giving itself money...

exploiter: "hey server can i have 99999999 money i swear i just sold the best block in the game joined 5 seconds ago" server: "sure"

[wild sandal]

Lol

[wild sandal]

Any way to resolve that 🤔

[warm pewter]

ya thats why i said with this technique you'd also want one of the parts on the server too, same as the clients, but for the server one you parent it to the server's camera so that it doesn't replicate (nothing gets sent over network)

and then you can use that part as the trigger

[wild sandal]

Ohhhhhhhhh

I understand

[warm pewter]

ya

[wild sandal]

And if I parent it to the server cam is it visible?

Or I can just change it's transparency

[warm pewter]

no, parenting to server cam keeps the part physically alive without replicating it

e.g it is subject to gravity and whatnot, but only the server can see it.

it's a bit like making a part on the client how it doesn't get sent to server. same thing but opposite direction.

you need the parent to camera step to make that work.

ya

[wild sandal]

Ohhhh

[warm pewter]

all this to avoid the 300kB/s+ bandwidth cost of 1000 moving parts.

code do be like that

[wild sandal]

It doesn't look bad

To do

[warm pewter]

anyway good luck, i think you got this

[wild sandal]

One last question 😁

Will the client part and the server (camera parent) part collide?

[warm pewter]

no

[wild sandal]

Nice

So wait is it easy to change? I just FireAllClient() and also spawns part and parent them to the server camera?

[warm pewter]

that's the main part of this method yes

you can add stuff to it and make it more complicated obviously

like make some effort to sync the parts like they have a shared guid so when the server sells the part it can notify all clients that it was sold so each client in turn can remove their version of that part

[wild sandal]

Oh yeah right the server part and the client part will not be at the exact same place

How bad is the delay?

[warm pewter]

they are completely different instance, so you may want them to have a unique number so you can pair them up later

[warm pewter]

about 250ms on average

[wild sandal]

Not bad

[warm pewter]

50ms from roblox physics, 200 from network latency

[wild sandal]

They will get their money +-250ms when their parts hit the cash collector

[wild sandal]

Client part are only for the looks why do I need to pair them?

[warm pewter]

so when the server does something to the part, like sell it, it can notify all clients what happened to that part

e.g if for one of the clients the part fell off the conveyor, it would stay there forever

you can either link it with a httpservice:generateguid orrrr just ignore it and listen for touch world or whatever and accept the desync

you need to try some of this stuff out bruh

asking isn't going to get you anywhere atp

why are you still here go build it

[wild sandal]

Right lol

[wild sandal]

Have school in 7h30 hours, need to go sleep 😂😂

[wild sandal]

I just delete it

[warm pewter]

maybe do that first, studio will still be here tomorrow

[wild sandal]

Do you script full time?

I mean do you live off roblox?

If not too personnal

[warm pewter]

not yet but that's the plan

i have

...

[wild sandal]

Nice

[warm pewter]

things

that im working on.

[wild sandal]

Hmmmmmmm

A story game?

[wild sandal]

Horror game

[warm pewter]

no

can be but no that's not the goal

[wild sandal]

Oh

[warm pewter]

with any luck you'll find out when its ready

[wild sandal]

Is it your first game?

[wild sandal]

Ohhhh

[warm pewter]

haha no

[wild sandal]

😁

[warm pewter]

have made a fair few games outside of roblox, 2 finished and released games on roblox (not great games tho, just practice, but they are completed)

[wild sandal]

Oh thats cool

How old are you?

[wild sandal]

What will be the name so I can try it?

And around when will you make it public?

[warm pewter]

most likely older than you

[warm pewter]

idk i havent decided. it'll be done when its done 🤷

[wild sandal]

I'm 18

[wild sandal]

Yesss

[wild sandal]

@warm pewter I haven't found anything online about server camera, do you know where I can find more info?

Does it work on any camera that you put on your explorer?

I will try it once I get home

[wild sandal]

So I could just delay the client spawn with task.wait(0.25) ? 🤔😮

(Making the FireAllClient() then task.wait() then spawn the server side dropper part)

Task.wait(0.25) would work for the average people ig

But for people with less and higher ping