Should I do effects on the client or server?

Help and Feedback Scripting Support
#1

I’m wondering whether I should do effects such as particles on the client or server. I hear a lot of people do it on the client by firing all clients when an effect is to be played, though I’ve always done it on the server, and I much prefer it.

SIDENOTE: Right now, I’m doing effects on the server. I’m not sure if this has any connection, but after being on a different tab for a reasonable amount of time while you are testing in studio (play button), effects are really laggy and delayed. Also, remote events fire really slowly. What is going on??

#2

If you want Effects to be seen by Everyone, i recommend the Server, the only downside is that its slow and delayed like you said,

meanwhile the client is fast, but its only running for the player and nobody else

You can Probably use a RemoteFunction or a RemoteEvent to send Data from Client -> Server and vice Versa to make the Effects Less Delayed

1 Like
#3

It goes slow after not having studio focused after a while. It’s really weird and it also happens in-game. It also makes moves really slow and this is very bad for my game. Thank you for replying, I think I’m going to try client and see what happens.

#4

I would definitely give client a try. I put animations and tweens on it now, which was basically a requirement for my game to look good. Only issue is communicating it. Instead of a remote event, consider using attributes. No biggie if using an event is better, though.

As for the tab thing is weird. If it gets better once the tab is refocused, it’s probably intentional to simplify the calculations if you’re not paying attention.

1 Like
#5

Things you can/should do on the server:

  • Particle emitters
  • Sounds

Things you should do on the client:

  • Animations (Animations will replicate)
  • Tweens
  • Lerping

Anything else you do on the server will jitter or stutter.

That sounds like an issue elsewhere in the code. That shouldn’t be happening.

2 Likes
#6

I think it must be something I’ve done. It’s quite rare and I’m waiting for it to happen again so I can record it and compare it to how it’s supposed to be.

#7

I hope that’s the case, but even when I refocus it does not fix at all. It seems like some sort of server lag… I’ve seen this kind of thing in other games but with different circumstances.

#8

That’s definitely a code issue then. Does it happen in an actual game?

#9

Yes, it has happened once before.

#10

Weird. I have no idea what the cause could be. Maybe post the code you’re using here.

#11

Anything visual or sound related should be on the client. The server should be logic only.

This is unnecessary bloat on the server. With the exception of things made in studio.

3 Likes
#12

There’s a bit too much code to send, although I think I’ve found the problem. I still need to do more testing though, to be sure.

#13

Particles are rendered on the client. Sounds are… emitted… from the client, too. This shouldn’t cause any performance problems

#14

Adding onto this: why not have everything on the clients, and use RemoteEvents to :FireAllClients() when an effect needs to happen?

#15

Yeah, thats the idea

Text

#16

These instances add up in larger games. Storing the ids then rendering it on the client is what I mean.

#17

Then add them to debris?

#18

I believe particles are automatically rendered on the client if it detects a particle emitter, so there’s not much of a reason to do it that way. As for animations and tweens, it is definitely advantageous to do what you’re describing, although if it’s possible to use attributes or values instead (and on the client connect to AttributeChanged) that’s better.

#19

The only reason I’d include particle emitters is for consistent architecture, though you’re right & the method I described would use more than the required resources.

Is not a way I’d thought about handling this.

There’s potentially an argument of using RemoteEvents over in-built ROBLOX events for easier manipulation and interpolation, though I can see the discussion on saving resources by eliminating the need for extra objects.

Interesting idea. I think I’m still on the fence about which method I prefer.

Kudos!

#20

Do you want exploiters able to activate them though?