The following is specific to my problem, but I believe the principles can be applied to any game.

I am currently working on a 3D game which will have many different types of spaceships. The physics and behavior of the spaceships are controlled by a base 'Ship' class. This base class in turn derives from a 'Drawable Object' class which handles the transformations and drawing of the ship.

I want the spaceships to have a set of stats such as

  • Max speed
  • Cargo capacity
  • Weapon power
  • etc

that can be passed into the physics and behavior functions.

However, during gameplay new spaceships will be able to be bought/upgraded, but i want to be able to pre-define a (possibly large) list of setups that will be available to the player.

What is the best way to store the available stat setups?

Should I be using a large JSON/XML file or similar to store the stats which is loaded at runtime? Or might I just as well hard-code the stats into the constructors of a set of derived classes?

The actual physics attributes (location, velocity etc) and its stats of a particular spaceship are being saved to file when the game is actually played.

I have researched about entity-component-system architecture, but I haven't found much about how to define these entity stats.

Any advice on improving my entity architecture would be much appreciated - this is one of my first attempts at hobby game development.


closed as too broad by Josh Apr 10 '15 at 16:52

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • \$\begingroup\$ JSON/XML is a good way to save your data, and it's going to be easier to edit them than having them hard-coded in your ctors (because your content-creators would not be able to change them). Your current approach of using inheritance is much against the entity-component-system philosophy and opens up the door to some shooting yourself in the foot. \$\endgroup\$ – Alexandre Vaillancourt Apr 10 '15 at 12:19
  • \$\begingroup\$ @AlexandreVaillancourt Should I instead be using a 'ship' class that has a 'drawable object' class as a field? I'll do some more research and maybe look at re-structuring my entity classes. \$\endgroup\$ – user60130 Apr 10 '15 at 13:51
  • \$\begingroup\$ At the core of the entity-component, you'd have an entity id, with components that would represent a ship, components that represent visuals, and components that represent physics. So there would not be a "ship" class, only a "ship" system that would update ships logic. Having a 'drawable object' in a 'ship' class is the first step instead of having a 'ship' object deriving from 'drawable' because what if you have ships that are off-screen? \$\endgroup\$ – Alexandre Vaillancourt Apr 10 '15 at 15:42

Having the ship stats in an external file would likely be a lot easier to maintain.

  • You can modify values without having to recompile your game binary
  • When you are working in a team with non-programmers, these can be taught how to edit these files on their own and contribute to the game balancing. It might even enable them to add and remove ships without help of a programmer.
  • When you pick the right format, editing the values will likely be a lot more convenient because of less language syntax around the actual values (this problem can be better or worse depending on what programming language you use. For example, when you use Javascript, a JSON config file and a file which initializes an object with fixed values is exactly the same thing)