Higher network traffic when it's avoidable is always bad, but my main thinking is that if you have a high-FPS game, latency effects will become much more pronounced.
| |
I assume this could be applied to SS13 codebases as well. In the past few months, many of the codebases have migrated to a process scheduler that has modifiable schedule times for different process() lists which can be changed to be the same on any tick lag, so on ours we've been experimenting with lowering the tick lag just to give a much smoother frame rate to the players. To me this sounds similar.
Of course at the moment our implementation suffers from certain things such as parts of the code that use world time and also there is some issue with the way we delay mob movement that at very low tick lags (60fps for example) that some keypresses can be lost between ticks and mobs will move more than one tile that has yet to be resolved. And also mob/stat has to be set to sleep to for a standard ticklag because it can eat cycles. But overall the reception to the higher frame rate has been phenomenal from the playerbase, excepting primarily the movement issue described above. | |
Yeah, my thinking is that this could be a fairly generalized option that almost any game could immediately apply.
| |
Well that really would be a very useful feature and a massive boost to the quality of the game (or any game) in my opinion.
| |
The main reason people use higher frame rates is for smoother animation, but it seems like that's all they really need. I'm wondering: What if the server frame rate could be kept at, say, 10 fps for a typical game, and it would only send map updates on those ticks, but the client could have a higher frame rate used for interpolating step changes, glides, and animation? Would that be a useful feature? This would be a very useful feature. | |
I'm curious how well this would work in terms of collision, but I'm assuming it would either be handled by clients somehow, or that because of the movement being visual the server would catch it in plenty of time.
I'm not really sure, but the feature as a whole sounds very promising. I'm very interested in seeing what it can do, so I'm all for giving it a whirl. | |
A slight amount of extrapolation may be nice to cover the extra time that interpolation will require. If latency to the server is 0.15 seconds but the client is given 0.1 seconds to interpolate smoothly to position updates, then that is kind of like 0.25 seconds latency.
Extrapolation over such a short time can be pretty accurate, and that is in 3d space, this is only 2d, so I think it would be even more accurate.  Here is a picture that shows a bit of random zig zag action going on with 10 position updates per second and latency of I think 150 ms on this Unity game I was trying to make. The red ball is the extrapolated path and blue is true path. The character was flying really fast too way faster than any normal game would have. | |
This would be nice, would keep me from having to run an intensive enough already game like ss13 at 0.5 ticklag or lower to get gliding movement that isn't molasses
| |
Extrapolation sounds great, but there's some serious problems with any attempt to implement it. For one, the code for handling Enter()/Exit()/Cross()/Uncross() happens on the server, so there's no way to build an accurate map of tiles the user can/can't enter predictably from BYOND's side of things without exposing a client-side DM interpreter to the web client and Dream Seeker. That's no small task.
Second, there's the issue of how to handle correction. Usually, correction is a game-specific thing, and really can't be generalized. This is why there are so few "plug and play" networking modules, because the player's feedback expectations vary from genre to genre, and even from game to game. With the way BYOND is structured, I simply can't see extrapolation actually working in a satisfactory manner. | |
Sounds like this could be a good feature, but then I'd have to ask, when would we be able to expect this feature to be available in a beta?
| |
Ter13 wrote:
Extrapolation sounds great, but there's some serious problems with any attempt to implement it. For one, the code for handling Enter()/Exit()/Cross()/Uncross() happens on the server, so there's no way to build an accurate map of tiles the user can/can't enter predictably from BYOND's side of things without exposing a client-side DM interpreter to the web client and Dream Seeker. That's no small task. This is only really an issue with pixel movement, but any game that uses gliding movement this will be great. | |
This is only really an issue with pixel movement, but any game that uses gliding movement this will be great. That's not true. The problem is the same with both. | |
Ter13 wrote:
This is only really an issue with pixel movement, but any game that uses gliding movement this will be great. How do you figure? If something is going to be moving in a game with gliding movement its already been given the goahead to go to that tile, nothing is going stop it because all the calculations have been done server side and now the client knows that thing is moving to xyz and if its within 1 tile away it knows to animate the gliding movement. If the client's framerate can be set by the server then the gliding movement can be nice and smooth instead of slow/fast/choppy based on the tickrate/server fps. TL;DR The client has nothing to extrapolate or to assume as the answer was already given to it by the server. If you've got a rebuttal please elaborate instead of just saying my line of thinking is incorrect. | |
Except I cant see anywhere where lummox was suggesting extrapolation in the first place, only interpolation.
| |
Yeah, I only meant interpolation.
| |
honk
| |
Lummox JR wrote:
Yeah, I only meant interpolation. I'm aware, but extrapolation was brought up and I thought it prudent to clearly explain why BYOND can't do extrapolation. | |
Another situation that gliding/interpolating would be useful is when a game is using pixel movement but with very large step sizes and low fps.
For example my game that has 10 fps with the fastest step size being 32 and the slowest player having 16. But you see we have rigged up custom gliding using animate() so you can't tell that much. | |
With say, for example a Gbps uplink, how would it be a bottleneck, if I might ask? And is there a way that could be improved?