Jump to content
  • Advertisement

tromtrom

Member
  • Content Count

    8
  • Joined

  • Last visited

Community Reputation

0 Neutral

About tromtrom

  • Rank
    Newbie

Personal Information

  • Interests
    Programming

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Well I'm trying this out in the context of a web browser game, so TCP it is anyway. Thank you for all the good suggestions
  2. Oh I see that makes a lot of sense now! Very interesting! For now I'm going with the first method, which is replacing the old value by the new value, because as you said there's a need to keep track of previous states at the level of the client in order to reconstitute the new value. And right now, as I'm still building everything up, I would like to see how the pieces fit together before even considering that XOR optimization. But it's great to see different options there in the future. Thanks a lot!
  3. Thank you both for such great insights, there's a lot of ideas to explore for sure! That ultimate quest for compression, fascinating topic! I had to wrap my head around it to completely understand why it would creates long strings of zeros, it's when oldVal and newVal are the same, right? So that means that on the second method, whether the property has changed or not, it's still part of the packet sent over? Would it not make the packet bigger in the end even after stripping the zeros out?
  4. Oh ok, I think this is the part I was missing, using bitmask to describe what is set or not. So I suppose in the message to the client you would have a set of bits that describes what has been set, followed by the actual values for each of these properties set. On the client you would read explicitly each bit from the bitmask (has x been set? yes? get the value, has y been set?...), and then assign its values to the network entity. Am I understanding this correctly?
  5. I've been doing some research on delta compression (used and described in the Quake3 doc http://trac.bookofhook.com/bookofhook/trac.cgi/wiki/Quake3Networking,), and I'm looking for some clarifications on that topic please if possible. I understand that the delta compressed state is the difference between any given world states, meaning that if we store the state of every entity in a world state at every tick, the difference would be only the states of entities that changed between these two world states. Now when sending back the delta state to the client, do we go as far as only mentioning the properties that changed? Let's say a character moved only on X axis but didn't move on the Y axis between two states, are we sending to the client the whole state (x, and y) or only the new x position? If that's the case and let's assume there are a few more properties that describes a character, how can the client identify which properties have actually changed when rebuilding the information from binary data.
  6. Are you suggesting a non fully authoritative server, but more logic on the client side? So more cheating allowed? I've actually looked deeply in their code on the client, and I couldn't exactly find any clues that lead to that. But maybe I'm wrong.
  7. Thank you all very much for your answers. Great breakdown on the current state of TCP vs UDP, and that yes my first guess about current state of internet speed was right. It's true, I think I need to revise my definition of Fast Paced Multiplayer. When I look at surviv.io (and trust me I played that one a lot!) I do feel that movements are very tight and precise and shots are very much on point. It does feel like a minimal PUBG where shots are crucial. Compared to slither.io which is way way more forgiving in terms of movement, and lags. But you might be right in the sense that big FPS title might be moving at a higher pace in general and that is maybe where the difference lies. What I appreciate with surviv.io is that it's a great example of what can be done nowadays on the web in terms of let's call it "semi-fast twitch" multiplayer shooter.
  8. I've been doing a lot of research on how to implement a game server to support a web based game in the vibe of surviv.io, or zombsroyaleio. There are so many ressources out there, but apparently surviv.io is built with NodeJS using Websockets. That implies also that they are built on TCP protocol. They might not look like big titles but they surely look very steady (from my point of view) and I feel like they do deal with classic Fast Paced multiplayer concepts such as Client-side prediction, interpolation, and potentially lag compensation. During my research, there seems to be that constant debate on UDP over TCP. To sum it all up, it seems that TCP is not appropriate for fast twitching games, however I do believe they fall into that category. How can they get away with TCP? Is this debate actually now outdated now we have better internet connections?
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!