LegacyWorlds Beta 6

As the second part of our series around design objectives, I’ll present here the limits we have to put on our imagination to design a game which we can actually write and why this limits exist.

First of all, why do we have to put limits? Some ideas we’ve come up with or some suggestions made by the players community either in the game forums or here in the blog’s comments look very cool and fun. However, accepting these ideas means they’ll have to be integrated into the game’s logic. Internally it means objects will have to be represented in the game database, that is as some row in a spreadsheet-like format with column headers representing object properties and each object having its specific values in each cell of its particular row. It means these values will have to be used to compute a particular effect which means a particular formula will have to be defined for each effect or set of effects. Some of these effects might appear transparent to the player: population grows without him having to interact with anything. However some imply management by the player. The burden we accept to place on the player has to be carefully weighted if we want to cope with our “not too time consuming game” objective.

In this context, a set of general rules can be devised and have to be followed.

The first rule regards genericity. What is meant by genericity? It means that we can’t plan on adding complex rules / a brand new set of technologies / plenty of calculations unless it either has a wide use or is absolutely necessary. Therefore every proposal has to be thought of in two directions:

• what is the scale of the idea compared to the whole game? Is it a big feature or a small side one?
• can it be declined in several versions easily? For instance a law corresponds to two states where different bonuses and penalties are applied to existing game parameters. Dozens of laws can be imagined which all work on the same principle.

In this context, big features which can be easily declined in several versions are preferable compared to small side features which are associated with unique code.

The second rule deals with simplicity. Of course the idea is to stick to reality as much as possible. However very realistic proposals tend to become very complex. It is therefore necessary to evaluate the level of complexity and assess:

• does the feature really bring something interesting to the game?
• as a player, would you agree on spending time to manage this feature as this level of details?
• can’t the feature be emulated by a more generic one without losing any gameplay experience?

A typical example around this topic would be ship cargo management. Of course it would be more realistic to have a fixed quantity of supplies on a ship and when the stock is down to 0 it can’t fire anymore or the crew revolts because they are hungry and the ship has to get new supplies. But it’s getting too complex and boring from a player’s point of view to have to manage ship supplies. Simply considering an upkeep cost and imagining non displayed little ships bringing supplies to the actual in-game ships should suffice.

The last rule relates to completeness.

When stated as a rough description of a general principle, new ideas are very difficult to evaluate by other members of the team. They often build up their own vision of the proposal which might differ from the intended idea and as such might approve or reject something which might end up being unmanageable or on the contrary quite interesting.

As such any first proposal should be as complete as possible. This completeness implies:

• describing the principles underlying the idea as much as possible,
• attaching characteristics to implied objects,
• defining rules which would allow the idea to be put into a working game feature.