And so on and so forth. This would also make it simpler to create custom update/render functions and custom properties per-person by doing person_object.update = function() {} as desiredInstead of using GetPersonList, you would just reference the persons[] array.

Do you think this is a good way of doing things? Would the new minisphere API benefit from using this method as opposed to the old way? I'd post this in minisphere's engine update thread, but I wanted to make this thread to ask for your guys' opinions on this method in general.

That's pretty much what I was going for. Just more complete But this is going to be dependent on minisphere, since it uses the threads module, and will likely add other stuff as time goes on. What are the get and set keywords from line 15 on? I've never seen those before. And what is the benefit of defining Actor.prototype as a raw object, as opposed to

It's probably not worth putting too much effort into the legacy map engine at this point. It doesn't play nicely with, e.g. the threads module and I had to write a few hacks just to make it cooperate. Even then it's not perfect: For example, calling threads.join() always takes input focus away from the map engine.

For minisphere 5.0 I'd like to write a new map engine from the ground up, implemented in JS, which is fully object oriented and seamlessly integrates with other parts of miniRT (threads, scenes, etc.). I actually originally planned to do that for minisphere 4.0, but decided instead to use 4.0 as a testing ground for the Sphere v2 API and hold off on more complicated stuff until the v2 API is finalized.

miniSphere 5.1.3 - Cell compiler - SSj debugger - thread | on GitHubFor the sake of our continued health I very much hope that Fat Cerberus does not become skilled enough at whatever arcane art it would require to cause computers to spawn enourmous man eating pigs ~Rhuan