How should I model an economy-based game in code?

Question

I'd like to create an economy game based on an ancient civilization. I'm not sure how to design it. If I were working on a smaller game, like a copy of "Space Invaders," I'd have no problem structuring it like this:

• Main Control Class
• Graphics Class
• Player Class
• Enemy class

I don't understand how I'd do this for larger projects like my economy game. Do I create a country class that contains a bunch of towns? Do the towns contain a lot building class, most contain classes of people? Do I make a path finding class that the player can access to get around?

Answer 1

Do I create a country class that contains a bunch of towns?

Sure.

Do the towns contain a lot building class, most contain classes of people?

Sure.

Do I make a path finding class that the player can access to get around?

Sure.

Everything you have suggested above seems reasonable. It may not be the best way for you in the long run, but that's fine. It obviously makes sense to you know since it's the organizational model that first came to you. It's important that you take that and begin an implementation from it. It will both get you started, getting you over this initial "design paralysis" that often plagues developers at the beginning of a task, and (if it proves to be flawed in some way) teach you a thing or two about the pros and cons of that particular approach to design.

You've naturally taken the concepts in your head and grouped them into code according to some simple rules:

• Does this concept differ significantly in behavior or in data from other objects I already have? (Countries and people share very little, if any, meaningful data or behavior, so they should be represented by distinct types in-game).
• Will I even need to manipulate this concept in the code in a significant fashion (if your game deals with individual people, you may need that Person class, but if the game only cares about them in the aggregate, as in earlier versions of SimCity, you may not need that type nor instances of that type to create a 1:1 mapping of a town's population. int populationCount may be enough).
• Does this concept require state? If so it should be encapsulated somehow that allows me to store this state (a class) rather than a bunch of free functions. (A pathfinding implementation doesn't have an analogous real-world object, but it does require keeping track of data such as which nodes in the map it has already considered, and that is better done through a class than by storing it in a bunch of hidden globals and making freestanding functions).

While simple, answering those questions can benefit you a great deal when trying to decide if and how to transform a mental concept into source code. You may also want to read up on the SOLID principles of object-oriented design.

Note that the suggestion of an entity/component system made in the comments is also a valid approach, though I would eschew it here unless you re-scope your project to be smaller (simply because taking on two new, large challenges in one project may be too daunting and may dilute the educational benefit you would otherwise receive from focusing only on one). In a component-oriented model, the "type" in the questions above becomes more implicit: not the concrete type in code, but the implicit type defined by the collection of components that form an entity. The same guiding principles can apply.

Answer 2

What you have described (a class for every main type of logical game object) makes perfect sense for as simple game. If this is your first time writing a game of this type, I would suggest doing it this way.

Just a couple of tips:

• Is a Player really different from an Enemy? A lot of the functionality is likely to be the same, so these should normally be the same class or extended from the same base class. Consider an AbstractPlayer base class with two subclasses HumanPlayer and AIPlayer - all the common functionality can go in AbstractPlayer.
• Prefer configuring objects with composition rather than inheritance. Don't make your inheritance hierarchies too deep. If you start calling a class ForgeWithSteelAnvil then you should be worried: A Forge might be a subclass of Building, but the type of anvil used should be an object contained within the building.
• Likewise prefer properties that enable you to configure objects rather than adding hundreds of slightly different object classes.

In more complex games, there are more advanced techniques you can use, but I suggest not using these until you are very comfortable with the basic OOP approach (i.e. have made a couple of completed games successfully). More advanced approaches might include:

• Prototype based object models - use a single class for all game objects, and model all your objects through properties / attributes and composition. Much more flexible/dynamic than standard OOP, but trickier to manage (in particular, the compiler won't help you much if you do something stupid). I used this to good effect in my little Roguelike game Tyrant (https://github.com/mikera/tyrant)
• Entity component systems - good if you have lots of complex behaviours that you want to mix and match in many different types of game objects. Very powerful, but hard to get right.

Answer 3

There are few methods that you can use to approach organizing your entities and data sets. I prefer to write a spreadsheet document and test data moving back and forth to make sure I am being efficient. If you are making the game yourself remember that it needs to make sense to you. Sometimes the most efficient route is to be slightly less efficient in code to make the project simpler.

If you want to have more help on structuring your content then find a old game source code that uses a similar structure or style and find their solution. Then refine it and fix it to your liking.