Technique ยท Updated 20December 2005, by Jason
This section describes the each major step as the program developed.
UPDATE 22> OctoberIneterface-8 is up. This update only changes the rule that measures each dwelling's distance to the closest amenity. Now this scoring mechanism returns the average distance to the nearest amenity, instead of all the dwellings' total distance. The result is a city no longer penalized to grow, and fuller, larger cities.
UPDATE 21> OctoberIneterface-7 is active.
This update fixes the following bugs...
1.) The amenities reported to the screen in the "SCORE" box were miscalculated.
This bug was fixed and now both the boxes with the letters in them and yellow
circles, and the numbers in the "SCORE" box are a function of the population
of the city.
2.) New amenities no longer are created randomly across the screen. Instead,
the function that places mini-Towers and high-Towers near city centers is
also a utility function that other parts of the program can access. This
allows the amenities to be placed by the same function that places the towers.
After the 200th generation, amenities switch from being placed randomly
to being placed near density.
3.) The density utility used to just look for dwellings and find the densest
area of homes (town homes and towers). Now it scores amenities equally with
town homes, and applies bonuses to towers.
4.) Amenities are more stable now, and don't appear and disappear without
cause. This was because of a misplaced "+1", which is now properly placed.
UPDATE 20> OctoberInterface-6b's code is up. As we talked about, if these rule's corresponding buttons on the interface are unchecked, then these rules return a score of zero. This means if just the "Townhouses w/ Zero Neighbors" and the "mini-Towers w/ Zero Neighbors" buttons are checked, the following rules all have 1/6th weight in the score of every generation's city...
new RuleMakeAmmenities(),
new RulePreferSpecifiedBuildings(),
new RulePreferSpecifiedPeople(),
new RulePrivateNearAmmenity(),
new Rule_TOWNZERO(),
new Rule_MINIZERO(),
... and by un-checking the mini-Towers neighbor Rule button all 5 remaining rules return a 1/5th weight score. This increases the potency and influence of the remaining rules.
UPDATE 19> OctoberInterface-6 has a replacement.
OctoberInterface-6b amends the problems with
UPDATE 18> The program appears sporadic over hundred-generation runs, and the cycles that the score swings through appear to be related to the "Distance-to-an-Amenity" rule. Since amenities appear and disappear so quickly, I think the affect on the score wildly changes in a few generations. The program selects houses that are close for several generations, then it disappears and those houses are a long way away from the next amenity.
UPDATE 17> The code for exporting images every 2nd, 5th, or 10th generation is now in OctInt-6. We can make huge folders of .tff files, and use Quicktime Pro, we can compile the movies at any frame rate. I'm going to investigate where this function exports the files before turning it on. By running it on other computers, we risk junking the hard disk up with hundreds of 1400x800 pixel tiffs per use.
UPDATE 16> OctoberInterface-6 is up. This program includes the FAR rules for mini-Towers and high-Towers, which become operational when a user checks the FAR buttons in the interface. There is a pressing need to tackle the problem with amenity reporting to accurately understand why they sweep in and out so unpredictably.
UPDATE 15> OctoberInterface-5 is up. This tackels the problems with the "densest plot" problem in OctoberInterface-3, and presents a more elegant solution. To model upward pressure, it adds one or two mini-Towers and high-Towers at every generation. The place these are added will be randomly selected, but with the following odds. The selected plot will be inversely proportional to that position's radius from the center of the "densest plot". So a victim of upward pressure 2 blocks away has a 1/2 chance; 8 blocks away is a 1/8 chance, etc. The blunt code for the radius is below -- called twice (once for the X, and once for the Y values of the upwardly pressured structure to be chosen)...
int pseudoRandom(){
float test = random(100);
if(test < 20){return 1;}
if(test < 35){return 2;}
if(test < 50){return 3;}
if(test < 60){return 4;}
if(test < 68){return 5;}
if(test < 75){return 6;}
if(test < 81){return 7;}
if(test < 85){return 8;}
if(test < 88){return 9;}
if(test < 90){return 10;}
if(test < 92){return 11;}
if(test < 94){return 12;}
if(test < 96){return 13;}
if(test < 98){return 14;}
else{return 15;}
}
UPDATE 14> OctoberInterface-4 has been posted. This update has the added rule to select for homes near an amenity. (It's always in effect from the moment you hit "Start Breeding") Remember now there are upward to 10 rules contributing scores, which are averaged into the overall score.
UPDATE 13> Here is OctoberInterface-3. This was the first attempt at a City-Center styled algorithm for adding mini-Towers and high-Towers, and it adds the towers as follows...
(1) Find the densest area by citizen population. It samples 5x5 plot through
the city and remembers the densest.
(2) Randomly choose the first of five structures in that 5x5 plot that aren't
already high-Towers.
(3) Roll a five-sided dice.
(4) If a one or two comes up, change the townhouse to a mini-Tower, or a
mini-Tower to a high-Tower.
(5) Repeat steps (3) & (4) for the other four structures chosen in step
(2).
This should work; it might choose the same 5x5 plot every time. If that's the only problem, the program is in pretty good shape. Random mutations should delete mini-Towers and high-Towers if the "People-slider" is backed down.
UPDATE 12> The decision of what algorithm to use to instantiate new buildings in our "growing" cities presents a crossroads. At issue is whether or not amenities, mini-Tower and high-Tower elements should be introduced in populated and amenity-rich areas ["designed in"], or, should each new element be allowed to mutate into cities at randomly selected plots ["accidentally placed"].
At stake is what kind of model each decision tends towards. The "designed in" model purports to create whole cities in macro scale. These cities could quickly being to have city-centers, perimeters, satellite cities, and unintentional emphasis could be throw toward a gestalt-ist view of the object as an organism. In contrast the "accidentally placed" random distribution of new elements might tend more towards a homogenous fabric, where larger patterns could be allowed to form. Emphasis would then fall on the specific, repeating adjacencies, and the larger patterns they produce, as a description of urban fabric.
Recognition is placed on the breeding rules to tend these instantiation strategies toward the same result. One could select for satellite cities or sprawl in more robust models.
UPDATE 11> An updated October-Interface-2 is up. The model has the citizen population dictating the amenities, not the structure coverage. The numbers used for critical population masses are as follows (#f is a data type for the value #)...
float popTable[] = {
/* BLANK PLOT OF LAND */ 0f,
/* LIBRARY */14678f,
/* SUPERMARKET */2500f,
/* RESTAURANT */1000f,
/* FIRE STATION */3400f,
/* POLICE STATION */ 7900f,
/* SCHOOL */6923f };.
UPDATE 10 > October interface added.
Resolved.
1. The new interface from Update 9 is installed.
2. The Citizen Target Slider & (red line) Citizen History Graphs are working
-- Rules read global values.
3. Amenity ratios from the interface effect the (still random) distribution
-- Rules treat slider value as universal variable.
4. New scoring system -- all scoring rules in effect all the time -- the
interface's buttons toggle "0" or tallied scores for all Townhouse, mini-Tower,
and high-Tower individual rules.
5. The breeding algorithm now clones the "parents" into the first five positions
of the future generation -- this should prevent worsening scores.
Not Resolved.
1. Should new housing prefer amenity-rich areas?
2. The amenity radius feature is working, but should look like a doughnut.
3. The FAR buttons need to have an effect - should we draw the effect to
the screen?
4. An algorithm should introduce mini-Tower and high-Tower elements - Anything
is better than the random distribution criteria used to date.
5. Topographic selection criteria haven't been determined -- economic factors
are still distant.
UPDATE 9 > The last Amenity Neighbor program will be the skeleton for additional work.
UPDATE 8 > Web page updated.
UPDATE 7> Wrapping function has been removed, so the city does not tile ad infinitum. The extreme left plots are no longer neighbors with the extreme right plots - this might present a scoring problem later; plots with fewer neighbors will naturally not be able to score as high.
UPDATE 6> Amenities are working. For the second program, the number of amenities is a function of the number of individual buildings - the name is a little misleading. This may not be what we are looking for, once R-6 is introduced. The amenities are placed randomly, however we can look into placing them where land is cheap later. The radius draw will be easier, but to have the selection criteria include proximity to amenities will take some of the weekend.
UPDATE 5 > Web page updated.
UPDATE 4 > First run of the "Two Neighbor Rule" -- Not pretty, but the rule dovetails nicely with models of medieval cities. When we have the time, it would be a fun experiment to model the Roman, Medieval, and Garden City schemes with a few tweaks to the rules.
UPDATE 3> Currently the program crash at 20,000 generations because the history function needs more memory. This is adjustable.
UPDATE 2> History Graphing feature fixed, this afternoon's graphs have been interesting because they don't settle into a local minimum, but at best remain oscillating, or at worst erratically drop. Added the new programs as 70-plot-squared version to old posts.
UPDATE 1> All "Neighborhood Rules" uploaded. Note two things. The code is in to let the cities be 30x30, 50x50, or 70x70. These are reverted back to 30x30 because now there is instability in the evolution of the cities. They settle into a local minimum too quickly without reaching their target structures population. Error-checking for that took so much time and notes that a utility was made to help track details about the evolution of the cities -- the "History" table, which will graph the score, people population, and structures population of the evolving city in 20-generation increments (note that it waits until the 100th generation before starting to graph.)