Devana how a browser game is made

21Nov/1021

the economy

I've finished the database structure for the economical part of the game; that includes module construction, resource management and various costs and requirements.

The multilingual system now includes a database side for the game assets localization. All asset names and descriptions will be stored in the labels table.
The labels are identified by type (numeric value that identifies which asset type it represents), id (asset id) and language (language id defined in each language's file in the languages folder).

Each faction has max values for how many nodes and modules (per node) one player can have. The faction type is assigned to each node.

Nodes have a lastCheck value, defined as a datetime type which indicates the last time the game has calculated the resource production values and other queue related calculations like module construction, unit training, ...

Modules are divided into types, based on what function they will have. The main mechanic is that modules require a static resource type, a resource type that cannot be produced, but exists in finite quantity. Think of modules as machines that require energy to produce stuff; where the energy is the static resource type, and the "stuff" is the dynamic resource type. Dynamic resources can be stored.
Each module requires an input (the static resource type), a maxInput value and a ratio. The ratio is an unsigned floating point number that defines the output based on the input using the following formula: output = input*ratio; the output is a "per hour" value.
The game determines the output type based on what entry the "module" column one resource type has.
0 is for static resources, while any other unsigned int designates the id of the module where that resource is to be produced.
Resources also have a max storage value.
The dynamic resources are stored as values in the resource_storage table, per node, and per resource type. And yes, static resources do not have entries there.
Free static resources are determined by the following formula: their maxStorage value minus all input values from all modules that require them as input.
Modules slots are stored in the module_slots table, with an assigned value for the module's required input. These entries are defined per module and per node.

Costs are stored in the costs table. The costs are defined per type (module, item, unit, ...), id (be it moduleId, unitId, ...) and faction. Each entry has a (dynamic) resource type defined and the value of that resource type required.
One can define costs as being comprised of 1 or more cost entries; 1 for each required resource type.
Example: there will b 3 entries in the costs table if the sword item costs 3 lumber, 5 steel and 10 gold.

Requirements are stored in the requirements table. The requirements are defined per type (module, item, unit, ...) and id (be it moduleId, unitId, ...). Each entry has a value associated to it depicting the id of the required type.
One can define requirements as being comprised of 1 or more requirement entries; 1 for each required requirement type.
Example: there will be 2 entries in the requirements table if the barracks module requires the blacksmith and mill modules.

And here's the sql structure: economyStructure

Filed under: devana 21 Comments