Version 8 (modified by pmccormack, 4 years ago) (diff)


Further rationale for object-oriented design decisions so far:

Most game sprites are button-like (they have a hovered state, and perform some action when clicked). Therefore, we have an abstract Button class that generically handles those type of methods.

For the policy-related buttons on the right side, we have a PolicyButton class that inherits from the Button class, and TaxButton, TariffButton etc. classes that inherit from PolicyButton. Each policy button needs its own class because each button will have different code for clickAction, unclickAction, hoverAction, etc.

Resources, represented by icons on the Map, also inherit from Button. As individual resource types don't have specific code, the type of a resource is an attribute of a Resource object. Countries, which are represented by town centers on the map behave the same way. Paul will code the AI and economic model within the resource and country modules, while I (Stephen) will continue work on the UI and make sure that the code the modules Paul works with conform to the same stylistic and idiomatic standards present in the ui and other modules.

Our ui module has a Window and an InfoBox class, along with the PolicyButton-derived classes. Button is in its own module because it is used on the Map as well. Our map module contains the Map class, and our country module contains the Country class.

A Window object has a pygame sprite group containing the policy buttons, an InfoBox? object that gets passed to buttons (so that they know what InfoBox? to update), and a Map object. The Map object contains a pygame sprite group of the resources and countries (which are represented by town centers). This modular design will allow Paul to work on the mechanics of the model (in the Map class) while I work on the UI. It is also flexible and designed to allow the game to be saved (by pickling the Map object and saving that).

Instructions for running:

To get python+pygame on windows, install the following in order:

On OS X Lion, install this:

Simply checkout the repository and run


With a few exceptions, our prototype revealed that our game concept is both desirable and feasible for the limited time frame we have. Already, we have almost all the art completed, and the user interface buttons appear and react to mouse actions appropriately. In addition, the underlying economic model begins to take shape by creating resources, creating countries, determining supply curves, and creating trade routes between countries based on policy and market forces.

In developing the prototype, several issues in initial plan were revealed. We implemented a simplified version of the desired economic model. In doing so, we had to make it more concrete than we had previously. We discovered that, instead of solving all the mathematical equations exactly, it was more efficient to discretize the process of creating trade routes between resources and countries. For example, instead of determining exactly how much wood Country A imports from each supplier, the function iteratively tells Country A to purchase a little wood at the lowest price it can find until it reaches its consumer demand. Eventually, all countries will find the most economically realistic good distribution without having to consider each resource’s supply curve.

In addition, our domain model specified that the Country class should manage internal resources and other Map elements. However, to centralize the economic model to one class, we decided to put the automatic trade route creation in the Map class. The Map class then also creates the countries and resources.

Finally, our disparate styles and knowledge of coding in python plagued the development of our prototype. Issues we faced range from tab/space errors to variable name conventions to cyclic class definitions. As we struggle to correct current errors, we know that future mistakes of the same variety will be less common.

Attachments (1)

Download all attachments as: .zip