I'm making a game where at some point the game will create enemies of random types. Each type of enemy available is defined on its own class derived from an enemy superclass. To do this, obviously the different types of enemies should be known. This is what I have thought of:

  1. Just make a list manually. Very simple to do, but I don't like it because I'll be adding more enemy types over time, so any time I add a new class I have to remember to update this (same if I remove an enemy). I would like some kind of auto-updating list.

  2. A completely component based system. There are no different classes for each enemy, but definitions of enemies in some file where all enemy types can be found. I really don't need that level of complexity for my game. I'm still using a component based model to some degree, but each Enemy type gets defined on its own class.

  3. Java Annotation processing. Give each enemy subclass an annotation like @EnemyType("whatever"), then code an annotation processor that writes in a file all available enemy types. Any time a new class is added the file gets updated after compilation.This gives me a feeling of failure even if its a good solution, it's very dependant on Java, so it means I cant think of a general design good for any kind of language. Also I think that this would be too much work for something so simple.

I would like to see comments on these ideas and other possible solutions


  • \$\begingroup\$ At first I was thinking you could do something clever with the factor design pattern, but after some searching I came across this question. \$\endgroup\$ Commented Oct 29, 2012 at 19:41
  • \$\begingroup\$ Go with number two, it's the least messy and most flexible. However, I think that any answer to this question would just be an opinion and you should do what you think is best. \$\endgroup\$
    – House
    Commented Oct 29, 2012 at 20:49

2 Answers 2


Why don't you use 1 & 2?

I think what you're looking for is a Factory with a createRandom method, and you can then register functions/classes from a definition file/data, you still have to remember to update the file but at least it won't need a recompile.

If your problem is remembering to update the factory then a possible solution would be that the enemy class auto-registers it self to the factory and then all your subclasses will have that behavior. This seems to fix all the problems stated in 1.

  • \$\begingroup\$ +1 Make each enemy subclass register itself to the factory, that's the easiest language-agnostic way. \$\endgroup\$ Commented Oct 30, 2012 at 9:34
  • \$\begingroup\$ Registering each class to the factory was the idea I was looking for but somehow I couldn't get that myself. \$\endgroup\$
    – plofplof
    Commented Oct 30, 2012 at 18:10

You seem to be using Java. If so, use its reflection and just scan all classes in your creature package.


You must log in to answer this question.

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