It's a bit pointless to talk about the performance of a game built for a 48 hour coding competition, but since you brought it up...
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.
> But back in the nineties we'd enter 48 hours or 24 hours "demo" competition and come up with stuff incredibly better looking than that.
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.
> And... Drumrolls: simply "iterating" over a seq made of a hundred elements in Clojure apparently takes more time than that.
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.
> But why oh why use a language that is very arguable not meant to write video games in (Clojure) to... write a game in it as an example of what can be done!? (or as an example of how powerful an IDE supposedly is!?)
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.
> And not a single one of these game is using that "Component Entity System".
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]
> So how are we, Clojure believers (I'm a big Clojure fan and investing lots of time and energy learning it), supposed to take any of this seriously?
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.
Though, if anyone's actually interested in coding a game in this style in Unity3D, I would heavily recommend against using Unity Components directly if you're at all concerned about performance and code clarity.
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.
There are shipping AAA games and game engines that use some variation of a component system for entities, including Unreal Engine 3 and CryEngine.
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.
And to elaborate more: The reason for this shift is that the current-gen consoles (xbox360 and PS3) are really, really bad at random access into memory.
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.
Just to add to this, the Cocos2d team has been advising developers to use the Javascript bindings since the last half of last year. The same codebase can be written and deployed cross-device and to the web with Cocos2d-html5.
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" :)