For the curious, here is Unity's components reference page:
Instead, have one MonoBehavior and a base properties class which you can delegate your events to (usually only a half dozen). That way you're not relying on undefined behavior on the Unity side, and you can, eg, new and clone properties without issue.
I use something similar for Under the Ocean (http://www.underthegarden.com), which has to deal in worst case with hundreds of objects with potentially tens of behaviors that cannot be known ahead of time.
The system works damn well - for my type of game, perhaps it's the only way to do it. But performance is forever a concern. Monobehaviors are nice (eg, you can edit its variables in the editor), but they're heavy weight.
In practice, "component entity system" simply means favor composition over inheritance. There are different ways you can architect your code to fit the definition, some of them efficient and cache friendly.
Chasing pointers on PC is bad, chasing pointers on them is suicidal. With them, it's better to do a linear copy of ~3kb than it is to reference one more uncached pointer. And this is especially bad because they don't have any kind of decent prefetchers -- if you haven't actually touched an object, it's probably uncached.
Becaus of this, if you use traditional OoO to structure your code, you leave an order of magnitude or more of performance on the table. And since the CPUs are slow as it is, you can't afford to do this.
With Spidermonkey and the bindings wrapping native implementation of Chipmunk physics lib, etc. the performance is great.
I've had proof of concept working with ClojureScript on Cocos2d-x for a couple weeks now.
Good code always comes with the requirement of figuring out which bits to optimize. OP seems to be confused if he thinks none of the bits in a game can be delegated to higher layers.
1) What are you basing your judgement of perfomance on? Not the HD recorded video that had two of my cores pegged the whole time I hope - because that's not at all representative. ChromaShift runs at 60fps on every piece of hardware I own (including a macbook from about 4 years ago) and generally runs at < 2ms per frame. There's a bug for some chipsets that causes chrome and FF to render canvas very slowly when hardware acceleration is on - if you're actually running the game, trying turning it off.
2) Even if it were slow, the comment you're making would be about JavaScript and Canvas performance not CLJS. The performance intensive bits of the game all delegate to JS, just like the performance intensive bits of any Clojure app are typically wrapped Java.
None of us are game designers or builders. I'm sorry it didn't live up to a professional's expectations for a 48 hour game. It's tens of thousands of elements and seqs aren't meant to be fast. You can easily just use an array when performance is critical. The game was never used as an example of how powerful the IDE is. The game is just a game. The concepts behind the game happen to be similar to how LT was designed. Do you have any issues with the actual design of LT? This post has nothing to do with ChromaShift. No one must build games on top of Unity and all the examples going back to the early 00's (like Dungeon Siege) must be a figment of my imagination. Entity systems are not new by any stretch of the imagination. [1] Clojure(Script) is very fast, but it's not C and won't ever be. I've never run into a performance issue that I simply couldn't drop down to the platform and then wrap nicely to get native JVM or JS performance.[1]: http://scottbilas.com/games/dungeon-siege
BTW, constructive criticism doesn't typically use words like "terrible" :)