Game Mechanics for Speed Running
1 year ago
United States

#1. By now a lot of people (Jennyfluff 2 years ago, and Marcel <2 months ago) have noticed that in OpenRCT 2 Fast-Forward% runs, the maximum speed at which the game will run depends on technical factors, like your hardware and other processes being run simultaneously (e.g. recording software).

-The same is true of normal speed.- If anyone gave you a specific time for ANYTHING, preface it in your mind with "around," "about," or "approximately."

Examples: Marcel stated in RCT 1 Park Value is recalculated every 12.8 seconds. Your time may vary. There's plenty of evidence against a fixed 12.8s already on this site. In a video, Marcel gives the length of a day in RCT as 13.21 or 13.65 seconds, depending on the number of days in the month. I timed how long it takes to get to 28 May (the day you unlock the 10th coaster) in an empty Razor Rocks (twice), and it was a full minute faster than in my 22-minute speedrun. So, more like 13+ seconds per day. And, obviously, it's influenced by how much stuff you have going on in your park. (Tying those 2 together, here's a little nugget for you: RCT1 doesn't show the day, only the month, but I caught Park Value updating on the same frame as the change in month. Coincidence? Could update 32 times a month, idk.)

Thus, the variable speed of the game is a factor at play in every scenario in every speedrun category.

The Windows compatibility mode you choose might affect it. Not that anyone would, but if you experiment, be sure to have save files ready to quickly re-unlock all the scenarios.

#2. Scenario Completion checks are performed about every 14 seconds, starting the moment you first open the scenario.

Yeah, pretty darn simple once you've ruled out what it's not based on.

#3. EIN (Excitement, Intensity, Nausea) calculation has the following properties:

By "Ride ID" (good luck finding that anywhere on the internet) Marcel was referring to the order of rides based primarily on what was built first. In Finish-5 scenarios, this is simple: Roller Coaster 1, Roller Coaster 2, etc. They receive EIN calculations in that order. Elsewhere, if you delete "Roller Coaster 1" and build a new "Roller Coaster 1", the new one usurps its place as first in line. Renaming does nothing.

The calculations "take" anywhere from 0.2 seconds for just a couple of station tiles to 2 seconds for an average-sized coaster, and beyond. A 1.5 second interval is average for a Finish-5 coaster. If you finish developing your coaster design and measure the EIN interval, you can expect it to be the same in any playthrough, +/- 1 frame. (However, on Dusty Desert I painstakingly duplicated the terrain around Rollercoaster 1 & 2 to build copies on the other side of the map--and got drastically different EIN intervals.)

The last coaster's EIN update is followed by an approximately 6.8 second refractory period where no EIN calculation is being done at all. Then, the cycle begins again with the first ride/coaster. Even if no changes are made to the rides or park, it keeps calculating them in this way, taking the same amount of time. 6.8 seconds off, 9 seconds to calculate 5 EINs, 6.8s off, etc.

Calculations are performed for rides which are in testing mode or open. Closed rides are not included in the calculation cycle. They are thrown into the mix as soon you hit test; it doesn't wait for them to complete a circuit.

Normally a ride should complete its first circuit before its calculation interval starts to receive the EIN. Sometimes a ride can arrive in the middle of its interval and get its EIN in half the time.

As for when the cycle starts, good luck finding correlation with anything. You're better off trying blindly over and over hoping the EIN lines up perfectly than running the numbers back to try to work out when you should start testing each ride.

#4. Pausing the game pauses everything: Park Value calculation cycles, Scenario Completion checks, EIN rendering.

United States

And, obviously, it's influenced by how much stuff you have going on in your park.

Actually... this is not obvious at all, and likely false. Here is an update.

"12.8 seconds," as stated by Marcel, is key. Here's how the game is coded:

  • 40 calculation "ticks" per second
  • 512 ticks per "day" = 12.8 seconds
  • 32 "days" per month = 6 minutes, 49.6 seconds

If your game goes slower than that, it's a deviation from how it's supposed to be.

  • Every 16 "days" you are charged for ride operating costs
  • Every 8 "days" you are charged for wages, research, & interest (and get notifications about not building exit paths, etc.)
  • Every "day" Park Value & Park Rating are updated, and scenario completion is checked (if applicable).

Returning to the subject of time, here are the culprits:

Most significant: Computer (+100%) Solution: Get/use a better computer.

Chris Sawyer designed this game to run on machines from 1995, yet it somehow challenges modern computers. I'd say you need a decent gaming desktop to run it at full speed. Especially on weaker computers, other processes can slow RCT down. On a basic consumer laptop running Fall Guys, browsers, etc., I was able to make RCT run twice as slow (1 month taking over 14 minutes).

2nd most significant: Resolution or Window Size (+10%) Solution: Use tiny window.

A comfortable view can cost you up to 1.25 seconds per "day", 39.625 seconds per month. (Times may vary based on your computer.) Can you blame Marcel for quitting over this?

Less significant: Random/mystery (+0.24%)

(All else equal, the speed varied this much.) I don't know. Probably still computer issues. Or differences in random game events? Zoom level? Sprites? Player input?

No clear significance: Compatibility mode (0%). Tests varied by a frame at times.

When I told Marcel about resolution affecting speed, he told his Twitch stream, and there was some brainstorming between he and zgeez about changing how we do things here, i.e. Normalizing speed. E.g. The guys who completed Diamond Heights in 40 seconds would be equal to those who completed it in 38 seconds, because they all used the start of Day 4 PV update.

Issue: It's not a one-size-fits-all solution. Having more seconds to work with is often an advantage. 38 seconds or 40 seconds to place those shuttle loops is pretty much the same thing, but 25.6 seconds is noticeably harder than 27 seconds for DH runs. Now consider Dusty Desert, where I slid in right before Day 9 in max res. A faster running game would clock in slower AND at a later day (Day 10).

United States

I forgot to mention how that applies to E.I.N. calculation. Calculations are done 40x per second, but other than that have no relation to the "days". The "6.8 second refractory period" is from the game checking the empty ride ID's from 6 to 255 or so. 250/40 = 6.25 (seconds). (Modified by my game's speed in 1024x768 + no way to know when this period ended & Ride 1's calculation began).

Game stats
Followers
91
Runs
477
Players
50
Latest threads
Posted 4 months ago
6 replies
Posted 1 year ago
0 replies