Simplest Sim
The simplest sim is just a sequence. The #ACTOR is looking for #FOOD, and the game inserts a number of progression #STEP between the #ACTOR and the #FOOD. As the #ACTOR walks each #STEP the game prints 'left', 'right'. Once the sequence is fully traversed the game ends.
This simple #UNIVERSE is made more complex with some definitions.
- STEP = 2, #FOOD = 8.
The #ACTOR may progress 2 #STEP costing 8 #FOOD. There is no negative balance, the #ACTOR cannot travel 4 #STEP on 8 #FOOD. The smallest #STEP is 2 (not 1), so all operations result in even integers. The #UNIVERSE ends after 16 steps.
So far so good, altough there are problems with this simple model. The #ACTOR just keep stepping, so lets see what MAY happen.
0xf: ACTOR TAKES 2 STEPS, GAINS 8 FOOD, BALANCE 0 0xe: ACTOR TAKES 2 STEPS, GAINS 24 FOOD, BALANCE 16 0xd: ACTOR TAKES 2 STEPS, GAINS 0 FOOD, BALANCE 8 0xc: ACTOR TAKES 2 STEPS, GAINS 8 FOOD, BALANCE 8 .. so on, so on... 0x0: ACTOR TAKES 2 STEPS, GAINS 0 FOOD, BALAMCE 0
After each step if #BALANCE is at 0 game over. The sequence runs 16 #STEP (F - 0 hexadecimal counting down), but the game might end as soon as STEP 1.
On the design-level anything may be a valid option. The #GAINS could be a roll of a dice between the values 0, 8, 16 and so on. The winner could be:
- the One with most #STEP - the One with highest #BALANCE - the One with most #STEP, highest #GAINS - the One with most #STEP, highest #BALANCE - the One with highest #BALANCE, highest #GAINS - the One with most #STEP, highest #BALANCE, highest #GAINS - the One with most #STEP, highest #BALANCE, highest #GAINS and the highest outcome of (#SOME #FREAKINGLY #COMPLEX #ALGEBRA)
As we factor in more variables such as actors and rules the variations could become quite large. Most times you could approximate by simply multiplying all terms - such as 1 ACTOR * 16 STEPS * 3 GAINS (assumming GAINS maybe 0, 8, 16)
To sum it up even this small example provides a few interesting observations: using only even numbers, scaling by even numbers seems to be a good design concept. The smallest integer should be 1024 instead of 2, so the game dynamics going to have more detailed resolutions. The are a suprisingly large number of victory conditions! The game could be non-starter or end abruply which is a joykill, and so on... Reading and writing this wiki is going provide more of these insights.
When this wiki gets to a point when there is enough content for a wikibook it is going to be published under the tite "Small but Sufficient Simming for Simpletons". After all, in OpenDominion there is only a slight disctintion between a 'user' and a 'developer'. Simming provides crucial proof of concept, verification of results, and when a sim does not work it could be an issue with the game. Yet this wiki must be kept as accessible as possible: If you cannot, or would not bother, explain yourself using high-school-level algebra you should probably be reading or writing a different wiki.
From this point forward we are going to analyse and sim each feature of OpenDominion, guided by the game's interface. The easier ones first - such as the building and terrain types. In this wiki creating a complete overview is going to take precedence over focused and detailed discussion - which are great, but are also limited in scope. A lot of information about the original game is now lost to the ages, and reconstructing whats lost must begin from memory, by intuition and with loads of creativity.
You are more than welcome to contribute, but please keep in mind that all and everyhting written here should help the game, its development, and its players.