• Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

11424 Excellent


About hplus0603

  • Rank
    Moderator - Multiplayer and Network Programming

Personal Information

  • Interests


  • Twitter
  • Github
  1. Sounds like you have a pretty custom need that's not "standard" and you probably wouldn't find a good solution for that. Btw: what do WebRTC browsers do on those 4G networks? Do they not work? Might be worth looking at.
  2. Your requirements seem pretty weird. Why can't you control the port? Why can't you get IP addresses for servers? What game has more than 12,000 separate servers, yet has to live with these requirements? Anyway, it seems to me that the best thing for you is to put the intended target route into your network packets. The packet header would then contain "please forward me to server instance X." You would write a simple proxy that would receive the UDP packet on the determined port, look at the X value in the header, and forward the packet as appropriate. Note that there really isn't a better way to do it using "just" plain UDP, because two users may be behind the same NAT firewall, and your system may decide that user A should go to server X and user B should go to server Y, and thus you can't just use the remote IP address as the route determinant. Similarly, some NAT firewalls rewrite the source port, so you won't have a well-defined source port for each user.
  3. Then you don't need a load balancer. Give each client a public IP, and let each client connect to the sever in question. Done! (IIRC, Roblox has something like 12,000 public IP addresses for their servers...) The other option is to use a different port for each destination server, so the load balancer would route port 2001 to server A, port 2002 to server B, and so forth. However, I don't know how high a packet rate you can get up to in the end in this way -- you'll very likely need multiple load balancers to keep up with "thousands" of servers. Anyway, public IP per server. Seems absolutely easiest!
  4. Any hardware load balancer should be able to do UDP DNAT load balancing, at least based on source IP:port. Many people seem to simply do this with iptables (on Linux) but I think Nginx can do it, too. Note, by the way, that the player doesn't connect to "serverA.yourgame.com," they connect to "loadbalancer.yourgame.com" which picks one of the servers to forward the player to. If you can give each player a separate name to connect to, you don't need the load balancer; just connect directly to the server.
  5. Authoritative server

    What is it you don't understand, more precisely? Do you understand how a regular game, with time stepped simulation, works? This link is pretty good as a general overview:
  6. 16-thread, 122 GB instances are $1/hour on Amazon. Or you could blow $13/hour for a 1900 GB server with 128 threads :-) By the time you have enough players that you need more than 8 GB of RAM or whatever, you probably also have enough subscribers to pay for the servers to run it. How does a player on tile X shoot/collide/interact with a player on tile X+1 if they are vertically stacked on the server? Do you teleport any projectile, and not use any raycast weapons? Maybe there are no player collisions that matter across tile edges? Anyway, I don't see why you couldn't just load each tile on the server for now, and keep an eye on memory consumption of tiles, and by the time you have enough content and players that it matters, go for something with more RAM.
  7. You don't need to load textures or render geometry for terrain. Maybe that's already calculated in the 8 MB, though? 800 meters squared times 256 chunks is 12.8 * 12.8 kilometers. This is larger than any current FPS or similar game. It is also large enough that simple float-32 based physics simulation will be unstable and jittery towards the edges. And how will you build all this terrain? That is a truly huge amount of data to create, especially if you want the data to be rich enough to require 8 MB per chunk. How fast do players travel, and how fast are chunks to load? With flash drives, I'd expect you to be able to load at least 100 chunks per second, and if a player travels 400 meters in a second, that's ... very fast! You'll probably do enough with 4 chunks loaded (the closest neighbors to the chunk quadrant each player is in.) And what do you do for remote players on the local player's machine? Load all the chunks on the local machine? Not show or simulate them if they're more than a kilometer away? Why is the game multiplayer then? Finally, a modern server has 256 GB of RAM or more. I don't think you can buy servers with only 32 GB anymore (although that seems to be the upper limit for regular laptops, and Apple is behind at 16 GB.) You can certainly rent fractional servers with much less RAM, though. Then, you may have to worry about CPU availability instead. In general, though, I wonder about the size of your levels, and where that content is coming from.
  8. Most engines make "object create" and "object delete" messages high priority, pushing them out ASAP. You'll also want to make sure that they get re-sent until they're acknowledged by the other side, to avoid object lifetime de-sync (which is worse than object state de-sync.)
  9. How big is a map chunk, in megabytes? How many players per map chunk? How would you create enough map chunks to fill up the memory of a server?
  10. I looks like the problem is one of user interface. Typically, the way rotations are expressed, are through a transform off identity. Whenever you change a widget, a brand new orientation is created, and the transformation matrix is re-calculated from scratch. It sounds like you are trying to calculate transformation using increments -- i e, After you rotate X 50 and Y 30, you then keep the result of that, and apply X - 50 to the end of whatever the previous rotation was. This is not how modeling UIs work. Modeling UIs start with 0, and then re-create the rotation matrix from identity each time you update the input parameters. You will note that, if you do this, you will also end up at "identity" when X and Y are back to zero. In general, the only case where you need incremental rotation is in a physics engine, and when you keep incremental rotations, you have to be very careful to re-normalize the quaternion (or re-orthonormalize the matrix) between each step, or you will suffer build-up of skew. There's also a question of where the point of reference is. Either the point of reference is the local object, or the point of reference is the world. You will express the same rotation differently, depending on how you think about it. (This is why you have to invert most scene graph matrices to create the model matrix you use for rendering.)
  11. If you don't want to allow client cheating, then you need to have some kind of physical security against hacking on the client, which means using a console, or building PC games that go into specific locations (like game halls or whatnot.) If this game is for users to play on their phones or home computers, then letting the client be authoritative will open you up to cheating, no matter what you do. All is not lost, though; if your game is not that big and important to people, there won't be very many people who want to cheat. (On the other hand, if the community is small, even a single cheater may ruin it and prevent growth.) Also, I don't see how you think that x/y is not important from an anti-cheat point of view. If there's a door or other obstacle in the way, if I can set my entity to be on the other side, I have effectively teleported through the obstacle. All the other clients have no option but to show the player going through walls -- else, your game will de-sync. (And de-sync happens even to legitimate players if you let other clients reject data from the authority.) The solution is to run the simulation on the server as well as the clients, or to accept that your game probably doesn't need strong anti-cheat design, and live with that decision.
  12. Some people do, some don't. There are a few options. You can, for example, run remote entities "behind" and the local entity "ahead" on the client, and send the data so it arrives "just in time" on the server. Or you can extrapolate remote entities to the client time, which means you're placing entities at "guessed" positions. Or you can display both the local player and the remote players in the "behind" time frame, while sending the commands "ahead" -- this introduces significant command delay, but makes the simulation 100% deterministic. (RTS games use this model, and hide the latency using a "Yes, Sir!" animation.) That solves the wrong problem. The problem is not that one client might be two milliseconds ahead of some other client. The problem is that there is 100 milliseconds latency from the client to the server, and then another 100 milliseconds of latency from the server to the other client. Having the server send "this is my current clock at game tick number X" to each client in its packets is perfectly good enough to derive a good clock on the clients; any improvement on that is not going to lead to improvements in gameplay.
  13. There is no "the time it REALLY happened." The best you can do is agree on an order of events -- "X happened before Y." And even that is hard when two different players talk to the same server. The way this is typically solved is that simulation is done in time steps, typically of a fixed size. The server and players then use the same time step numbers, and any action sent is tagged as "this action happened at time step X." You can do this with variable time step size (Unreal Engine doesn't have fixed time step, for example,) and then you'd simply send the timestamp instead of the time step number, for each event. This also lets each side bunch events from a number of simulation steps into a single network packet. For example, you may simulate 144 times per second, but only send network packets 40 times per second; each packet will then contain the events for 3 or 4 time steps. Bunching transmissions up like this does add some additional latency to the networking, but as you typically need to work with connections with high latency anyway, it's not that bad. Sending packets 40 times a second means you delay any particular event at most 25 milliseconds; players in Massachusetts connecting to a server in Atlanta will typically see more latency than that just in transmission time, anyway.
  14. Is Unity or Unreal fit my needs? Veterans only

    I have done significant work with both Unreal and Unity. You can write a game in Unreal using entirely C++, no Blueprint needed. That being said, artists and gameplay programmers may be more productive in Blueprint. The fact that you get FULL source code for editor and runtime in Unreal is a big win. You can fix whatever you feel you need to fix. In Unity, if there isn't a "thought out" point where you can slot in your code, you're kind-of up the creek without a paddle. Unreal with C++ will run faster (and thus use less battery, if you're on mobile) than Unity if you have a lot of custom logic. C# is not native C++ code speed. Writing high performance C# code is a skill you have to learn in addition to C# itself, and the Mono runtime is much lower quality than the native .NET runtime. Beware. The Unreal renderer is high performance, and you can add/change the features you want in C++. Beware that reflections are not fully orthogonal. By default you only get one reflection plane for example, if I recall correctly. From your descriptions, it sounds like using Unreal with plain C++ game code would be the best option, but it also sounds to me as if the amount of development needed for the game you're suggesting might be more than you expect. Perhaps you should have a plan to use everything just-as-is to save time, and develop all the game bits first, and if there is time/money left over, start changing things like ambient occlusion or tone mapping?
  15. There are many, many ways that this happens, depending on the specific games. Some games send the inputs for each player for each simulation frame to all other players, and implement deterministic / lock-step simulation. Some games send inputs for each player to all other players, but buffer some number of simulation ticks at a time, and then let the server "correct" player positions every once in a while. Some games send inputs only to the server, and the server sends a stream of entity updates at some network tick rate. Some games send player positions to server, which forwads to others. (This option makes it pretty easy to cheat, so it's less common.) I highly recommend you download the source code for a number of games for which the source is available, and check them out. This may be anything from good-old Quake III, to the latest Unreal Tournament Next.
  • Advertisement