Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (497)
Games in Android Showcase (114)
games submitted by our members
Games in WIP (563)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 2 [3] 4
  ignore  |  Print  
  Game Object Component System  (Read 25091 times)
0 Members and 1 Guest are viewing this topic.
Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #60 - Posted 2009-06-15 22:20:11 »

Yuk to Spring Smiley
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.

Cas Smiley

Offline Mr_Light

Senior Member


Medals: 1


shiny.


« Reply #61 - Posted 2009-06-16 01:27:30 »

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?

Quote
Yuk to Spring
[size=5pt]I wanna fiddle with ROO[/size]

It's harder to read code than to write it. - it's even harder to write readable code.

The gospel of brother Riven: "The guarantee that all bugs are in *your* code is worth gold." Amen brother a-m-e-n.
Offline appel

JGO Wizard


Medals: 51
Projects: 4


I always win!


« Reply #62 - Posted 2009-06-16 08:32:02 »

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.

Check out the 4K competition @ www.java4k.com
Check out GAMADU (my own site) @ http://gamadu.com/
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #63 - Posted 2009-06-16 08:57:52 »

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.

Actually I've been using a fork of Cas' resource code for ages now, and IMHO it's pretty good - copious use of reflection makes it trivial to write a data-driven game with minimal boilerplate code.

Were I to write it these days I might be tempted to use something like XStream, as my uneducated view of Spring is that it's a bit heavyweight for my liking.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline appel

JGO Wizard


Medals: 51
Projects: 4


I always win!


« Reply #64 - Posted 2009-06-16 09:37:09 »

Actually I've been using a fork of Cas' resource code for ages now, and IMHO it's pretty good - copious use of reflection makes it trivial to write a data-driven game with minimal boilerplate code.

Were I to write it these days I might be tempted to use something like XStream, as my uneducated view of Spring is that it's a bit heavyweight for my liking.

I was thinking about using XStream. But I guess somewhere on that road I drifted towards Spring. I guess I didn't want to create my own schema.

Check out the 4K competition @ www.java4k.com
Check out GAMADU (my own site) @ http://gamadu.com/
Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #65 - Posted 2009-06-16 12:07:55 »

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 Smiley

Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #66 - Posted 2009-06-16 13:29:05 »

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 Smiley

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.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline Mr_Light

Senior Member


Medals: 1


shiny.


« Reply #67 - Posted 2009-06-16 14:55:12 »

I assume this is meant for princec?
not really.. not specifically.

Quote
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?

sure other roads lead to Rome too, but they have their own bumps.

It's harder to read code than to write it. - it's even harder to write readable code.

The gospel of brother Riven: "The guarantee that all bugs are in *your* code is worth gold." Amen brother a-m-e-n.
Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #68 - Posted 2009-06-16 16:54:09 »

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.

Cas Smiley

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #69 - Posted 2009-06-16 17:29:13 »

I have a blured vision of ES benefit

First: definitely read Mick's and my articles (and Scott Bilas's stuff too).

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 allows - positively encourages! - limitless recombinations of game-logic to achieve anything you could possibly think of, with *minimal* re-typing by a designer, and *even less* custom programmer code per new combination

* 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.

malloc will be first against the wall when the revolution comes...
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 799
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #70 - Posted 2009-06-16 18:02:40 »

First paragraph throws a TooManyAcronymsException ?



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
Offline DzzD
« Reply #71 - Posted 2009-06-16 18:02:51 »

First: definitely read Mick's and my articles (and Scott Bilas's stuff too).
...

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 ?


EDIT :
an excellent paper too : http://www.devmaster.net/articles/oo-game-design/


EDIT 2 :
Quote
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),


R < P < S < R  Tongue

so, that's may be the big advantage : dealing with cyclic graph game design (or aribtrary one) ?
 

Offline aazimon
« Reply #72 - Posted 2009-06-16 18:32:57 »

Yuk to Spring Smiley
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.
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #73 - Posted 2009-06-16 19:36:11 »

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 Smiley.

malloc will be first against the wall when the revolution comes...
Offline ewjordan

Junior Member





« Reply #74 - Posted 2009-06-16 20:10:02 »

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 Smiley.  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 Smiley.
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.
Offline Mr_Light

Senior Member


Medals: 1


shiny.


« Reply #75 - Posted 2009-06-16 20:18:50 »

Quote
Normally if you have an abstract class called Human, you might derive Man and Woman classes from it.
errr?

Quote
you can say human->activateAction( CATCH_CRIMINAL ). If it isn’t a PoliceOfficer, then it won’t have that Action. Nothing happens, just as we would expect.
Vigilante extends Human  Roll Eyes


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.

It's harder to read code than to write it. - it's even harder to write readable code.

The gospel of brother Riven: "The guarantee that all bugs are in *your* code is worth gold." Amen brother a-m-e-n.
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #76 - Posted 2009-06-16 20:36:31 »

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.

But totally worth it Smiley.

malloc will be first against the wall when the revolution comes...
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #77 - Posted 2009-06-16 20:47:32 »

errr?
Vigilante extends Human  Roll Eyes

Yes - OOP sucks donkey when it comes to game-logic design + impl.

Quote
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.

Sorry!

malloc will be first against the wall when the revolution comes...
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #78 - Posted 2009-06-16 20:49:06 »

R < P < S < R  Tongue

so, that's may be the big advantage : dealing with cyclic graph game design (or aribtrary one) ?
 

Hmm. I see what you mean, but no, that's definitely not "the big advantage of ES", rather it's "something that OOP is guarnateed to f*** up every time, but with ES Just Works".

i.e. it's more of a reason "not to use OOP" than it is a reason "to use ES". Unfortunately, there aren't many viable alternatives to OOP ... Smiley

malloc will be first against the wall when the revolution comes...
Offline Mr_Light

Senior Member


Medals: 1


shiny.


« Reply #79 - Posted 2009-06-16 22:35:10 »

I'm not sure still  Smiley

It's harder to read code than to write it. - it's even harder to write readable code.

The gospel of brother Riven: "The guarantee that all bugs are in *your* code is worth gold." Amen brother a-m-e-n.
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 799
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #80 - Posted 2009-06-16 22:47:41 »

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();

Entity entity1 = new Entity();
container.add(entity1);
container.register(entity1, HealthComponent.class); // creates HealthComponent
container.register(entity1, MovementComponent.class);

Entity entity2 = new Entity();
container.add(entity2);
container.register(entity2, HealthComponent.class); // creates HealthComponent
container.register(entity2, DecayComponent.class);

HealthSystem<HealthComponent> healthSystem = new HealthSystem<HealthComponent>()
{
   public Class<EntityComponent> type()
   {
      return HealthComponent.class;
   }

   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?
   }

    // like this... ?
    private boolean isDying(HealthComponent comp)
    {
         return comp.health < 10;
    }
}

// and now we feed the Container a HealthSystem, which
// iterates over all Entities with a HealthComponent
// and invokes system.perform(entity, health)
container.execute(healthSystem);


Maybe this code clearly shows that I'm missing your point. (?) Maybe, but I'm fairly sure I'm going in the right direction.


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
Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #81 - Posted 2009-06-16 23:16:32 »

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.

Cas Smiley

Offline DzzD
« Reply #82 - Posted 2009-06-17 11:50:26 »

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):

POSITON fields : EUID   X   Y   Z
APPEARANCE fields : EUID   SHAPENAME
HEALTH fields : EUID HEALTHVALUE

I have three components that I can mix together to create my real gameobjects

So if I want to create a new object that have a Position and an Apperance I will get a new EUID and do two insert in POSITION & APPERANCE tables.

INSERT INTO POSITION (with inded EUID the same in both table)

and, if I want to remove I simply do an SQL delete (for all components/tables):

DELETE FROM .... where EUID='XXXX'

now if I want to add FIRE to my game I will just add a FIRE table with those fields : EUID, GUN_TYPE

in fact I clearly see that entity doesnt have anywhere a real OO meaning, this is just an identifier, but components seems to maps OO objects , no ?

second, does the above is completly wrong or no ?

EDIT :
POSITION => mean the Moveable component
APPERANCE => mean Viewvable component
HEALTH => mean somethingable component
etc...

Offline Riven
« League of Dukes »

JGO Overlord


Medals: 799
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #83 - Posted 2009-06-17 12:12:52 »

Well, that's what I make of it, and it certainly can be implemented that way, as I currently have it just like that.


One nice thing is that you can have a 'ram container' and a 'sql container' and use the one that best fits your Component type, specified in a 'hybrid container'.


EntityContainer sql = new SQLContainer();
EntityContainer ram = new RAMContainer();

EntityContainter hybrid = new HybridContrainer();
hybrid.setDefaultStrategy(ram);
hybrid.setStrategy(PositionComponent.class, ram);
hybrid.setStrategy(HealthComponent.class, ram);
hybrid.setStrategy(DecayComponent.class, sql)

Entity entity = new Entity();
hybrid.add(entity);
hybrid.register(entity, HealthComponent.class);
// etc


That way you can have instant access (RAM) if you need it , and can use slower access (SQL) for systems with a lower 'tick rate', or simply have less entities.

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

JGO Coder


Medals: 1


http://t-machine.org


« Reply #84 - Posted 2009-06-17 15:30:11 »


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 Smiley.

Quote
Maybe this code clearly shows that I'm missing your point. (?) Maybe, but I'm fairly sure I'm going in the right direction.

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 Smiley)

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.

(the latter type being like template-programming in C++)

Have I made it totally and utterly obscure yet? Smiley

malloc will be first against the wall when the revolution comes...
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #85 - Posted 2009-06-17 15:31:53 »

Well, that's what I make of it, and it certainly can be implemented that way, as I currently have it just like that.

Yes!

Quote
One nice thing is that you can have a 'ram container' and a 'sql container' and use the one that best fits your Component type, specified in a 'hybrid container'.

YES YES YES! Smiley

malloc will be first against the wall when the revolution comes...
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 799
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #86 - Posted 2009-06-17 15:43:22 »

Sorry - wasn't intended to be patronizing

...

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

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 Smiley)
(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.


Have I made it totally and utterly obscure yet? Smiley
Quite, but I'll just stumble through all my mistakes and see what's best.

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

JGO Coder


Medals: 7


Current project release date: sometime in 3003


« Reply #87 - Posted 2009-06-17 16:59:09 »

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 Smiley. 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?

Endolf

Offline Riven
« League of Dukes »

JGO Overlord


Medals: 799
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #88 - Posted 2009-06-17 17:17:23 »

Well, that's pretty much it.

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.

Code like:
entityContainer.execute(spatialSystem, "WHERE x BETWEEN 50 AND 63");
feels evil.


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
Offline CaptainJester

JGO Knight


Medals: 12
Projects: 2
Exp: 14 years


Make it work; make it better.


« Reply #89 - Posted 2009-06-17 17:31:15 »

First: definitely read Mick's and my articles (and Scott Bilas's stuff too).

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 allows - positively encourages! - limitless recombinations of game-logic to achieve anything you could possibly think of, with *minimal* re-typing by a designer, and *even less* custom programmer code per new combination

* 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  Wink ) 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.

Pages: 1 2 [3] 4
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

BurntPizza (24 views)
2014-09-19 03:14:18

Dwinin (39 views)
2014-09-12 09:08:26

Norakomi (68 views)
2014-09-10 13:57:51

TehJavaDev (93 views)
2014-09-10 06:39:09

Tekkerue (47 views)
2014-09-09 02:24:56

mitcheeb (68 views)
2014-09-08 06:06:29

BurntPizza (51 views)
2014-09-07 01:13:42

Longarmx (38 views)
2014-09-07 01:12:14

Longarmx (44 views)
2014-09-07 01:11:22

Longarmx (40 views)
2014-09-07 01:10:19
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!