
A Study of RCT Time
Author/Contributors:
Dave "RCT Help"
Introduction
One day when playing Rollercoaster
Tycoon I tried to reconcile the data in the Financial Information
Window with the financial information available in each ride and
attraction window. I became terribly confused.
The Financial Information Window is
updated constantly for some items and weekly and fortnightly for
the remainder, with the data being reset every month. However, all
the financial data for rides and attractions is described in terms
of hours. In one scenario I was playing, how was it possible that
the Ride Tickets raised around £6,000 in a month,
but a single coaster was reporting ticket sales of over £13,000
per hour?
Similarly, ride times are reported
in minutes and seconds and the amount of time that guests spend
in the park is measured in hours and minutes. However, a guest may
appear the day you open the park, and still be there (financial)
years later.
I began to ask myself how Rollercoaster
Tycoon calculates time. This article is a summary of my findings
and conclusions from my study of various time factors in the game.
Findings
From various experiments, which I have
described here, I found the following:
 The ride time is not 'real'. If
you have a fast enough processor and a ride time is reported by
the game as 2 minutes then when you watch it on the screen, it
will take less than 2 minutes. On a slower processor it will take
longer than 2 minutes, but still be reported as 2 minutes in the
game.
 The ride 'hour' uses the same timeframe
as the ride time. For example a ride with a single train and a
ride time of 2 minutes (30 per hour), a capacity of 24 people
per train and a price of £3 per person will report an income of
£30*24*3 = £2,160 per hour. In fact it is a little less than
this as some time has to be spent unloading and reloading the
train and minimum wait times once loaded.
 A game financial 'month' is equal
to 7.5 ride or guest 'minutes' (equivalent to 1 ride or guest
hour equalling 8 financial months).
I learned this by starting with a
completely empty, closed park, and opened only a single shop on
the first of the month. The shop had a reported hourly running
cost of £49.60. On the first of the following month, the Financial
Window showed that my previous month's running costs had been
calculated as £6.20. This is one eighth of £49.60 so in one Financial
month I had incurred one eighth of a shop hourly running cost.
One eighth of an hour is 7.5 minutes, therefore one financial
month equals 7.5 ride minutes!
 Observing a single guest that arrived
on the first of a month, on the first of the following month,
(s)he was reported as being in the park for 8 minutes (seconds
are not reported) and on the first of the following month, (s)he
was reported as being in the park for 15 minutes. I concluded
that the guest and the ride time frames are the same. One Financial
Month equals 7.5 guest minutes and 1 guest minute = 1 ride minute.
 Turning to queue times for rides,
I started noting:
 the dates that guests joined the
end of queues, and the time they had been in the park
 the dates that they got onto the
ride, and the time they had been in the park
 the queue time that the ride was
reporting while the guest was in the queue.
 that the queue remained full at
all times while my monitored guest was in the queue. In other
words, the queue length was always the same while I monitored
the guest, and therefore the overall ride queue time did not
change while I was monitoring it.
Based on my observations, I have
reached an interesting conclusion. The reported queue time
does not reflect the typical actual queue time. The queue time
is either an underestimate or an overestimate depending on whether
the queue capacity is less than or greater than the ride capacity.
The game appears to be using a calculation
along the lines of:
 Total ride capacity (T) = Number
of trains*number of cars per train*Number of guests per car
 Number of guests in the queue
= (Q)
 Ride time = (R)
 Queue time = ((Q/T)+1)*R
The way the game calculates queue
time produces unrealistic reported queue times compared with the
actual observed queue times. The above formula is a guess which
produces approximately the same answer as the game, but I know
for a fact that the game factors in minimum and possibly maximum
wait times. More of this later. However, whatever formula the
game uses, the differences between reported and observed queue
times are significantly different for rides such as log flumes
that have many, small capacity, singlecar 'trains'. For example,
the Logger's Revenge log flume track design that comes with the
game has 9 trains (boats), 1 car per train, 4 guests per car.
This gives a ride capacity of 36 guests (9*1*4). The ride time
is 4 minutes 50 seconds (290 seconds).
For this particular ride when there
are 40 people queuing the game calculates queue time to be 10
minutes. ((40/36)+1)*290 = 10 minutes 12 seconds. However observation
shows that the typical actual queue time from the 40th person
joining the back of the queue to getting into a boat is closer
to 5 minutes.
To make things more complicated my
formula does not seem to apply to rides where the queue capacity
is less than the ride capacity. For example, Dodgem Cars with
a ride time of 3 minutes report a queue time of 1 minute until
3 queue tiles are placed. (3 queue tiles hold 15 guests, and the
ride capacity is 12). Once 3 queue tiles are placed the queue
time begins to be reported as 7 minutes.
Neither of these Dodgem times seems
to make any sense. If the ride time is 3 minutes and the queue
capacity is less than the ride capacity, then the minimum queue
time is 0, and the maximum is 3 minutes, with an average of 1.5
but the game reports a queue time of 1. One might expect the game
to report the average, rounded up to 2. Furthermore, with queue
capacity of 15 guests, by my calculations a guest joining a queue
has a minimum queue time of 0, the maximum is now 6, with an average
of 4.5, yet the game reports 7. Again, a worst case has been used
when the queue capacity is greater than the ride capacity. But
when the queue capacity is less than the ride capacity, the game
is understimating queue time.
As a test of whether the game's queue
time calculation really is flawed, I added a Logger's Revenge
ride to a very busy park. I built a queue to hold 40 guests, set
the ride price to zero so that queue would always be full, and
set the minimum wait time to 240 seconds (4 minutes). I was expecting
the ride's queue time to be really high. The 37th, 38th, 39th
and 40th guests in the queue should get into the 10th boat to
arrive at the station (4 people per boat). With such a long minimum
wait time, the station always has a backlog (sorry!) of boats
so that as soon as one boat leaves there is already another one
ready to load guests. The 9 boats before the 10th boat all have
to wait for 4 minutes each before they start the ride, and so
I would expect the queue time for the 40th guest in the queue
to be 9*4 = 36 minutes. Observation of a guest showed that this
was correct, but the ride queue time reported by the game was
20 minutes!
There is clearly some poor mathematics
in the game being used to calculate queue times. However, in fairness
to Chris Sawyer, the most realistic calculation would be incredibly
complex. It would have to take into account average queue lengths
over a period, number of trains, ride time, time to unload and
load trains, minimum and maximum waiting times once loaded, whether
the ride can leave fully or partially loaded, ride reliability
and downtime, weather, etc.
Nevertheless, I think that a more
realistic queue time for the game to report would be:
 Total capacity of ride (T) calculated
as described above
 Ride time (R)
 Number of guests in the queue
(Q)
 Queue time = (Q*R)/T
This formula assumes that there are
always enough people in the queue to fill a train when it arrives
at the station, that trains are evenly spaced around the ride,
and disregards the mimimum wait time. However, in my parks that
is a fairly accurate description of what happens.
In the Loggers Revenge example above
where there were 40 people in the queue, ride time is 290 seconds
and ride capacity is 36, queue time would be (40*290)/36 = 322
seconds or nearly 5 minutes 30 seconds. In the Dodgems example
this would give (15*180)/12 = 225 seconds or 3 minutes 45 seconds.
Both these calculations fairly accurately reflect the actual times
that I observed.
Conclusions
I now know the difference between ride
time, and financial time. A financial month is equivalent to 7.5
ride minutes, 1 eighth of an hour. Guest minutes are calculated
in the same way as ride minutes. Therefore I can now accurately
predict the effect on my finances of building a ride.
For example, I know that using the
design for the Shuttle Loop steel coaster, I can build it for £1,195
on flat land. By observation, in a busy park with a fully charged
queue, the ride will take around 2,424 guests per hour. The running
costs are £72 per hour. So at £2 per guest (the default) my income
is £4,848 per hour which after running costs means that the profit
is £4,776 per hour. Dividing this by 8 gives me the profit I can
expect in a financial month. In this case it is £597 per financial
month. This means that if I double the default fare my profit will
be £1,194 and I will recover the cost of the ride in the same month
that I build it. If I treble the price to £6, which I know guests
are prepared to pay in most scenarios, I will pay for the coaster
and have around £600 extra in the bank. Every month after that just
from this one ride I will have £597*3 = £1,791 extra in the bank
providing that I maintain the ride and that guests remain happy
to pay a fare of £6. But with a tidy profit after only 1 month,
fare reductions to the default £2 will still add £597 per month
to my profits on this ride. Perhaps much lower fares after a month
will raise satisfaction and park value and attract even more guests!
I also know that with any ride that
has a queue time greater than 7.5 minutes (1 financial month), there
are some guests in that queue who will earn me no income that month.
But I know that where the queue capacity is less than the ride capacity,
the game is going to underestimate the queue time, and when the
queue capacity is greater than the ride capacity, the queue time
is going to be an overestimate, especially on rides with lots of
small capacity trains.
To help me with this problem, I have
an alternative calculation for queue time which appears to be more
realistic. If this alternative calculation gives me a queue time
of greater than 7.5 minutes, I will consider shortening the queue
so that the guests have a chance to give me more income in that
particular month by standing in shorter queues!

