2
\$\begingroup\$

I'm currently developing a small game, that includes spell casting. My class structure looks like this: enter image description here

AbstractSpell

enter image description here

AbstractDamageSpell

enter image description here

AbstractClickableSpell

enter image description here

AbstractClickableDamageSpell

enter image description here

"Clickable" means that the user has to hit a key followed by a mouse click. Some spells don't need that extra mouse click (like Windwalk). As you can see, AbstractDamageSpell and AbstractClickableDamageSpell have the same properties and methods. Is there a better way of extending these classes? Any hints in general?

\$\endgroup\$
1
  • 2
    \$\begingroup\$ This question is a little too open-ended ("better" is somewhat subjective, there's no way to know what the correct answer is, and asking for general hints is not a good fit for a Q&A site). I really want to answer this, but this site is not the appropriate place for such kinds of questions. You might try gamedev.net, or rephrasing to ask a more concrete and specific question. \$\endgroup\$
    – Sean Middleditch
    Commented Oct 8, 2013 at 15:46

1 Answer 1

Reset to default
6
\$\begingroup\$

Several suggestions come to mind.

I feel you may have gone a little inheritance happy. While inheritance is a great tool, sometimes all you need is a little more customization of a single object.

First, a component system seems to jump out as a good candidate. Then you'd just have a Spell class (or perhaps something even more broad, but that's not necessary to explain the process), and components that you attach to it, like DamageComponent or ClickableComponent. When the spell is cast, the manager responsible for it would cycle through the components to determine how to interact with it.

If you're not too familiar with components, or feel like you'd like an approach in between a standard OO approach and this, you can give your Spell members like m_pDamageComponent and m_pClickableComponent and have the value NULL indicate that they aren't relevant, and use the object it's pointing to otherwise. Actually, if the behavior is simple and consistent, there's no reason it needs to be encapsulated. Those can just be booleans.

I can elaborate on any of these suggestions if necessary.

\$\endgroup\$
8
  • \$\begingroup\$ Thanks! Are there any tutorials for components? I come from PHP and didn't hear about these. \$\endgroup\$
    – Chris
    Commented Oct 8, 2013 at 15:55
  • \$\begingroup\$ Yeah. You'll see a lot about components here. GameDev has lots of huge fans of the component model. Here's a good article motivating its use: richardlord.net/blog/what-is-an-entity-framework \$\endgroup\$
    – TASagent
    Commented Oct 8, 2013 at 16:48
  • \$\begingroup\$ The key thing to keep in mind is that Entity Component systems are not really Object Oriented design. Some people love it, and some people hate it. I've always preferred an approach that combines more traditional OO design with the use of components, but that's not for everyone either. \$\endgroup\$
    – TASagent
    Commented Oct 8, 2013 at 16:49
  • 1
    \$\begingroup\$ Evolve Your Hierarchy is the usual article to point new people to about components in games. ECS != component-based design. "Traditional OO design" doesn't really mean anything in this context; a good component architecture can be a better example of the OOP paradigm than most inheritance hierarchy messes. :) \$\endgroup\$
    – Sean Middleditch
    Commented Oct 8, 2013 at 21:19
  • 1
    \$\begingroup\$ @Chris: I would just note that a component-like approach to spells is not quite the same thing as what most of the existing articles and frameworks are all about (which almost exclusively focus on component usage for game objects rather than "support objects" like spells). I think the key concept that component approaches focus on you should take away here is the data-driven design aspects (use a more flexible system focusing on the interfaces and implementations of discrete spell effects and then use data to compose full spells from those pieces). \$\endgroup\$
    – Sean Middleditch
    Commented Oct 9, 2013 at 17:14

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .