Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Game performance optimization – A practical example from Industry Idle

ruoyusun.com

Post reply on HN
Print view View original

31–37 of 37 posts

Re: Game performance optimization – A practical example from Industry Idle

#31

Post by archi42 »

insraq wrote: post #18
archi42 wrote: post #14

Huh? I am surprised that you choose to use a "setTimeout"-like callback there. Everyone on the internet is an expert (/s), so here is my intuition: If a mine produces $stuff at a rate of x $stuff/s, the factory it is sending to will have a supply of x $stuff/s coming from that mine; the factory's total supply will be the sum of all these x from the various mines that are sending to that factory. So what I would do is…

> Are the deliveries continuous and not bursty They are not "bursty", but they can fluctuate. Power fluctuation, fuel shortage or upstream supply chain issue could cause a building to skip a production cycle - and impact all its downstream. In fact that is a core challenge in the game. So the core game logic has to be simulated, not calculated. Doing multithread in JavaScript (via WebWorker) is kind of painful.

With the suggested method you could skip a production cycle by unlinking a producer from a consumer. Due to the setTimeout the fluctuations propagate through the factory just as they would with resource nodes flying around. Of course the details are a bit more complicated (you don't want to miss resources or produce too much due to the abstraction), and I see why you went the easier route ;-)

Yeah, multithreading is often a pain. OTOH the gains can be enormous.

Re: Game performance optimization – A practical example from Industry Idle

#32

Post by dfghdfhs »

insraq wrote: post #13
fenomas wrote: post #6

Lots of cool stuff here. But on the last point about managing renders, for my money any browser game is in a state of original sin if its logic and render loops are tightly coupled. The Right Thing To Do is to run logic and rendering at separate cadences, with rendering driven exclusively by requestAnimationFrame. Then when the browser is minimized, RAF stops firing and rendering is skipped entirely (on top of the ot…

Hi, the game is already doing this. As mentioned in the article, logic tick is running at a much lower frequency than rendering loop (30/60FPS). When playing in the browser and is minimized, the game will simply pause - rendering and logic. Browsers will throttle timers which will cause inaccurate logic tick as well. Most idle gamers actually do not like this behavior [1] - people prefer the game to run in the backgr…

Are the logic and the rendering loop in separate threads?

If so, how do you ensure that when the rendering loop reads the shared state, it sees something consistent (i.e. something that hasn't been updated by the logic loop in between the time when the rendering loop started accessing it, and the time when the rendering loop finished accessing it)?

Re: Game performance optimization – A practical example from Industry Idle

#34

Post by yxhuvud »

> To optimize this, instead of scheduling a function call, we simply add the information to a Map - the arrival time, resource, amount, and target building. Then in the tickDots method, we loop through the map and if a resource has arrived, we remove it from the Map and add the resource to the target building. This reduces the frame time from barely under 16.7ms to a comfortable 11ms.

What you have implemented here is a priority queue, with O(1) insertion and O(n) deletion. It is easy to get down priority queues to O(log n) deletion without sacrificing insertion speed noticeably much. So unless you have some good reason to iterate all resources every iteration, changing to a better priority queue implementation will most probably yield you even more of a benefit.

Re: Game performance optimization – A practical example from Industry Idle

#35

Post by insraq »

yxhuvud wrote: post #34

> To optimize this, instead of scheduling a function call, we simply add the information to a Map - the arrival time, resource, amount, and target building. Then in the tickDots method, we loop through the map and if a resource has arrived, we remove it from the Map and add the resource to the target building. This reduces the frame time from barely under 16.7ms to a comfortable 11ms. What you have implemented here i…

You are right. A heap/priority queue would be good. However the resources needs to be iterated and ticked every frame - to update the rendering data (transform) and perform culling (because the viewport might change - a player might move or zoom the camera).

Re: Game performance optimization – A practical example from Industry Idle

#36

Post by insraq »

dfghdfhs wrote: post #32
insraq wrote: post #13

Earlier quoted context omitted.

Hi, the game is already doing this. As mentioned in the article, logic tick is running at a much lower frequency than rendering loop (30/60FPS). When playing in the browser and is minimized, the game will simply pause - rendering and logic. Browsers will throttle timers which will cause inaccurate logic tick as well. Most idle gamers actually do not like this behavior [1] - people prefer the game to run in the backgr…

Are the logic and the rendering loop in separate threads? If so, how do you ensure that when the rendering loop reads the shared state, it sees something consistent (i.e. something that hasn't been updated by the logic loop in between the time when the rendering loop started accessing it, and the time when the rendering loop finished accessing it)?

No. Multithread JavaScript (WebWorker) is a bit hard to work with. So currently they are all running in the main thread, just "at separate cadences"

Re: Game performance optimization – A practical example from Industry Idle

#37

Post by avereveard »

lmm wrote: post #11
avereveard wrote: post #3

Missing one important thing: if your object goes in a straight line at a fixed speed with a known start and end position, instead of going through the game engine tweens you can build an equivalent CSS animation between the start and stop position and it'll be blazingly fast.

Why should it be faster? It's doing the same work. In modern browsers with their heavily optimized and JITed JavaScript runtimes, an animation in JavaScript will often perform better than the equivalent CSS. (And that goes double if you're using WebGL and can just hand it off to the graphics hardware).

> if you're using WebGL

iphone's chrome entered the chat

Post reply on HN