This is a repost from City of Steam Design Dev Journals
Well, what I mean is… worst case scenario rendering. We consider doomsday to be when over 1000 players enter a single map and everyone rage quits due to poorrendering framerate.
There are two times that this is most common: Immediately when the server goes live; During weekly peak times.
So Joey, Johnny, Fan, Al and I were having a very late night discussion about how to distribute player population so that the first impression of the game doesn’t suck, and boy this meeting went long. I’m going to share a couple of the suggestions.
1) Shards, Instances, Copies: Instanced or hard-written copies of the same levels to balance population density. This does distribute players across many different levels, but it just has a lot of problems associated with being in the wrong level from your friends. We thought of sending various races or classes to their own tutorial levels, for example, but realized that players would hate this because of the two friend scenario…
“… you play Draug Arcanist, I’ll play Hobbe Warder.” And these two players will go to different levels and never meet each other. Fail. And on top of that, it still doesn’t solve when high level players are all crammed into the highest level public area.
Lets say you have different “lines” of communication in addition to everything else and players can swap to a different line at any time. This way would allow you to find friends and switch to a common line. But people would expect this to happen automatically, and there would be a lot of problems with customer service just explaining this.
2) Rendering Cap: After a certain population, you just stop showing the additional players who enter a scene. This really does work the most efficiently and looks best too because you just don’t know the scene is overpopulated.
This involves putting players into a priority list and then rendering the most important ones first (friends, team, guildies, etc). After that, the remaining players to be rendered are simply hidden, not rendered.
This has some problems when it comes to chat and 3d world synching. If you can hear someone in chat, but they aren’t rendered in the 3d world, it can be a nuisance. You could still select that player to bump their priority up to the top (and thus render them in full), but that’s not a perfect solution. Also, selecting them could be very difficult because of the volume of messages being pushed through the small local chat window.
3) Player Visual Downgrading: We thought that if there were over a certain amount of players, we start to downgrade what they look like, and hide certain bits and pieces to make rendering efficiency better. This works like a rendering cap except that after the cap is exceeded, every player thereafter would become a static mesh.
A static mesh is one that has no animation. It can still move around and glide from place to place, but it doesn’t animate (it doesn’t run or walk or idle). This is a better compromise than hiding the player, because you can still find them and select them (for trade, duels, interaction, etc.) And besides, if there are 300+ players on screen at once, you probably won’t know or care if they aren’t animated nicely –name, race and class is all you’ll need.
Now, because we still show all the players, the rendering cap on nice looking players would be lower because you have all those players on screen. It certainly doesn’t look the best, but at least you can select them.
After several hours, we decided on doomsday rendering scenario number 3, and will hopefully give players control over the distance and population of players that can be rendered in a scene. That’s what we’re going to be trying out for beta.
Next year we might be able to do a system of split lines/shards/instances, if it’s necessary on top of everything else. We don’t really want to split the population in a scene like that, but if the game is really doing well, it won’t be a problem –we can afford the time and money to solve it at that time.
Get on over to the Forum and share your thoughts!
