Forum_account wrote:
Do you use key repeat events for movement? Or just key press and release events? Key down/up & a movement loop. Even when the game was using tile based movement, it had such a system implemented. The default repeat macros are too broken to be used for movement. | |
Falacy wrote:
Key down/up & a movement loop. Even when the game was using tile based movement, it had such a system implemented. The default repeat macros are so broken when used for movement. Did you ever measure to see how much of a difference that made? Or was that before bandwidth profiling was available? | |
Forum_account wrote:
Or was that before bandwidth profiling was available? Well, it was long before that thing was ever implemented, but I've never used it anyway. I would have to assume that having 10 to 20 times less messages per second would consume less bandwidth. | |
|
#24 Feb 4 2012, 12:42 pm
|
|
I tried HU2 again. But all I saw was movement there's nothing else going on, how's it like when there's actual fighting involved?
I can say the same about A Miner Adventure. It looks nice, it feels alright, not great. But there is nothing going on, no monsters, no animating NPCs or anything. (Opinion based on a handful of minutes spent in-game moving around, etc...) | |
Forum_account wrote:
A higher framerate will lower the latency. At the cost of burdening the host's connection. A 120ms player at 10fps will have his commands delayed one server tick while a 120ms player at 30fps will have his commands delayed by four ticks. What's worse, being behind by one step or four steps? You also have to factor in BYOND's build-in network delay which slows the game down anyway. All this combined with the fact BYOND really has no way of hiding lag means you're pretty much leaving everything to a dice roll. Falacy wrote: As I mentioned before, The Planet's server of HU2 is running native pixel movement at only 20 fps. ... There are currently ~50 people online, and practically no network lag issues.  When I logged in and walked around the game was extremely choppy. | |
2DExtremeProductions wrote:
I tried HU2 again. But all I saw was movement there's nothing else going on, how's it like when there's actual fighting involved?Combat can lead to game freezing lag, but not due to pixel movement or networking. A client.screen related bug can currently cause massive performance issues. However, if I play the game in software mode, everything runs perfectly smooth for me (including combat). If you right click on Master Roshi, who is near where you start the game, you can go into a combat mission and test against some NPCs. SuperAntx wrote: When I logged in and walked around the game was extremely choppy.Strange, the game runs smoothly for me, and my connection speed isn't even as good as yours. I assume you were holding down the movement keys, and not tapping them? Could you try toggling hardware mode through the pager and joining again to see if that makes any difference? | |
Falacy wrote:
I assume you were holding down the movement keys, and not tapping them? That's right, I only released keys in order to change direction. Could you try toggling hardware mode through the pager and joining again to see if that makes any difference? It looks pretty much exactly the same without hardware rendering, only with increased CPU usage. | |
SuperAntx wrote:
At the cost of burdening the host's connection. A 120ms player at 10fps will have his commands delayed one server tick while a 120ms player at 30fps will have his commands delayed by four ticks. What's worse, being behind by one step or four steps? I'm not sure what "120ms player" means. The number of ticks shouldn't matter. If one step is 32 pixels at 10 fps and 8 pixels at 30 fps, being one 100 ms tick behind is the same as being four 33 ms ticks behind. It's the time that matters, not the number of ticks. The problem with low framerates is that ticks are longer. Processing doesn't take place until the next tick so even if your messages arrive at the server instantly, you may have to wait as long as 100 ms to see the result. That's why games with low framerates appear unresponsive (it also makes the animations look bad). With pixel movement you'll have to send position updates to the user every tick. The amount of data sent per second is roughly proportional to the framerate. Going from 10 fps to 20 fps will, in the worst case, double the amount of data sent by the server per second. We can apply this in reverse. If a BYOND game running at 10 fps can support 50 players without network latency becoming a burden it could support at least 25 players at 20 fps and at least 16 players at 30 fps. | |
SuperAntx wrote:
* it still fails Strange, perhaps there is some issue we could attempt to diagnose. I have edited the video of my experience into my previous post. As you can see, movement appears smooth to me for both my own character, and another player running around nearby. | |
Forum_account wrote:
I'm not sure what "120ms player" means. I was referring to their ping. The number of ticks shouldn't matter. If one step is 32 pixels at 10 fps and 8 pixels at 30 fps, being one 100 ms tick behind is the same as being four 33 ms ticks behind. The difference is with tile movement BYOND is still able to animate the slide from one tile to the next. With pixel movement the atom will appear to leap however many pixels were lost between updates. Sliding from one tile to the next certainly looks a lot better than leaping 32 pixels. | |
I tried HU2 and my experience was just like Falacy's video.
SuperAntx wrote: The difference is with tile movement BYOND is still able to animate the slide from one tile to the next. With pixel movement the atom will appear to leap however many pixels were lost between updates. Sliding from one tile to the next certainly looks a lot better than leaping 32 pixels. The player won't leap 32 pixels at a time. If it takes 80 ms for a message to go from the server to the client, the client isn't receiving updates every 80 ms. If the framerate is 30 fps they're receiving updates every 33 ms (on average), it's just that each packet is 80 ms "late". Their position is still updated 30 times per second (network latency won't change that). This 80 ms latency isn't a big deal because, as I've explained, games running at 10 fps will only have higher latency. | |
|
#32 Feb 4 2012, 1:27 pm
|
|
Concerning latency.
If BYOND is TCP protocol based, shouldn't my movement be "acted" upon later, when I lag? Just thought about that after I tried to jump three times in 'A Miner Adventure' and it only jumped twice. | |
2DExtremeProductions wrote:
Concerning latency. I have no idea how BYOND handles lag. It may disregard messages that are past a certain age. If you lag badly enough, it might make sense that the server disregards your message. It could also just be receiving messages at odd times. If you press the jump key, wait a second, then press it again, there's no guarantee that the server received those messages one second apart. If you have a high latency you might expect to see two jumps, but the server may have received both jump commands at the same time. It processed the first one which makes you jump, but then the game ignores the second jump command because you're already in the air. This sounds like a problem, but it something that all multiplayer games have to deal with. Each player is performing actions on their computer but the game is in a different state when the actions are received by the server because it takes time for the message to be sent. | |
|
#34 Feb 5 2012, 11:32 pm (Edited on Feb 6 2012, 12:50 am)
|
|
Hrm. I'm still a bit wary about all this; making a fast-paced action shooter really doesn't seem like one of BYOND's strengths. Maybe I'm just worrying too much though. If I do attempt this I'm going to have to take a step back and figure out how to effectively do this without sacrificing gameplay for performance (or the other way around, maybe?).
I'd definitely love to have someone who actually knows what they're doing with fancy pixel movement and all that jazz assisting me though, but I should put together a classified ad for that. | |
LordAndrew wrote:
Hrm. I'm still a bit wary about all this; making a fast-paced action shooter really doesn't seem like one of BYOND's strengths. Maybe I'm just worrying too much though. If I do attempt this I'm going to have to take a step back and figure out how to effectively do this without sacrificing gameplay for performance (or the other way around, maybe?). The problem isn't that BYOND can't handle it. The problem is latency, and that's just something that all multiplayer games have to deal with. In World of Warcraft, my character doesn't start casting a spell until the server receives the request from my game client. In a PvP situation this means my actions are slightly delayed but so are everyone else's. As long as your game doesn't boil down to "who has the fastest reflexes" it'll be fine. | |
I'm not familiar with networking, but isn't this also something that BYOND can improve internally? I'd assume games like WoW, despite handling far more than a BYOND game, run a lot more smoothly due to optimized networking or latency handling. Maybe there are optimizations BYOND can make to make experience smoother in certain styles of games.
| |
Toadfish wrote:
I'm not familiar with networking, but isn't this also something that BYOND can improve internally? I'd assume games like WoW, despite handling far more than a BYOND game, run a lot more smoothly due to optimized networking or latency handling. Maybe there are optimizations BYOND can make to make experience smoother in certain styles of games. As long as crucial game actions are handled on a central server, latency will be present (that doesn't mean it's a problem). It may be possible to reduce the amount of information that is sent to clients but that doesn't necessarily affect the latency. Messages can only travel between the client and server so quickly. It would be a huge change to allow for as much processing to be done on the clients as is done in other games. For example, in World of Warcraft you can move without communicating with the server because all map and terrain information is stored on your computer. In a BYOND game movement triggers a lot of procs (ex: Move(), Enter(), etc.) and it'd be hard to handle all of those actions on the client without creating a lot of additional headaches for the developer to deal with. One thing that could help is to have developer-controlled server to server communication. If you could have a BYOND game create a TCP connection with another BYOND game server and give the developer complete control over what data is exchanged and how it's formatted, people could optimize communication to fit their game. For example, suppose you're creating a racing game where the only thing you need to communicate is position - each player needs to know the positions of all other players. You could make the game so that each person runs the .dmb locally and your servers create TCP connections to each other and exchange position information. Latency wouldn't be as much of an issue because each player runs the game locally. The only latency would be in the updates you're receiving from other players, but this is a better problem to have. | |
|
#38 Feb 6 2012, 3:15 pm
|
|
Wait, can't we program it so that the player do not receive packets from players X pixels away from the player?
I thought there was something like this in BYOND. I also thought that resources were saved on the client after the player loads them once. I haven't touched BYOND in many years, so I am not sure. | |
2DExtremeProductions wrote:
Wait, can't we program it so that the player do not receive packets from players X pixels away from the player? Players only receive updates about things they need to know but it's BYOND that decides what information the player needs to know. There's no way for the developer to control what information is sent to each client. I also thought that resources were saved on the client after the player loads them once. It depends on what you mean by resources. Icons are stored by the client, but information about turfs might not be. When a client connects to a game with a 100x100 map, the client has no information about the map. As they explore the server sends them more information but I'm not sure if the client remembers it all. It's possible that the client only keeps the information for atoms shown on the player's screen and forgets information as soon as objects leave the screen (or as soon as they get a certain distance off the screen). | |
Do you use key repeat events for movement? Or just key press and release events?
I've never measure it, but I always figured it was quite a source of lag to have 50 clients spamming the server with "I'm still holding the arrow key" messages as they're moving. If you only macro the key up and down events the server can deduce that the key is still being held without any extra messages being sent.