• Create Account

Banner advertising on our site currently available from just $5! ### #Actualfrob Posted 04 March 2014 - 04:00 PM Ah, yes, I was referring to the sport-style environment, not "friends on LIVE" environment. When I write of the competitive environment, I am referring to the people (including one of my brothers) who routinely compete in semi-pro game leagues and competitions. These are often run by the various companies, sponsored by hardware vendors, and usually end up inviting all the semi-final competitors to Las Vegas from around the globe for the final few rounds of web-broadcast events. They also involve prizes of cash and hardware. (My brother just finished one such tournament that offered a$100,000 cash prize to the winning team, they took fourth with each player in his team getting $5000 in addition to the all-expenses-paid vacation.) The competition rigs that people bring to these events are rather impressive pieces of hardware, often with every piece of non-essential software removed and the entire machine dedicated to that one game's optimum performance. The networks provided are also often rather intense with very low latency network switches and similar cards in most boxes. The main takeaways from my post were basically that (1) reduced coupling between unrelated components is usually a good thing, and (2) the update frequencies of all the systems should be based on what is best for the game, not because of the old TV standards. Update as fast as you need to give a good simulation, whatever that means for your game. Draw as fast as reasonable for your game. Obviously a network simulation of go or chess will have different display requirements than a twitch shooter. Many game styles benefit if you decouple players from each other, some work well with completely independent simulations with just a few key pieces kept synced. Finally, figure out update rates that make sense for your game. If 60 Hz makes sense for your simulation, then great. If instead 15 Hz makes sense for your simulation, or 85, or some other number, then that is what is best for you. If your game has AI that runs at 4 hz, player input that is processed at 30 hz, and a physics world that gets simulated at 120 Hz and that works for you, then great, whatever works for you. ### #1frob Posted 04 March 2014 - 03:56 PM Ah, yes, I was referring to the sport-style environment, not "friends on LIVE" environment. When I write of the competitive environment, I am referring to the people (including one of my brothers) who routinely compete in semi-pro game leagues and competitions. These are often run by the various companies, sponsored by hardware vendors, and usually end up inviting all the semi-final competitors to Las Vegas from around the globe for the final few rounds of web-broadcast events. They also involve prizes of cash and hardware. (My brother just finished one such tournament that offered a$100,000 cash prize to the winning team, they took fourth with each player in his team getting \$5000 in addition to the all-expenses-paid vacation.) The competition rigs that people bring to these events are rather impressive pieces of hardware, often with every piece of non-essential software removed and the entire machine dedicated to that one game's optimum performance. The networks provided are also often rather intense with most machines running very low latency network cards and switches.

The main takeaways from my post were basically that (1) reduced coupling between unrelated components is usually a good thing, and (2) the update frequencies of all the systems should be based on what is best for the game, not because of the old TV standards.

Update as fast as you need to give a good simulation, whatever that means for your game.
Draw as fast as reasonable for your game. Obviously a network simulation of go or chess will have different display requirements than a twitch shooter.
Many game styles benefit if you decouple players from each other, some work well with completely independent simulations with just a few key pieces kept synced.

Finally, figure out update rates that make sense for your game. If 60 Hz makes sense for your simulation, then great. If instead 15 Hz makes sense for your simulation, or 85, or some other number, then that is what is best for you. If your game has AI that runs at 4 hz, player input that is processed at 30 hz, and a physics world that gets simulated at 120 Hz and that works for you, then great, whatever works for you.

PARTNERS