[quote=“aazimon,post:100,topic:33645”]
I’m not sure that’s right - it’s the old OO thinking!
If I’m getting ES right, the ‘old’ procedural or OO approach is to think;
‘a game is code controlling a set of data’
but the new ES approach is to think;
‘a game is a set of data which uses code to change itself’.
The advantages of thinking in this new way are enormous! Everything (including logic code) just becomes a set of UIDs - change 1 int and you can change the behaviour of anything. Better still you can easily and quickly find things that were hard to find before (How many trees are near me?, Which players are running away?). With ES these are just easily optimised database queries.
Game state persistence is built right in! Perfect for distributed apps…
I like this idea! I think we’ll see more of ES, especially in more complex games.
That wasn’t OO thinking, that’s attempting to model physical objects in what amounts to a program model - probably where most people fall down with OOP.
OOP is perfectly fine for all of these problems so far described; if you find you need some domain-specific problem solving and you’re a Java programmer, consider modelling the ES implementation problem in OOP rather than the direct solution. In other words, use OOP to write an ES, then implement your game using the ES.
Of course if it’s that complicated you’re probably also using more than three levels of indents, and need spanking.
At the risk of inserting a noob question, can anyone show how (if at all) it could be incorporated in a “game” loop like the following:
`
while (running)
{
// tick something over
something.tick();
// display something to the user
render(something);
}
`
Would what be the “something” that ticks over here? Would it be a single Entity Container, containing everything that has been set up? This would presumably imply that every entity would have a “tick()” method, or some other similar way of updating itself.
Also on a completely unrelated thought process, would other non game world objects like user interface objects be entities too?
Question is: why would you convert a completely simple and intuitive system like that into some newfangled and probably slower and harder to understand system?
I code my games for learning, I’ve never yet finished one, but I hope I understand something about technology or software engineering each time. Playing with entity systems might be fun, and that’s reason enough for me YMMV
Just compare it with Java sourcecode.
If your whole game is in one class, you’re making a (beginners) mistake.
Same thing for XML. Split it, and make references to other XML files.
`
while (running)
{
// Let each system tick
system1.tick( system1components );
system2.tick( system2components );
…
// …or the obvious sensible way to do it instead
foreach( system in systems )
{
Collection entities = getEntitiesForSystem( system );
system.tick( entities );
}
// display something to the user
render( getEntitiesForSystem( getRenderableSystem() ) ); // I'm assuming you do animations inside your Renderables system
}
public Collection getEntitiesForSystem( ASystem system )
{
runSQLqueryToGetAllEntitesMatchingSystem( system.getUniqueName() );
}
`
…or something like that. Typed off the top of my head, and trying to convert into java, didnt bother firing up eclipse, so where there are stupid mistakes try to ignore them
If you want them to be part of the game, yes.
I would advise start off with them as “not”, but you may decide to add them in later. Many games decide to merge UI and game sooner or later.
For instance, lots of games run the renderer in the background of the main menu, showing a simulated bit of game (AI battling it out on one of the game maps, for instance).
For instance, lots of games like to have the UI context-sensitive based on what’s happening in-game: if the UI needs to read the state of game objects, and needs possibly to alter the state of game objects directly (e.g. “set the “selected” game unit”), then it’s generally going to make life easier if the UI can “speak” directly to the entities.
But … for the first time, this is hard enough already, I’d probably aim to keep them separate as long as possible, just to keep yourself as un-confused as possible.
I dig this idea but I’m confused about a few things. The post linked to here from T=Machine mentions that the Flyweight pattern should be used for components (he said this in the context of adding functions to components but since functions are not relevant to Flyweight I assume that he meant the statement to be general). Right below that it says “all data lives in Components; ALL data”…
So I’ve got a component for “Position”. It holds my Entities’ 3D position. For it to be flyweight wouldn’t make sense since it updates its data to what is basically a random value constantly (creating a bunch of instances!). Maybe he was mentioning Flyweight as only for cases where its useful? I would not expect it to be normally useful but I might have confused the whole thing.
I’m also not sure how I could have, say, a Physics component/system, an Animation component/system and a Collision handling component/system and have them coexist safely. I assume that individual systems need to synchronize with one another but aren’t they supposed to be completely distinct? Or is this an “as distinct as possible – suffer through the synchronization” kind of deal. How can three systems (potentially with order dependencies) update/utilize the same entity’s position value?
Finally, the analogy to RDBMS is spot-on. I see the entity idea less as declarative-programming than procedural-programming (which undeservedly got a bad name after its popularity faded). Of course, an OODBMS isn’t usually a bad thing either. If they work for your games needs then switching to db4o or something is smart. I find it hard to use because of its object activation policy and I don’t have serialization bottlenecks so I haven’t bothered but if I did I’d switch DBMS in a heartbeat.
