Jump to content
  • Advertisement

mrimamister

Member
  • Content Count

    6
  • Joined

  • Last visited

Community Reputation

126 Neutral

About mrimamister

  • Rank
    Newbie
  1. Also, I was wondering how you could make use of contiguous memory when a system makes use of sets of different types of components as this seems to be the case for most systems, especially if you slice the components into smaller pieces?   For example: RenderSystem takes Position { x, y, depth } and RenderInfo { mesh, texture, shader } CollisionSystem takes Position { x, y, depth } and CollisionBox { width, height, x_offset, y_offset } MovementSystem takes Position { x, y, depth } and Movement { vx, vy } ...and so forth...
  2. I never said anything about composition or an ECS not being OOP, it's why I emphasized "traditional" OOP. I do agree with your point about balancing complexity and flexibility and creating a game instead of a game engine.   I have a few questions about this implementation:   1) How would I go about interdependency between components without something like a component mapper? E.g. physics, rendering and player behaviour need the transform component, I could pass the transform in the constructor of the mentioned components when adding them to the game object, but as soon as I decide to change a component (e.g. PlayerMovementBehaviour to AIMovementBehaviour) the transform needs to be passed to the new component. (I guess that the problem of the order in which components update can also play up here).   2) Going with the example above (physics, rendering and player behaviour need the transform component), the definition of what a component is becomes a bit vague, transform is a component but all its operations are handled in other components? Would that mean it's a good idea to have a distinction between 'behaviours' and 'attributes'?   3) If I implement the GameObject class to just contain a container of ambiguous components, how would I identify components (to for example change PlayerMovementBehaviour to AIMovementBehaviour) without something like a component mapper.     Also, I want to release a game, and learning how to do it is a great bonus (so it'll get easier in the future). I also want to have a lot of fun programming it (which working with an ECS isn't really so far). I honestly couldn't care less about having to do it in a specific way as long as I get to code it myself.    Much appreciated!
  3. The thing is that once you assume that behaviour can be defined by parameters/properties, you basically go back to composition. For example if you have AI behaviour in say the 'Basic Enemy' class (which most likely other enemy classes will inherit) and then later you later decide you want the player to also be controlled by an AI (e.g. 'demo mode' when the main menu has been inactive for a while). You could make a base class AIEntity and make both the basic enemy and the player inherit that (obviously very bad because you'd just end up making a blob(?) class as an easy fix) or you could (more likely) say "hey, in that case let's just give the player a property IMovementBehaviour which can be set to say PlayerBehaviour or AIBehaviour at runtime". All good, except when you repeat these steps a dozen times and come to the conclusion that a lot of behaviour should be changable in runtime. That leads to classes without any implementation and with just a bunch of behaviour interface properties which is essentially the same as a CES.   This is of course based on a lot of "what if"'s but I never developed a game before on a relatively large scale, and I'm sure a lot of things will pop up during the development, it doesn't really seem possible to know exactly how everything should behave from the beginning. Am I just overthinking it? 
  4. Thanks everyone for the great replies, this has definitely been very educational!           Could you elaborate on the alternatives? Although I'm writing this system partly to educate myself on how an ECS works (on a lower level than Unity), I am serious about developing my game and have thought before that this may be a bit overkill (I'm developing a 2D rpg with tile maps). I've tried developing games before using 'traditional' OOP, by which I basically mean just a bunch of inheritance trees, and I've seen it turn out really nasty (multiple inheritance, duplicate code, different classes with only slight differences). I never actually tried to use 'normal' composition (e.g. Player has 'IMovementBehaviour', 'IRenderBehaviour', IXBehaviour properties) but I came across this thread: http://gamedev.stackexchange.com/questions/34625/composition-heavy-oop-vs-pure-entity-component-systems Here someone explains how even if you do take the latter mentioned approach, you still end up with empty classes that just contain a bunch of components (back to ECS). (The only difference I see in the example in the link is that components also contain logic, which isn't part of the 'traditional' ECS approach, and I can imagine that interdependency between components can become a problem)   EDIT: grammar
  5. Hi phil, thanks for your response, there are some things I'd like to ask about some more.     Would this mean I make these classes a non-singleton and just pass references/pointers to whoever is using them? (e.g. EntityManager has a pointer to SystemManager that it sends messages to on add/remove component). Even though it seems a bit cleaner, it does mean that whenever you decide to make use of what-would-be-a-singleton, you'd have to go out of your way to add it to the constructor (or even worse: add getters and setters).       What confuses me about this is if you store the components as say IComponent* or void*, how would that solve the issue of accessing contiguous memory? This is actually why I thought it would mean you'd have to couple back the code because when a system requests say a 'Position' component, the EntityManager would still have to iterate through the components to see which one is a 'Position' component. Unless you store all types of components in their own respective container (e.g. vector<Position> position_components <-- accessed by entity index/id). But this would couple back the code again because you'd have to create a new container for each new component that an entity could possibly have.     EDIT: Your suggestion about the camera entity sounds like a good idea! But how would I go about making sure only one camera can be active at a time (without making use of a global state)?
  6. Hi everyone,   I'm working on making an Entity Component System in C++ for my game and there are some things I'm a bit confused about. Right now my game is structured as following: Entity: Contains an unique id and a bunch of components, only accessible by using a singleton EntityManager. e.g. int EntityManager::createEntity() void EntityManager::addComponent<T>(T* t, int entity_id) T EntityManager::getComponent<T>(int entity_id) Component: Simple 'databag' structs without any methods, just simple data. These are stored in entities using the above mentioned EntityManager as void* (and using typeid::hash_code to compare the requested types at get/hasComponent). System: Derived from 'ISystem' with only two methods 'onUpdate' and 'onMessage', and stored in a SystemManager singleton. When a component gets added or removed the systems get a message containing the entity id, so they can (un)register to it. Is this the right way of doing this? I read some things about getting a lot of cache misses if you don't store components in a contiguous array but I can't imagine how to do that without coupling back the code again. (So far I haven't noticed any performance issues, though there's not a lot running right now).   Furthermore, these two problems have been bothering me a lot: 1) It seems like a good idea to use separate rendering systems (e.g. SpriteRenderer, ShapeRenderer, TilemapRenderer) but how do I take care of things like sorting (depth, shader, texture) and batching when these systems are completely decoupled?   2) The camera, I've searched far and wide for a good answer but I can't seem to find one. Is the camera an entity? If so, does that mean the view matrix is a global or singleton? (What if I want multiple camera's with only 1 'active' like in Unity?). This is assuming that the camera transformation gets applied at the rendering process, otherwise I guess it'd be possible to have like a 'CameraSystem' which translates all objects opposite of the currently active camera position, though that seems slow to me. Please enlighten me! Thanks in advance my dear gamedevs!
  • 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!