There are also two very insightful discussions over at gamedev.net:
I’m working on a simple “game” engine at work. It will not be used to create games, but training scenarios. So workers can train on procedures in a power plant. I’ve been looking at Unity3D and Blade3D for inspiration and they both use a Component System. I recommend trying out Unity to see how it works. It has a 30 day trial version. The documentation is also available on the net. Here is the part about GameObjects and Components:
http://unity3d.com/support/documentation/Manual/Building%20Scenes.html
I did not know about the “Game Object Component System” before reading this thread. Has given me something to think about 
I’ll probably go for a “Components with methods” rather than “Components as pure data”. I guess I’m too stuck in the OO way of thinking.
Some random thoughts. Components need to talk to each other. There is no need to abstract this interaction away using the observer pattern. Either use direct references if the target don’t change, or do a query whenever needed. A component should be able to get hold of and use any other component or GameObject. Setting up the references could be done when the level loads. An example is a LookAt component. In the editor you could add the LookAt component to a camera. The LookAt component should have a target property that you set threw the ui. Of course you could specify this information in the xml file if you don’t have an editor.
Scripting lends it self very well to the Component System. A script is simply a Component. You could implement a 3’rd person camera using a script. This script Component would require that the GameObject also has a Camera and Transform component. Reference to the other components would be found when the components are initialized and cached for later use. The script would also need a target. This could be done in the editor ui or the script could search the world for the Player GameObject when it was initialized.
I’m still thinking about how to integrate the components with the scene graph. A Transform component would have a matrix and a parent. A Model component would have the visual representation. But should the component or a Manager class attach the GameObject to the scenegraph?
This is what I’ve been thinking about for some time now.
I’ve been thinking of creating something like a NodeComponent, which does not much but to store a list of children gameobjects. The NodeComponent needs to be attached to a gameobject to enable it to become a parent.
Another way is to simply attach gameobjects to other gameobjects. The problem with that solution is that ALL gameobjects would need to have it’s own List object. This creates a big overhead needlessly, especially when you might have hundreds of gameobjects and hundreds of bullets flying around, each requiring a List. (There is also some consensus that the gameobject should really be nothing but a GUID (global unique id) in the game world, and not “contain” anything, just be attached to components.) So let’s forget about this idea!
The NodeComponent needs to be explicitly attached to a gameobject so it can contain child gameobjects.
And now regarding the local/world translation and rotation problem.
The NodeComponent should ensure that children gameobjects have the world translation and rotation, so they don’t need to look them up or calculate them. The gameobjects should be oblivious to the fact they are attached to another gameobject (via NodeComponent), so the NodeComponent needs to recalculate the translation and rotation, and set it, for each gameobject before they are updated and rendered.
Cas (and others perhaps - but Cas was most vocal and made the easiest-to-refute claims ;)), I don’t think you’re seeing the whole picture here. Multiple inheritance helps “not at all” for entity systems. Generally speaking, all OOP features/variatns help very little with ES’s - until/unless you want to use it internally inside a method implementation because the method itself is so vast that it needs splitting down using something - and we are all well aware of how good OOP is at doing that.
IMHO, within 20 years, ES’s will be used for almost all mainstream programming. OOP is poor paradigm for real-world projects, it always has been - it only started as a desperate attempt to improve on a language where fundamental language constructs were based on “what would be easiest to compile into assembler” rather than “what would make programs better” or “what would make software development better” etc. OOP was a nice-stopgap, and it will always remain useful as a way for breaking down large pieces of complex contiguous code into an easier-to-manage low-level code. But it sucks for application writing - we just don’t work this way.
Bigger problem, which is the real reason I suspect ES’s will eclipse OOP, is that OOP is the antichrist of SQL - and there’s literally nothign you can do to change that (unless you win a nobel prize for mathematics by solving stuff that mathematicians and computer scientists have so far been unable to). Our world relies more and more on data. Have a look at the “data” languages: they’re all functional (SQL, XSLT, etc), and OOP can’t do functional. Even if you think the world will stop becoming more and more data-centric, just look how much data is already stored in SQL. New data, simple data, stuff that’s done by intermediate programmrs like us … well, it may not all be going into SQL too (although HSQLDB et al are making inroads on that - Firefox uses SQL internally, the iPhone provides local SQL as a core service to programmers, etc), but most that isn’t, that’s going into “something more modern”, is going into… XML. For which the primary interaction language is XSLT. And so it goes on…
I never thought OOP helped a massive amount for entity systems particularly. But my point is that the “big” picture is actually nearly always, in fact, a very “small” picture and people just like to overcomplexify and overengineer everything and never get anything done because they’re too busy bashing square pegs into round OOP holes.
Cas
+1
trying to always make “hyper generic stuff” seems very nice but… at the end, is there always a real benefit ? is there a real solution ? it is something as a quest
Ugh. When I wrote HSQLDB, I meant SQLite.
Anyway …
People occasionally beat me over the head demanding that I finish the Entity Systems for MMO post series, but I don’t want to mess it up with some half-assed followup. Sadly, I no longer work on MMO tech, don’t even work for an MMO developer any more, and so I have no opportunity to carry on experimenting with this stuff - and I’d really like to include some worked example code in the next post(s).
It is so easy to fall into OOP coding accidentally when doing this stuff, and I want to be sure that my next posts are very explicit about the details of how people should architect their ES code.
ES’s are fairly easy to do efficiently in C++, since most of the real challenges are about how to efficiently access vast amounts of data from streamed sources (i.e. structs are very good) - but there’s no reason you can’t do them well in Java, with a little effort
If anyone’s interested in putting together a java-based ES game - especially if they’d open-source it - I’d love to help.
Essentially, I can advise you on how to architect the ES side of it, and work with you through the specific implementation issues that come up. The one thing I can’t do is write code for you - I don’t have time.
When I find the perfect programming paradigm, I will write the perfect program.
@blahblahblahh: Given your comments and that you’ve had some actual experience with this stuff, are you saying that it’s the functional deficiencies of OOP that are solved by ES, or does it run deeper than that?
For instance, if you were writing game logic in Scala, Ruby, or Javascript (all solid OOP/functional mixes, though Javascript is kind of an odd man out given its odd breed of OOP), would you still write an ES system for the game, or are there easier or equivalent solutions within the languages themselves?
I’m very curious to see an example of situations where you really win with this sort of approach, as well as hear guidelines for implementing it.
That said, I agree with Cas’ point about picture size. Most projects, classes, code, and components for games are never going to be reused, and time spent worrying about how to make reuse and extension easier is utterly wasted unless the project has a very large scope (like an MMO, for sure).
This has been a recurring theme, yes - ES -> SQL -> ES is trivial without boilerplate code, unlike OOP -> SQL -> OOP.
Although I havent yet delved far enough to check whether it’s only some aspects of fn that are made-up-for this way, or all of them (in my experience, it seems to be the latter - OOP + ES == a decent, practical, simulation of fn-programming for your game objects).
I don’t know Scala, I haven’t looked at Ruby in a very long time (that’s the one that’s a SmallTalk variant?), but Javascript is blatantly not functional. Being able to do a bit of slightly-functional-like programming in a language does not make it a fn language - javascript is inherently imperative, for instance. My vague memory of Ruby was that it wasn’t especially fn either (but it’s been at least 4 years since I even saw any Ruby code, so I honestly have no idea there).
I’m not trying to be pedantic - the same issue crops up with OOP: is there a minimum set of OOP-ness that a language requires to be considered an OOP language (since the invention of C++, and Bjarne’s explanation for it, most people have felt “yes”, IIRC). You can, for instance, simulate OOP inside Perl - but it is so obviously a simulation that you would never call Perl an OOP language (and “OO-Perl” is a slightly tacky concept that - if you know what it means - is fine, but often confuses people into thinking that Perl does full OOP)
By preference, I would write all MMO games entirely in fn languages.
Sadly, there are far far far too few trained fn programmers in the world - and unless you work in telecoms or microprocessor design (or other similarly niche fields), it’s very hard to get any commercial experience in proper fn programming. Which all makes it prohibitively expensive, in real terms, to use fn for everything.
OOP + ES is a neat compromise where your coders “only” need to learn this new paradigm - the ES - which itself comes with a framework that solves a lot of problems they’d have had to work on anyway (for instance, the SQL de/serialization issues), and can carry on working in their language-of-choice with their IDE of choice and compilers, runtimes, etc of choice - and deubggers etc.
I have a blured vision of ES benefit (one thing I understand on it is that : you store data in the functionalities (component) rather than in the object/entity itself, is that right ? I have trouble to understand why an ES cannot have an equivalent OO design as the interfaces samples posted previously).
anybody able to post a short, clean, working code showing a basic ES implementation in java ?
For one: you can add/remove functionality from an Entity at runtime, as apposed to compile time when using interfaces.
I’ve never run into the problems discussed in this thread.
Unless you want to either define/load new units in runtime or allow easy modding, I don’t see the difference between defining a unit in an external file (xml or whatever) and in a java class file.
I think the problem is that ES shines in situations that nobody but Adam has encountered.
Most of us would never reach the point where OOP would not suffice.
The ‘fact’ that ES is better, is irrelevant if you can easily manage your own design.
Well, the ES design is certainly, hm, design-provoking. But for my RTS game it’s probably a overkill, although I do like the design idea and will probably experiment with it on future games.
However, the idea of taking the functionality out of the gameobjects and move it into specialized components is working out quite well for my RTS game.
Now I’ve integrated Spring into my game design. All the gameobjects are defined as prototype beans in the spring bean XML file, and if I wish to create a new instance of a starship I simply call:
GameObject myStarship = (GameObject)beanFactory.getBean("myStarship");
or if I want to add many starships into the game:
// as it's a prototype bean, each getBean() method creates a new instance of myStarship
worldGameObjects.add((GameObject)beanFactory.getBean("myStarship"));
worldGameObjects.add((GameObject)beanFactory.getBean("myStarship"));
worldGameObjects.add((GameObject)beanFactory.getBean("myStarship"));
worldGameObjects.add((GameObject)beanFactory.getBean("myStarship"));
^ the above code can even be defined in another Spring XML file, called worldGameObjectsBean01, and inject it as the worldGameObjects list. That way I can define multiple worlds, or maps, in order to load them, simply by injecting them into the game-engine on demand.
Overkill? I don’t know. Maybe it’s because it’s never been done before (well, at least in this isolated community) that we think it’s too much, we fail to see the benefit. For me, I’m starting to see them.
At least it’s one way of doing things.
Actually, was doing that in 2003 for Alien Flux, and have done it ever since. I use factories configured by XML to create instances of stuff. It’s like a lightweight and slightly easier to use and understand model than the various kitchen sink implementations out there.
Cas
I’ll admit very little JS or Ruby knowledge; however, in Javascript functions are true objects, you’ve got real closures, nested functions, higher order functions, you can pass functions to other functions, etc. Once we add eval into the mix I don’t know of anything you can do in Lisp that would be very difficult to translate to JS (though the code would certainly be a little heftier without proper macros). What it lacks is predefined convenience methods that tend to permeate functional programming (fold, reduce, map, flatmap, etc.), and I’m not sure how it fares at tail call elimination, it might blow stack in your typical browser just like the JVM would. Don’t know as much about Ruby, to be honest, but from what I’ve heard it satisfies most functional programmers fully apart from the speed issues.
Javascript gets a real bad name because most of the uses it sees are very imperative and don’t exploit its power, but to my knowledge it’s a perfectly full featured fn language, albeit an impure one. It definitely has flaws, but I don’t think it particularly imposes an imperative style, even if it does make it easy to fall into.
What would you require in a fn language that it doesn’t have? (aside from perhaps a flat out prohibition on state-ful programming, as the Haskell guys would prefer) And what sort of language does qualify, in your view?
Who cares… as someone’s mentioned, this is a Java games dev board 
Cas
Indeed, me == pulling the discussion OT into a language war yet again, as usual.
Still, Java (the platform) has a ton of flexibility as far as the language you code in, which to me is one of its greatest strengths. Since it’s so easy to mix any and all of the mentioned languages in with Java code, I don’t see why we should restrict ourselves from discussing the possibility, esp. if it’s a faster/easier/better solution than the alternative (which I’m not sure about, since I still don’t entirely grok the claimed problem, lacking concrete examples of OOP’s failures in typical game settings).
If all you need to solve your problem is a few function pointers or a closure, it’s takes a couple downloads and a cut and paste to add a scalac step to your Ant build, compared to the weeks it might take to design, build, and debug a sophisticated component system. It’s more work to use Ruby or JS alongside Java, but it’s still a lot less time than you’d spend to architect a perfect pure-Java solution.
…is all I’m saying. 
If anyone is interested, here’s this game of mine (very infant) that is using this Game Object Component System, and also Spring, which I use to define the game objects.
You can check out the link there which shows the Spring XML, should give you an idea. But, it’s all in development still. But, with this power I can now rapidly create components and put together all sorts of game objects in the XML, and get them going in a heartbeat.
Some download overhead because of spring and slick libs.