Of course, but I don’t think anyone claimed anything to that extent in this thread? The original touched CPU processing speed in regards to component/system design; certainly it doesn’t make any guarantees about how often the screen redraws.
When developing for mobiles, I’m assuming everyone has (alternatively wants) a few lower-end devices to test on.
Edit: Ok, I kinda did hrm.
Just in case I wasn’t clear: 100(60/200) = 30% of the GPU budget is consumed for a 60Hz target if you add something that runs in isolation at 200Hz. FPS is a useless and misleading measurement. Peoples brains work well on linear data and the 1/x nature of FPS requires stopping and thinking about it.
Doesn’t matter what your talking about or where the computation occurs.
In any case I’m a bit perplexed by the use of an entity system and then coming up with problems… rather than the other way around. I had thought that the problems would be driving the development of a solution. I must be old fashioned too.
Cas 
The problem isn’t so much with entity systems per se, but with the Artemis entity system’s way slicing things makes some things easier, but a few things harder compared with a more traditional entity system (the Artemis website clearly states that it’s a bit of an experiment to see if this alternate way is better or not).
As I said before, I think entity systems solve more problems than they introduce, but if you’re happy with other (equally valid) approaches, then that’s fine too.
Since as far as I know you’ve not used a traditional entity system, nor have you used Artemis, and you’re happy with what you’re already doing, why are you grumping up a thread about comparing the two?
The reason I’ve been grumpy that past couple of days is because I did a code review for an ex-boss of mine for his current project which is circling around the toilet bowl. If you look at the code from a high level…it looks nice and clean. If you look at the individual parts, well they all look nice and clean as well. But if you actually think about the problems its supposed to be addressing, then it’s one big WTF were you thinking?? Modern computer science “methods” and writing are completely and utterly full of shit. They all claim that there are a limited number of choices and that code comes first. It inverts sound methodology. Code comes last.
My view is that it is. Component based is a solution searching for a problem. . I cannot fathom why anyone thinks it useful. Take an RPG. Why would a monster in an RPG need to be able to contain a “banking transaction request” or a “phone book entry”? Code to the statistically significant. Think low-level, write high level. Problem comes first, then potential solutions. If no solutions are desirable, then change the problem statement. Solution dictates data. Then the final bastard step-child afterthought is the code which transforms the data.
Then this is not the thread for you, sorry.
We have lots of threads on the merits (or otherwise) of entity systems, or you can start another yourself. This is not that thread.
Well, going back to your original post, there’s still some relevance…
[quote]I’d like to start a discussion on how people are currently using entity systems, and how they’re structuring them.
[/quote]
One (valid) answer is that people are not using entity systems, and the reason is, they solve problems you never really had, and created a bunch more problems for you. Although you say “inheritance heavy” in your OP… I’ve hitherto generally got away with just one layer of inheritance mostly in OOP (an abstract Entity, and then a few derived classes describing broad interaction mechanics between them, eg. Player, Bullet, Gidrah). It’s simple… it’s fast. I don’t have to spend time on forums asking how to do things right. (You don’t either, you’re worldly wise and experienced). So we’re left wondering what you could possibly be doing that merits the brain-ache? (“I want to drive to London! But instead of buying a car I’m going to assemble one out of different parts first!”)
Cas
I’m actually not attempting to enter into the debate of component based or not. You ask a question: Do I do “A” or “B”? I’m saying that’s the wrong question. The correct question is: “Here are my requirements (ATM)” What options do I have? By arbitrarily settling on “A” or “B” you’re placing the importance of code before your requirements.
I read the question as - even if a bit vague - this is my higher level design, and what are some common, general approaches to these set of problems. It’s no different than asking about approaches for avoiding heavy inheritance or other issues that are common to a specific domain.
@princec One layer of inheritance takes a lot more of skill/experience and forethought to pull off - code quality tends to degrade over time (I’m working in an 18 y.o. product - I stare into its perplexing depths every day); ECS’s flat hierarchy tends to be more resistant to that. As Orangy Tang said, it also makes it more feasible having several programmers working on the same code without getting in each others way.
Personally, I find ECS to be very intuitive - it lets me focus on the problems and scales very gracefully from a complexity POV (which was [the/a] primary reason for their being, not cache-friendliness - as is often brought up nowadays).
As much as I like ECS, the video in that page is right. You have to know when to stop splitting. What is worse is that it is totally game dependent. Doing a system like this for tic-tac-toe is just overkill, but it sort of works for organizing modules.
ECS has a lot of similarities to multi-threading. There are some instances where splitting things up really makes things easier. There are others where you’d just be creating vomit. ECS is a smaller form of data threading, but you still have to make sure you take full advantage of your hardware. For the games I’ve programmed, I never went past Artemis. ECS works well improving modules, but fails at connecting them.
Games just contain too much logic to take advantage of this. We just don’t use data trees enough to get the power data driven architecture like ECS gives. In games, ECS will always be overkill because let’s face it, not all aspects of a game is data. We just use data to assist logic structures. In logic and gaming, the fastest path is always the best one. Sorry entities, but your piping path takes too long…
If feels like the prickly and gooey people have a hard time persuading the other kind why their point-of-view is the right and just way. Now I feel like waging a war on tabs vs spaces… which is counter to Watt’s point, but I feel so very gooey right now.
I utterly cannot parse what on earth you’re trying to say here. It sounds like you’re making the usual mistake and focusing on ECS as cache-optimal design, and not from a general architecture/organisational view.
I think he’s trying to say that much of “games” is about “rules” rather than the data that those rules manipulate but it’s a bit hard to understand
Orangy, how about you describe your current game to us?
Cas
Sure. The basic concept is 2d elite-lite with local multiplayer. Fly around a procedurally generated galaxy and shoot stuff. And some other special stuff that’s secret right now 
My initial annoyance came from trying to sync all of the floating asteroids in the galaxy across the network. A naive component solution involves a component that tests if the transform has changed, and if it has replicate it over the network. Obviously this spends a lot of time doing redundant checks. Additional annoyance - ideally objects near the player should be updated more frequently to use network bandwidth more efficiently. Right now I’ve a crude coordinate hashing thing doing that, but crowbarring in some kind of quadtree would certainly help.
A more traditional entity system (ie. non artemis), or even a non entity system approach would be much simpler by entities pushing themselves onto a ‘dirty’ list when their position is changed, and blatting through that every frame. That’s harder to do cleanly within artemis without violating some of the constrains - either components have to become non-dumb, or things like the physics system have to become aware of the network system and push change notifications between each other. These are not terrible things, but highlight a wider issue where a ‘pure’ approach leads to less efficient behaviour.
An additional snag is that gameplay-wise I have to sync all of the objects because the player can see them all of the time - think always-on mini map which spans the whole galaxy (it’s more complicated than that but that would be too awkward to explain fully).
One thing that’s become apparent is that people write components in very different ways:
huge monolithic components that are basically just like their original pre-ECS entities. Minimal changes to wrap your head around, but misses the benefits of combining logic components in interesting ways. Still gets you good stuff like easier editor integrations etc. though.
Chunky components that handle their logic and communicate with other components in defined ways. Nicer to combine but quite a change that seems to take people at least a few months to wrap their heads around and do properly.
Thin, data-only components and aspect-like systems that updates some combination of components based on what’s present (or not) in a single entity. Great for really breaking things down into tiny pieces of logic and making dependencies super-explicit (and avoid a lot of the config problems of 2) but makes communication between components and systems hard (without resorting to flags and polling).
Components as ids into external systems. Tends to happen a lot when integrating some 3rd party library - physics being a good example. The component becomes a proxy for the actual data (possibly just an id/pointer) stored in an external system. Nice because the external system doesn’t really know/care about the component system, and the rest of the game gets a nice clean component interface to interact with.
1, 2 and 4 are largely interchangable within a single project, which is awesome. But 3 very much expects a different data model so it seems not really compatible with the first two approaches. Often I think discussions about ECS tend to be very polarizing because people have either decided one way is the ‘best’ way, or don’t even realise the other ways exist. Similarly I wonder how many people have been turned off them because they’ve been exposed to one style and assumed all other ECS are like that (in particular the artemis / style 3 approach is hugely off-putting on first encounter and requires a pretty huge mental shift in approach).
Some spatial portioning sounds like a really good idea.
No. The player needs to see what he/she expects to see. That’s quite different.
Massive overkill. Where’s the actual simulation being performed?
Unless there is extreme cases of gravity, couldn’t non-player objects have a bit of prediction. This type of simulation is probably better handled on the server end with clients only polling where objects are and predicting client side where they will end up. Not really an ECS problem, but more of an efficient data transfer issue.
As for what I was saying, it was just that ECS is very effective on trees with many leaves. Like say, character classes in an RPG, where one weapon can have 5 attributes and each adds a different art piece to the weapon. However, ECS isn’t as effective if you needed to attack, as if a monster was split into many body parts you’d need to calculate the effects to each part.
Most of the time, we just don’t use trees in gaming enough to get the power of this organization. Modularization is the best tool and probably the only way we have to effectively use ECS. In your game, I’d just simplify the simulation so only coordinates and prediction can be used for accurate representation* of the entities.
No need to poll. If you have a server then it runs both the full and predictive models and therefore “knows” when a client needs an update. UDP the reference data when needed and client ack’s and some client side smoothing…done.
The devil’s in the details though, eh
Sounds like the client only really needs any kind of timely update for things within some sort of reference distance… everything else can be sent at much longer intervals and either just smoothed or warped into position when not actually in the FOV.
Even so I’m still wondering what an ECS is useful for in this scenario.
Cas
I’ll get back to the other replies in a minute (they need proper thinking about), but:
ECS is giving me a lot of options for making new world entities very quickly. For example a planet is made from these components:
Entity
An asteroid:
Entity
And a player ship:
Entity
I may have sliced these too finely - as I said this was a bit of an experiment in using Artemis.
Absolutely. And I was thinking that myself while typing…but not enough information to attempt to go into details. And yeah limiting clients to potentially interesting set and only transmitting new members and updates for existing is all good.