I'm just floating an idea here and would like some opinions.
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?
In its current setup the webclient would need special handling here and would have to tick maps more frequently, but the direction I'm moving it in ought to make it possible to do the same thing there eventually.
Mostly what I'm thinking is that for your big action-RPGs, a server is more comfortable handling more players with longer ticks, but client-side animation can still be made to look really smooth. Smoother, actually, because it'd be interpolating on its own.
ID:1860613
 May 28 2015, 12:25 pm
|
|||||||
Resolved
| |||||||
|
May 28 2015, 12:52 pm
|
|
Kaiochao
  |
I'd like this. Would you also add interpolation for pixel movement and/or the camera (i.e. animate(client, pixel_...))? Or could it be that movement is actually happening at a faster rate than the server?
|
I think it would make sense in this context to interpolate client pixel movement. It's definitely one of the things I'd want to consider. But in this context it wouldn't necessarily be an animate() thing.
| |
I'd appreciate this.
| |
This feature sounds nice on the surface, but what form would it actually take? Would you be able to adjust the client and server frame rates independently, like some kind of client.fps/tick_lag? If so, I like the direction that's going in. I just think this should be optional, because I'm sure the animations of many games rely on a high server FPS.
| |
If the client were to interpolate, then the server doesn't necessarily need to have a high FPS for any animations. The concept would of course be totally optional; I expect it would mainly be used by most games simply to give a smoother appearance, while the server end of things wouldn't have to work so hard and could therefore accommodate more players.
| |
With the way BYOND is set up, any feature that takes the pressure off of the server is going to be a good idea. It sounds like this would make the default movement system work in the same way as animate().
| |
I'd absolutely love to see this implemented.
| |
This is how most client-server setups run, right? The server just manages the game clock while the client handles the FPS output? I can't see any reason not too.
Thumbs++ | |
This is absolutely essential for BYOND in my opinion. The sacrifice is too big when running at 30-40 FPS. Sure, we can make it work but having the ability to interpolate client side animation just means we can have the server running at 10 FPS and still have it look great; thus taking the strain off the server and being able to push BYOND's limits even more.
At some point I want to create an Engine in BYOND the has similar load balancing as MMORPGs. I've wanted to for a while and now that Severed Worlds has their own implementation I'm even more motivated in doing so. This feature would benefit Severed Worlds as well. Allowing each of their server instances to support much more than they could originally. Ultimately this would benefit every active developer in BYOND that's trying to push past BYOND's limitations. BYOND has it's drawbacks, but if we can break past those draw-backs then we can literally accomplish anything. Push past these drawbacks and we'll stuff this software into the mouths of the developers in the 2D AAA Game Industry. | |
Yeah, I think Severed World would benefit hugely from this once the webclient is in shape to see it through. The main thing is, I have to get the webclient DSified first.
| |
This feature would be incredibly useful. There are many multiplayer games which could benefit from the visual bump in quality without actually needing the extra processing which comes along with an increased frame rate. It's already a good idea to decouple AI and physics from the frame rate, so any game with an event scheduler should be able to adapt quite easily.
| |
I agree with this feature request. Having something like map, /obj, /turf, etc. at a slower set rate than /mob would be great.
| |
That sounds fantastic. How difficult is this to pull off?
| |
I'm not entirely sure of the difficulty yet. At the core it should seem as basic as just having a separate tick_lag for the client, ticking the client at that rate, and only using the server rate for dealing with things like commands. However, a prerequisite is finishing DSification of the webclient, which would have to come first for this to work. So this isn't an immediate plan, but something I'm looking at for down the road (hopefully not very far).
My recommendation for Severed World would be to plan to use this feature, by making sure any sleeps, spawns, etc. are all done in whole numbers (single ticks). Obviously the main source of Severed World's webclient issues right now is the frame rate, and one of the major driving factors of DSifying the webclient is for high FPS games to function well, so it's kind of a "Gift of the Magi" situation--webclient takes burden off server, only for the FPS no longer to be the issue. But my hope is that all games can experience high-FPS performance client-side and the benefits of low-FPS handling server-side. | |
It seems to me turning off gliding for pixel movement was a bad move in the first place given the way BYOND's networking model works. This is definitely a feature I support. Most game engines have a FixedUpdate loop and a separate FrameUpdate loop. Most physics engines often run at 20TPS at most, while rendering engines can run anywhere between 30 and 60 FPS (usually they won't beach 60FPS, but will display higher values as vFPS).
Honestly, I think this would allow us to achieve a higher standard of visual fidelity without increasing the burden of knowledge required to make a world run smoothly at high FPS values. | |
Well with pixel movement, the idea was that the gliding was being handled directly with the actual step_x/y values. Interpolating the pixel movement (essentially a new form of glide) wouldn't actually make sense without the concept of separate frame rates, which I never thought of at the time.
On the bright side, I think trying to implement separate frame rates at that time would have been harder. The main obstacle in the way now is the webclient, which I already plan to deal with. | |
I think this would be an excellent feature.
| |
While a great idea itself, perhaps we'd have more use in getting more out of BYOND itself in terms of performance. I'm sure there's always places to do optimizations, as minor as they might be, every bit helps to get it all to run a lot faster as a whole.
| |
StarSmasher44 wrote:
While a great idea itself, perhaps we'd have more use in getting more out of BYOND itself in terms of performance. I'm sure there's always places to do optimizations, as minor as they might be, every bit helps to get it all to run a lot faster as a whole. I'm always up for more optimizations and look for them wherever I can. However the server will always have certain bottlenecks, in networking if nothing else, that would benefit from the client ticking faster. | |