Timeline for Inheritance vs Composition
Current License: CC BY-SA 3.0
14 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 30, 2014 at 15:50 | comment | added | Daniel Revell | Assuming you meant ECS and not CBE??en.wikipedia.org/wiki/Entity_component_system | |
| Oct 29, 2011 at 12:31 | history | edited | Engineer | CC BY-SA 3.0 |
added 60 characters in body
|
| Oct 3, 2011 at 20:00 | comment | added | Engineer | @CC Ricers (see also my comment above). A combination is also possible, eg. Your RenderBatch class might hold a list of PreRenderTasks and a list of PostRenderTasks (and other for eg. intermediate processing, too). In a sense, you could still call this composition, although with lists, the line begins to blur. | |
| Oct 3, 2011 at 19:54 | comment | added | Engineer | Composition is used when the combination of roles (read: distinct interface implementations) at runtime cannot be known, and there are many such roles. Your suggestion will make sense only if your composing members are roles -- i.e. if said members are not interchangeable with one another eg. Pre- and PostRenderTask. If interchangeable, all you need then is one sequential list of rendering tasks to process; in this case, any one could be swapped with another and work equally as well. Here they implement the same interface, and so do not serve distinct roles. Each one is just a RenderTask. | |
| Oct 3, 2011 at 19:33 | comment | added | ChrisC | Should entities not directly related to game logic also be componentized? I am currently working on a shader system that can link various "rendering tasks" for complex rendering techniques. Currently they all extend from an abstract RenderTask class, and objects inheriting from it have unique functions and setups related to the task at hand. | |
| Sep 1, 2011 at 18:33 | comment | added | DampeS8N | It is worth noting that this doesn't mean that all your Weapon types shouldn't implement an interface. Just that WHICH weapon type an entity has shouldn't be defined by the entity extending the Weapon. This also places more emphasis on having a proper set of factories (objects or mothods), as you no longer can create new examples of an enemy by creating a new one. | |
| Sep 1, 2011 at 11:52 | comment | added | Jonathan Connell | Surprises are fun, but surprises that mean you die without warning, like a low level ship that can OHKO you, are just frustrating ;) Of course this may not be what you meant in your answer. Also, there is much more to a game than just game design. | |
| Sep 1, 2011 at 11:35 | comment | added | Engineer | If surprises are bad, then Moria/Angband is one of the worst-designed games in existence. Yet it's been actively played & developed for 30 years. No, surprises can be a lot of fun... as can failure due to those surprises, evidenced by the stories players tell about their ignominious defeat in Dwarf Fortress. It's the folly, and the unexpected, both in life and in games, that is the spice. | |
| Sep 1, 2011 at 11:22 | comment | added | Jonathan Connell | Should also be noted that the "but when you get in range suddenly you realise it has a big-ass wormhole gun. Surprise surprise!" is bad game design :D | |
| Aug 31, 2011 at 20:08 | comment | added | James | Should be noted that due to the high inter-reliance of game entities that inheritance often complicates things and makes maintainability and extension a cumbersome task. Component systems tackle this problem nicely and the other additional benifit is what is listed in the answer above ;) | |
| Aug 31, 2011 at 19:15 | comment | added | John McDonald | +1 Thanks for the article, I've been meaning to do this in my game for quite some time | |
| Aug 31, 2011 at 18:09 | vote | accept | Peter Short | ||
| Aug 31, 2011 at 18:09 | comment | added | Peter Short | Thanks for the advice mate :) Nice to know I wasn't hearing voices! | |
| Aug 31, 2011 at 17:34 | history | answered | Engineer | CC BY-SA 3.0 |