Jump to content
  • Advertisement
Sign in to follow this  
LAURENT*

Many enemies, many classes.... no?

This topic is 1088 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

 So, I have a question about C++. Let's say that I have an enemy class for a game. I want to be able to have (in theory) an infinite amount of enemy types in my game. So I would have to have multiple arrays, one for each enemy class? Is there a better way?

Share this post


Link to post
Share on other sites
Advertisement
Have a generic game object class that lets you attach a behavior to it. Then store an array of GameObjects for your update loop. If you need a behavior to be able to access a specific game object, such as an enemy needing a reference to the player, then simply tag the player game object. and allow enemies to look up game objects by tag.
 
// forward declaration
class GameObject;

class IBehavior
{
  public:
    virtual void Update(GameObject* target, float deltaTime) = 0;
}

class GameObject
{
public:

private:
  string mTag;
  IBehavior* mBehavior;
};

class EnemyBehavior : public IBehavior
{
public:
  virtual void Update(GameObject* target, float deltaTime);
}

You may consider generalizing this further to make IBehavior be a base class of IComponent where components can do anything from game logic to rendering. Instead of having a single IBehavior per game object, you would have an array of IComponents per game object. Edited by HappyCoder

Share this post


Link to post
Share on other sites

ECS systems also lead to some neat things you probably haven't considered. I remember reading a blog post from a company called knucklecracker where he made a heat seeking missile using A*, which was a pretty standard idea. However, he also made a wormhole-like teleporter that units could move through. When he was testing one day, he realized that if he opened a wormhole, then shot a heatseeking missile, it could fly through the wormhole to find units as well, which wasn't the intended behaviour (But was pretty cool).

Share this post


Link to post
Share on other sites

Frob's explaination is very good. You can actually take the ECS a step further. Instead of an "Enemy" class, I use an "Actor" class. It's used for players, NPCs, enemies, and anything else that moves or acts.

 

Actors contain movement methods which are linked to calls to animation. Depending on what the Actor actually is,  "ShooterInput" for shooter-types AIs, "FollowerInput" for followers, etc are attached. Then I have a static "PlayerInput" class which can target any actor. (which disables it's attached AI)

 

The biggest perks to this is, if i retarget "PlayerInput" over to another Actor, the player than then control that actor since they all use the same interface. So as a result, I can "possess" other actors, or control turrets, control vehicles, etc.

 

There's obviously limits to its usefullness, such as the player controlling a landmine. The landmine's movement is zero, jumpheight is zero, rotation is zero, and its FireWeapon() method just makes it explode :-)

Edited by SirWeeble

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • 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!