quake84
Official Terrarian
Hey!
In the current state, Terraria's multiplayer support barely goes out of its' co-op comfort zone.
From experience I gathered running public servers I can tell that there's plenty of room for improvement (and gain) that can be made relatively easily.
I'll try to explain each one of those problems, why it needs a fix, how an example fix could look (theoretically or pseudocode etc) and what improvement it brings wherever possible/applicable
1. Multiplayer menu (and other menus in general) could use a better display of recent servers and available options.
Character and world selection got fleshed out UIs (relatively to the rest of the game) however multiplayer is still.. a text-based mess.
Example:
VERSUS
The world selection for singleplayer is decently designed, just like character selection. Previews, buttons, various information and the like.
Multiplayer server selection? A bare text field and 5 or so clickable textlines which point @ previous servers. In a perfect world multiplayer servers would have a similar screen to character/world selection, where entries are just... servers.
I am not an UI designer, but I'm fairly confident copying the UIs for character/world selection and editing them slightly would bring a massive improvement.
2. Little control over the client on a server
In Multiplayer, server operators have very little control over what players do. In fact, in vanilla such control is completely nonexistent! It's unnecessarily complicated to do something as simple as editing a player's inventory.
SSC is a good step in the right direction, but it's not enough.
Many packets sent to the client get dropped, and many other required packets are either nonexistent (some data being effectively unobtainable) or they carry very little metadata required for, say, anti-cheat validation.
My favorite example of that is inventory synchronization. Currently you only get information that "this slot changed to X,Y,Z". Why did it change? Where did the previous item go? Where did the new item come from? Why did the stack size change? All of those things have to be painstakingly figured out while it could be a lot easier for developers. Inventory management packets should be broken up into a few packets:
* The current packet (#5) should be left in for connecting purposes (sending the inventory to the server)
* All inventory operations like stack splitting, moving items etc. should have their own packet that explicitly defines which item got moved where and from where.
* If the above point isn't possible, at least some more rhyme and reason to inventory updates. A "consumeitem" packet could be great for things like bullets and arrows (so that I or anyone else doesn't have to play guess games where and why that item vanished)
3. Clientsided-ness of the game
This links with point #2 - the majority of the game functionality happens on the client's side. Hit registration in both PvP and PvE, AI simulation et cetera. This is certainly lag resistant when untouched, but when the server tries to make any changes is falls apart. Additionally, many things being clientside (worst offenders being of course hit registration and inventories) opens up a gate for cheating in multiplayer....
Nobody likes this, especially server admins. Please expose more knobs to servers so this can be stopped gracefully.
4. Lack of authentication
Currently the game's multiplayer is nothing but a bare socket. This means circumventing bans is one of the easiest things people do. Get a VPN/proxy, change your uuid and continue being a nuissance to server staff. SteamID-based authentication (and perhaps a GoG equivalent) would be a godsend here. So would a more persistent client identification system. Perhaps a Steam-verified hardware ID? The harder to spoof, the better.
4a. Insecure connection
The game runs on unencrypted sockets. Multiplayer servers (most of the time) require logon to a server account using /login.
The passwords are transferred over plaintext through the Internet. Many people reuse passwords to multiple sites.
This is a recipe for disaster. Some sort of traffic encryption for servers would be a godsend here.
5. Lack of customization on server side
Server operators have very little possible place to customize their players' experience on their server. There's no GUI system whatsoever, everything is done through chat (which on its own could use a revamp) and the most we get is status texts. Which lock up the game sometimes. And combat texts. Which are largely out of our control. We can't even decide how long the text lingers.
One thing we could be given could be a sign-like GUI with buttons for server administrators to be able to send to the client and get input from.
Or allow using colours in status texts and disconnect messages. Perhaps manual spawning of "gore" (aka particles)? Or large colorable HUD text which we could use to, say, announce a minigame's winner or a game event. The possibilities are truly endless, and many of them are "almost implemented" and all it takes is adding the hud element, and exposing the knob to server developers.
6. Horrendous netcode
After some performance testing it's clear that a lot of processor time is wasted in netcode classes. The processor load increases in a factorial manner as more and more players join the server. In fact, the stock server cannot "uphold" more than 30-40 players without dying a horrible death of a mixture of lag, overloading and bugs. The main causes are netcode but not only that.
The problem lies in suboptimal implementation and synchronized I/O. Each client should have a packet queue we can drop information into and move on. Granted, many parts of the game would require a radical redesign to accomodate that, so optimizations instead of that would also work.
Part of this is also how the client behaves. There should be more consistency in how often a client updates (aka "at least once a second" or something of the sort). This applies to the majority of network communications between the game and server.
7. NPC AI optimisation
NPC AI is another one of the processor cycle hogs in the server code. Having a 'full' 200 mobs spawned can make the server steal an entire cpu core all to itself and grind the server's update rate to a screeching halt.
Image taken with 36 players (bots) and 200 random mobs spawned. The "perfect" tickrate is 60.00. So here we have effectively ~58% of the desired performance with relatively few mobs (200 is nothing!) and few players (many minecraft servers get more than 36 players, it's also nothing!)
8. Hardcoded limits
Currently the game has a hardcoded limit of 255 players, 200 NPCs, 400 items, 1000 projectiles and the like.
To allow multiplayer to fully flourish (without restricting it) most of those limits should be removed, or at least adjusted (scaled up that is) to make sense. In the current state one player can "have" about 3-4 projectiles before the server hits the limit (pets, light pets, etc are also projectiles), there can be about 1 or 2 items per player laying on the ground before they start disappearing and there's less than one mob per player. Implying everyone went onto a very large map and had an area all to themselves (which is possible) the game would be unplayable at best.
Considering a scenario where there are 255 players on a map (and the server is stable [hypothethically, of course]) one light pet, one pet and two musket shots from each player deplete the limit.
In reality the limits get tripped with as few as 30-50 players during a boss fight. Bee guns and the like spawn hundreds of projectiles.
9. Expert HP scaling
Ridiculous. With 30-50 players boss health scales so much it's undefeatable in one night. There's simply not enough time to deal enough damage. The expert HP scaling should cap off at some point.
I do not mean to come across as rude, so I apologize if I did - but those are dire issues the require almost immediate attention. Please do something about this.
Multiplayer has a lot of potential, but all of it goes and will continue going to waste if it doesn't get noticed and embraced by you - the devs.
Please do give it a chance.
In the current state, Terraria's multiplayer support barely goes out of its' co-op comfort zone.
From experience I gathered running public servers I can tell that there's plenty of room for improvement (and gain) that can be made relatively easily.
I'll try to explain each one of those problems, why it needs a fix, how an example fix could look (theoretically or pseudocode etc) and what improvement it brings wherever possible/applicable
1. Multiplayer menu (and other menus in general) could use a better display of recent servers and available options.
Character and world selection got fleshed out UIs (relatively to the rest of the game) however multiplayer is still.. a text-based mess.
Example:
VERSUS
Multiplayer server selection? A bare text field and 5 or so clickable textlines which point @ previous servers. In a perfect world multiplayer servers would have a similar screen to character/world selection, where entries are just... servers.
I am not an UI designer, but I'm fairly confident copying the UIs for character/world selection and editing them slightly would bring a massive improvement.
2. Little control over the client on a server
In Multiplayer, server operators have very little control over what players do. In fact, in vanilla such control is completely nonexistent! It's unnecessarily complicated to do something as simple as editing a player's inventory.
SSC is a good step in the right direction, but it's not enough.
Many packets sent to the client get dropped, and many other required packets are either nonexistent (some data being effectively unobtainable) or they carry very little metadata required for, say, anti-cheat validation.
My favorite example of that is inventory synchronization. Currently you only get information that "this slot changed to X,Y,Z". Why did it change? Where did the previous item go? Where did the new item come from? Why did the stack size change? All of those things have to be painstakingly figured out while it could be a lot easier for developers. Inventory management packets should be broken up into a few packets:
* The current packet (#5) should be left in for connecting purposes (sending the inventory to the server)
* All inventory operations like stack splitting, moving items etc. should have their own packet that explicitly defines which item got moved where and from where.
* If the above point isn't possible, at least some more rhyme and reason to inventory updates. A "consumeitem" packet could be great for things like bullets and arrows (so that I or anyone else doesn't have to play guess games where and why that item vanished)
3. Clientsided-ness of the game
This links with point #2 - the majority of the game functionality happens on the client's side. Hit registration in both PvP and PvE, AI simulation et cetera. This is certainly lag resistant when untouched, but when the server tries to make any changes is falls apart. Additionally, many things being clientside (worst offenders being of course hit registration and inventories) opens up a gate for cheating in multiplayer....
Nobody likes this, especially server admins. Please expose more knobs to servers so this can be stopped gracefully.
4. Lack of authentication
Currently the game's multiplayer is nothing but a bare socket. This means circumventing bans is one of the easiest things people do. Get a VPN/proxy, change your uuid and continue being a nuissance to server staff. SteamID-based authentication (and perhaps a GoG equivalent) would be a godsend here. So would a more persistent client identification system. Perhaps a Steam-verified hardware ID? The harder to spoof, the better.
4a. Insecure connection
The game runs on unencrypted sockets. Multiplayer servers (most of the time) require logon to a server account using /login.
The passwords are transferred over plaintext through the Internet. Many people reuse passwords to multiple sites.
This is a recipe for disaster. Some sort of traffic encryption for servers would be a godsend here.
5. Lack of customization on server side
Server operators have very little possible place to customize their players' experience on their server. There's no GUI system whatsoever, everything is done through chat (which on its own could use a revamp) and the most we get is status texts. Which lock up the game sometimes. And combat texts. Which are largely out of our control. We can't even decide how long the text lingers.
One thing we could be given could be a sign-like GUI with buttons for server administrators to be able to send to the client and get input from.
Or allow using colours in status texts and disconnect messages. Perhaps manual spawning of "gore" (aka particles)? Or large colorable HUD text which we could use to, say, announce a minigame's winner or a game event. The possibilities are truly endless, and many of them are "almost implemented" and all it takes is adding the hud element, and exposing the knob to server developers.
6. Horrendous netcode
After some performance testing it's clear that a lot of processor time is wasted in netcode classes. The processor load increases in a factorial manner as more and more players join the server. In fact, the stock server cannot "uphold" more than 30-40 players without dying a horrible death of a mixture of lag, overloading and bugs. The main causes are netcode but not only that.
The problem lies in suboptimal implementation and synchronized I/O. Each client should have a packet queue we can drop information into and move on. Granted, many parts of the game would require a radical redesign to accomodate that, so optimizations instead of that would also work.
Part of this is also how the client behaves. There should be more consistency in how often a client updates (aka "at least once a second" or something of the sort). This applies to the majority of network communications between the game and server.
7. NPC AI optimisation
NPC AI is another one of the processor cycle hogs in the server code. Having a 'full' 200 mobs spawned can make the server steal an entire cpu core all to itself and grind the server's update rate to a screeching halt.
Image taken with 36 players (bots) and 200 random mobs spawned. The "perfect" tickrate is 60.00. So here we have effectively ~58% of the desired performance with relatively few mobs (200 is nothing!) and few players (many minecraft servers get more than 36 players, it's also nothing!)
8. Hardcoded limits
Currently the game has a hardcoded limit of 255 players, 200 NPCs, 400 items, 1000 projectiles and the like.
To allow multiplayer to fully flourish (without restricting it) most of those limits should be removed, or at least adjusted (scaled up that is) to make sense. In the current state one player can "have" about 3-4 projectiles before the server hits the limit (pets, light pets, etc are also projectiles), there can be about 1 or 2 items per player laying on the ground before they start disappearing and there's less than one mob per player. Implying everyone went onto a very large map and had an area all to themselves (which is possible) the game would be unplayable at best.
Considering a scenario where there are 255 players on a map (and the server is stable [hypothethically, of course]) one light pet, one pet and two musket shots from each player deplete the limit.
In reality the limits get tripped with as few as 30-50 players during a boss fight. Bee guns and the like spawn hundreds of projectiles.
9. Expert HP scaling
Ridiculous. With 30-50 players boss health scales so much it's undefeatable in one night. There's simply not enough time to deal enough damage. The expert HP scaling should cap off at some point.
I do not mean to come across as rude, so I apologize if I did - but those are dire issues the require almost immediate attention. Please do something about this.
Multiplayer has a lot of potential, but all of it goes and will continue going to waste if it doesn't get noticed and embraced by you - the devs.
Please do give it a chance.
Last edited: