Weather Bias in Utopia?

[intvnut]

I wrote up a quick and dirty C program to simulate many millions of tics of weather movement across the Utopia map, to see if there are any biases inherent in the weather algorithm. It turns out there are. The weather turns out to be very sensitive to its initial velocity, in fact.

 

The weather movement algorithm is pretty simple. Weather always originates from [27, 0], with a velocity of [+5/8, +4/8]. (+5/8 means it takes 8 tics to move 5 pixels.) On any given tic, there's a 1-in-10 chance of modifying the weather's velocity. If the algorithm decides to adjust the weather velocity, it picks a direction (N/S/E/W) and increments the velocity by 1/8 in that direction. If the weather moves off screen, it gets deactivated.

 

It turns out that the fixed starting location/velocity and the deactivate-on-exit behavior lead to a pretty stable distribution of "likely weather" areas. Furthermore, the right island seems to get more weather than the left island, on average, if my simulation is accurate.

 

Below is my "heat map". Every four bands in the color spectrum represent a factor of 10 difference in likelihood that pixel seeing weather. Two adjacent bands in the color map are approx a factor of 1.78 apart.

 

 

As you can see, the right island gets more rain on average than the left, with the buld of the benefit concentrated in the northwest corner of the island. The entire west coast of the right-hand island gets a pretty good bit of rain. The left island has a more concentrated set of raininess along its east coast. Overall, it's dryer.

 

I suspect this ends up making the right hand island easier to get started with, while both islands are agrarian and just getting established. In the long run, though, since all weather follows these trajectories (rain, tropical storms and hurricanes), the right island will also see more damaging weather events.

 

Now, I did experiment with the parameters a little bit, to see how sensitive the model is to that initial velocity. It turns out it's quite sensitive. Here's what it looks like with [+5/8, +5/8] as the initial velocity:

 

 

And here's what it looks like with [+4/8, +5/8]:

 

 

As you can see, slight changes in that initial velocity really shift the distribution around, even though most of the motion is a random walk. You have an extreme sensitivity to initial conditions, and I think it's reinforced by the fact weather deactivates when it reaches a screen boundary, so you can't average behavior over an unbounded amount of time.

 

I suspect this bit of code was intended to reduce the bias a little by shifting the weather entry point occasionally:

 

       MVII    #$0003, R0          ; 51EB  \_ Random 0..2
       JSR     R5,     X_RAND2     ; 51ED  /

       TSTR    R0                  ; 51F0  \_ If non-zero, done spawning
       BNEQ    L_51F8              ; 51F1  /  weather

       INCR    R2                  ; 51F3  \
       MVII    #$001B, R1          ; 51F4   |_ Set X coord to 27. 
       SWAP    R1,     1           ; 51F6   |  (But, it should already be 27!)
       MVO@    R1,     R2          ; 51F7  /

 

But, as my disassembly comments indicate, this picks between a starting X coordinate of 27, or with 1-in-3 chance, selecting 27 instead. That is, no matter what, you're starting at [27, 0].

 

You can see my quick and dirty code here: http://spatula-city.org/~im14u2c/intv/dl/weather-track.c

 

Enjoy!

[BillyHW]

Fascinating. I've always wondered just what the probabilities of getting rain on a particular tile were. I always played with the left island with my cousin, and knew that the bottom right corner of the island got more rain. I figured though that the program was symmetrical and the islands were programmed to have essentially equivalent squares.

 

So which of the above simulations is the from the game?

 

And did they make a mistake in the code then? Did they originally intend to mix it up a bit?

[+DZ-Jay]

Great job, Joe!

 

To me, it always felt as if the east coast of the Western Island received the most rain, with the South East peninsula being the most prime location for crops. That's why I always picked the Wester Island.

[+DZ-Jay]

Great job, Joe!

 

To me, it always felt as if the east coast of the Western Island received the most rain, with the South East peninsula being the most prime location for crops. That's why I always picked the Wester Island.

 

By that I mean, that the Wester Island can concentrate on being agrarian on the East Coast, and have plenty of real estate for development, with low chance of "bad weather" ruining it.

 

-dZ.

[intvnut]

Fascinating. I've always wondered just what the probabilities of getting rain on a particular tile were. I always played with the left island with my cousin, and knew that the bottom right corner of the island got more rain. I figured though that the program was symmetrical and the islands were programmed to have essentially equivalent squares.

 

I think that was the intention, but the problem is that that goal is nearly impossible with this algorithm within the constraints of the 20x10 playfield. You'd need weather to come in from more angles and a wider range of velocities to even out the map, I think.

 

So which of the above simulations is the from the game?

 

The first simulation is from the game. The other two are to show how sensitive the distribution is to very minor changes in the input.

 

And did they make a mistake in the code then? Did they originally intend to mix it up a bit?

 

I think they may have. The code I spotted could be in error, or it may be dead code left over from some experiments trying to change things up that never got removed. There's a bunch of weird fossils in the code, such as this inexplictably complex bit of code for making a constant:

 

       CLRR    R0                  ; 5255  \
       SDBD                        ; 5256   |- Why all the extra code?!
       XORI    #$D8C0, R0          ; 5257  /

 

Why isn't that just a MVII?

 

By that I mean, that the Western Island can concentrate on being agrarian on the East Coast, and have plenty of real estate for development, with low chance of "bad weather" ruining it.

 

Yeah, I got that impression too -- that it seems like the left (western) island gets fewer catastrophic weather events inland, because most of the weather is concentrated along the east coast and that south-east peninsula. Simulation suggests we're right.

 

Now, my simulation could be bad...

 

 

 

And now for something kinda offtopic, but this apparently needs to be said:

 

------------------------------------------

 

To clear up any confusion, since I was asked in private email: The Utopia code I posted previously doesn't assemble. It isn't meant to, and I have no intention to change that -- it's too much work and not an activity I think is worthwhile.

 

I posted it so we could gain a better understanding of how it's all put together and enjoy it how it is, and maybe learn something to help us develop our own original, unique games. So, while it largely looks like a valid, complete assembly program, it's not meant to be nor will I do the work necessary to make it so. It's only meant to be an exploration and explanation of its algorithms, not "Utopia source code."

 

Sorry for any confusion.

Edited May 21, 2012 by intvnut

[Rev]

What the hell is your IQ anyway. Awesome job!

[BillyHW]

I could have sworn that the bottom right corner of the left island got the most rain.

[+DZ-Jay]

I could have sworn that the bottom right corner of the left island got the most rain.

 

It looked to me that way too, although I must say that there were some rain clouds that seemed to want to oscillate for a long time in the top-left peninsula of the Eastern Island.

[intvnut]

I could have sworn that the bottom right corner of the left island got the most rain.

 

It looked to me that way too, although I must say that there were some rain clouds that seemed to want to oscillate for a long time in the top-left peninsula of the Eastern Island.

 

Well, they're within 60% to 80% of each other, so it's not a huge difference.

Edited May 22, 2012 by intvnut

[intvnut]

BTW, a minor error in my writeup above. The divisors for the velocities are 32, not 8. So the initial velocity is [+5/32, +4/32] and velocity updates are +/- 1/32 on one of the axes. The C simulation is correct.

 

I just had a brain-fart when I described it in English is all...

[+DZ-Jay]

BTW, a minor error in my writeup above. The divisors for the velocities are 32, not 8. So the initial velocity is [+5/32, +4/32] and velocity updates are +/- 1/32 on one of the axes. The C simulation is correct.

 

I just had a brain-fart when I described it in English is all...

 

So, it takes 32 ticks to move 5 pixels?

[intvnut]

BTW, a minor error in my writeup above. The divisors for the velocities are 32, not 8. So the initial velocity is [+5/32, +4/32] and velocity updates are +/- 1/32 on one of the axes. The C simulation is correct.

 

I just had a brain-fart when I described it in English is all...

 

So, it takes 32 ticks to move 5 pixels?

 

Yes.

 

You can see that, actually, if you watch the memory location for the X coordinate, for example. The X/Y coordinates are stored in 8Q8 (8 integer, 8 fraction). The velocity is an 8-bit value that apparently gets multiplied by 8 and then added to the X coordinate 20 times a second.

 

Here's a trace of the first few tics of X coordinate update, courtesy of jzintv:

 

WR a=$031F d=1B00 CP-1610          (PC = $16C7) t=15931758   <-- initializes X position to $1B.00
WR a=$0321 d=0504 CP-1610          (PC = $16C7) t=15931933   <-- Initializes X vel to +5, Y vel to +4
WR a=$031F d=1B28 CP-1610          (PC = $133F) t=15969968   \
WR a=$031F d=1B50 CP-1610          (PC = $133F) t=16012757    |
WR a=$031F d=1B78 CP-1610          (PC = $133F) t=16057697    |
WR a=$031F d=1BA0 CP-1610          (PC = $133F) t=16104873    |__ 20Hz updates.  Each moves X by $00.28, which is $00.05 * 8.
WR a=$031F d=1BC8 CP-1610          (PC = $133F) t=16148763    |
WR a=$031F d=1BF0 CP-1610          (PC = $133F) t=16193263    |
WR a=$031F d=1C18 CP-1610          (PC = $133F) t=16236899    |
WR a=$031F d=1C40 CP-1610          (PC = $133F) t=16281705   /

 

So, after 32 tics (1.6 seconds), the weather would move 5 pixels if its velocity remains unchanged.

[First Spear]

Reading this for the first time in an effort to get cluew on coding for the Inty. Great work!

[+DZ-Jay]

Now, I did experiment with the parameters a little bit, to see how sensitive the model is to that initial velocity. It turns out it's quite sensitive. Here's what it looks like with [+5/8, +5/8] as the initial velocity:

 

 

Doesn't this make sense for a world axis that is essentially askew from the diagonal normal? It seems intuitively that an initial velocity of [+5/32, +4/32] would set the weather on a trajectory that bisects the sea between both islands.

[irvinetom]

Super fascinating... and now I know which side to pick lol. Amazing work as usual!!!!