Seems like as good a time as any for an update.
The level editor is coming along great. Stuff made with it is looking super awesome.
However, I've recently discovered that the game is kinda CPU intensive. This is a problem for my game in particular because of how I want the level itself to be able to be used as a weapon, and I want the players to be able to be clever and lure a difficult enemy into a trap that was a bit earlier in the level to defeat it instead of tackling it head on. This means as the players move from one room to another, the game has to keep processing what's going on in other rooms so enemies can follow.
I've been optimizing and have managed to double the number of enemies in an area from 50 to 100, though that will probably be reduced some later when the rest of the code is in there. Some good news is that's on an about ten year old CPU that I want to be the minimum spec (AMD Athlon 64 x2 4400+), and top of the line modern processors' single threaded performance is about three times that, so on even a midrange modern computer that should be more like 150-200 enemies or more.
This is still less than I hoped for the minimum spec (100 enemies in an area not enough? You crazy, Arima?), but I think I can make it work, though I'll likely have to design a dynamic level loading system that loads sections of a level that are close and saves and deletes sections that are far. I have to be careful when doing that though, or an enemy could wander into a section of the level that isn't there.
I was hoping to avoid having to implement anything like that for the prototype, but to get a good idea of what the game is like it'll probably have to be there, though I have an idea for a 'cheating' version that will be less effective, but hopefully effective enough and far easier to implement.
I'm also beginning to doubt a design decision. I've made each unit use physics for its base, which works great for sliding objects along obstacles and allows me to make cool swarms like this:
However, doing do ups the CPU use, especially since I discovered chrome/node webkit doesn't actually support asm.js for accelerated physics, and I'm not sure it's worth it. I'm going to have to debate it for a while. Perhaps if I'm clever, I can set it up to make it so I can turn on physics use when I want swarms and leave it off otherwise, but then players might wonder why enemies can move through each other sometimes and not others. I'm not sure it's a good idea to be inconsistent on that matter. Hmm, maybe I can dynamically turn it off or on depending if an object is overlapping another or not. Gonna have to play with it a bit to find out if that's effective or not, or even necessary with a dynamically loading level.