That’s the way it’s usually done, but it’s not really feasible on a platform like Flash.
For one, multithreaded engines are heavily data-oriented. Instead of having many classes that each have their own properties (like Flashpunk entities), they’ll use large banks of entries that each game object refers to. Since all that memory is in one place, it can be copied very easily, and oftentimes there will be two copies of each object at all times; one that belongs to the game state, and one that exists as a snapshot of the last tick for the renderer to use.
Further reading: https://github.com/EngineArchitectureClub/TalkSlides/blob/master/2012/11-DataOrientedDesign-SeanMiddleditch/DataOrientedDesign.pdf
Just by virtue of its design, Flashpunk can’t take advantage of this approach. Don’t get me wrong, the Entity/World model is really great, but it’s inherently incompatible with memory packing techniques that make it viable to constantly be copying state. On top of that, Flash doesn’t allow direct memory access anyway, so the point is moot.
Off the top of my head, the minimum processing each entity would require each frame in order to take a snapshot would be as follows:
- Whether the entity is visible
- The entity’s position
- The entity’s graphic (recursively; remember graphiclists)
- The graphic’s position, scale, opacity, etc
- The graphic’s source image (with tinting, this would require a hard copy each frame)
It’s very likely that each graphic would have to be copied wholesale, since each one has a very different
render() function; just look at Backdrop and Emitter for two examples of the specialized work involved. Copying the reference wouldn’t suffice, since that would open up the possibility of desyncs.
Short version: Due to Flashpunk’s structure, the limitations of the Flash platform, and considerations that must be taken when attempting multithreading in general, it’s just not feasible.
In any case, we’re pretty far off-topic now.