Jump to content
  • Advertisement

bovine.genius

Member
  • Content Count

    5
  • Joined

  • Last visited

Community Reputation

108 Neutral

About bovine.genius

  • Rank
    Newbie

Personal Information

  • Interests
    Art
    Audio
    Programming

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Except that if you read my original post again, you'll see I'm basically agreeing with you. I pointed out that what I think is the most valuable part of ECS doesn't require an ECS. In fact, a separate PhysicsSystem is all I was trying to get at, although I guess I went about it in a roundabout way. I didn't say the data should be moved out of entities, but rather that it can be useful to move functionality out of entities.
  2. Of course 2 actors containing physics data can interact, but it's going to require something extra. If you have an "updatePhysics" method on your entity, how does it know about the other entities? It needs something else. You can pass in an array of the other entities I guess, but at that point you've already made things more complicated, because you have to filter out the current entity. In any case, I'm only pointing out that pulling the update code out of the entity class is an easy way to simplify things a bit. I never said it's the only way to structure a game. You don't even have to move all updates out of the entity. It's just a useful design tool. Not sure why you seem to be so upset about it.
  3. Of course they do. By separating code and data, I really meant moving the update code out of an instance method on entities. Maybe it would have been clearer if I had said entities and the code that updates them are separated. The point is that putting an update method on an entity class always ends up in hard-to-solve communication problems, because you need more global knowledge to do the updates. For example, having an update method on an entity that runs the next step in the physics simulation is going to introduce a lot of complexity, because physics engines often require updating multiple entities at once. Having the update function be external to the entities means that you can easily have it operate on all entities without introducing hacks or complex communication systems into the code.
  4. I think the main value of an ECS is actually that the data and the code are separated. The reason for this is that for most actions in a game engine, it's useful to be able to access multiple entities at once. You don't need to use components to get this benefit. You can still have your entities be classes (or even just structs), but you don't put any functionality in them. Then you have a render function that works on an array of entities, and similarly for physics and AI. These are the Systems of an ECS. It doesn't have to be complicated, and you don't have to use components to get the most important benefits of an ECS.
  5. bovine.genius

    Character Animation book

    Game Engine Architecture has a whole section on implementing an animation system, and even discusses things like animation blending.   This might also be of interest, although it is probably more approachable after reading the relevant chapter in Game Engine Architecture: http://www.gamasutra.com/view/feature/131863/animation_blending_achieving_.php  
  • 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!