| Sunday, December 31, 2006 |
  Generators and Towns | 
Posted - 12/31/2006 12:29:06 AM | I have posted the first of experiments here. The white dots are towns and the green dots are content generators. Click on them to see what is what. The yellow dot in the center is the main town for the game, with which I have not yet done anything.
In the completed game the generators will not have a "physical" presence; they exist only to provide origin points for the various trade goods.
The towns and generators are not yet really talking to each other. I hope to take a first pass at something a little more realistic during the day on Monday. What better way to start the new year than with a little coding?
| |
| Wednesday, December 27, 2006 |
| Avoiding Repetition | |
Posted - 12/27/2006 6:18:41 PM | In my game engine I am trying to have most, if not all, of the content created procedurally. This means lots of reliance on pseudo-randomness or seeded random number generators.
This also means that, when creating a list of names, avoiding duplicates can be kind of tricky.
My game has fifty towns with names based on the names of towns in Ukraine near the shore of the Black Sea. I broke the town names into prefix, root, and suffix pieces, then explored ways to re-combine them to make an arbitrary number of unique names.
Here are the prefixes:
<prefix>
<n>Novo_</n>
<n>Dobro_</n>
<n>Velkyo_</n>
<n>Ljubo_</n>
<n>Mala_</n>
<n>Kryva_</n>
<n>Stari_</n>
</prefix>
Here are the roots:
<root>
<n>Valentyn</n>
<n>Soskar</n>
<n>Cebryk</n>
<n>Kalyn</n>
<n>Blakoj</n>
<n>Stepan</n>
<n>Dmytr</n>
<n>Zvir</n>
<n>Lukash</n>
<n>Kater</n>
<n>Levk</n>
<n>Taras</n>
<n>Oleksandr</n>
<n>Lozuv</n>
<n>Vytjaz</n>
<n>Percun</n>
<n>Pavl</n>
<n>Voron</n>
<n>Yelzav</n>
<n>Zachar</n>
<n>Janys</n>
<n>Oleks</n>
<n>Mychajl</n>
<n>Pozn</n>
<n>Vojnyc</n>
<n>Most</n>
<n>Zovtn</n>
<n>Borys</n>
<n>Strjuk</n>
<n>Lukan</n>
<n>Natas</n>
<n>Zereb</n>
<n>Lebed</n>
<n>Fedor</n>
<n>Scasl</n>
</root>
Here are the suffixes:
<suffix>
<n>ivka</n>
<n>ynka</n>
<n>anka</n>
<n>evo</n>
<n>ove</n>
<n>ovate</n>
<n>ajka</n>
</suffix>
7 Prefixes, 35 roots, and 7 suffixes. And therein lay the second of my problems.
The first problem was as follows: I was using the initially generated random numbers for the towns as seeds for their names. I took the seed number and did a modulo 50 (%50) to determine the new seed for the names. This worked well enough, but I came up with many duplicates, because more than one of the random numbers would have the same result of the modulo (e.g. 768%50==18, 29418%50==18). Therefore, many duplicates. Since the initial numbers were for all intents and purposes random, I was left with going through the array of town names every time a new town was generated and making sure duplicates were re-calculated. This bothered me for two reasons:
1. If I want to use the engine for a large (e.g. 10000 towns) world, I would have to go through a rapidly growing array 9999 times to make sure avoid duplication
2. A town shouldn't have its own name constrained based on what another town is called. In other words, the towns should not be aware of each other.
So using seeded numbers was out the door. However, each town also has an index number (0 - n) which is unique for each town. This was a little more promising. All of my mental models seemed to work, so I whipped up some code and looked at the result.
Even more duplication! In a list of fifty towns, almost 20% of them had the same names. Unacceptable.
So I went back through my model and discovered something: The theory worked perfectly! It was the data set that needed a little tweaking.
Look at the three parts of the names: three lists, 7, 35, and 7 words long. Among those numbers, the Least Common Multiple is 35, and the Lowest Common Denominator is 7. Using these numbers I got a repeat period of 35, which meant 15 duplicated names out of a list of 50 towns. Almost 20%!
As a quick experiment, I commented out one of the root words, which left me with a number set of 7,34,7, which has a LCD of 1 and a LCM of 238. With that one change I suddenly had nearly eight times the number of unique usable names available, and they were all predictable!
I don't know if this is the best way to go about creating lists of names like this, because it requires constraining the data set to match a numeric quirk of the generator; it is, however, easy to debug and has a very low impact on the processor, as compared to going through a list of a thousand words a thousand times.
Nest: Putting this knowledge to use in the creation of individual town content.
| |
| Tuesday, December 26, 2006 |
| Starting Over Again and Again | |
Posted - 12/26/2006 3:59:03 PM | Here I am again, back at the beginning.
The game I wanted to build for the Four Elements competition went nowhere, due mostly to me being a bum and not working on it; either due to no time, or no interest in staring at a computer.
So now I have a little time, and a little more energy, so I am going to pick up where I left off before (at the very beginning) and try to build something.
I am starting with what I am calling, for lack of a better term, an "economy engine". This will populate the different towns in the world with a variety of trade goods, set the relative availability and values of those goods, and then control the availability and price based on world events. Right now I am starting with having availability fluctuate based on the month of the year. For instance, grains are more readily available (and therefore less expensive) around harvest time. Wolf pelts will be more common in the winter, when hunger drives the wolves to hunt closer to human habitation.
The data structure of an individual trade good looks like this:
<item
name="deer hide"
weight="4"
volume="2"
base_value="5"
base_availability="30"
availability_dropoff="5"
price_increase="3"
lifespan="100"
origin="-18,0"
peak_month="November"
category="clothing"
/>
Here is what the attributes mean:
name : The name of a particular trade good
weight : weight of one unit of an item
volume : volume of one unit of an item
base_value : unmodified value of one unit
base_availability : unmodified likelihood of an item being available for trade
availability_dropoff : how quickly availability of an item drops off at increased distance from the point of origin. If this value is "0", then the product is equally available everywhere.
price_increase : how much the price of an item increases as a function of rarity
lifespan : how long an item will last once purchased. Think of food spoiling
origin : the location of the "generator" of an item. This provides for localization of products, thus making them more trade-able.
peak_month : At what time of year is the item most easily available? The corollary to this is that, at the opposite end of the year the item will be at its rarest.
category : What "type" of item is this? Food, metal, clothing, luxury, and the like.
The first step in this project is to get the towns populated with trade goods. Once I have that sorted out and balanced, then I will add the cyclic ebb-and-flow of availabilities and prices.
My chosen medium is Macromedia Flash, so as I solve problems I will post examples and code. I hope to have a game engine completed in time to use it for a game in the next Four Elements competition.
| |
| hi all! | |
Posted - 12/1/2006 4:25:59 PM | I just wanted to pop in and say congratulations and Good Luck to all of the participants of 4e5.
I was with you in spirit.
| |
|
| S | M | T | W | T | F | S | | | | | | | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | | | 28 | 29 | | 31 | | | | | | |
OPTIONS
Track this Journal
ARCHIVES
November, 2009
March, 2009
January, 2009
November, 2008
October, 2008
September, 2008
August, 2008
July, 2008
February, 2008
December, 2007
November, 2007
October, 2007
September, 2007
July, 2007
June, 2007
March, 2007
February, 2007
January, 2007
December, 2006
August, 2006
July, 2006
June, 2006
|
