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.
> And... Drumrolls: simply "iterating" over a seq made of a hundred elements in Clojure apparently takes more time than that.
> 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!?)
> And not a single one of these game is using that "Component Entity System".
> 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?
[1]: http://scottbilas.com/games/dungeon-siege
BTW, constructive criticism doesn't typically use words like "terrible" :)
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.
Because Chris has absolutely no interest in writing a game (as an end goal). He's trying to write an IDE. He wrote a game to test out some ideas that he thought had direct applicability to his design for an IDE. Turns out that it helped him develop some insights into how to build dynamic systems with immutable data structures and composable, aspect-oriented behavior injection. I think that means it was a successful experiment; he wants to share his learning process.
No one is arguing that Clojure is the right tool for the job when it comes to real-time games, so I have no idea why you are so upset...
On my machine, at least (map identity (range 0 99)) takes 0.046072 milliseconds, which is somewhat less than 16 milliseconds. Now, maybe there's something I'm missing here, can you clarify the source of your assertion?
Again, definitely not trying to be confrontational, and I don't know clojure very well, nor do I know anything about games programming, but that was what I found on my i3 core with nrepl running in emacs 24.
On topic, I think that the architecture proposed sounds really interesting (as does much of Light Table).
To make this more concrete, if I take the former expression, and make it go to 1000, or 10000, or 10000000000000, it seriously takes the same amount of time on my system. By passing the result to doall you are forcing the entire seq to be iterated and executed.
"ChromaShift is terribly bad"
"it's freakin' ugly"
"finger quotes quality of the finger quotes text editor"
You certainly sound like someone who has an open mind and is respectfully putting forth constructive criticism!
Is mean.
Classic.
> The "problem" is that they're talking about that "CES" as it was the one way to create games. But how many games written in Clojure have been shipped? Heck, how many games written in Clojure are even playable?
CES has been around for a long time and was originally created as an OOP design pattern to get around the inflexibility of the traditional Actor model in OOP. It's not a Lisp design pattern. Don't take Clojure's (alleged) runtime performance shortcomings and tack it on to CES so you can claim it's a shoddy design pattern.
The performance of a CES implementation is reliant on just that; the implementation. And CES systems can be quite performant; I've used CES-derived approaches in design of high-fidelity simulation environments and it's served me just fine.
Anyways, the main point: what does the fact that Clojure isn't a great language for building games have to do with this post?
Some things surprised me when I first did the timing -
1) Turns out that a function call plus an empty loop over a million items is ~16 ms in Python.
2) Turns out that on a pretty high end machine you get about 174k function calls in 16 ms. On a Core 2 duo laptop you get about 80k function calls in 16 ms. (In both cases the function takes no parameters and has a no-op body)
For getting timing information on your own machine you can run the code from https://github.com/deepankarsharma/cost-of-python
I think it's important to remember one of the core tenants of python is to first write in python, then optimize the bits where necessary in C by moving those calls into an extension - by using cython you get to move to C like speeds by just annotating your existing python code.
Also - I think a fairly more common approach to using python in game development is to write the core in C++, then call out to python for scriptability purposes (e.g. configuring characters/levels) - rarely would one write a full game in python unless extensions were heavily used, for the reasons quoted above.
a) allocating more than 160k objects
b) creating more than 22k numpy arrays
c) entering a with context more than 3700 times
d) doing a single for loop of over a million elements
can save you time from the get go. I am not suggesting that you cant write fast interactive code in Python, I am saying you wont write fast code by accident.
To put this into perspective, in Supreme Commander you have thousands of units, shooting tens of thousands of bullets/missiles/shells each of which is being simulated by a physics engine with accurate collision detection that actually takes the shape of all the models into account (so if an airplane hole in it (http://www.supremecommander-alliance.com/uploads/RTEmagicC_B...) then a bullet coming at the hole will fly through the hole.
Video example: https://www.youtube.com/watch?list=PLwzh5b6Jwbq8xFe0TCW4BSA9...
ClojureScript is great but if you follow the idioms then you'd likely have problems testing a single bullet for collision against a single model, let alone tens out thousands against thousands (and building the spatial data structures to support that). And then remember that this is just part of what needs to happen each frame, you also need to update the trajectories and locations of every object, render the world to the screen, synchronize the actions of each player with each other player, compute the sound based on the location of the camera, etc.
But your example is a bit exaggerated. I guarantee you that an RTS like Supreme Commander doesn't update the physics simulation or game logic at 60 frames per second. It's probably more like 10 FPS with the rendering engine interpolating objects at 60 FPS.
That figure comes from the presentation linked to by this post, but I'm not sure where it came from before that. In any case the team had performance problems for a comparatively trivial amount of processing work. Looking at the game you could easily run that game logic at 10000 updates per second when you implement it in C/C++.
That seems like an impossible statement without deep knowledge of the inner workings of the popular games you are referring to, which you certainly don't have access to.
Also, CES is a fairly longstanding design pattern for game development (at least 10+ years) - I refer you to this comment: http://news.ycombinator.com/item?id=4907998
You could implement a component-entity system in C or C++ just as easily.
Is there any inherent reason why you couldn't write a performant game in ClojureScript, if you took the time and energy to focus on performance and polish as much as with other games?
I don't think the point of these articles is "if you want to write a game better do it in Clojure with CES" but "look at this interesting programming concept"
From the parent:
if you want to run at a reasonable framerate you need to perform quite some logic in about 16 milliseconds[...] simply "iterating" over a seq made of a hundred elements in Clojure apparently takes more time than that.
There's obviously a tradeoff here with immutability/correctness/speed, but when you need to iterate over thousands (or hundreds of thousands) of items, you can get 'native' speed when you need it.
On my first day on the job I was assigned a maxed out SG Reality Engine and I installed Scheme on it - figuring that I would want a scripting language for fast changes, etc. I quickly realized that was bullshit, and and used C++ for everything for performance.
Today, I do about 2/3 of my work in Clojure but if I were ever to work on games and virtual reality projects again I would go back to using C++.
> And not a single one of these game is using that "Component Entity System".
That's plainly wrong. The idea that this person could know the internals of every game being made right now is silly enough. But, having myself worked on AAA games in the recent past that used component-based architectures, I can say with authority that this guy is Full Of Shit.
I've worked professionally in the video-game industry and I must say that I'm a bit disappointed by all these blogs / videos trying to promote tools and/or languages by using very poorly conceived games.
Take ChromaShift for example: it's terribly bad. We're in 2013 and the thing draws less "pixels" and yet is slower than any 2D scroller from the 80s running on a C64.
Sure, it was done in 48 hours and kudos for that... 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.
The author of ChromaShift made a talk about the "Component Entity System" he's using.
And that's where the "suspension of disbelief" simply doesn't work for me: everytime he shows the game, it's freakin' ugly and slow as molasses.
Then comes the disappointment: if you want to run at a reasonable framerate you, of course, need to perform quite some logic in about 16 milliseconds (the author correctly mentions it in its talk).
And... Drumrolls: simply "iterating" over a seq made of a hundred elements in Clojure apparently takes more time than that. Not to mention that if you create objects at every frame then at one point the GC shall have to kick in and your real-time performance will suddenly drop (the author says that in the talk I watched about CES/Chromashift).
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 "problem" is that they're talking about that "CES" as it was the one way to create games. But how many games written in Clojure have been shipped? Heck, how many games written in Clojure are even playable?
There are, today, lots of people writing games (either professionals or amateurs) and selling them (or giving them away for free).
And not a single one of these game is using that "Component Entity System". And hardly any of them is using Clojure (there may be one or two exceptions but that's about it).
And every single of these real games (even the simplest smartphone game) is looking better and is more responsive than the poor examples we see in Clojure talks.
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?
Once again, I don't want to be mean: these guys are typically good programmers but, to be honest, they don't know anything about game programming and that is a bit saddening.
EDIT: I won't even start talking about the "quality" of the "text editor" part of Light Table. I like the concept of LT but I do wan't a client/server mode where I can plug in vim or Emacs (or Sublime Text 2 or whatever) as my text editor. Otherwise I'm never going to take LT seriously.