I'm new to game programming and currently trying to understand Entity Component System design by implementing simple 2d game. By ECS I mean design, described here for example

In my game I have different kind of weapons: automatic, gun, grenade, etc... Each type of weapon has it's own affect area (gun shots along the straight line and grenade explodes and covers some spherical area) , damage impact, visual effect and bullet amount, delay between shots. So I don't completely understand how to implement weapons. Should weapon be an Entity or it should be a component? And how the player should pick up a weapon, switch between different types of weapons and etc.

  • 6
    just don't try to force a design just because it sounds cool, you probably don't need it with your simple game, and my opinion you should start with simpler appraoch. Just try to get sth on the screen and try to get your game running – concept3d Nov 2 '13 at 22:20
  • You'd likely want to make the weapon an entity. I don't see a problem with entities equipping other entities. You can easily have an inventory component that stores entities as well. – MichaelHouse Nov 2 '13 at 22:20
  • 1
    This is kind of just a design decision you should make for yourself. It's something that only you really know the answer to because you're the one designing the game. – MichaelHouse Nov 2 '13 at 22:35
  • 3
    ECS are a difficult thing to get a handle on until after you have some traditional architecture experience. ECS are not perfect, the architecture is a reaction to deep OOP designs that are horribly flawed and while ECS fixes many of those OOP problems they also require some advanced knowledge to set up and use. Spend time and let the game itself tell you how it wants to fit together. Spend some time with Unity or Unreal, both have a component based portions, to see how they make it work. – Patrick Hughes Nov 2 '13 at 23:43
  • 1
    @PatrickHughes I totally agree that what I was trying to say in my first comment. – concept3d Nov 3 '13 at 1:22

In ECS everything is broken down to components that describe functions.

  1. A weapon is a physical item so one component will be a physical position. If it is on the ground or thrown at an enemy (sword / throwing knife) then you need the physical position component to decide if it was picked up or hit something (e.g. wall or monster). When a weapon is held you can use the physical positional component of the owner. A physical component is important because it helps us keep in mind that a weapon does not have to be held to be useful (mines for instance and gun towers are an example).
  2. A weapon is sometimes a container. It contains an Ammo entity. Some weapons could contain different types of ammo for different effects. Some weapons can be enhanced or enchanted so you may or may not need another container for such buffs.
  3. A Weapon is a factory. It creates moving projectiles or AoE zones that collide and affect mobs.
  4. A weapon can sometimes deteriorate (as in Diablo) so it may have a health component.

So this is how I would define a weapon:

Factory component, Container component, Physical (position & velocity) component and health component.

In my book, an entity is something that takes part in the simulation of the world. In that category belong all visible game objects, but also logical entities such as trigger areas.

A weapon does not take part in the simulation of the world by itself. Unless of course the weapon is dropped in the world and thus becomes a pickup item. But a weapon held and used by an entity is not an entity itself, it is an entity attachment. Think of the weapon as being part of the entity's inventory, with effects - ie it changes the entity's visuals, the type and amount of damage it can do, and so on.

So a weapon clearly changes the behavior of an entity and can be replaced, too. That makes it a component of the entity rather than an entity by itself.

  • Yes, but the weapon could also be view as an entity in a game where e.g. you can pick up and use all the items in the world - it'd be easier to have subentites than to convert entities to components and back again. – Polar Nov 2 '13 at 23:18
  • I think this is debatable. One issue I see is that while in the world the entity will have different components than when it's in the inventory (or they need to be enabled/disabled accordingly). Having a different class of entities (ie "Items") may help to differentiate between active (entity) and inactive (item) entities. An item can hold a reference to an entity, so when it gets dropped the entity is added to the world, while the item gets added to the spawned entity as its "item representation". This is a swap procedure, meaning the entity changes its "mode". – LearnCocos2D Nov 2 '13 at 23:25
  • Also it would allow either item or entity to be discarded and recreated as needed, especially in low-memory situations. Otherwise it will be difficult on the visual side to differentiate between the entity representing a world object (perhaps textured 3D model) vs representing an inventory item (perhaps a 2D texture). – LearnCocos2D Nov 2 '13 at 23:29
  • 2
    @Polar: weapons are typically totally different objects when they're dropped in-game vs in-inventory in any game, whether it uses inheritance trees or ECS or some more flexible variant of component-based design. If you think of a GunData object, that can trivially be copied between an inventory list and an GunPickupComponent. Once in-inventory, the gun will typically no longer have a model (and if it does, it's usually a very different model), will no longer have physics/collisions, won't have a fade-away timeout, etc. – Sean Middleditch Dec 2 '13 at 23:51
  • @Sean Ignoring the fact that this was posted a month ago, that's a fair enough point. I was thinking more along the line that your inventory was part of the world (if that makes any sense at all) - e.g. all of the items in your inventory, or at least some, were rendered with your character to 'increase realism'. – Polar Dec 3 '13 at 0:25

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.