Best way to go about random object generation?

Started by
7 comments, last by Amrazek 16 years, 10 months ago
The title is a little obscure, but I'm trying to find out if there's an easier, more extendable way of going about creating objects. The situation is this: I have an object that generates planes at random. Currently, it only generates one type of plane -- EnemyPlane. Now, EnemyPlane makes a great generic class and what I'd like to do is make a few of its members virtual and have subclasses of EnemyPlane, which will create planes with different behaviors. There's a problem, though: ideally, I'll have several subclasses of EnemyPlane (as an example, let's say I have AccurateEnemyPlane which shoots bullets aimed at the player instead of straight down the screen, or MissileEnemyPlane which fires missiles instead of bullets, etc). Now, my Generator class needs to be able to create these planes in a more or less random manner, and I was hoping that there might be a better way of doing this than my first thought:

// just pseudo-code
switch (planeID) {
   case 1: // regular plane
       // create a regular plane here
       break;

   case 2: // accurate plane
       // create accurate plane
       break;

   /* etc */

}

Not only is doing this tedious, it seems rather unextendable. If I wanted to add a new plane type, I'd have to manually edit the code every time. Any suggestions on how to avoid this? Or should I just bite the bullet and go for it anyway? Thanks!
If I put my 2 cents in and get a penny for my thoughts, where does my other penny go?
Advertisement
I think the easiest way to do this would be to use the random number generator functionality of whatever language you're using.

What's the language? Perhaps we can provide you some resources. If you're using C++ for example, head over here:
http://www.fredosaurus.com/notes-cpp/misc/random.html

Basically, you can generate a random number, and if it's within a certain range you select one type of plane over another.

So the switch would be similar, but instead of determining the type on the plane's internal ID you could determine it based on a randomly generated number. Whatever it chooses, you make a new instance and place it in the world.

Hopefully this helps. Let us know what you're using and we can point you to some more specific solutions for your particular programming language.
- Edgar Verona"But when a long train of abuses and usurpations, pursuing invariably the same Object evinces a design to reduce them under absolute Despotism, it is their right, it is their duty, to throw off such Government, and to provide new Guards for their future security."
[google] "Factory Pattern".
What you're looking for is known as a Pluggable Factory, and you should read up on that. However, you seem to be assuming that creating different Plane subclasses is the best way to model different plane behaviors. It's not. Consider that your plane can be accurate or inaccurate; can fire missiles or bullets; can have propellors or jets; and can have retractable landing gear or fixed landing gear. Right there that's sixteen classes to have to code up, with huge amounts of duplicated code. Yikes.

Instead, you should be delegating each of these independent bits of customizability to different properties of a single Plane class. A Plane should HAVE a PropulsionType, which could be a JetPropulsion or a PropellerPropulsion. It should also have a Weapon, which could be a BulletGun or a MissileGun. etcetera.

Read this.
Sneftel's right. I think what you're looking for is something similar to the composite pattern. Make weapons objects, targeting logic objects, propulsion objects, etc. Then, allow a single plane object to be able to have these different components.
Quit screwin' around! - Brock Samson
Minor nitpick: The "composite pattern" is a very different thing from composition, yet another poor choice of terminology on the part of the GoF.

Composition sounds like it's exactly what I'm looking for, but I'm a little fuzzy on how to go about implementing it.

So I should have a concrete class called EnemyPlane, and then EnemyPlane will have pointers to pure virtual classes (which are generic in nature, like WeaponSystem, EngineType, etc), which are then subclasses into concrete classes?

Then composition is a matter of creating instances of the subclasses?

class EnemyPlane {public:     /* constructor, member variables ,etc */private:   WeaponSystem* myWeapon;};



class WeaponSystem {   virtual void fire() = 0;}



class MachineGun : public WeaponSystem {   void fire() { /* implementation */ }};


Is that roughly the correct way of doing it?
If I put my 2 cents in and get a penny for my thoughts, where does my other penny go?
That's pretty much what I'm getting at. Going about it this way, you can add weapon, engine and AI components without ever having to change your EnemyPlane class.

There's many ways you can go about this depending on what your needs are. I'd imagine that you want each plane type to be rendered differently so a single concrete EnemyPlane class may not be the best solution. One solution may be to have different child classes of EnemyPlace that set their pointers to the correct objects upon initialization. Another approach may be to make them more data-driven (which may also add a lot of unnecessary complexity). Using factory methods may help as well but, like I said, it all depends on your needs. There's no need to make things more complicated than necessary. At least going this route should allow you flexability.
Quit screwin' around! - Brock Samson

Actually, I think this will do quite nicely :)

Thanks for the help.
If I put my 2 cents in and get a penny for my thoughts, where does my other penny go?

This topic is closed to new replies.

Advertisement