I'm try to make a small 4x game for my own educational purposes.

Currently I have interfaces like IStarSystem which contains a list of IPlanets. My next step was to make classes implementing those interfaces. Is it better to make classes like BarrenPlanet, GasPlanet, et cetera or is it better to make a single Planet class and define the different types in a XML file?

  • 1
    \$\begingroup\$ Hi, welcome to the site. This is a Q&A site and not a discussion forum, and consequently you should only ask one question per thread to ensure you get the best answers. Since your follow-up questions were also extremely broad and discussion oriented (also a bad fit for this site), I've edited them out to focus on your main question. See the FAQ for more. \$\endgroup\$
    – user1430
    Commented Aug 13, 2012 at 16:10
  • \$\begingroup\$ What's a "4x game"? (Our routers are having a problem with Google.com atm. I'll try Binging it.) \$\endgroup\$
    – jcora
    Commented Aug 13, 2012 at 18:23
  • \$\begingroup\$ I found it, in short, an RTS game with a lot of depth. "Explore, expand, extract, exterminate." \$\endgroup\$
    – jcora
    Commented Aug 13, 2012 at 18:25

2 Answers 2


In general, it will be better for you to take an approach that doesn't senseless create complex inheritance hierarchies. It does not sound, from the limited information you've provided, that barren versus gaseous versus normal (et cetera) planets different so significantly that they warrant their own unique types. It sounds like these are all properties of a single Planet class.

Consequently, you should go with your second approach and create a single Planet class that can be configured by way of its properties (which you can load, as you noted, from XML or some other data store).

Because there is no need for unique types per planet type, this approach will be much more maintainable if only by virtue of having fewer types and thus less code to maintain.

  • \$\begingroup\$ Thanks for your answer and I thought your right, thanks for the advice. \$\endgroup\$
    – Sebastian
    Commented Aug 13, 2012 at 17:50
  • \$\begingroup\$ Design-wise this also has benefits. If your game is 3D, you can with 2 spheres and 4 textures, create planets that range from small barren moons all the way out to gas giants. The 2 spheres are a terrestrial under-layer with a gas layer above that grows more or less transparent as it gets thinner or thicker. The terrestrial core can be barren, have green splotches of various transparency, and have blue splatters over it. (rock, plants, and water). Thus you can create all planets we know of. And with color shifting, can change the sky, rock, water, and plant colors. \$\endgroup\$
    – DampeS8N
    Commented Aug 13, 2012 at 18:05

Thanks to this question, I now know what 4x stands for, so thanks :)

Anyhow, I would say no, but it depends.

I think a classic example of classes is cars. Cars have several properties (color, make, model, weight, whatever suits you...) and several methods - say, gas, break.

Now, in the programming representation, if you were to, say, create a bunch of cars that share a certain set of properties and don't add more, then you would stick to a single class. For example, if cars had only a color and no other properties unique to each, then you would want one class. But if a specific car has special properties/behaviors - let's say, some cars can transform into some flying thing and some cannot. Flying objects will have different properties then the normal one, and so a new derived class is appropriate.

IF you think about inheritance, the general concept is, the base class is what they all have in common. Derived classes each need to differ in some respect.

So consider your planets. If each planet has, say, only a texture, position, rotationSpeed, and nothing else - then you can just craft different planets (like different colored cars) from this one class. On the other hand, if planets have special properties or methods, then you could make special classes for each planet, though they should still have SOMETHING in common and thus inherit from a Planet class. For example, if the gas planet can explode, dissapear, or has new fields (say, something about the atmosphere), then you can make a specific class for it, assuming a BarrenPlanet cannot do the same things.

In conclusion, it depends, but from what I can gather you could get by with a single Planet class (choose based on your circumstance, though), and as Josh said, needlessly adding a bunch of specific Classes with the inheritance will just make it confusing.


You must log in to answer this question.

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