| bio | website | star-hope.org |
|---|---|---|
| location | United States | |
| age | 35 | |
| visits | member for | 1 year, 5 months |
| seen | Dec 23 '12 at 22:20 | |
| stats | profile views | 18 |
Videogame and simulations programmer.
Lisper, JAPH, and MOS-65xx hacker, among other things.
|
Nov 6 |
comment |
Organizing an entity system with external component managers? If an Entity is a class of OOP object, then typically it has to hold together its Components. This causes all sorts of “fun problems,” particularly with regards to distributed processing, multiple threads, and the like. EG: Entity.GetComponentTypeXYZ() might have to load the component data, or else every component of every entity must be visible in core somehow. |
|
Mar 12 |
awarded | Commentator |
|
Mar 12 |
comment |
Organizing an entity system with external component managers? @Raine, in the case of having data inside an Entity Object, however, one easily falls prey to having to instantiate the object with a cluster of weak references (or similar) to every possible component, which can seriously harm scalability of the system |
|
Mar 12 |
comment |
Organizing an entity system with external component managers? @DavidGouveia mentioned “optimizations…looking up entities by ID.” In fact, the (few) systems I've implemented this way, tend to not do so. More often, select Components by some pattern indicating that they're of interest to a particular System, using Entities (ID's) only for cross-component Joins. |
|
Mar 12 |
comment |
Organizing an entity system with external component managers? In ref: “pure” entity system: the Entity ID is typically something like: typedef unsigned long long int EntityID;; the ideal is, that each System can live on a separate CPU or host, and only require to fetch components that are relevant to / active in that System. With an Entity object, one might have to instantiate the same Entity object on each host, making scaling more difficult. A pure entity-component-system model splits processing across nodes (processes, CPUs, or hosts) by system, rather than by entity, typically. |
|
Dec 28 |
comment |
How do I start writing an MMO game server? Not strictly an answer, but: you should strongly consider starting with a working MMO server framework, and then altering it to your specific needs… |
|
Dec 23 |
comment |
Organizing an entity system with external component managers? There's a pretty good overview series at t-machine.org/index.php/2007/09/03/… et seq. |
|
Dec 23 |
comment |
Organizing an entity system with external component managers? (Sorry for the encyclopædic comments, but:) the problem with a “type” is that an Entity is inherently of any type for which it holds a Component, so you can do GetEntitiesOfType by simply iterating a global list per-Component, which might be on a different host than another Component. The model is relational, like SQL tables — Components map nicely to TABLEs, Entities to PRIMARY KEYs. |
|
Dec 23 |
comment |
Organizing an entity system with external component managers? In a pure Entity/Component system, an Entity is usually atomic: e.g. typedef long long int Entity; a Component is a record (it might be implemented as an object class, or just a struct) that has a reference to the Entity to which it's attached; and a System would be a method or collection of methods. The ECS model isn't very compatible with the OOP model, although a Component can be a (mostly) data-only Object, and a System a code-only singleton Object whose state lives in components... although "hybrid" systems are more common than "pure" ones, they lose many of the innate benefits. |
|
Dec 22 |
comment |
Entity communication: Message queue vs Publish/Subscribe vs Signal/Slots This is also the canonical “definition” of how an “ideal” E/C/S system “should work.” The Components make up the blackboard; the Systems are the code acting upon it. (Entities, of course, are just long long ints or similar, in a pure ECS system.) |
|
Dec 22 |
answered | How common is automated testing in game development? |
|
Dec 22 |
comment |
Organizing an entity system with external component managers? I don't know if perhaps this is meant to be a hybrid system, but it sounds like your "managers" are what I've generally heard termed as "systems;" i.e. the Entity is an abstract-ID; a Component is a pool of data; and what you term a "manager" is what's generally termed a "System." Am I interpreting the vocabulary correctly? |
|
Dec 22 |
comment |
Organizing an entity system with external component managers? Not to be pedantic, but again… in a pure Entity (relational) system, entities have no type, except that imparted to them by virtue of their components… |
|
Dec 22 |
comment |
Organizing an entity system with external component managers? Caveat emptor: at the point at which your Entity contains data, it's an object, not an entity… One loses most of the paralelizing (sic?) benefits of ECS in this structure. "Pure" E/C/S systems are relational, not object-oriented … Not that it's necessarily "bad" for some case(s), but it's certainly "breaking the relational model" |
|
Dec 22 |
awarded | Supporter |
|
Dec 22 |
comment |
Functional reactive programming (FRP) in games. Some doubts and thoughts Essentially, yes, that would be my idea. — In the system I'm building, I actually have each system provide a “filter” function, such that changes to components run through the (hopefully fast) filter function and then get queued into a worker task to be processed if they match its (perhaps approximate) conditions. EG: the graphics system for a certain viewport might provide a super-fast but potentially overly-broad filter to grab anything it "might" see, without having to cull 90% of the world. (Only changes that begin or end within potentially-viewable range are passed into the work task) |
|
Dec 22 |
awarded | Teacher |
|
Dec 22 |
answered | Functional reactive programming (FRP) in games. Some doubts and thoughts |
|
Dec 1 |
awarded | Autobiographer |