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.

From various experiments, which I have described here, I found the following:

1. 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.
2. The ride 'hour' uses the same time-frame 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.
3. 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!

4. 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.
5. 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, single-car '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 down-time, 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.

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!