I am trying to rewrite my tower defense game using client sided rendering, but i am still confused where to even start. I would appreciate some resources, and maybe a flow chart lol
try to think about what the server needs and what the server doesn’t. anything that the server doesnt need to see (models, parts, animations) you make the client handle. for example for enemies, the server just needs the data of where the enemy is on the road as well as some enemy logic. anything else is something you can let the client handle/render.
1 Like
Doesn’t all this stuff render on the client already? Besides, the server still has to see all the models, parts, animations, and what not so it can send them to the client. They don’t render on the server though, that’s the client’s job.
Yes however you can optimize large ammounts of npcs by only rendering them on the client
How would i store the locations of the enemies while also keeping it accurate across multiple clients? How would the towers target it?
have you considered taking a look at the Chickynoid framework? the player models are loaded only on the client, while their locations (and other things) are validated by the server and use boxes. these boxes are not replicated to the client.
Can ypu provide a link or article to it?
i don’t have experience working on tower defense games so im not quite sure what the standard is (and take this with a grain of salt), but you’d preferably have your server keep the location data in the script itself and have the script access and write to i guess a dictionary. that way writing and accessing the data is fast and you don’t accidentally end up firing a bunch of code (i.e when you change the position of a part roblox might have to recheck and recalculate a bunch of other stuff etc etc).
now for client replication, personally i’d have it so the client has data regarding the movement speed of an enemy unit and calculates/moves it themselves, with the server syncing/sending the location of units in case the client goes out of sync.
for tower targetting the server could say 'this tower attacks enemy unit UNIQUE_ENEMY_NAME ’ and the client would find the position of the unit and then fire some tower unit animation code which points the tower at the enemy and causes some animation and vfx to happen.
more specifically:
- when the server creates an enemy, fire every client and passes them (the enemy type, the starting position, and additional data depending on what features your game has). the client then creates the enemy by finding the model that the enemy type uses, moving it to the starting location, and add them to your code which you use to move every enemy forward.
- your enemy-movement code on the client would be connected to RunService. every frame you run your enemy-movement code which would move the enemy with similar logic as to how you would move enemies server-sided, but you also move the enemy model and rotate it to match its movement direction. Since your game could lag, remember to use DeltaTime (the time between frames) in whatever movement formula you use so that even if the player lags/has low fps the enemies will keep going at the same rate
- every X duration, maybe every second, the server sends out a table of every enemy (their unique name) and their current position. this is so if the client’s enemies’s go offsync they will be put back to where they should be, based on the server.
then theres some more considerations (telling the client to delete an enemy upon death, telling the client to reverse an enemy’s walking direction, or to slow down, or whatever else kind of features your game has) but i think thats most of the logic (remember I’m not a tower defense developer so take the ideas above with a grain of salt, although they should work.)
1 Like
I think we have a failure to communicate here. What I mean by render is that stuff is drawn on the screen. That happens on the client, not the server. From reading about NPCs, those would have to be on the server so all the clients can see them. If you create an NPC only on one client, none of the other clients will see it, or even know about it. It has to be on the server so they can all see it. That’s just the way it is.
Now with that being said, there’s nothing saying that you cannot make your own custom implementation, but that’s probably more work than most people ware willing to do. An NPC changes position, the client sends the change to the server which broadcasts it to all the other clients. That’s one way to do it and the server would be out of the loop. However, that raises various security issues.
js visualize on the client and do logic on the server its that simple lol
Can you provide a more detailed explanation as to how the towers will target the enemies? How will a tower know that an enemy has entered its range?
You could have the server handle the targetting code (checking if a enemy is in a tower’s range). Whenever you want a tower to shoot an enemy (when the enemy is in range), the server would deal some damage, apply status effects if the tower applies any (like slow or burn), and finally the server would fire a remote telling every client to make tower X attack enemy unit Y (X being the tower that is shooting and Y being the enemy that should be shot up. With this you keep the logic on the server but visualize the attacking on the client. And whenever an enemy dies, the server tells the client this (via a remote) and the client would delete the enemy or play a death animation.
But keep in mind lag issues. If a player’s internet lags for long enough that a tower fires twice (or more), you might have the tower display 2 effects at the same time which can be weird and even cause an error. Preferably you might want tower attack effects to be overwritable/cancellable (as in whenever a tower shoots, you check if was already shooting and if so, clear/cancel any shooting effect or anim and finally tell the tower to shoot the enemy). Although there’s possibly a better solution to this.
1 Like
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.