Welcome to the FAQ for The Ride: Minecraft Intercontinental Railway III. This page should (hopefully) answer at least some of the questions this video prompts people to ask.
How long is The Ride, really?
The Ride runs from 0,0 to 1000000,1000000, which when one does a little Pythagorean math gives a result
of 1,414,213 blocks, measured at its dead-center. Since a Minecraft block is one meter cubed, this means
that The Ride is 1,414 kilometers, or 879 miles, in length.
It is roughly one-sixtieth of the maximum length possible to construct anything in Minecraft at the time of this writing. The track is longer than Texas, and is almost as long as California, compared against both at their longest points. It's also longer than real-life mine tracks - Wikipedia mentions the longest 900mm gauge mine rail system as being the Leipzig-Altenburg lignite field in Germany, at 726 km in total length.
Is this a world record?
The Ride is, as of when it was posted publicly, the longest confirmed-length minecart track ever made by one person in single-player mode. Only one other publicly known track is longer, and it was built on a server with multiple people.
How fast is the cart moving?
Throughout most of the ride, the cart moves at 360 meters per second, or roughly 1,296 KPH, or roughly
805 MPH. This is slightly above the speed of sound at sea level, or roughly triple the speed of most of
the fastest bullet trains.
This video might convey how fast The Ride actually is...
Why did you pick that speed?
I tested several different speeds, and 360 m/s felt super-fast without being so fast that everything shot past too quickly to be seen, even with the framerate set to 60 FPS. 480 m/s, for example, stopped feeling like a smooth run and started feeling like terrain was snapshotting past.
Why did you make the cart move so fast?
I don't think anyone wants to sit through a 49-hour minecart video at normal 1.7.x minecart speed, not including lag. Even with the brief flirtation with "superfast" carts the ride would still take 20 hours to ride end-to-end.
How many resources would it take to make a track this long in survival mode?
Based on the vanilla recipe, to craft the minecart rails alone would require 1,007,617 iron ingots and 167,936 sticks. Based on typical ore generation amounts, this means having to extract every single iron ore block from probably a couple hundred thousand chunks. Also, based on a vanilla furnace taking 10 seconds to smelt one iron bar, it would take 7.6 years to smelt this much iron with one furnace. Based on all of this, building this long of a track "the hard way" (read: farming and crafting everything, no creative mode or /give) would take a dozen people a few years. Your "based" might vary.
That music - what is it, who made it, and where can I get it?
The soundtrack for The Ride is from the album "Solar Echoes" by Nigel Stanford, who graciously granted
me permission to make use of several of its tracks. If you'd like to pick up a copy, drop by his website:
The man does some amazing things, both musically and scientifically - the Cymatics videos are mesmerizing...
The video stutters in places. What gives?
More than five thousand lag-induced duplicate frames were found and removed, along with over three hundred frames where some sort of artifacting or glitching occurred (most commonly in the form of the track vanishing or being retextured with random block textures). I didn't get all of them, and the ones I missed are the cause of the occasional stutter. (This is actually the THIRD upload - the first one has far more roughness to it.)
Why is the video so grainy/blurry in places?
Video compression relies on the idea that only part of the image is usually changing, and more often than not
the change is in the form of a panning motion so part of the previous frame is still on screen, it's only moved.
For a video like this, the only thing that doesn't change from frame to frame is Steve's hand - even the track
has changes flashing by (e.g., the redstone torch and boosters every few frames). It's very tough to compress a
video with this much movement, and most compression methods don't handle it well. The minimally-compressed video for
The Ride is 7.5GB in size as a result, and that's as a constant-bitrate 20mbps H.264 video file. Transcoding
this for upload to Youtube dropped that down to almost 4GB but caused a lot of quality loss.
It took three tries to make it look as good as it currently does on Youtube. There's just too much movement to transcode into something Youtube wants, and Youtube's own transcoding isn't set up with this sort of thing in mind.
Creative mode? Really? Coward!
Oh yes, I wanted to try to build something this large with a non-zero chance of Creepers blowing it up, Endermen stealing parts of the track, getting shot at constantly by skeletons, etc. How about "no."
The Game Setup
How big is the map? Can I download it?
The map is over 60GB in size. Yeah, you read that right, over sixty gigabytes. It's almost fifteen thousand regions. We are looking into hosting options for it, but that's a LOT of storage and bandwidth so hosting cost is definitely a factor.
What mods or modpack did you use?
The modpack used was The 1.7.10 Pack, version 0.8.0, by "Hi it's me," which is available through the Tekkit Launcher. The pack also has its own website.
Why use a modpack, why not just do this in vanilla?
Vanilla would have been far easier, but far more boring. Using a large modpack like 1.7.10 Pack adds a lot to the game aesthetically, such as extra biomes, additional structures, and just generally more variety. (It also greatly complicates things, as huge modpacks make Minecraft an unstable memory hog.)
The Building Process
How was the Ride built?
The Ride was built in sections that were designed to interlock diagonally. These were then laid by a combination of AutoHotKey scripts and WorldEdit commands.
How long did it take to build?
It took three weeks to pregenerate the terrain, which was done entirely in-game, another three weeks
to place the 14,000+ track segments, and ten days to ride the track in a minecart from end to end to
find and fix problems. During the find-and-fix phase twelve sections of track had to be removed and
The entire process, from the first time seeing "building terrain" to the upload of the video, took almost five months and was performed entirely by one person with no outside assistance at any point in the process.
How many people and computers were involved?
The entire project is the work of only one person, with no outside help, using one computer, a rather powerful Asus gaming laptop. The video shoot was done with three computers so it took less time than only using one would have, but again only one person was involved.
Couldn't you do this on a Bukkit/Forge server in like five minutes?
No, although this is a frequently-repeated idea, that's not how it works. It's actually pretty hard to megabuild in Minecraft because although the game supports huge build areas it doesn't like moving rapidly around them, and terrain has to be pregenerated before you can consider spamming WorldEdit /paste commands everywhere. Chunk load times alone are a major limiting factor. And then add a modpack into the equation.
The Recording Process
Why 720p instead of 1080p, etc.?
Everything was shot at 1280x720 resolution for two reasons. First, storage requirements - jumping from 720p to 1080p instantly makes everything 50-75% larger and I was already colliding with storage space limits as it was. Two, only one of the machines I was using to record would do 1920x1080, where the other two were 1680x1050, so recording at a higher-than-desktop resolution would require trickery and Minecraft didn't care for such trickery - it promptly crashed every time I tried various things/mods or simply opened it up in an oversized window. So 720p was the highest resolution I could run with that would accommodate the equipment I used.
Why 60 FPS?
60 FPS allows faster travel speed without the terrain shooting past the camera so quickly that it's tough to discern what's shooting past. At 30 FPS, anything past 240 m/s looked like it was snapshotting into and out of view instead of moving along somewhat smoothly, and at 60 FPS 480 m/s did likewise. 360 m/s @ 60 FPS seemed a good compromise of speed versus framerate versus watchability. Compare the video at 30 versus 60 and this should become more obvious.
The Ride doesn't move like all of the other fast-run timelapse minecart videos I've seen. How did you make it?
The short explanation is that I reconfigured Minecraft rather heavily, and used the game as a still-frame renderer. The resuling stills were then combined to produce videos. Essentially it's all-digital stop-motion animation. Doing so allowed me to accurately simulate a minecart at mach one plus without having to try to force the game to actually move a minecart that fast. This is important because even with mods that are specifically designed for shooting video within Minecraft, it's not possible to emulate high speeds in-game. Minecraft simply cannot keep up with Steve moving 6 blocks for each sixtieth of a second - that's more than a chunk of terrain covered per game tick.
So you didn't use Minema, etc. to do this?
Mods like Minema cannot force the game to work faster than it does, and Minecraft can't handle having its
player-character move more than about 12 meters per second. It can take the game 30-90 seconds to load chunks
as you move, and if you're moving a chunk every twentieth of a second or so, the game can't even begin to keep
That said, Minema and CameraMod were used in this video to produce the closing credits.
So how did you actually shoot the video then?
The actual shooting process is essentially summed up thus: move Steve, wait for Minecraft to finish rendering the environment, take a screenshot, rinse and repeat. The moving was done with AutoHotKey and WorldEdit commands, and I had to create a custom teleport script for WorldEdit that emulated 1.8.x+ teleport commands in 1.7.10 since 1.7.10 didn't have pitch and yaw support for the native /tp command.
How long did that take?
Excluding lag, it took on average about 40 seconds for Minecraft to fully render the scenery for each single
frame of video. The vast majority of this is chunk loading times, and even with OptiFine, this is the single
biggest time sink of the entire process.
Each ten seconds of video (600 frames @ 60 FPS) required around 6.5 hours to shoot. The 2,700+ seconds of ride time took about 1,800 hours to shoot, and three dozen of the 300-some-odd segments had to be reshot for various reasons. Including intros and outros and credits oh my, it took three computers almost three months to shoot everything - I started the shoots in early October and wrapped the last segment in mid-December, and then spent a week reshooting several thousand frames that caused stuttering.
How much disk space did that require?
Each ten-second segment required six gigs of stills and produces a 50 megabyte H264 movie file. Over six gigabytes' worth of these segment files were required to produce the finished Ride. (To save space, each time stills were converted into segments the stills were deleted. If not for this, it would have taken a few terabytes to hold everything.) To conserve space as much as practical, everything was shot in 720p resolution, and the videos were encoded to H264 at 20Mbps CBR to maximize quality.
What hardware and software did you use?
Hardware-wise, the build was done on an upgraded Asus G75 gaming laptop. Recording was shot on three different
PCs with a mix of hardware.
Software-wise, the stills were renamed by Bulk Rename Utility, and encoded with ffmpeg using AnotherGUI as a frontend. Some audio mastering was performed using Audacity. Automation was handled by AutoHotKey. The finished product was built in Adobe Premiere Essentials, and then moved over to a trial of Premiere Pro for the final export. A trial of After Effects was also used to build the speedometer and closing credits. (I used a trial because I don't have the money to spare for a Creative Cloud subscription.) Transcoding for upload was handled by handbrake.
Why? Just, why?
Because I could!
You need a life/girlfriend!
Not really a question, but this sentiment is expressed frequently.
The nice thing about automating the process is not having to babysit the process. This frees up time for doing, well, "other things."
Besides, gaming is only one of my hobbies, and since I have a full-time job I like to get some time in on a game to help me unwind from the day.