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.
Game performance optimization – A practical example from Industry Idle
11–20 of 37 posts
Re: Game performance optimization – A practical example from Industry Idle
#12Although I'll of course agree a better computer helps the iterative dev cycle.
Re: Game performance optimization – A practical example from Industry Idle
#13Lots 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…
The "background mode" mentioned in the article is about the Steam version, which runs in Electron and I have to set `backgroundThrottle: false` flag. In this case, Electron will not throttle timers and I can safely disable rendering while leave the logic running.
[1] https://www.reddit.com/r/incremental_games/comments/seid8w/c...
Re: Game performance optimization – A practical example from Industry Idle
#14Everyone 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 a setTimeout("increase supply of stuff for target factory by x every 2.5s", 2.5) to link a mine to a factory (and "decrease..." for unlink). This simulates that the first resources take some time to arrive.
Are the deliveries continuous and not bursty? Then the cheap way is then to increase the resources every second (or whatever your ticklength is) for the appropriate fraction by iterating over the factories - which are probably much fewer than the resources in flight. Players might notice this.
Are the deliveries bursty? Keep an array of pairs (burst_amount, burst_time, burst_stride) and when iterating over the factories to add resources, add those for which "burst_time modulo tick_time == burst_stride". This requires some discretisation, but would the players even notice...? Just make sure that if you draw resources on the screen that they arrive roughly in sync with the actual resource update in the factory.
Bonus: This could go in a thread of it's own that only takes care of these updates. But I am not sure if that can be done in your language like I would do it in C++.
Curious why you've chosen to use massive amounts of timeouts with the respective overhead.
Re: Game performance optimization – A practical example from Industry Idle
#15Earlier quoted context omitted.
Browser games like this are normally drawing pixels into a canvas, not creating DOM objects for each game entity.
I know, that's not a limit tho. you get the canvas origin from the engine and offset the animation. you keep a pool of div on the side, and when you need one depending on your culling result you attach the sprite image as a background, tweak the css animation start,end and attacch it to the overlay. you keep a relative offseted parent on the div, so that as the canvas scroll, you can adjust it wherever you go. overfl…
Re: Game performance optimization – A practical example from Industry Idle
#16Huh? 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…
Re: Game performance optimization – A practical example from Industry Idle
#17Re: Game performance optimization – A practical example from Industry Idle
#18Huh? 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…
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.
Re: Game performance optimization – A practical example from Industry Idle
#19Lots 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…
I'd go further: for many games the right thing to do is pause execution entirely if the window is minimised or the user switches to another tab or application. Obviously not possible for online multiplayer games, but a good practice for single player. Rendering can be but isn't always the most expensive portion of a game's execution, but if you have a lot feeding into that in terms of object updates and game logic yo…
Re: Game performance optimization – A practical example from Industry Idle
#20Missing 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).