HI all, I just wanted to let anyone who might care that I have started a developer journal on my engine dev for our upcoming game release. I get questions from time to time on what/when things are happening over here and I think this will be the best way I can put the word out. Check it out if your interested, thanks for your time.

Well briefly I will say that it really isn't a language issue, it's a design issue, but it's not so easy to see that until you are deep in the probelm space. The sentence above is the best search terms for finding more info on that in a general sense, i.e. not related to game engines but programming in general.

Since you have an interest I wll make a more thorough post in my blog about this ASAP, but in the meantime I can say that as far as I'm concerned this is a major differentiater between "old school" game engine objects and a really up-to-date and versatile game engine object system, almost to the point to saying that the old way (compile-time inheritance) is hacky in today's game space.

Also, this was a HARD learned lesson with our engine, and as many of the industry people promoting this style have said, it really takes that lesson to appreciate the change.

(After re-reading this, I can see my response is rather nebulous, I apologize for that, as I wrote above I'll have to get into details in the blog.)

The one that particularly got my attention was ww.gamearchitect.net one with the 3 series on scenegraph objects and such. It seems to me that most, if not all, of his concerns stem from bad design. For example "The Diamond of Death. What do you do if trigger objects are derived from game objects, and dynamic objects are derived from game objects, but you want a dynamic trigger object?"

Why would a trigger be in the same group as a mesh or a skinned character? Technically, they are both "game object"(s); your just costing yourself unnecessary overhead...

In the second GameObjects blog/article, he says "Using a directed acyclic graph instead of a tree, you can share objects and animation state across multiple locations in your world" which only begs the question, what is the difference between a directed acyclic graph and a tree? Conventional trees *are* directed acyclic graphs from what I have understood.

"You'll have the same problem animating control points for higher-order primitives. Height fields, lights, volume fog and shadows are similarly likely to end up being awkward special cases.". Those seem to fit quite elegantly in the scheme of things from what ive read and seen...

Apologies if it seems like ive put his blog/article under a microscope, but Im in the middle of making my own game engine and I thought i had the scenegraph element well and truly finished

PS. the reason I got Java involved in this because he mentions multiple inheritence in a few places

I think I have blurred the distinction between a game object and a mesh. Although the two seem connected, a mesh is a small subset of a game object, a game object will have sound, physics and what have you. Am I right in thinking that?

If so, a data driven, component based system definetly makes sense. However, it does beg the question, why did all the previous engines use inheritence based schemes? It seems a component based one is easier to code, easier to maintain and more powerfull overall...

Yeah, the state of the art always seems to be about 10 years behind in games for some reason.

Cas

The main reason for that is because games operate in a very constrained environment (whether in reality or by design) and it takes time to evolve those 10 year ahead of games concepts to games' demands. Also, game design tends to be conservative, somewhat of a "if it ain't broke don't fix it" mentality.

In the case of composite vs. inheritance the debate rages on the software world still and even outside of gaming many developers still focus heavily on an inheritance based architecture. Shoot, most of the standard Java APIs are still like that. So you can say that gaming is behind, but then so is most of software development...

Distinguishing his question from your answer would be much clearer if you put the quoted text in a blockquote. That's common blogging convention. Had I not read the post here first I would have been a bit discombobulated, even with your bold headers. As for editing the Blogger template, from the Dashboard click on the "Change Settings" icon. From there, select the template tab. You'll be presented with the template in a text box.

I did have backlinks enabled for new posts( that's the only option), but they defaulted to hide, so I switched it to show now, but I don't see any difference.Also, I just "blockquote"d (right from the textarea editer) the question section but all it did was indent the section as you can see, Maybe I'll mark it off in some other way.

One of the thinsg that confuses this is that there have been systems where their "inheritance" really weas closer to what you call componentization.

ColdC was a great example (an old MUD development language). Even small talk, arguably the original OOPL, had component-ish elements to it.

I actually designed a scripting lanugage to live on top of Java that soem day Im going to implement called Kelvin (because of its ColdC roots) that used a "slotting" system where an object itself is an empty shell with no methods or fields. Methods or feilds get added by "slotting" in these thinsg called "Qualities" at run time. Each Quality is implemented as a Java class and there is a run-time call mechnism that handles inheritance between qualities. (I got an early bersion of all this workign in POC and suprrisingly performance wasnt too awful.)

The reason we've seen implementations of "inheritance" move away from more component like behavior though is that performance issue. Compile time inheritance can be optimized. Optimizing the links in a run-time dynamic inheritacne schemes is somewhere between difficult and impossible.

Got a question about Java and game programming? Just new to the Java Game Development Community? Try my FAQ. Its likely you'll learn something!

There is a experimental language that....wait for it... SUN is working on called "Fortress" that sounds similiar to the features you just described, although it is being designed as a Fortran replacement! I read part of the spec a couple weeks, back very ineresting.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org