I don't think that people will notice a huge difference between framerates in animated icons, but people will notice a bigger difference in moving objects (if you're using pixel movement) and for those moving objects the rate of updates is the framerate.

If you want to update things less frequently than world.fps, just don't do something every tick. The server will still do some processing each tick but that doesn't mean it has to do everything every tick. I've always wondered why people didn't do this - if you increase a traditional tile-based game's framerate to 20 fps but still restrict players to moving/attacking once every 0.1 or 0.2 seconds, the amount of processing the server does is about the same, it's just split across more ticks.

FIREking wrote:

I notice it. The difference between even 30 fps and 60 fps is staggering to my eye. Movement of atoms is much smoother at 60 when the move rate (pixel_step_size) is low.

This could help games with larger tiles, but with 32x32 tiles there won't be much of a difference once you get over 30 fps. If anything, 32 fps would look the best and every higher framerate that's not a multiple of 32 would look worse.

As I said, there's nothing stopping you from limiting how often actions can be performed. If you want to set world.fps to 60 to have smoother transitions between tiles, you don't have to let players move 60 times per second. The updates are limited by what actions can occur and how frequently they occur. If players can only move 10 times per second, it doesn't matter if updates can be sent 20, 30, or 40 times per second - the rate of movement is more limiting so the increased framerate won't have much of an impact on the server.

What I really meant by this feature request is this...

Setting world.fps to 10 vs world.fps set to 60 means you'd have less ticks per second, less bandwidth per second, and more processing time per second yet you'd be limited to only 10 graphical updates per second.

The idea here is to allow us to separate the number of graphical updates from the number of packets / ticks per second.

Forum_account wrote:

FIREking wrote:

Implementing soft-action-limiting wont change the internals. Can current internet connections even communicate 60 times a second? Because that's what you'd be forced into with world.fps = 60

I am pretty sure it sends a packet every tick.

It may send more packets but many of them are empty. If a player can move 10 times per second and you send 60 updates per second, you're sending 50 updates that contain nothing because no actions happened. You might be able to improve performance if you sent fewer updates but it'd make a small difference. It shouldn't be a strain on the server to send those empty updates (assuming it even does that).

Well, if what you're saying is right... then about 70% of BYOND games really need to update their code.

So for an example... a server with 50+ clients could be stable at world.fps = 60 so long as the server code / logic is clever and well designed?

It doesn't sound feasible. As soon as you have anything costly to process, and it takes longer than a single frame, won't you have some problems?

Honestly, I think none of the developers will touch this part of the code because its too scary to change for them.

When I was writing my game in java, *hardly a comparison to the mammoth that is DM/seeker/daemon*, I spent just a week on my game loop and different ways of separating graphical frames from update frames. It seems silly that byond isn't setup this way; unfortunately I know why.

Stephen001 wrote:

If it takes more than a tick, it takes more than a tick, that's not a huge problem if your sleep()s are scaled up according. Consider the case where you have 60 ticks per second instead of 10, but you've done 6x on the sleeps you use. CPU processing can overrun by 6 ticks before you lag a timed event, or basically, sleeps are still 1/10th of a second, and so you still have 1/10th a second for processing. But 60 animation frames, not 10.

Yes, but we have no control over how this is structured internally beyond sleeping or soft-code throttling. We really need a way to control how often the server and client communicate (tick and send packets) separate from how often graphics are drawn. Otherwise, a value of 60 for world.fps would not scale well with more clients.

FIREking wrote:

It doesn't sound feasible. As soon as you have anything costly to process, and it takes longer than a single frame, won't you have some problems?

Not at all. Loading a map from file (reading the file, generating all the turfs/objs, etc.) will take more than a tick even when world.fps is 10 but it doesn't matter if this takes longer than a tick. The only actions you need to happen in a timely manner are the ones closely related to the user and those are usually very quick things (moving, attacking, etc.). Even then it doesn't matter too much - if ticks are 1/60th of a second and something takes two ticks, after you factor in latency the players won't be able to tell.

Complex Robot wrote:

Believe me, I know this. I have made a networked game before, and reducing the number of packets sent makes a much bigger difference than changing packet size.

I'm not sure if BYOND always sends packets if there's no information to be updated. Even if it does, computers can easily handle 10 packets per second. It might sound like a lot of packets to you but it's a drop in the bucket. If BYOND games were playable at 10 fps in 1997, they better be playable at 20-40 fps today.

Sending packets every frame isn't ideal but:

1. It's often necessary. In general, there's no way for the general BYOND game client to know how to interpret events that have happened in the past. If you were creating a custom client for your game you could program the client to make assumptions to deal with latency and less-frequent updates. In general, there's no easy way for BYOND to handle this. Also, for pixel movement, the rate of packets being sent *is* the rate of graphical updates.

2. It's not a big deal. Sending 20-40 packets per second sounds like a lot but it's not an issue for a computer. If it wasn't an issue for BYOND games to send 10 packets per second 10-15 years ago, modern computers can certainly handle sending 20-40 messages per second.

There aren't a lot of "network programmers" because that's not a real title. Most of the programming work people do with networking is done at a high level so a lot of the work is done for you - if you're using SOAP over HTTP, the communication work has already been done. You're dealing with the higher level issue (what data will be sent), not the networking (how it is sent).

Most of the work being done in networking is on a lower level, much lower than opening TCP sockets and sending bytes. Most of the work deals with how you encode data and manage its transmission and most of that work deals with wireless communication. There is an algorithm side to those problems that you could consider programming, but I wouldn't call those people "network programmers".