You must be logged in to post messages.
Please login or register

Pharaoh: Game Help
Moderated by VitruviusAIA, Gweilo

Hop to:    
loginhomeregisterhelprules
Bottom
Topic Subject: Predicting Roaming Walks
« Previous Page  1 2  Next Page »
posted 03-18-05 10:18 ET (US)   
My university recently replaced the server that was home toAmbulomancy, a little monograph I put together describing what I hadlearned about roaming walks by 2005.   The link to the allnew and improved second (2007) edition of the monograph is here: ambulom2ed.pdf
The document is 197,073 bytes and 29 printed pages long.

Reply 13 in this thread contains additional notes about the new edition.

[This message has been edited by StephAmon (edited 09-09-2007 @ 09:50 PM).]

Replies:
posted 03-18-05 10:21 ET (US)     1 / 29  
The behavior of “random walkers” is not so random.  You can predict it:  not every square of travel from the first step a roamer takes out the front door of his building until he reaches his walk-finish square if there are stub roads and other branches all along his route, but more than enough to be useful.  Roamers are locked onto a fixed path for several squares at the beginning of most walks, and this little bit of certainty often provides all we need (given the seldom-branched roads in our cities) to direct them where we want.  So, if you want to know in advance where the roaming walkers in your next city will go, this article is for you.  With a little crafty tweaking of the roads, you can even make them go where you want.
   Visitors to Pharaoh Heaven who have suffered through some of my earlier articles on roaming walker behavior may be in for a pleasant surprise.  Brugle helped me a lot with Ambulomancy through his critical review of the manuscript.  In fairness to Brugle, however, I must note that I tore up and redrafted the original text that he saw.  So, if any idiocies or inaccuracies have crept back into the paper when Brugle was not looking, he is not too be blamed; I am.  Comparing the two versions, I have to say Brugle’s suggestions have worked wonders.  He unerringly zeroed in on several areas of ambiguity (forcing me back into the walker labs to iron out details), gently steered me toward a more fact-dense and less chatty style, and expunged at least one flagrant error.  Any readers who make it to the end of the article without becoming hopelessly befuddled owe a great debt of thanks to Brugle for his efforts.  I know I do.
   Actually, reaching the end of the article might not be such a problem.  I wrote it while keeping DawnOfWere’s request for a short-ish summary in mind, so the real meat of roaming walk prediction is packed into the first four pages.  Some illustrations of the four types of roaming walks follow, but they come with glyphy and should not present much of an obstacle.  The article ends with a bunch of addenda providing more fine print about issues like ferries, but few readers would be likely to need this stuff right away to get the essential idea of how the roamers work.  One other constraint imposed on the writing of this article should also increase its reader friendliness: no complex coordinates!  So, with these assurances I hope you will read, and enjoy, this little guide for Pharaoh players to the “divination of walks” Ambulomancy.

StephAmon

[This message has been edited by StephAmon (edited 03-18-2005 @ 10:25 AM).]

posted 03-18-05 16:13 ET (US)     2 / 29  
StephAmon,

Reading through it now and it looks good. You and Brugle did an excellent job with it. Don't know if I'll use any of it soon, but would be an excellent tool for "debugging" an errant walker. Always so much more to learn about this game.


“If I could stand wearing an Eagles jersey, I would try to get an old-school Eagles jersey made up with "QB Eagles-0". I think I managed to find the only way to make a football jersey geeky, but there you go.”
-Paul Mazukiewicz

My nation of One-Ballia at NationStates

posted 03-18-05 21:54 ET (US)     3 / 29  
GodOfRandomDeath:

I’m happy you noticed this little guide.  If you ever get a “busted building”, it’ll be here, and it might help.

StephAmon

posted 05-08-05 12:13 ET (US)     4 / 29  
Hello StephAmon,

finally I had the time to study this excellent work - Thanks to you and Brugle.

When I built my latest city (Itjtawy with almost 24000 people), I had troubles with 3 types of walkers, which behaved unlike the described walkers.
The architect, the tax collector and the senet player vanished or wandered off road or through buildings.
So I experimented with the architect.
I built two parallel roads with the length of 70 and 60 Tiles and 10 Tiles in between - like this:


<- 39 Tiles ->
Small Statue
<- 39 Tiles ->
ArchitectFirehouseHutHutSmall Statue

The roadblocked connection (rbc) to the upper road is at tile 60 of the lower road.
The architect wandered to the northern walk target - 133 tiles away - and then he disappeared.
In the following table I'll use the notation 59R 11U 63L for this trip, which means the architect left his office then he moved 59 tiles to the right, 11 tiles up and 63 tiles left.
Now I moved the rbc step by step to the left and got these results:


rbc at tilewalk-1walk-2walk-3walk-4distance of walk-4remarks
6050R 50L1R 1L 41R 41L1R 1L 41R 41L59R 11U 63L133very long
4450R 50L1R 1L 41R 41L1R 1L 41R 41L43R 11U 47L101very long
4350R 50L1R 1L 41R 41L1R 1L 41R 41L43R 10U 46L99off road
4250R 50L1R 1L 41R 41L1R 1L 41R 41L43R 9U 45L97off road
3550R 50L1R 1L 41R 41L1R 1L 41R 41L43R 2U 38L83off road
3450R 50L1R 1L 41R 41L1R 1L 41R 41L43R 1U 37L81off road
3350R 50L1R 1L 41R 41L1R 1L 41R 41L43R 36L79
1650R 50L1R 1L 41R 41L1R 1L 41R 41L43R 2L45
1550R 50L1R 1L 41R 41L1R 1L 41R 41L43R43
150R 50L1R 1L 41R 41L1R 1L 41R 41L43R43


I suppose that the algorithm has some problems, if the roadblock is within the default walk distance d.

[This message has been edited by Max (edited 05-09-2005 @ 04:39 AM).]

posted 05-09-05 00:48 ET (US)     5 / 29  
Max:

I am very glad you got a chance to look over the random walk guide, since you have zeroed right in on an important area.  I fear I am going to have to sit down with your data and probably reconstruct your roads in my own lab before I can get back to you with anything like an intelligent reply to your post.  Before I do so, however, I wanted to offer two general observations and to raise two questions for you.

First, the observations.  You are absolutely right that the architect, tax collector, and senet player do not strictly adhere to the rules laid out in the Ambulomancy guide.  I think of them plus teleporting dancers, musicians and bazaar sellers collectively as “supernatural walkers” Awarding them this title at least helps to console me for the fact that I do not understand them at all well.  Even though these walkers do things that most roaming walkers cannot (like vanish, teleport, or go off road), both you and I seem to have found that these supernaturals still somehow use or reference the walk-target squares of ordinary walkers.  I saw dancers and musicians from pavilions appearing on otherwise inaccessible walk targets; you saw architects make walks (of lengths that would be utterly impossible for other long walkers) that terminated by vanishing on a walk-target square.  Like teleporters, I really think that the vanishing and off-roading walkers deserve more study, and I am delighted to find that you feel the same.  I really should have said something more explicit in Ambulomancy to warn readers about architects and tax collectors not playing by the rules.  I hope that your post and this reply will provide the necessary fair warning.

Second, Brugle reminded me in his review of the manuscript that walkers from buildings at dead ends (like your architect) frequently make “false starts” (exactly as you document for walks 1 and 2 in your table) and that my model of roaming walk generation does not account for false starts.  Arrgh!  Too true.  I simply cannot handle dead ends yet.  I tried to be honest about this (without absolutely and painfully trumpeting my ignorance) on p. 7 under “Default Details”.

Now the questions:

#1 - Are you sure you are listing the walks in the right order?   I ask because the walks appear to be progressing in counterclockwise order, i.e., in the reverse of the usual sequence.  Before I saw your data, I had only seen counterclockwise walk order with teleporting walkers.  Very exciting. Thank you!  I will have to reproduce this effect in a lab and play with it some more.

#2 - All the walks in the "walk-3" column in your table look like grounded walks beginning with a destination walk to the (plaza-marked) SE walk target seven squares to the right of the architect's walk-start square.  Do these really end with the disappearance of the architect 50 squares from home, or does he actually return - visibly - to his walk-finish square?  In other words, could you have listed those walk 3's as "50R 50L"?  I ask because I have never before seen a case in which an architect vanished during a grounded walk (unless he wandered off the road first by failing to turn the final corner in a loop).

I will return with a more fleshed out response once I get a chance to reproduce the effects you describe in my lab.  I hope you will not hold it against me if this takes a couple of days, because we are entering final exam period at UMass at the end of this week  (Many exams to write!), and I am still recovering from a bout with asthma that sent me to the emergency room.

Until then,  thank you for some wonderful clues to supernatural roamer behavior.

StephAmon

[This message has been edited by StephAmon (edited 05-09-2005 @ 00:54 AM).]

posted 05-09-05 03:05 ET (US)     6 / 29  
Hello StephAmon,
you are right - sorry for the inaccuracies - I corrected the table in replay 4.
I guess you noticed, that the formula for the travel distance (td) of walk-4 with rbc between 15 and 60 is always: td = 2 * rbc + 13.
I wish you all the best - no need to hurry..
posted 05-09-05 10:06 ET (US)     7 / 29  
Max:

Many thanks for the edits. We can now see pretty clear evidence of clockwise rotation, so we may be able to figure some of this out.

Hey! Your architect does not vanish after default walks. I never checked, but I honestly thought he would.

Thanks also for the formula. I was not thinking of the pattern that way (I was working in glyphy), so I missed it. That has got to help.

StephAmon

posted 05-17-05 16:18 ET (US)     8 / 29  
Most of StephAmon's observations also apply to Caesar III roaming walkers. This comment applies only to C3, but I thought that it belongs here. (I'll link to this thread from the C3 Game Help forum.)

In either a "blockage-shorted" or "grounded" walk, the walker switching from destination to random mode "does not reverse direction". On an intersection-free loop road, that means that a Pharaoh walker will continue around the loop (at least until switching back to destination mode for the return to its building), but a C3 walker might not.

In C3 (unlike Pharaoh), destination walkers who are following a road will cut corners. (Note to StephAmon: using C3, your research might have been easier. ) If a walker was cutting a corner when it switches from destination to random mode, it may go in any road direction (since none of them are the reverse of cutting the corner). An example, in the next paragraph, may make this clearer.

In my latest C3 city (a try at an interesting challenge: the "career" Valentia at Very Hard difficulty without trade, debt, the "rescue" gift, or initial personal funds), I started a housing block with a 46-tile intersection-free rectangular loop road, where I expected all roaming walkers to complete the loop. Most did. However, on 1 walk out of 4, the trader from one market near the east corner had a "grounded" walk which began with a counterclockwise destination walk to the tile just SW of the loop's north tile, and since she cut corners getting there, she arrived travelling toward the west (cutting from just SE of the north tile to just SW of the north tile). Switching to random mode, she chose to travel toward the northeast (not the reverse of toward the west) and continued clockwise. When switching from random back to destination mode near the loop's south tile, she reversed back to counterclockwise to return to her market, and therefore missed some houses on that walk. (Fortunately, I expect that traders from the 2 other markets, who go by all houses on every walk, will be sufficient to prevent devolution.)

Thanks, StephAmon, for explaining what otherwise would have been a puzzling (and annoying) mystery!

[This message has been edited by Brugle (edited 05-17-2005 @ 04:25 PM).]

posted 08-16-05 18:58 ET (US)     9 / 29  
ERRATUM

The March 2005 edition of Ambulomancy contains an error in the description of the pattern used by the walker algorithm to search for road squares around routing centers.  This error is reflected in Table 1 and in text that refers to it.  The March 2005 edition states that routing centers are not searched by the algorithm for roads.  This is incorrect.  Recent research results indicate that a routing center is examined after the square to its NW and before the square to its southeast.  An easy way of seeing this would be as follows:

Change the notation “RC” in Table 1 to “.

A single disconnected road square occupying a routing center now appears capable of defaulting out the walk controlled by that center.  Moreover, if a connected road square on a routing center has the highest priority of all the connected roads near the routing center, the algorithm places a walk target on the routing center that will be used for calculating either shorted or grounded walks.  Finally, a road square on a routing center can serve as a teleportation-landing square for an entertainer teleporting from a pavilion.  Naturally, future editions of Ambulomancy will include a completely renumbered version of Table 1, and the text will be appropriately revised.

I apologize abjectly to the community of Pharaoh builders for misinforming them.   I also offer deeply felt thanks to Jimhotep, who brought the use of routing centers as teleportation-landing squares to my attention, and thus alerted me to the potential error.

StephAmon

EDIT 10Sep2007: This error is corrected in the 2nd edition of Ambulomancy. StephAmon

[This message has been edited by StephAmon (edited 09-10-2007 @ 00:38 AM).]

posted 11-06-05 16:33 ET (US)     10 / 29  
Current Status
of the Response to Max’s Challenge

I have taken so long to craft an adequate response to the challenge posed by Max’s architect to ambulomancy that I think I had better offer at least the partial response of which I am presently capable.

In the table Max presents in reply 4, walk #1 must have a formal direction of southeast.  In the accompanying figure, Max clearly shows the walk target (plaza square) associated with a SE formal direction lying seven squares to the right of the architect’s walk start.  Walk #1 takes the architect from his starting point 50 squares to the right (in the figure, or in the SE direction), which corresponds exactly to the sum of the architect’s predicted seven-square destination-mode walk to the plaza (his SE walk target) plus his 43-square random-mode walk to the go-home point.  The expected clockwise rotation in the assignment of formal directions to walks would, therefore, make walks #2 and #3 the SW and NW walks, respectively, and walk #4 (the really interesting one) has a formal direction of NE.

The SW and NW routing centers lie outside Max’s figure, but if the only roads present are the ones in the glyphy, the algorithm’s search for walk targets around either of those two routing centers will fail to find a road square in the 13x13 areas searched.  Consequently, both the SW and NW walks in the architect’s quadramble should default to 43-square long, pure random-mode walks.  With both of these walks, however, a potential ambiguity exists in trying to assign a default direction.  Version 1 of Ambulomancy identified the default directions for cases in which a roaming walker’s start square falls on “a straight stretch of road” or on a corner.  Default directions for walkers starting at the center of three-way and four-way intersections also appear to be variable and untrustworthy.  Max’s example starts default walks (#2 and #3) on a starting square that is not unambiguously within a “straight stretch of road”, since the start square is adjoined only by a single road square rather than a pair of road square on opposite sides of the walk-start point.  Evidently, the architect is not regarded by the algorithm as starting in a “straight stretch of road”; dead ends do not seem to be the same as straight pieces of road.

In Max’s table, the two default walks (#2 and #3) beginning from dead ends make “false starts” in which the total distance traveled from walk-start to go-home point still has the usual length for a default walk (43 squares for a long walker like an architect), but the walk bounces back to this walk start square after his first square of travel (before making the remaining 41 squares in his default walk).  I can offer no explanation based on routing-centers or walk-targets for why this occurs.  A little preliminary checking shows that false starts always occur when 1x1 buildings start a walker on a dead end (not one square away from a dead end) when that dead end terminates a NW-to-SE road.  False starts also occur at NE dead ends (i.e., the end of a road extending away to the SW).  Curiously, I have not been able to produce false starts by roamers from 1x1 buildings at SW dead ends.  The picture gets more complicated when buildings of larger sizes are considered.  I suspect we will need a big Dead End Table in which one cross indexes building size and position with dead end compass direction to find out which combinations will reliably produce or avoid false starts.  I plan to develop such a table in the not-too-distant future, since a few default walks from dead ends are hard to avoid in mining country.

For the present, however, it seems prudent always to assume that a roamer on a default walk will make or will fail to make (whichever is "worse") a false start from a dead end, unless he comes from a 1x1 building and starts on a SW dead end.  Fortunately, default walks tend to be very rare in actual cities, except at map edges or near unbuildable areas like mountains and dunes.

Max’s table makes it evident that 43-square long blockage-shorted walks (e.g., walk #4 in the last two rows of the table) do not begin with false starts, even though they have the same length to the go-home point as a default walk.

Apart from the first two and last two rows in the table, all the different variations of walk #4 shown by Max are examples of “confused walks” and I have discussed the little that I presently know about walks of this kind in a different thread (Walkers and teleporters from pavilions").  I have earnestly tried to develop some ability to predict what a roamer of this sort will do when it reaches the end of the random phase of its roaming walk (when a decent gods-fearing walker would turn around and go home), but so far I have failed.  My only consolation is that once a roamer is in confused mode (e.g., once he has left the road) he will vanish and return instantly to his building ready to begin another walk if he blunders into a non-garden structure.  In densely packed housing blocks, this means the confused walker hits a building immediately when he tries to leave the loop road and soon will begin a new walk.

[This message has been edited by StephAmon (edited 11-06-2005 @ 04:37 PM).]

posted 11-18-05 22:29 ET (US)     11 / 29  
Erratum
Tie-breaking Revisited

In the first edition of Ambulomancy, I made an error in describing the rule used by the algorithm in choosing between two alternative paths of equal length connecting a roaming walker's walk-start square to the target for one of his walks.  This note offers a correction of my mistake.  In addition, the same rule used for choosing between two available short-circuits (connecting walk start to target) also appears to be used when choosing between two paths of equal length by which a roaming walker could return to his walk-finish square when he re-enters destination mode for the homeward-bound half of his walk.  To allow the rule to be described in sufficiently general terms so that it can apply to either situation, I will refer to the square on which the roamer enters destination mode as the walk origin and the square he is trying to reach as the walk terminus.

Tie-breaking rule (amended).  The algorithm selects a destination-mode path for a roaming walker by starting at the walk terminus and looking backwards along the path towards the walk origin.  When two alternative paths of equal length (shorter than all others) can be traced from the walk terminus to the walk origin, the algorithm chooses between the two paths based on the directions they take from the point at which they diverge, according to the following order of preference:  NE > SE > SW > NW.

The order of precendence described in the rule, above, agrees exactly with the order described in the first edition of Ambulomancy.  The only difference between the original and amended versions of the rule is that the new version states that the paths must be explored backwards from terminus to origin, whereas the original version said that the algorithm looked for the divergence point beginning at the walk-start square and heading in the outward-bound direction.

Fig. 6 shows a situation that requires the algorithm to apply its tie-breaking rule to a road geometry that reveals its use of the backward-looking version of the rule.  When the dentist is dispatched on a walk of any of the four formal directions, his target (ordinary plaza tiles in the figure) will be "unwalkable".  When the roadblock is present, it lies on the dentist's path between his walk-start square and all of his four targets, so all four of his walks short out due to blockage.  If the roadblock is removed, then all of the dentist's walks short out due to distance, because the closest of his targets can only be reached after 39 squares of travel - well beyond the limit of 25 for a short walkers, like a dentist.  The dentist's choice between the yellow and blue paths shown in the Fig. 6 is the same whether the roadblock is present or not, so the following discussion will explore the situation more commonly encountered in actual cities - shorting due to blockage (with the roadblock installed).

RoadRoadRoadRoadRoadRoadDentist turns around w/o roadblockRoadRoad Road
Road Road Road
Road Road Dentist turns around if roadblock present
Road Roadblock Road
Road RoadRoadRoadRoadRoad
Road Road
Road Return routeReturn routeReturn routeReturn routeDivergence governing outbound route choice
NE target Return route Outbound route
RoadGarden Return route Outbound route
Road NE routing center Return route Outbound route
Road Return route Outbound route
Road Return route Outbound route
RoadRoadRoadRoad Return route Outbound route
Road Divergence governing return route choiceOutbound routeOutbound routeOutbound routeOutbound route
NW target Road
GardenRoad Road Road
Garden Road Road Road
NW routing center Road Dentist Road Road SE routing center
Road RoadRoadRoadRoadRoadRoad RoadRoadRoadSE targetRoadRoadRoad
Road Road
Road Road
RoadSW targetRoadRoadRoadRoadRoadRoadRoadRoad
Garden
Garden
Garden
SW routing center
Fig. 6. Roads forcing the walker algorithm to break ties for a dentist's destination-mode pathways.  When the dentist departs from his office, he passes along the yellow road squares, but when he returns to his office he takes the other route, passing over the blue squares.  Small statues denote the routing centers of the dentist's office, and the dentist's walk targets are shown with ordinary plazas.  Gardens have no effect on walks, but are included to highlight the relationship between each target and its corresponding routing center.  In most browsers (but not my copy of Firefox) pop-up labels identify many features of the glyphy.  Supporting buildings like housing and a firehouse are not shown.  North lies toward upper left.
posted 11-18-05 22:32 ET (US)     12 / 29  
When the roadblock is present, all four of the dentist's walks in Fig. 6 pass through three phases:  outward-bound destination mode from the walk-start square to the square just SW of (or below, in the figure) the roadblock; then in random mode to the green plaza square; and finally in destination mode to return from the green plaza square to the walk-finish square of the dentist's office.  The tie-breaking rule applies to both of the destination-mode phases.  In the outward-bound destination mode walk, the walk terminus is the road square touching the roadblock from its southwest, because that is the last road square the dentist can legally (without violating the roadblock) reach in trying to get from his start to his target.  The amended tie-breaking rule is applied by starting at this terminus and working backward toward the dentist's walk-start square looking for the point of divergence, which in this case is the red road square.  From this divergence point, the first yellow road square lies SW, and the first blue square lies NW.  The algorithm seems to look for roads around a divergence point in the same order that it looks for roads around a 1x1 building when it is trying to identify a walk-start square, so the SW branch is chosen.  Once that selection has been made, the road connection to the walk-start square of the dentist's office becomes unambiguous, and the path from terminus to origin (including the yellow squares) has been chosen.  The dentist is then sent along that path in the reverse order, from origin (walk start) to terminus.

At the terminus (next to the roadblock), the dentist switches to random mode to use up the remaining squares of his 26-square outward-bound walk.  This takes him to the green plaza.  On the green plaza (his homeward origin) he reverts to destination mode for the return trip to his walk-finish square (his homeward terminus).  Once again, the dentist has two alternative routes of equal length leading to his terminus, so the algorithm  begins tracing the route from the walk-finish square (terminus) to the green plaza (origin) looking for the divergence point, which is found to be the green road square in Fig. 6.  From this divergence point, the yellow road square lies SE and the blue square lies NE.  NE trumps SE, and the blue path is selected.  The dentist, thus, returns from the green plaza square to his walk finish via the blue road rather than the yellow road.

When the roadblock is removed, all the dentist's walks become distance shorted and lack a random-mode phase separating the outward- and homeward-bound phases.  The yellow plaza serves both as his outward-bound walk terminus and as his homeward-bound walk origin.  His path choices remain the same as they were when his walks were blockage-shorted: yellow path for the outward-bound walk, and blue path for the homeward-bound walk.

Although the original version of the tie-breaking rule accurately predicted all the tie-breaking path choices in my original trials, it gives exactly backwards predictions for Fig. 6 - erroneously suggesting that the yellow path would be taken for the outward-bound portion of the dentist's walk and the blue path would be followed when he came home.

Once it knew what to look for, it became straightforward to design more road geometries to test whether the first divergence point discovered when searching in the forward or reverse direction was the determinative one for path choice.  The algorithm appeared cheerfully willing to send the walkers almost any direction from the first divergence point it found looking forward from origin to terminus, but it always obeyed the NE > SE > SE > NW order of preference for roads touching the first divergence point it found when tracing backwards from terminus to origin.  A series of additional tests (not detailed here) also revealed that the distances from the terminus and origin to their closest divergence points did not matter.  The terminus could lie 15 squares from the nearest divergence point, while the origin actually was a divergence point and the order of direction preferences around the divergence point closest to the terminus was the only one that mattered.

EDIT 10Sep2007: The revised version of the tie-breaking rule appears in the second edition of Ambulomancy. StephAmon

[This message has been edited by StephAmon (edited 09-10-2007 @ 00:42 AM).]

posted 09-09-07 22:22 ET (US)     13 / 29  
My university has warned us that they are going to decommision the server that hosted not only the first edition of the Ambulomancy monograph but also all my funny colored roads that I used in many of my old posts. At the time of this posting, I notice that the colored roads in reply 11 above are still working, but they soon will not. Rather than edit all my old posts, I thought I would put together a second edition of Ambulomancy including the later discovered information on teleportation from pavilions and about confused walks, which Max's reply 4 to this thread forced me to explore. The second edition also fixes the mistakes reported as Errata above in this thread.

I plan to leave the document available through the link at the beginning of this thread for a while to give readers a chance to find errors in it. I hope those readers will report them to me in replies to this thread, so I can edit the document to fix the mistakes. I then plan to upload it to Pharaoh Heaven's Downloads sections, so that no matter what my university does with its servers in the future, Pharaoh players of the future will be able to find it.

The second edition of Ambulomancy includes a new nine-page section at the end called "Applied Ambulomancy". I tacked it on because all the examples of defaulted, grounded, and variously shorted walks in the original document looked totally useless from a Pharaoh-playing perspective. In contrast, "Applied Ambulomancy" contains an analysis of the behavior of several of the roaming walkers in an actual housing block that I recently used in Sauty at very hard difficulty. The analysis includes discussion of the teleporting dancers and musicians from one of the pavilions in the block.

Another property of the block analyzed in "Applied Ambulomancy" is that its pair of firemen always go around the block in the counter-clockwise direction, never stray into either of the block's stub roads, and are always separated by a little more than half the 52-square circumference of the block's main loop. Even better, they stayed that way for all the decades that it (alas!) took me to complete Sauty and never caused me a bit of worry.

I hope folks like the new edition.

StephAmon
posted 09-11-07 17:00 ET (US)     14 / 29  
This sounds great. (I will comment on the monograph after I read it, but that might not be for a while.)
posted 09-11-07 23:35 ET (US)     15 / 29  
Brugle:

I am much relieved that you noticed the appearance of the 2nd edition. If you get a chance to look at the thing, I'm sure you will have some really useful editorial suggestions. You're good at spotting even little typos, and you also have helped me in the past with getting the whole tone and perspective of one of these things better oriented.

Hope to hear from you in a bit.

StephAmon
posted 11-23-07 17:18 ET (US)     16 / 29  
I'm sure you will have some really useful editorial suggestions.
I'm afraid not. Now that I have the ability to play Pharaoh (and C3) again, I looked over the new edition of Ambulomancy. The only suggestion I have is to change the date (March 2005) on the first page. (I hope to look over (and comment on) your Sauty's "fire-proof blocks" soon.)

The changes for the new edition appear to be primarily the incorporation of stuff (including teleportation from pavilions, confused walks, and some interesting applications) that you've covered in forum posts (with some new or changed examples). Since I read and (I think) understood those posts, I didn't find much new.

Pharaoh can be played, at quite a high level, without a detailed understanding of "random" walkers. But most players who don't already have that understanding (and are willing to put in a bit of effort) should find their play improved by reading the more complete Ambulomancy.
posted 05-27-08 09:32 ET (US)     17 / 29  
I have a question:
In Erik's Hammanat entry for the Pharaolympics, he takes advantage of the reliability of the four quadrambles to send his one and only water carrier to each housing block in turn. This makes sense, but according to your Ambulomancy guide, the water supply should send the water carrier off on a grounded walk for every leg of the four quadrambles. The problem is that, using your Ambulomancy guide, I've located the four routing centres and worked out that the conversion from destination to random mode always happens before an intersection, yet the water carrier always goes straight forward, never turning right or left into a perfectly available alternate route, despite being in random mode. Why is this?
posted 05-27-08 10:54 ET (US)     18 / 29  
the water carrier always goes straight forward ... despite being in random mode. Why is this?
Your question isn't clear.

Are you asking why the water carrier always does the same thing on a particular quadramble (say, the one toward the southwest), rather than vary randomly (say, sometimes going straight at the intersection north of the southwestmost fancy residence and sometimes turning left at that intersection)? Even in "random" mode, walkers are not truly random. They follow a fixed algorithm, so if the entire road network stays constant, the routes of the 4 quadrambles of a given walker will not change.

Are you asking why the water carrier goes exactly where Erik seems to want it to go? I suspect that is because Erik tried various layouts and found one that worked well. When the Hammanat contest was held, we (forumers) knew much less about "random" walker routes.

Are you asking why the water carrier seems to have a tendency to go straight (or in the same direction as the routing center) at an intersection, rather than change direction? I don't know if anyone (aside from the original programmers, of course) has determined the algorithm for the "random" part of a random walker's walk. To me, there does seem to be a tendency to go straight (or in the same direction as the routing center) at an intersection, although that doesn't always hold throughout the "random" part of the walk. (The walker is supposed to appear to be just wandering around, so I wouldn't expect the algorithm to be too simple.) It would be nice to know more about that algorithm, but we can do pretty well with the knowledge that we have (or much less, actually).

[This message has been edited by Brugle (edited 05-27-2008 @ 10:57 AM).]

posted 05-27-08 11:15 ET (US)     19 / 29  
I have just studied the block watching the water carrier carefully.

i took particular interest in the North east quadramble as the water carrier, having converted to random mode, never takes the first road that appears some 15 or so tiles on from his conversion.

however, if one was to move that road intersection one tile north east so it looked like this: (north is up-left)


Legend

(the plaza represents the intersection i moved up one tile)
(assume the water carrier came from the left (north-west)

then the water carrier will always take the plaza (in the diagram) road rather than continue round back to the water supply.

what this shows is that, 'random' walkers will, in this set up, always tend to continue in the direction they are currently headed and will not change direction, even at an intersection, while in random mode.

i hope this answers your question. maybe someone will take to looking at this more closely. i would be happy to but would need some guidance. or if StephAmon is still about...

[This message has been edited by cantique (edited 05-27-2008 @ 12:15 PM).]

posted 05-27-08 11:34 ET (US)     20 / 29  
cantique,
I did not say that "'random' walkers ... will not change direction, even at an intersection, while in random mode". Please don't attribute something to me that I never said.
posted 05-27-08 11:59 ET (US)     21 / 29  
Sorry Brugle,

i misinterpreted what you said.
i have altered my post.
posted 05-28-08 20:40 ET (US)     22 / 29  
Quoted from Brugle:

I wouldn't expect the algorithm to be too simple. It would be nice to know more about that algorithm

It certainly isn't simple, if by 'simple' you mean 'easily fathomed'. I think many people have the impression that a walker arrives at a tile where there is a choice of direction and flips a coin to decide which way to go. I think a number of things contribute to the outcome. I am satisfied that map location is one of them since tests run at one location have produced results which are repeatable at some alternative locations but not at others. We already know that location determines the direction of the 'quadramble' taken by the first walker from a new building (as well as whether huts can merge) but I'm not aware that anyone has spotted a pattern, e.g. something that can be resolved to a function of X and Y coordinates.

I believe too that not every intersection is even checked. Many times we have seen the advice to avoid the 'maze' which you would expect to be caused by double width roads, yet if you actually build one you will find that most walkers go straight along them with no problem. For aesthetic reasons I use these often and in my experience the only times a walker deviates from 'straight ahead' are (i) a mode conversion takes place, (ii) a 'proper' intersection is reached, or (iii) a kink in the road is approached. It does not seem feasible that the walker is making a choice on every tile and always choosing 'straight ahead'. Triple/quadruple roads (while not very useful) will also guide walkers in a straight line for the most part.

Over at C3 Heaven it has been reported (by Trurl/lemmus) that a walker returning to a previously visited intersection (such as from a stub road) will be sent in a predictable direction based on the direction he was sent on the previous visit and the number of tiles he has walked since then. I have not found this to be 100% reliable but the 'hit' rate is very high indeed.

Yet another factor which demonstrably affects the choices made is whether the walker is/was a 'default' walker, a 'blockage shorted' walker or a 'grounded' walker (after conversion to 'random' mode). This may indicate that the number of tiles walked has a bearing, since each of these will start their 'random' walks at a different point and therefore approach the intersection with a different tally of tiles walked.

It would indeed be 'nice' to know more about that algorithm but after many hours of testing I somehow don't think I will be the one to enlighten you any time soon.
posted 05-29-08 05:51 ET (US)     23 / 29  
I'm not sure that your observations and conclusions are correct. I haven't read StephAmons papers in detail, but as I understand it randomness as in flipping a coin, nor the location on the map play any role whatsoever, but that the position of the home building relative to the road network fully deterministically determines the walking behaviour. The algorithm is complex, which explains the appearance of randomness, but AFAIU is largely described. Please correct me if I'm wrong.
posted 05-29-08 09:13 ET (US)     24 / 29  
joshofet,

Sorry, but I think that you're wrong this time. As far as I can tell, Trium3's observations here do not contract anything in StephAmon's Abulomancy.

A "random" walker can go through up to 3 phases (that we've identified):
1) a "destination" phase, where the walker goes to a tile that is selected by an algorithm that starts by looking 8 tiles to the NE, SE, SW, or NW,
2) a "random" phase, where the walker appears to be wandering around, and
3) another "destination" phase, where the walker returns to its building.
StephAmon's work mainly concerns phase 1). Trium3 in reply #22 is mainly talking about phase 2), which we do not understand as well as phase 1) or phase 3).
posted 05-30-08 06:31 ET (US)     25 / 29  
I wasn't aware of that second phase, or rather I thought that both the first and second stage were what is commonly referred to as a "random" walker, and that that full stage was described by the deterministic algorithm of StephAmon. Thanks for the correction.
« Previous Page  1 2  Next Page »
Caesar IV Heaven » Forums » Pharaoh: Game Help » Predicting Roaming Walks
Top
You must be logged in to post messages.
Please login or register
Hop to: