Maximum player limit for a twitch shooter?

Options
I talked to a programmer for some help with a photon shooter I'm making in unity and he said this-

"From what I've seen many of the photon powered shooters are smaller in scale, you wouldn't generally have more than 10-20 players in a "room" and you would expect less than 5-10 on screen for any player at a given time. I'll admit that personally I haven't run the numbers, I've mainly speaking from what I've heard over the years from other people so I could be wrong about it but from what I've done myself I could see a number of problems."

Is this true? I was hoping to get at least 30+ people per server on screen.
This is discouraging to hear because I also want to have alot of AI around such as in DayZ & WarZ.
Is it possible to make a networked game of that size with photon&unity?

Comments

  • Tobias
    Options
    There is no hard limit to the max number of players.
    The problem is that more players mean that more updates will arrive on each client and it gets more and more likely that the connection breaks due to that. Using more bandwidth exposes weaknesses in the infrastructure and the more you can miss in a short time during an outage, the more difficult it gets to catch up.

    You can get more players per room out of Photon. It's pretty lean and very flexible. However PUN is not built to expose this flexibility but instead make things easier to start with.

    That said: Experiment! Use reliable data transfer as rarely as possible. Skip any update you don't need and save every byte that's not important to send. Then add interest management to save updates from far away.

    The applications we build on top of Photon are for "most" games and "room based" but it's open to come up with more specialized solutions. You could even sell your Photon-based application and dev framework, if you would like to.
  • Lizzy
    Options
    You need to have very highly optimized terrain and models.

    You can get around 10,000 in one scene with interest management.


    The question becomes... Can you make very low-poly models and terrain? Can you make the whole terrain in less than 20,000 tris?
  • Well yeah, the poly's would cover some of the client side usage. However what you're suggesting is that the client also recieves 10,000 packages multiplied by the PhotonNetwork.sendRate per second. If you're looking at a game where you need precision on the location of each player in the scene, you would be looking at a sendRate of anywhere between 30 to 60, which would result in a whopping 600,000 packages being recieved per second by every client in the room.

    So yeah, the poly count is obviously something to take into consideration, but more importantly you would need to consider your server programming.


    Some key things to consider would be:

    -the minimum changes that you want to be aware of. I can't remember the property names off by heart, however the PhotonNetwork class has three properties which allow you to decide whether it is worth updating other players based on the difference between the Vector3/float values in the last package and the current package. For example, setting the minimum vector3 change to zero, will result in every player updating their vector3 position every sendRate, even if they are not moving. However, changing it to a very small number will result in a drastic decrease in the size of packages sent due to players not updating their position/rotation every sendRate.

    -pick very carefully what to send in your packages. If you can have the client manipulate the other players rather than the information within the package be used to manipulate them, you will decrease the size of your packages and increase stability. This one is quite possibly the most important and most difficult part of server programming as it will require a lot of pre-planning when it comes to building the client-side programming.

    An example:
    One thing I like to do is to build a basic controller class, and an input reader class. The input reader class would be designed to read a player's inputs. So for example, i'll have a singlePlayerInputReader (activated in single player mode) which will do nothing but read the local controllers and then *!!send their values to the control interface!!*. The multiPlayerInputReader will read the variables coming from the package and then *!!send their values to the control interface!!*. Then, the control interface literally animates/moves/uses abilities based on the inputs being pressed by the other players. You would still need some server correction using this method (sending the position/rotation and having the client Lerp to the corrected position/rotation) too, however this would be apposed to sending the animation states; position rotation of child objects; server instantiating or sending the states of particle ettects etc etc. Using this method also allows you to turn off reliable data transfer entirely (on the photonViews), which is a huge bonus.

    -this one is a given, even for singple player games with a lot of moving objects. Disable other players as and when they leave your vision. WIthin unity there are OnVisible and OnInvisible callbacks (those might not be the method names so check the mono class of Unity) which allow you to do something when an object leaves and enters your viewpoint. Now, it wouldn't be simply a case of disabling all of the other player's objects when he/she leaves your view, because if you do their position stops being updated, meaning that if they then move back into your viewport over the server, you wouldn't know about it. So, the easiest way around this one would be to disable virtually everything but the root object which holds the photonview, and keep updating the position, but ignore everything else. Obviously there may be some cases where a player can still maybe fire a projectile at you while they are not in your vision, but as long as the projectile is server instantiated you should be okay here.

    -finally, and possibly most important is your sendRate. The sendRate ultimately defines how accurate the states are of all players within the room. If you've ever played an online game and seen that moment where someone's position suddenly Lerps to another position, the time between those to moments is the time between two packages.

    Ultimately, your goal is to keep the sendRate as low as possible, whilst keeping the position/rotation/states of each player accurate (time-wise) enough for the game to work. For example, say you build an fps game (please don't), when you as the local player fire your gun at another player and hit them (locally), you should be sending an RPC to that other player telling them they've been hit. However, on that other player's screen, he/she might have been some distance away from where you were actually shooting due to the fact that he had made a quick change in direction between the time of the last package that was sent, and the one that is just about to be sent. This obviously isn't the end of the world because the local player is ultimately more important here, however you obviously want to avoid this as best as possible.

    There are so many tricks that can be done to work around problems like the one above that I can't begin to list them all here. However here are some regularly used ones that might give you some ideas:
    -Lerp server corrected variables (for example the position) to the maxMovementSpeed*Time.deltaTime. This basically means that regardless of how low your send rate is, and how far the player is from their actual position, they will move to their corrected position at their maximum movement speed, rather than make random and ugly changes in their position.
    -Make even the locally controlled player be controlled by the server package. This basically means to send your local control inputs to the server, and wait for your own package to be resent back before you move your own player. This might not be a good idea for a twitch based game though.
    -Add a "homing" effect to projectiles and abilities which require you to land exactly on a target player. This will cause projectiles to look as if they hit in both the attacker and the defender's screen, even when the position of the player's don't exactly match in both clients.


    I am by no means a professional server programmer, so take this information and do with it as you wish. However, hopefully the above information has brought to light that indeed a twitch game with a large number of players in each room could be done in Photon, but the reason why "photon powered shooters are smaller in scale" is because of how much goes into making it work on a larger scale.

    With that being said, if you do plan on going ahead with your project, let me know. I'd be happy to help if I can.