Often times, the inefficient part will come either from running a lot of slow player code (which we have to make several times slower in order to make it yield control back to the game engine, instrument performance, handle errors, etc.) or from serializing updates from the worker thread to the main thread. CodeCombat simulates the level’s execution independently of playback speed, so usually we try to finish simulating a level that takes 60 seconds in about 2 seconds, and the streaming works fine. But sometimes on crazy levels when performance is bad, simulating actually goes slower than streaming–often because there are is so much data about where everything is and what it’s doing that can’t be super efficiently transferred because it’s a web browser with an imperfect concurrency model. (Whereas in The Witcher 3, you only run in real-time, there is no serialization needed, player input is very simple instead of possibly slow-running code, and you can optimize the crap out of your multi-processor performance to run graphics on graphics card, physics on one core, AI on another core, the rest of the game on a third core, etc.)
Then there are always places where we have introduced code in our game engine that’s just stupid slow, haha, like the Ring of Flowers. Possibly raise-dead is doing something similarly dumb and it just needs optimization.
Stranded in the Dunes is a particularly challenging level because of how long the level lasts–several minutes–and how many things there are (because it’s not just about serializing the data of what’s on the screen but also about serializing the full history of every unit that every existed in the level. Kevin likes to make these super challenge levels that make hardware bleed. Summit’s Gate is my fault, sorry. Makes it very hard to use flags in those levels, I know.
We’ll keep working on it, but you might want to skip the undead hordes for now if the performance is too bad to beat a particular challenge level.