Jump to content
  • Advertisement

cranberryq

Member
  • Content Count

    7
  • Joined

  • Last visited

Community Reputation

120 Neutral

About cranberryq

  • Rank
    Newbie

Personal Information

  • Interests
    |programmer|
  1. cranberryq

    What's a room?

    An NPC entity might get constructed like this... [/quote] Thanks! Somewhat reassuring in that I saw exactly what I expected to see.
  2. cranberryq

    What's a room?

    Thanks for the sources!   I'm curious... Can you show me an example of entity construction under this system? In the T-machine variant of ECS (which is the one I'm looking at right now), construction ends up being something like:   auto e = Entities.create(); e.addComponent(Position(...)); e.addComponent(Renderable(...));   Typically with some kind of internal logic in addComponent that registers the entity with interested systems. The idea of components remaining private to systems appeals to me far more than the basically duck-typed, expose-everything, share-everything T-machines approach.
  3. cranberryq

    What's a room?

    OK, got it.   Is there any documentation on this formulation of ECS? I realize it's basically a different way of doing the same thing, but there are always important subtleties that emerge sooner or later. One question that arises is that if the components themselves are inside systems... Is it actually possible to create entities without knowledge of specific systems? In the "components live outside and are just data" formulation, the components are directly specified by whoever's creating the entity, without any specific knowledge of which systems will eventually process the components.
  4. cranberryq

    What's a room?

    I see. This is certainly something I've been considering. I have a fair amount of experience in programming language design, type systems, formal verification, etc. In those fields, you generally start from the smallest possible formal model that you can get away with and only add something if there is absolutely no possible way you can avoid it. As such, I've been thinking about an ECS implementation in the strictest possible terms. That is, the system has entities, components (data-only), and systems. Communication between systems is achieved via an event bus, and the assumption is that systems automatically have compatible entities registered and deregistered on creation/destruction/component changes. Sharing of data between systems is discouraged. If you think extending this model with this kind of partitioning is worth it, then I'll certainly look into it.
  5. cranberryq

    What's a room?

    I wasn't passing judgement.   I'm well aware what constitutes a room. My problem is that I've never implemented anything using an ECS before and am trying to find conventional solutions to specific problems of data sharing and communication when dealing with a strict ECS.
  6. cranberryq

    What's a room?

    I suppose the behavior as described doesn't require entities themselves to have references to the rooms they're in. Note that the AI system does require access to room data both for attacking entities in the current room, chasing entities across room boundaries, and for plotting paths that may span multiple rooms.   I'm not really convinced, however, that your proposal really addresses what I asked. I phrased the question along the lines of "should rooms be entities?" because it highlighted something that I've not seen addressed in any of the literature on ECS systems online. That is, long-lived data shared between systems that isn't associated with any particular entity. In particular, I've read that the idea is to eliminate this as much as possible in the interest of reducing coupling between systems.     Regardless of how the rooms are represented, I think we agree that they at least do have a representation...     So the individual rooms may have unique identifiers? Because, presumably, to try to reduce coupling via sharing data, the systems don't actually get full access to the room data structures, just some small aspect of them.       I feel like you may have made my point for me: Rooms do seem to require some run-time representation The full room data structure probably shouldn't be shared between systems, in the interest of reducing coupling and in the interests of good software engineering (data hiding). Therefore, each system that deals with rooms in any form should only be exposed to some small aspect of them Rooms likely need unique identifiers if the full room data is not going to be shared between systems Rooms are created and destroyed at run-time To avoid storing room data globally, the room graph should ideally be encapsulated in a system who's only responsibility is to track entity movements between rooms, and to manage the creation/deletion of rooms. They seem to have all of the characteristics of entities.
  7. Hi.   For the purposes of this question: Assume a bog-standard ECS system. Entities contain a set of references to components, components are pure data, and systems are (possibly stateful) functions that register/deregister compatible entities on entity creation/deletion/update, and are evaluated in a fixed order at a fixed rate. I say this just so that we know we're all talking about the same thing, as ECS means different things to different people.   Let's assume a game somewhat like the old Atari Berzerk:     The world is an undirected graph of rooms containing the player and monsters. When the player moves into one of the room's doors, the player is moved to the connected room in the graph. Let's assume that monsters and the player can move between rooms, and that each room contains some sort of room-specific physics context for performing collision detection and the like (perhaps one Box2D world per room). One physics context per room because entities in different rooms cannot collide or interact physically in any manner. Let's also assume that the rooms themselves can be created and destroyed at run-time (perhaps procedurally generated to some extent).   So, we probably need: a system that's responsible for performing physics updates and collision detection for entities in all rooms, and publishing events when collisions occur a system that's responsible for managing the graph of rooms, keeping track of which entities are in which rooms, and publishing events when entities move from room to room a system that's responsible for running AI a system that renders the room containing whatever is the current camera Additonally, the camera, player, and all monsterlike entities should probably hold a reference to the room to which they currently belong.   This raises a lot of questions! It seems as though the four systems will end up fairly tightly coupled and need to share long-lived data that is not tied to any particular entity (and therefore won't be in components and is not appropriate to be shared via events). The system managing physics needs to know about the current set of rooms, because it has to run physics updates for those rooms that it considers active. The AI system needs to know about the graph of rooms when planning paths that span multiple rooms. The rendering system needs to know about rooms to some extent in order to render the contents of a room. The room system obviously needs to know about rooms because it is the authority for the graph of rooms and is responsible for tracking entities and creating/destroying rooms. Each of these four aspects are fairly distinct, however. Are the rooms themselves entities? They have a similar lifecycle to entities, multiple systems need to update their own internal state when rooms are created/deleted, and it seems like at least some of the above could be implemented by giving entities that represent rooms a RoomComponent (that may be completely empty) and having systems maintain their own state keyed on the ID of each registered entity that has a RoomComponent.    
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!