Jump to content

View more

Image of the Day

Boxes as reward for our ranking mode. ヾ(☆▽☆)
#indiedev #gamedev #gameart #screenshotsaturday https://t.co/ALF1InmM7K
IOTD | Top Screenshots

The latest, straight to your Inbox.

Subscribe to GameDev.net Direct to receive the latest updates and exclusive content.


Sign up now

Creating Enemies

4: Adsense

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.


  • You cannot reply to this topic
3 replies to this topic

#1 Spawn_Kcb   Members   

120
Like
0Likes
Like

Posted 18 August 2014 - 02:21 AM

Hello All,

Another design question here. I am creating enemies in my JRPG and have come to another sticking point.
 
Namely, do you create a single "Enemy" class and then instantiate objects of that type, then load the respective properties from say a flat file or database like "Bestiary";
 
enum EnemyType{
 
Orc = 1;
Goblin = 2;
Skeleton = 3;
DireWolf = 4;
Zombie = 5
}
 
Enemy Orc = new Enemy(EnemyType.Orc);
Enemy Zombie = new Zombie(iEnemyType.Zombie);
 
etc.
 
Or do you create a different sub-class for each type of enemy, and then hard code the properties for that class?
 
Or is it just a case of personal preference? 
 
I hope that all makes sense and thanks for the help.
 
Regards
 
Kevin



#2 ExcessNeo   GDNet+   

619
Like
2Likes
Like

Posted 18 August 2014 - 03:18 AM

It's all down to personal preference really, a popular pattern is the Entity-Component model which is described fairly well in this article.



#3 BlackCorsair   Members   

115
Like
0Likes
Like

Posted 18 August 2014 - 04:00 AM

I normally write a base class with all common properties there and than a subclass for every enemy which allows me to easily modify their behaviour independently.


www.corsairgames.com


#4 haegarr   Members   

7359
Like
0Likes
Like

Posted 18 August 2014 - 04:09 AM

This is a typical problem where composition and data oriented design should be preferred. Reason is that inheritance yields in more maintenance problems due to needlessly deep hierarchies, and design work would be burdening the programmer.






Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.