interfaces are about communication between objects, inheritance had something to do about Liskov substitution principle to be right. Are you sure your objects are capturing the stuff you want to capture? Differently put: are you modeling from the right perspective?

interfaces are about communication between objects, inheritance had something to do about Liskov substitution principle to be right. Are you sure your objects are capturing the stuff you want to capture? Differently put: are you modeling from the right perspective?[size=5pt]I wanna fiddle with ROO[/size]

I assume this is meant for princec?

Dependencies/communication between components is utilizing separated interfaces pattern, as they are dependencies between packages. This is all very standard.

I don't know about those gidrahs.xml and tags.xml, they seem to be very implementation specific. It will be a nightmare to refactor your code.

Orangy - you should look at the latest stuff I've got in SPGL - it's even more super simple and flexible than it was before, XML wise! And the sprite engine has gone from strength to strength with labels and subroutines and floating point coords etc. Soon I'll put timebased animation into it (rather than tickbased).

Orangy - you should look at the latest stuff I've got in SPGL - it's even more super simple and flexible than it was before, XML wise! And the sprite engine has gone from strength to strength with labels and subroutines and floating point coords etc. Soon I'll put timebased animation into it (rather than tickbased).

Cas

Actually I keep meaning to rewrite the resource stuff because it's not quite keeping up with what I want to do with it (in particular background loading/streaming and reloading automatically when files are changed). I'd be interested to hear what other people use/want in terms of resource and metadata loading.

Dependencies/communication between components is utilizing separated interfaces pattern, as they are dependencies between packages. This is all very standard.

I'm pointing at something much more basic than that, to use a anything you need to know how to interact with it. If your not interacting with it it might as well not exist.

one level of abstraction fits all?

HeavyTank do we need another class for that? isn't that just a tank that looks a bit different has a little more armor, weighs a little more. Perhaps Tank should be able to capture those difference. A Tank isn't that a armored vehicle with tracks and a cannon mounted on it? Does a tank interact with the terrain or is it the tracks that interact with the terrain? Or does a Tank interact indirectly interacts with the terrain through it's tracks... Sure if your game only contains tanks it's over-designing if your wondering about that. The more sophisticated your world is the more sophisticated your model should be. Why do we seem to favor one-way-of-modeling-your-stuff-fits-all approach here?

Actually I keep meaning to rewrite the resource stuff because it's not quite keeping up with what I want to do with it (in particular background loading/streaming and reloading automatically when files are changed). I'd be interested to hear what other people use/want in terms of resource and metadata loading.

I've been meaning to add that feature too. We should probably have a chat about it.

But after that, off the top of my head, here's an idiot's guide to the value of ES:

* The typical, most basic, simplistic of all game designs is a 3-way difference of options; RPS is a specific form of this (R > P > S > ... R), but there are a few classic other ones, such as (A approx.equal to B; A > B; A > C; ... but if everyone else goes A or B, then C >> A + B - for instance Microsoft Hearts). OOP is *completely incapable* of representing either of these forms of game logic, and they are two of the most common forms of game logic we see every day in games everywhere. This is because OOP *fundamentally requires* that everything fits in a DAG - and DAG == very-boring-gameplay

* ES fundamentally works on limitless datasets: it's very easy to build caches for, it's very easy to write hyper-efficient memory managers, it's very easy to write distributed executation algorithms (using divide-and-conquer), and it's very easy to write approximation algorithms. This makes life a LOT easier when you have large numbers of MOBS (e.g. in an RTS, or in any MOB-heavy game where MOBS have non-trivial - or a wide vareity of possible - behaviours. Obviously it works extremely well in any MMO, too)

* When you have an existing codebase, and want to add a new type of enemy, or even a new small game-feature that will affect many - but not all - game entities (perhaps add a feature "reload time" that affects 75% of the existing weapons), this is trivial to add with any ES, but the more OOP your codebase, the harder it is to add (unless you get very lucky and find that the 75% has a 100% correlation with the subclases of a particualr class; in real-world game design *that never happens* because it would be an extremely dull change to the gameplay

* very fast, easy to debug, network code is very easy to write for ES (because all data fits a very small set of known templates; this is just a corollary of the other data/distributed-processing/caching benefits)

* very powerful debugging and gameplay-testing tools are much easier to write (ES work very well even when you "take away" entire subsystems: so, for instance, you can disengage your render layer trivially - but you can equally disengage any other layer, and mock it - suddenly automated testing becmes very easy, and it's quite easy to write compile-time behaviour checkers that will tell you in advance the "side effects" of altering behaviour X, or component-onwership Y)

* anything to do with data serialization and replay is much easier to write - very powerful for debugging and for reproducing bugs seen in the wild

...and a bunch of others. But that's just from the top of my head, as noted.

Anyway, it's just a big task to write a game that actually benefits from ES.It's is a power tool, and most of us are used to hitting nails with hammers.

The end result might be structurally flawed, but we deal with it just fine.

That said, I'm very interested in giving it a whirl, although I don't really like the EntitySystem, as your EntityComponents simply become flags, and your set of EntitySystems is basically structured like a relational database. I know that's the whole point, but it doesn't feel intuitive. For some reason I'm too used too OOP, and it's not easy to let go. Programming everything in the EntityComponents feels much more natural to me - and if you can keep your dataset in RAM, you can easily get away with the 'hybrid'.

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

I already read Mick's paper and it helped me to see some benefit ES can have, I did not know about Scott Bilas's but found this one wich seems to be pretty well explained ( it also provide some code snipets for a better understanding ) http://gbgames.com/blog/2006/03/object-oriented-game-design/ , so thanks to have pointed me its work as it is very nice, I did not read yours yet, but be sure I will. I already read most of the benefit you pointed out in others papers before my last post, it is just that I have trouble to have a "very clear vision", anyways thanks for those precisions.

NB.: my question may be more revelant this way, if it is so much fantastic (and I beleave it can be..) "when we must not use such component based architecture ?" and why it is not used often ?

Yuk to Spring Check this out: gidrahs.xml(with accompanying include tags.xml)The guts of it all works with just 4 classes! If I had access to @annotations I'd have an even easier time of it too.

Spring is a very useful tool for large application. But for use as in a game, I would think a smaller API to pre-build game objects would work better.I'm currently working on a similar project. I have a tool that builds an XML that would then be use for basic game object setup, allowing me to focus more on game design.

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?

YES - if you have stateful programming, you do not have a functional programming language. That's a simple law - *by definition* you mustn't break it (or, if you're going to break it, you have to be very careful to viciously limit the kinds of state and the ways in which state can be retained - most practically useful real-world fn-programming happens in languages that have "a little bit of state, but stored in a functional way"; in fact, IIRC, they all simulate "state" only by using true fn primitives - so, in all honesty, it's not really brekaing the cardinal "no state" rule).

Allowing state is like saying that "all private members in an OOP langauge are constantly exported and accessible to all code - in *all* domains - at runtime". Fine. But you just made it *impossible* to enforce several tenets of OOP (data hiding, abstraction, etc). That's no longer an OOP language - although you'd still be *capable* of writing OOP code, other people could piss all over it .

YES - if you have stateful programming, you do not have a functional programming language. That's a simple law - *by definition* you mustn't break it (or, if you're going to break it, you have to be very careful to viciously limit the kinds of state and the ways in which state can be retained - most practically useful real-world fn-programming happens in languages that have "a little bit of state, but stored in a functional way"; in fact, IIRC, they all simulate "state" only by using true fn primitives - so, in all honesty, it's not really brekaing the cardinal "no state" rule).

Ok, at least I understand your claim, then, even if I disagree with your definition of "functional programming language," which seems a bit restrictive for my taste . A hard-line approach would have to consider even Lisp a non-functional language because it contains direct mechanisms for dealing with state. Merely having the ability to do it doesn't mean most people do, and since probably 95% of the Lisp code in existence is purely functional, I have a hard time saying it's anything but a (impure, perhaps) fn language.

Quote

Allowing state is like saying that "all private members in an OOP langauge are constantly exported and accessible to all code - in *all* domains - at runtime". Fine. But you just made it *impossible* to enforce several tenets of OOP (data hiding, abstraction, etc). That's no longer an OOP language - although you'd still be *capable* of writing OOP code, other people could piss all over it .

I'd say a closer analogy would be to say that an language is not OO unless it explicitly disallows public members, right? Otherwise anyone can still piss all over your code and use your library in an imperative way - who amongst us hasn't seen this done (and likely done it ourselves!) once or twice?

In any case, we both certainly agree that functional programming is entirely about immutability and state-free programming, which is really the issue; we simply differ as to what we consider a functional language; I see it as something that allows functional programming, you see it as something that enforces it. I'm happy to chalk it up to a difference of definition - the wars over this at Hacker News wage on to this day, so there's clearly no "right" answer.

That said, I'm very interested in giving it a whirl, although I don't really like the EntitySystem, as your EntityComponents simply become flags, and your set of EntitySystems is basically structured like a relational database. I know that's the whole point, but it doesn't feel intuitive. For some reason I'm too used too OOP, and it's not easy to let go. Programming everything in the EntityComponents feels much more natural to me - and if you can keep your dataset in RAM, you can easily get away with the 'hybrid'.

You have completely missed the point, then, and I strongly advise you "don't bother, forget you ever heard about this, and enjoy OOP. One day, when you find you've suddenly understood the meaning of 'OOP-hell', come back and have another go - you might find you like it"

If you read through my early articles, you'll see that I explicitly mention (several times, I think) how hard a lot of OOP coders find it to "stick" at ES - they keep "accidentally" going back to OOP paradigms; this *is not easy* if you've heavily internalized the OOP way of thinking. Most of my difficulty / time / work spent on ES in the field was in getting OOP programmers to stop (trying to) writing OOP code in the ES - including myself! It was *really tough* to break the habits of a lifetime.

Anyways am I missing all this non-OO-ness what everyone is talking about, all I see is OO with a dash of persistent attempts at throwing static typing out the window.

OOP: I AM THE LAW!!!! You WILL obey your parents! Your parents WILL obey your grandparents! TO INFINITY!!!!!

ES: I have his legs, her arms, their eyes, your left ear, your brother's right ear, and I have the wings of a bat. Since I contain no new functionality, it took literally zero source code to implement me. Oh, and by the way - I have a sister, and she's got the exact complement of everything I have. She also is zero source code.

The "obvious" advantage over OOP is in the first sentence (you can "pick n mix" behaviours from anywhere, and it all works 100%).

The "subtle" advantage over OOP is in the last sentence (even though with an OOP-sourced compositional logic system, there are some things you *can* implement efficiently, recombining them is generally impossible. this is *built in* to the concept of OOP at a fundamental level).

If you're still not sure, then you maybe don't understand OOP well enough, in which case I suggest you go learn more about the theory and history of it - you'll probably find it improves your own understanding of the more complex and esoteric bits of OOP, and helps you write better OOP code first-time, every time. Objects were invented antithetically to the idea of "compositional logic" - they were invented as "hierarchically inherited logic", like parent -> child -> grandchild.

NB: you can have hierarchical logic in a fn language (e.g. have a look at XSLT...), but you cannot enforce it in a fn language - the fn nature means it can always break out of that. OOP lets you enforce it (or, at least, make it *really really difficult* not to live inside it).

...but I'm probably just confusing the issue more than I'm helping here. The original blog posts I did on this topic took many many many hours each of careful thought and re-writing to try and make extremely clear ... what is actually very easy to misunderstand. The posts I've done in this thread - on the other hand - are tossed out quickly, and are probably rather poorly explaining things / making a complte mess of it.

You have completely missed the point, then, and I strongly advise you "don't bother, forget you ever heard about this, and enjoy OOP. One day, when you find you've suddenly understood the meaning of 'OOP-hell', come back and have another go - you might find you like it"

I thought such remarks were beneath you? No need to be so patronizing. You might miss my point? What I'm saying is that I *like* the functionality in the component, as opposed to the system. I already wrote quite some code around these Entities and Components (and Systems as of today) and it certainly feels like a database - in the current code, you can already simply grab all entities that have component X, without plowing through all the entities. Similairly, you can grab all components in an entity, without the entity having a list of children. The implementation can both be a DB, or a hacked alternative using lots of java.util.Maps to quarantee nearly instant access to 'columns'.

Currently I have code like:EntityContainer container = new MySQLContainer();

public void perform(Entity entity, HealthComponent health) { // there is a 1:1 relationship between the entity and health object. // fields like health.min, health.max, health.current are 'bound' to this entity

if(health.isDying()) // this is code in the component - bad if(this.isDying(health)) // this is code in the system - better? // remove entity from the container else health.recover(); // this is code in the component - bad this.recover(health); // this is code in the system - better? }

What I assume, is that the Component classes/types are like different tables, as you have a fixed amount of columns/fields per {Health|Decay|Movement}Component. Components are like records in a these tables: they only contain data. To connect everything, you have a table like:(entity_id INT, comp_type INT, comp_id INT UNIQUE)So that you can instantly find all types that have the same comp_type, and JOIN one of the Component tables depending on what that comp_type actually is. the comp_id is the foreign key used to join the entities to the components.Either that, or a foreign key (entity_id) in each Component type table.(Is there a more efficient way that you worked out?)

The System behaves like a stored procedure for a specific component type (like Health).

It just takes a while to get used to, and my preference for the code-in-component might just as well change sooner or later.

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

I suppose that when I have a problem that isn't totally easily solvable with OOP I'll look to something else to solve it. So far though in about 30 years the only problem I've found that is dealt with better in another language is SQL. It'd be nice to mix the two a bit more.

the more I think of its design the more I like it (I think that I will try to use such architecture starting from scratch for my next demo and than I hope I will learn a lot from this experience), but I am probably still a lot wrong on how I have understanded it.... so ... below is how for now:

let's say I want to create a simple game where gameobject can have ( at the start of my game design ) a position,appearance,health and want to store all of that in a DB

I will then create three SQL table like the following (EUID stands for Entity Unic Identifier):

I thought such remarks were beneath you? No need to be so patronizing.

Sorry - wasn't intended to be patronizing, I just badly phrased it: it was intended literally: don't touch an ES in that case - it will be more trouble to you than it's worth. But *if* you find yourself shouting "FSCKING OOP!" at your monitor one day ... that would be a good time to revisit this subject, and see if you feel differently about it (I supect you would).

Quote

public void perform(Entity entity, HealthComponent health) { // there is a 1:1 relationship between the entity and health object. // fields like health.min, health.max, health.current are 'bound' to this entity

if(health.isDying()) // this is code in the component - bad if(this.isDying(health)) // this is code in the system - better? // remove entity from the container else health.recover(); // this is code in the component - bad this.recover(health); // this is code in the system - better? }

By "code should be in the system", I mean that the physical location of your functions that contain that code is "inside classes that are internal to the system, not inside classes that define the java/OOP objects that are used as game-entities".

Depending upon how you call the perform method, it could count as either. If you made it explicitly static, then it could *only* be the latter - but you'd also be throwing away the on-the-ground benefits of OOP as a generic programming paradigm for writing those funcitons.

BUT ... from your code snippet, I think you fully understand what I'm trying to say here, so I'll shut up .

No, that convinces me that you've got it. In the light of this, I don't understand your previous statements where you said you wanted to revent to code-in-component, OOP style?

Quote

It just takes a while to get used to, and my preference for the code-in-component might just as well change sooner or later.

Have you tried writing a system where you write all the code in the system, not in the components? maybe attempting to do that will make it clearer what you don't like (or why you do, in fact, like it )

I found that I hadnt' realiased I had 2 or 3 different mutually incompatible "types" of OOP object in my architecture - there were the game-entities, the behaviour of metacode, and the internal represetnations WITHIN The systems of the PLACEHOLDERS for game-entities that the system was TEMPORARILY referrring to while executing.

No, that convinces me that you've got it. In the light of this, I don't understand your previous statements where you said you wanted to revent to code-in-component, OOP style?

Don't forget that you have experience under your belt, and I have not. I bet it was like that for you too, initially you were trying to figure stuff out by trial and error, and refactored your code time and time again.

So don't be too harsh when others are making 'silly mistakes', while this is only natural when starting something new.

Have you tried writing a system where you write all the code in the system, not in the components? maybe attempting to do that will make it clearer what you don't like (or why you do, in fact, like it )(the latter type being like template-programming in C++)

No. I've only been coding on this for a few hours. The API is - more or less - done, but using it is something totally different, and will often show the bugs, weaknesses and the things that were misdesigned/misinterpreted.

Wow, I must be on the right path understanding this, as I was sitting at work staring out the window, i also spotted the whole entity is just an ID thing, and figured derby in ram might be a nice way to address all this. Want to know what entities are near you?, query the position components retrieving the entity IDs . Not sure sql is all that fast mind, but it does mean that the posibilities for searching your game world are huge.

So do I also understand correctly that the components (or their classes) contain no logic?, they contain data, and the system contains the logic?

There are indeed some problems: it's not easy to get a subset of the Entities with a specific Component, but then again, didn't we always have to code that somewhere else? Quadtrees, octtrees...

You can fake with with Components, sure... but that seems to be totally abusing the system (not the System).

In SQL, you can however refine your WHERE clause - but how to do that transparantly from inside the System is not easy. When you're working in RAM, you'd implement it with an EntityFilter->accept(Entity entity) but then you'd be iterating over all Entities anyway - not much use.

Blahblahblahh, maybe you also have figured a solution for this, or will we simply use the existing code to deal with sptial algorithms? Doing everything in SQL simply won't cut it, when you're checking 'who is near me' hundreds/thousands of times per frame, at 60fps.

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

But after that, off the top of my head, here's an idiot's guide to the value of ES:

* The typical, most basic, simplistic of all game designs is a 3-way difference of options; RPS is a specific form of this (R > P > S > ... R), but there are a few classic other ones, such as (A approx.equal to B; A > B; A > C; ... but if everyone else goes A or B, then C >> A + B - for instance Microsoft Hearts). OOP is *completely incapable* of representing either of these forms of game logic, and they are two of the most common forms of game logic we see every day in games everywhere. This is because OOP *fundamentally requires* that everything fits in a DAG - and DAG == very-boring-gameplay

* ES fundamentally works on limitless datasets: it's very easy to build caches for, it's very easy to write hyper-efficient memory managers, it's very easy to write distributed executation algorithms (using divide-and-conquer), and it's very easy to write approximation algorithms. This makes life a LOT easier when you have large numbers of MOBS (e.g. in an RTS, or in any MOB-heavy game where MOBS have non-trivial - or a wide vareity of possible - behaviours. Obviously it works extremely well in any MMO, too)

* When you have an existing codebase, and want to add a new type of enemy, or even a new small game-feature that will affect many - but not all - game entities (perhaps add a feature "reload time" that affects 75% of the existing weapons), this is trivial to add with any ES, but the more OOP your codebase, the harder it is to add (unless you get very lucky and find that the 75% has a 100% correlation with the subclases of a particualr class; in real-world game design *that never happens* because it would be an extremely dull change to the gameplay

* very fast, easy to debug, network code is very easy to write for ES (because all data fits a very small set of known templates; this is just a corollary of the other data/distributed-processing/caching benefits)

* very powerful debugging and gameplay-testing tools are much easier to write (ES work very well even when you "take away" entire subsystems: so, for instance, you can disengage your render layer trivially - but you can equally disengage any other layer, and mock it - suddenly automated testing becmes very easy, and it's quite easy to write compile-time behaviour checkers that will tell you in advance the "side effects" of altering behaviour X, or component-onwership Y)

* anything to do with data serialization and replay is much easier to write - very powerful for debugging and for reproducing bugs seen in the wild

...and a bunch of others. But that's just from the top of my head, as noted.

I read Mick's article and your article.(Still waiting for the next installement ) Does Scott Bilas have an article on this, other than his GDC slides? I went through his slides, but would like to read something in more detail if he has it.

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