OpenTTD 16Backward trains.
Forward planning.
OpenTTD 16 is still a beta.
Choose your track before moving your world.
OpenTTD 15.3 remains stable while 16.0-beta4 is in testing. Understand reversing trains, multiplayer fixes, save files and the free download route.
A train reaches a terminal, changes direction and leaves with its locomotive suddenly at the opposite end. For longtime OpenTTD players, that visual shortcut is familiar enough to disappear into the scenery. The next major version challenges it. Trains can move backward, and players who choose a stricter setting must think about how a real arrangement of tracks allows a train to turn. What looks like a small animation change can become a new network-design problem.
There is an important qualification before rebuilding a railroad: OpenTTD 16 is not the stable release. On October 19, the project's official download pages identify 15.3 as stable and 16.0-beta4 as the testing release. This guide separates the two, explains the changes that matter to an existing transport empire and sets out a way to explore them without confusing a test with a migration. The screenshots are real, credited examples from several earlier versions and configurations, not a claim that we personally benchmarked the current beta.
ROUTE NOTE / 01Two download tracks serve different purposes
The official stable page lists OpenTTD 15.3, released April 4, 2026. The testing page lists 16.0-beta4, released September 20. Both are current in the sense that the project offers them, but they answer different questions. Stable is the established release line. Testing is where players can try the next line and help expose problems before it becomes the regular release.
That distinction matters most when several people share a game. A new feature can be attractive to one participant while the rest of a group wants an uninterrupted evening with an existing map. Agreeing on a version is therefore part of planning the session, not an administrative detail to discover after everyone arrives. A screenshot from a beta feature announcement does not tell you which executable a friend's server is running.
For a player with a long-running solo save, the choice is similarly practical. If tonight's goal is to finish a freight corridor, the stable installation and familiar world provide one kind of continuity. If the goal is to understand reversing behavior, a separate experiment provides a better setting. These are different activities, and neither needs to displace the other. You can be curious about the next release without turning the only copy of a favorite network into a test case.
Sources: OpenTTD stable download: 15.3 · OpenTTD testing download: 16.0-beta4
ROUTE NOTE / 02Why beta4 arrived one day after beta3
The September 20 announcement is unusually focused: beta4 fixes a multiplayer desynchronization introduced in the previous day's beta3. Specifically, terraforming land could cause a desync and eject a player from the game. The announcement describes a targeted hotfix, not a declaration that every multiplayer problem has been eliminated or that version 16 has left testing.
A desync is different from simply noticing a slow animation or a crowded junction. In a shared simulation, the participants need to maintain a consistent game state. A bug that breaks that agreement is a software problem, even if the visible symptom is that someone disconnects. The useful response is to identify the exact version and triggering action rather than assume that buying a faster computer would resolve it.
This also illustrates why the final part of a version number matters. Saying that a group is using 'the 16 beta' leaves out a meaningful distinction between beta3 and beta4. Record the complete release name when asking for help or comparing behavior. If a report describes the specific terraforming issue fixed in beta4, first establish whether the affected session actually used beta4. The same symptom on a different build or under different conditions is not automatically the same defect.
ROUTE NOTE / 03Push-pull appearance is not the same as a new penalty
The project's June explanation separates two ideas. A train with a driving cab at its rear can reverse without the old instant flip, continuing at full speed. This visual improvement applies automatically. A separate, optional rule removes the instant flip from trains that do not have a rear cab; those trains then reverse at a restricted 20 mph. Leaving the default behavior enabled avoids that optional network challenge.
For American readers, a cab car is the useful mental model. The engine does not have to appear at the leading end for a train to be controlled from that end. The relevant question is whether the train has the appropriate driving position, not merely whether a locomotive graphic is visible in front. Add-on vehicle sets can make that distinction more detailed, which is one reason a screenshot alone is not a complete specification.
The design consequence is conditional, not universal. A terminal that works under the default settings does not become obsolete just because the software can depict backward movement. But choosing the stricter rule makes a train's orientation part of the operating plan. Before changing a network, identify which of those two experiences you want. 'More realistic' is a preference, not a requirement that every existing player must accept to continue enjoying the game.
Sources: Backward-train design explanation
ROUTE NOTE / 04A terminal becomes a question about movement
Consider a simple example: a train enters a dead-end platform with a locomotive at one end and no driving cab at the other. Under a rule that restricts backward running, its next departure is no longer just a matter of clearing the platform. The route out of the station must account for its orientation. That can turn an apparently local station decision into a problem involving the approach tracks, neighboring junctions and available land.
There are several broad approaches to that problem. A through station keeps trains moving onward. A loop can turn a train around. A triangular track arrangement can reverse its direction through a sequence of moves. The project's explanation discusses these patterns, but choosing among them is not a contest to find one universally best diagram. The useful design is the one that fits the particular traffic, terrain and operating rules.
A loop may occupy land that a compact terminal cannot spare. A more compact arrangement can introduce crossing movements that need to be understood. A through route may fit a regional line but not a station built at the edge of the map. These are planning tradeoffs, not performance results measured here. Sketch the intended movement before laying expensive track, and distinguish a route that is physically connected from one that trains can use in the intended sequence.
An experiment can be small. Use one train and a short route to watch its arrival, reversal and departure. Add more traffic only after the basic movement is clear. This makes a failure legible: you can see whether the difficulty comes from orientation, routing or another train occupying a section. A sprawling network is impressive to look at, but it is a poor first laboratory when several unfamiliar rules are changing at once.
Sources: Backward-train design explanation
ROUTE NOTE / 05The beta also changes how you read and build a world
The first beta announcement includes improvements beyond train movement: searchable dropdown lists, a combined vehicle-preview window, more control over generated terrain and adjustments to map details. It also introduces a setting for the aging rate used in cargo payments, intended to make slower vehicles on large maps more viable. These changes affect the work of managing a world as much as its appearance.
The common thread is friction. A large collection of available objects is less useful if finding one interrupts every building decision. Numerous preview windows can divide attention. A large map can create distances that make an otherwise appealing transport idea awkward under existing economic settings. Interface and simulation adjustments address different parts of that experience, so they should not all be summarized as 'better graphics.'
For a returning player, the practical question is which friction matters in the current project. If choosing station pieces is the recurring obstacle, a searchable interface may be more consequential than a new visual effect. If the pleasure lies in building long, slow routes, an economic setting may change the kinds of worlds worth attempting. Neither observation proves a particular route will make money. It identifies a feature to investigate with a clear purpose.
Sources: Beta1 feature announcement
ROUTE NOTE / 06Backward ships require the right content, too
The beta3 announcement adds support for NewGRF authors to create double-ended ships that move backward instead of turning around at each dock. That wording matters. Engine support for a capability is not a promise that every existing ship in every vehicle set will immediately behave differently. The content author and the selected set remain part of the picture.
The same release introduces a Screensaver Mode that follows random vehicles around the map, available from the question-mark menu, along with additional coastal details. Watching a network can be a pleasure in its own right, especially when a player has spent hours arranging routes that finally run without constant intervention. But watching automatically selected vehicles is not the same as a diagnostic tool proving that all services are efficient.
If you are evaluating a specific ferry route, keep the question narrow: which ship set is active, does that ship support the new behavior, and what happens at the dock? If you are simply enjoying a finished world, the observational mode serves another purpose. A feature can be worthwhile without needing to become a productivity tool. The important thing is not to confuse an aesthetic tour with evidence about the entire network.
Sources: Beta3 feature announcement
ROUTE NOTE / 07NewGRFs are part of the game you are loading
NewGRFs can change vehicles, industries, cargo, buildings and other parts of OpenTTD. They are not merely interchangeable wallpaper. The official wiki explains that the selected NewGRFs are integral to a save and should be chosen before starting a game. It also warns that not all combinations work together. A beautiful screenshot showing an industry overhaul is therefore not a reliable picture of what a default installation will contain.
That distinction is visible in this article's archival images. Some show FIRS, an industry replacement set; another shows a historical patchpack. They illustrate the range of customized worlds, not the unmodified feature list of beta4. A patchpack can change the program itself, while a NewGRF changes supported game content. Treating both as simply 'mods' can hide compatibility questions that matter when sharing a save or reproducing a problem.
Before experimenting, record the exact add-on names and versions associated with the world you care about. If you want to test a new engine feature, beginning with a simpler configuration reduces the number of explanations for unexpected behavior. That is not an argument against complex modded games. It is a way to separate the pleasure of building a richly customized world from the narrower task of finding out what one change does.
Sources: NewGRF manual and configuration cautions · FIRS project and source information
ROUTE NOTE / 08A backup should survive the experiment
The project's documentation emphasizes support for loading older saves in newer official revisions. That is not a promise that a save written by a newer version can be opened again by an older one. The source code explicitly rejects save formats newer than the running program understands. A successful load into the beta should not be treated as proof of a reversible round trip.
The practical safeguard is straightforward: keep an untouched copy before experimenting and give the experimental save a clearly different name. Avoid relying on a single file that is repeatedly overwritten. If the original world depends on particular add-ons, preserve the information needed to identify those, too. This advice concerns the player's own files; it is not an instruction to distribute someone else's scenario or graphics without checking their terms.
A useful test record can be only a few lines: original version, test version, save name, active content and the specific setting changed. If an experiment fails, those details tell you what was actually tested. They also prevent a common misunderstanding in collaborative play, where one person thinks everyone is still using the original save while another has already continued it in a different release.
Sources: OpenTTD repository: compatibility statement · Save-format version check in source
ROUTE NOTE / 09Free software and a store listing are different questions
OpenTTD's distribution changed in 2026, but its project explained that the direct website download remains free. In its March statement about Steam and GOG, the team said new players on those platforms would need to purchase Transport Tycoon Deluxe first, while existing access and the separate free website route were part of the arrangement. The team described a collaboration with Atari and said the project retained its independence.
For a new player, the useful distinction is between acquiring software through a particular storefront and acquiring it from the project's own site. A storefront condition does not, by itself, establish that the open-source project has disappeared or that every download now requires payment. Conversely, the availability of a free direct route does not mean a store must offer identical packaging or terms.
Before spending money, read the current listing and decide which route you actually want. This article does not quote a current store price or promise that a bundle has a particular discount. The direct download pages and the project's explanation are the starting points for understanding the options. A discussion about preserving a classic game can be emotionally charged, but the purchase decision still benefits from separating licensing, distribution and convenience.
ROUTE NOTE / 10The base game needs graphics, but not necessarily the old CD
OpenTTD's download page explains that a separate base graphics set is required and can be obtained on first run. OpenGFX provides an open graphics route; OpenSFX and OpenMSX supply optional sound and music. Original Transport Tycoon Deluxe data can also be used by people who own it, but those original files are not simply supplied as a free download by the project.
This matters when helping a friend start playing. Sending only the program name may leave them wondering why the setup asks for another component. Explain the distinction between the engine and its base assets before they assume something is broken. The open graphics route is also different from selecting a specialized vehicle or industry set after installation. One supplies the basic presentation; the other changes the chosen game content.
For screenshots and videos, the rights question follows the same layered structure. OpenTTD's creator guidance permits commercial and monetized content using the core game and open base sets, but it does not automatically cover every third-party add-on or the original commercial graphics. A file being easy to download is not the same as permission to republish it. The credits attached to the images here identify the relevant creators and licenses rather than treating all game imagery as interchangeable.
Sources: OpenTTD stable download: 15.3 · Content-creation guidance
ROUTE NOTE / 11A useful bug report starts with a reproducible situation
The development team asks players who find bugs to report them through its issue tracker. Its contribution guidance stresses useful details and a situation that can be reproduced. For a simulation game, a save near the problem can be more informative than a long description of everything that happened during an evening. The point is to help another person reach the same failure, not simply to register that the experience was frustrating.
Before filing a report, note the complete version, operating system, whether the game was single-player or multiplayer, and what happened immediately before the problem. Separate what you observed from your theory about its cause. 'The client disconnected after this terrain change' is an observation. 'The graphics pack broke the network code' is a hypothesis that needs evidence. Clear language makes it easier for maintainers to ask the next useful question.
A screenshot can show a message or an arrangement of tracks, but it cannot always capture the simulation state that produced the issue. Likewise, an old screenshot of a similar-looking station does not prove the same bug exists in the current release. The project also asks people not to file core-game issues about unofficial patchpacks or third-party add-ons. Check existing reports and release notes before adding a duplicate. If sharing a save or log, review it for information you do not want public and follow the project's current reporting instructions.
Sources: Contribution and bug-report guidance
ROUTE NOTE / 12Choose the experiment before choosing the version
A good first session with version 16 can have one specific goal: observe a cab-equipped train reversing, compare a terminal under the optional rule, or examine a supported double-ended ship. Keep the map and content simple enough to understand the result. The aim is not to establish that the beta is universally better or worse, but to discover what one announced change means in practice.
A good ordinary session can be equally deliberate: continue a stable-release world, improve a junction or invite friends into a version everyone has agreed to use. There is no requirement to participate in testing to be part of an open-source game's community. Players who prefer a predictable evening and players who enjoy reporting regressions contribute to different parts of the same ecosystem.
OpenTTD's next version is interesting because it connects the visual language of transport with the operational choices beneath it. A train moving backward can be a more convincing animation, an optional design constraint or both, depending on the settings and content. Keeping those layers distinct makes the update easier to understand. The best starting question is not 'Should everyone upgrade?' It is 'What do I want to learn or build tonight, and which release supports that goal?'
Sources: OpenTTD stable download: 15.3 · OpenTTD testing download: 16.0-beta4
Comments
Post a Comment