openrct2/opengraphics

A project to create free replacements for the graphics in Rollercoaster Tycoon 2

OpenRCT2

An open-source re-implementation of RollerCoaster Tycoon 2, a construction and management simulation video game that simulates amusement park management.

---

---

Download

Latest release	Latest development build

---

Chat

Chat takes place on Discord. You will need to create a Discord account if you don't yet have one.

If you want to help make the game, join the developer channel.

If you need help, want to talk to the developers, or just want to stay up to date then join the non-developer channel for your language.

If you want to help translate the game to your language, please stop by the Localisation channel.

Language	Non Developer	Developer	Localisation	Asset Replacement
English
Nederlands

---

Contents

• 1 - Introduction
• 2 - Downloading the game (pre-built)
• 3 - Building the game
  • 3.1 - Building prerequisites
  • 3.2 - Compiling and running
• 4 - Contributing
  • 4.1 - Bug fixes
  • 4.2 - New features
  • 4.3 - Translation
  • 4.4 - Graphics
  • 4.5 - Audio
  • 4.6 - Scenarios
• 5 - Licence
• 6 - More information
• 7 - Sponsors

---

1. Introduction

OpenRCT2 is an open-source re-implementation of RollerCoaster Tycoon 2 (RCT2). The gameplay revolves around building and maintaining an amusement park containing attractions, shops and facilities. The player must try to make a profit and maintain a good park reputation whilst keeping the guests happy. OpenRCT2 allows for both scenario and sandbox play. Scenarios require the player to complete a certain objective in a set time limit whilst sandbox allows the player to build a more flexible park with optionally no restrictions or finance.

RollerCoaster Tycoon 2 was originally written by Chris Sawyer in x86 assembly and is the sequel to RollerCoaster Tycoon. The engine was based on Transport Tycoon, an older game which also has an equivalent open-source project, OpenTTD. OpenRCT2 attempts to provide everything from RCT2 as well as many improvements and additional features, some of these include support for modern platforms, an improved interface, improved guest and staff AI, more editing tools, increased limits, and cooperative multiplayer. It also re-introduces mechanics from RollerCoaster Tycoon that were not present in RollerCoaster Tycoon 2. Some of those include; mountain tool in-game, the "have fun" objective, launched coasters (not passing-through the station) and several buttons on the toolbar.

---

2. Downloading the game (pre-built)

OpenRCT2 requires original files of RollerCoaster Tycoon 2 to play. It can be bought at either Steam or GOG.com. If you have the original RollerCoaster Tycoon and its expansion packs, you can point OpenRCT2 to these in order to play the original scenarios.

OpenRCT2.org offers precompiled builds and installers of the latest master and the develop branch. There is also a Launcher available for Windows and Linux that will automatically update your build of the game so that you always have the latest version.

Flathub offers flatpaks for Linux distributions that support this application distribution system:

• Latest release

Some Linux distributions offer native packages already. These packages are usually third-party, but we're trying to resolve issues they are facing.

• Arch Linux: openrct2-git (AUR) and openrct2 ([extra] repository)
• Ubuntu PPA: develop branch (nightly builds)
• openSUSE OBS: games/openrct2
• Gentoo (main portage tree): games-simulation/openrct2
• NixOS (nixos-unstable channel): openrct2
• Fedora 28 i386/amd64: openrct2

Some *BSD operating systems offer native packages. These packages are usually third-party, but we're trying to resolve issues they are facing.

• FreeBSD: games/openrct2
• OpenBSD: games/openrct2

---

3. Building the game

3.1 Building prerequisites

OpenRCT2 requires original files of RollerCoaster Tycoon 2 to play. It can be bought at either Steam or GOG.com.

Windows prerequisites

• Visual Studio 2022 (Enterprise / Professional / Community (Free))
  • Desktop development with C++
• MSYS2 MinGW Toolchain. The toolchains with supported dependencies are mingw-x86_64, mingw-xi686, ucrt-x86_64, clang-x86_64, and clang-xi686, each of these require the $MINGW_PACKAGE_PREFIX and msys and clangarm-64 are lacking packages for some dependencies
  • sdl2 (only for UI client)
  • freetype (can be disabled)
  • fontconfig (can be disabled)
  • libzip (>= 1.0)
  • libpng (>= 1.2)
  • speexdsp (only for UI client)
  • curl (only if building with http support)
  • nlohmann-json (>= 3.6.0)
  • openssl (>= 1.0; only if building with multiplayer support)
  • icu (>= 59.0)
  • zlib
  • gl (commonly provided by Mesa or GPU vendors; only for UI client, can be disabled)
  • cmake
  • benchmark (optional)
  • innoextract (optional runtime dependency; used for GOG installer extraction during setup)
  • libogg
  • libvorbis
  • flac

See the wiki for the actual package names used in pacman.

macOS prerequisites

• Xcode Command Line Tools
• Homebrew
• CMake (available through Homebrew)

Linux prerequisites

• gcc (>= 8.0) or clang (>= 10.0) (for C++20 support)
• sdl2 (only for UI client)
• freetype (can be disabled)
• fontconfig (can be disabled)
• libzip (>= 1.0)
• libpng (>= 1.2)
• speexdsp (only for UI client)
• curl (only if building with http support)
• nlohmann-json (>= 3.6.0)
• openssl (>= 1.0; only if building with multiplayer support)
• icu (>= 59.0)
• zlib
• gl (commonly provided by Mesa or GPU vendors; only for UI client, can be disabled)
• cmake
• innoextract (optional runtime dependency; used for GOG installer extraction during setup)

Refer to https://github.com/OpenRCT2/OpenRCT2/wiki/Building-OpenRCT2-on-Linux#required-packages-general for more information about installing the packages.

---

3.2 Compiling and running

Windows:

Show instructions

1. Check out the repository, this can be done using GitHub Desktop or other tools

2. Open a new Developer Command Prompt for VS 2022

3. Navigate to the repository (e.g. cd C:\GitHub\OpenRCT2)

4. To build the x64 version, use msbuild openrct2.proj /t:build /p:platform=x64 To build the x86 version, use msbuild openrct2.proj /t:build /p:platform=Win32 To build the Arm64 version, use msbuild openrct2.proj /t:build /p:platform=arm64

   Note: The file g2.dat may not be generated on cross-compilation (e.g. building for Arm64 on a x64 machine). In this case g2.dat must be copied from a x86/x64 build.

5. Run the game, bin\openrct2

Once you have ran msbuild once, further development can be done within Visual Studio by opening openrct2.sln. Make sure to select the correct target platform for which you ran the build in point #3 (Win32 for the x86 version, x64 for the x64 version, arm64 for the Arm64 version), otherwise the build will fail in Visual Studio.

Other examples:

set platform=x64
msbuild openrct2.proj /t:clean
msbuild openrct2.proj /t:rebuild /p:configuration=release
msbuild openrct2.proj /t:g2
msbuild openrct2.proj /t:PublishPortable

macOS:

Show instructions

CMake can build either a self-contained application bundle, which includes all the necessary game files and dependencies, or it can build a command line version that links against system installed dependencies. CMake will retrieve the dependencies from Dependencies automatically. You can build the macOS app using CMake using the following commands:

cmake -S . -B build
cmake --build build --target install

Then you can run the game by opening OpenRCT2.app

To build the command line version, you'll need to disable the macOS app bundle:

cmake -S . -B build -DMACOS_BUNDLE=off
cmake --build build
cmake --build build --target install
ln -s ../data data

Then you can run the game by running ./openrct2.

To link against system dependencies instead of letting CMake download the dependencies from Dependencies, add -DMACOS_USE_DEPENDENCIES=off to your cmake args.

Detailed instructions can be found on Building OpenRCT2 on macOS using CMake.

Linux:

Show instructions

The standard CMake build procedure is to install the required libraries, then:

cmake -S . -B build -DCMAKE_INSTALL_PREFIX=. # set your standard cmake options, e.g. build type here - For example, -DCMAKE_BUILD_TYPE=RelWithDebInfo
cmake --build build # you can parallelise your build job with e.g. -j 8 or consider using ninja
cmake --build build --target install # the install target creates all the necessary files in places we expect them

You can also use Ninja in place of Make using -G Ninja in the first command, if you prefer, see Wiki for details.

Detailed instructions can be found on Building OpenRCT2 on Linux.

Note: the cmake -S . -B build syntax is available for CMake >= 3.14. For older versions use:

mkdir build
cd build
cmake .. -DCMAKE_INSTALL_PREFIX=. # set your standard cmake options, e.g. build type here - For example, -DCMAKE_BUILD_TYPE=RelWithDebInfo
cmake --build . --target install

---

4. Contributing

OpenRCT2 uses the gitflow workflow. If you are implementing a new feature or logic from the original game, please branch off and perform pull requests to develop. If you are fixing a bug for the next release, please branch off and perform pull requests to the correct release branch. master only contains tagged releases, you should never branch off this.

Please read our contributing guidelines for information.

4.1 Bug fixes

A list of bugs can be found on the issue tracker. Feel free to work on any bug and submit a pull request to the develop branch with the fix. Mentioning that you intend to fix a bug on the issue will prevent other people from trying as well.

4.2 New features

Please talk to the OpenRCT2 team first before starting to develop a new feature. We may already have plans for or reasons against something that you'd like to work on. Therefore contacting us will allow us to help you or prevent you from wasting any time. You can talk to us via Discord, see links at the top of this page.

4.3 Translation

You can translate the game into other languages by editing the language files in data/language directory. Please join discussions in the #localisation channel on Discord and submit pull requests to OpenRCT2/Localisation.

4.4 Graphics

You can help create new graphics for the game by visiting the OpenGraphics project. 3D modellers needed!

4.5 Audio

You can help create the music and sound effects for the game. Check out the OpenMusic repository and drop by our #open-sound-and-music channel on Discord to find out more.

4.6 Scenarios

We would also like to distribute additional scenarios with the game, when the time comes. For that, we need talented scenario makers! Check out the OpenScenarios repository.

---

5. Licence

OpenRCT2 is licensed under the GNU General Public License version 3.

---

6. More information

• GitHub
• OpenRCT2.org
• Forums
• Facebook
• RCT subreddit
• OpenRCT2 subreddit

Similar Projects

OpenLoco	OpenTTD	openage	OpenRA
Chris Sawyer's Locomotion	Transport Tycoon Deluxe	Age of Empires 2	Red Alert

7. Sponsors

Companies that kindly allow us to use their stuff:

DigitalOcean	JetBrains	Backtrace
Hosting of various services	CLion and other products	Minidump uploads and inspection

opengraphics's Issues

pos.txt values are incorrect

The values that are generated by the scripts for pos.txt are positive. In general, values should always be negative, or "0,0"

tutorial Simon Foster used to create tree assets

Simon Foster apparently spends the time to look at his youtube comments and post meaningful replies. I was reading a reply chain and found this link that he posted, which he said was the method used to create the trees RCT1 and RCT2:

http://www.animationartist.com/2000/Tutorials/LWTrees/lwtrees.html

Planning out the Roadmap

We'll need a broad roadmap of what sprites should be created first.

There're several reasons why this matter, some to keep in mind are:

• Some sprites rely on others (Vehicles generally rely on a peep model, etc.).
• Some sprites may pose technical or design challenges that need to be discussed first.
• Some sprites are currently not supported by our toolset yet.

Something like the ground sprites are very prominent in the game, they may be a logical first target. But due to their prominence, we probably have to talk about the texture that we'll use for it. A different color of grass may heavily impact the look of the entire game for example.

As such it might be best to focus on less prominent graphics to test the waters with. They may be easier to change out later on as well. If we end up not liking these first endeavors.

Currently, our Blender tool does not support tracks. Due to this feature not being available yet we can not yet start generating track sprites unless we use X7's specialized track renderer.

We do not need to plan out every single individual object, but a general idea of which types of objects we want to tackle first, and which will come much later down the line will be important.

The Official Peep Model

If I were to make a guess, more than a quarter of all the sprites are peep sprites. The peep sprites have hundreds of animation frames for moving around the park, as well as separately rendered peep sprites for each individual ride. On top of that, the staff sprites use the peep as a base and expand upon that to create visually distinct characters with their own unique animations.

Almost all ride replacement models will have the need for a peep model. To ensure consistency we will have to provide a peep model that can be used for all use cases.

I've made an approximation of the peep model that Saad has turned into a more professionally rigged character to support animations in #11. This peep model was created from a mock-up but we need to discuss its shape and form. And eventually release an official OpenRCT2 peep model that can be used for the OpenGraphics project, as well as custom rides.

Pos.txt calculations unable to output positive values

The root of this issue is that when we do the final trimming of images using ImageMagick, we tell IM to output the XY position of the trimmed image on the original canvas. This gives us the negative of the value we need to output to pos.txt.

canvastex=$(convert "finished/pic$g.ppm" -trim -print '%X%Y' -quiet "finished/pic$g.ppm")

The problem occurs because of the way ImageMagick deals with trimming blank images, which occur relatively often with the peep sprites. IM generates what it calls a "missed image", a blank single pixel image, and outputs -1,-1 for the XY values. I originally assumed that there wasn't any situation where this XY value would be otherwise negative, so I did a very naive check for these missed images:

missed=${canvastex:0:1} # Catch missed (i.e. empty) images
if [ $missed == "-" ]; then
	posx=0
	posy=0
...

Peep sprites often wind up giving negative IM position values, so these are incorrectly interpreted as missed images and thus their actual position values are not recorded in pos.txt.

I'll have to detect missed images in a different way to solve this...

Remap-able colors rendering

Rendering out the remap-able colors in Blender is currently messy. I'm constantly facing issues with the colors bleeding, especially in the highlights. As seen below, the green set in the palette never gets as bright as the other colors, which means that highlights on a green-remap material tend to turn pink or yellow.

It's entirely arbitrary what colors are used to store these remap-able colors, since they'll be remapped to different colors anyways. In reality, they really are just used to represent 3 sets of 12 different brightness values. It shouldn't be difficult to just render the remap materials normally, and then individually use the rendered brightness to map these to the remap palette. I think this is accomplishable within Blender by using color ramps to map the brightness to the various colors.

Rollercoaster Tycoon 1+2 font

Fonts

Do the fonts in OpenRCT2 need to be higher resolution? Preferably yes.
Having higher resolution fonts can improve legibility, in 3D mode it should fit aesthetically.

Trebuchet MS is the most accurate font I can find to match RCT's. RCT has the font at an odd resolution, as many of the lowercase letters lose their defining features (e.g. lowercase "i" not having a notch on the left, similar effect on "t").

The` key details of the font don't match completely, but it could be assumed that RCT has the font size so low that the details get crushed (e.g. lowercase "t", "y" and numbers).

• Lowercase "y" that has a straight-angled (no hook) - Detail crushed?
• Lowercase "t" that has a minimal horizontal line end to the left of the vertical line - Matches
• Lowercase "l" that has hooks to distinguish between lowercase and uppercase - Matches
• Numbers should appear similar when at low resolutions. More distinct curves and hooks appear when the font is at higher resolutions (I don't know a way to test that this is true) - Detail crushed?

Discrepancies: Uppercase "M" and "$" (replace these particular characters with Tahoma ones?)

Compare with the images below:

I am almost certain that the game uses Trebuchet MS.
Trebuchet MS is also included in Windows by default.

The Rendering Pipeline Discussion

Introduction

Back in the day, RCT players would use sprite editing to create new scenery pieces, some users tried to do a bit more, like Amazing Earl. Currently one of the first user-generated sprite rendering pipelines that we know of. His initial efforts have shown that it is possible to create new graphics for the game similar to how Simon Foster would have done it.

OpenGraphics for OpenRCT2 was initially kickstarted by Zrowny in 2016 with a setup made for Blender 2.7-, creating the repository, and getting some of the first objects made.

A while later in 2018, I tried to have my own shot at it, once again using Blender 2.7. Thanks to the groundwork by Zrowny, research from Spacek, X7 and Coors, and even some information from Simon Foster himself we got to a point where we had a very promising setup. Since then Blender 2.8 came out, which removed Blender Render.

Luckily Frutiemax took it upon himself to show what we could do without Blender Render, creating his own set up along with several objects.

In the meantime, X7 created his very own renderer. Specifically designed to render vehicles and track sprites, some of which have already been added to the game.

The Dilemma

Things were looking really good until Blender 2.8 came out. Blender 2.8 significantly improves Blender in its accessibility and has turned Blender into an industry tool. Unfortunately, to do so the developers had to remove Blender Render. Blender Render is a scanline renderer, just like the default scanline renderer in 3ds Max that Simon Foster used to render most of the RCT2 sprites. The only rendering methods currently left are Eevee, a hybrid optimized for fast rendering. Which utilizes OpenGL with ray tracing for more accurate lighting. And Cycles, a full-on path-tracing renderer.

Frutiemax has done some amazing renders with Cycles. Unfortunately, not every aspect has been quite figured out yet which may cause complications.

X7 on the other hand has been working on his own renderer which is highly optimized for track rendering. The results are really solid and a custom renderer would allow us to be independent of what rendering engines Blender contains. Maintaining a custom renderer has its own challenges.

What we're discussing

As it currently stands the dilemma has meant that we're not able to move forward with the OpenGraphics project. We've had countless discussions, but we can't come to a conclusion without carefully considering all our options. Allowing all the major contributors to chip in. And provide evidence for how different options might compare.

The main question is: What rendering engine will we use?

From there we'll have other aspects to discuss regarding the pipeline. The rendering engine is the biggest roadblock at the moment that we need to get out of the way before we can move on.

The options

Currently, we have the following options to consider:

• Use Blender 2.8+ with the Cycles rendering engine
• Use Blender 2.8+ with the Eevee rendering engine
• Use Blender 2.7- with the Blender Render rendering engine
• Develop and use a standalone custom renderer
• Develop and use a custom renderer for Blender 2.8+

Please share and discuss thoughts and concerns for each option.

Tools and workflow?

I want to help but I don't know how start.

• Is there a tool or parameter in cli mode of OpenTTD to extract the sprites?
• Is there a tool to pack the "custom sprites" into .dat file?

Thanks.

Active Discussions

Here's a list of the official discussions that came from #16. Try to fit thoughts about the overall project and workflow to these discussions if possible.

Open Discussions

• Priority: What will be our roadmap, how will we split things up, and what parts do we want to do first?
  #20
• Model-Render Pipeline: What tools/plugins will we provide, and what does it need to be capable of?
  #19
• Structure: How will we structure this repo, and will we have some form of automation?
  #19

Closed Discussions

• Rendering Methods: Which renderer will we use for our official setup?
  #18
  We will use Blender 2.7, with the "blender render" renderer.

Yet To Be Discussed

• Originality: To what degree can we move away or expand upon the shapes, colors and options in the original game, and to what degree do we want to maintain it?
• Object Maker: How will we go from renders, to a parkobj file and how will we integrate that into our workflow?

The wiki entry for small scenery numFrames is cut off

numFrames : integer
The number of frames specified for this animation. This is normally equal to the length of frameOffsets, and MUST not be longer than it. Note that this is not necessarily the length of the animation (see animationMask). It's also not necessarily the number of unique images used in the animation, since

This is important, since

some grass sprites incorrect size

The grass sprites are very good, but there is one small issue where two of them are one row of pixels too small when rendered. Sprites #3 and sprite #11 are missing the bottom row of pixels when compared to the original graphics, this causes a small gap in rendering the terrain.

Multiple resolutions and animation frame count

I think it would be a good idea to render the sprites in multiple resolutions as well as at least 24 frames per second for animations.

This would allow future versions of OpenRCT2 to zoom in more into your park as well as give it a more fresh appearance for newer players. By storing the sprites in different sprite sheets, the sprite resolution could be choosen by the player in the game.

Animations should always be rendered with a high frame count to allow for highly fluent animations. It would be easy in code to just skip X frames to simulate the original low-frame animations.

Another game that has added such a feature is the Knights & Merchants Remake.
Of course the default should always be the same resolution and frame count as RCT2 but I think this would make a nice addition to the game.

Output images have too many digits for the numbers

At the moment, the compile script outputs final images with a static 5 digits for their numbers, as such:

pic00000.bmp, pic00001.bmp, ...

This causes issues with using RideMaker, since it expects images to have the lowest necessary digits for the ride (i.e., a ride with 300 images would need images with only 3 digits, picXXX.bmp), and it won't replace the first 10 images, leaving the originals.

Identifying the focus of OpenGraphics

So far there have been several efforts to create a workflow for the OpenGraphics projects. Most of our efforts are currently separate and use different pieces of software, setups, and workflows. Each of these workflows with its own strengths that are tied to the beliefs of its creators.

Over the past few years, we've had countless discussions about how to move this project forward, things like the importance of recreating the original style, upping the scale, and Blender versions are topics that often come up anytime one of us gives it another go.

This project is a massive undertaking, and due to the complexity of the sprites, we will not be able to rely on pixel art for asset creation (Like for OpenTTD's initial replacement graphics OpenGFX). Instead, we will have to rely on a process for rendering sprites from 3D models and animations consistently.

We can split up the pipeline into 2 segments that may be able to work independently from each other:

• 3D asset creation
• Rendering process

My suggestion would be that we each note down what our personal focus is. What boxes would the OpenGraphics pipeline have to tick to satisfy your personal beliefs about what the OpenGraphics project should become and achieve.
Additionally, explain what you've experimented with so far, and what the strengths of your process are.

This will hopefully allow us to bundle our efforts, strengths and believes in one place, which will make it easier for new contributors to get an idea for where we're at.
From there I'd like to split up the discussion into separate topics to hopefully come to conclusions about how we would like to tackle the individual components that make up the OpenGraphics project.

For this first stage, please refrain from discussing people their personal beliefs. We'll get to that once we've gathered enough input.

Here's a suggestion for the format you can use for your response:

### Personal Beliefs
What should OpenGraphics aim to achieve? What aspects do you believe will be most important to consider?

### Personal Experience
What have you tried already? What are your project's strengths and purposes?

[22-05-2021] You may now discuss and suggest separate discussion topics #16 (comment)

Project needs a proper licence

There isn't currently a licence for this project. To avoid any troubles later on, it should have one. I would advise to look at similar projects to see what kind of licences are common for this sort of thing. If there is any doubt between multiple ones: I would generally recommend taking one that is as permissive as possible, but you can always ask.

Creating the Official Workflow

We need to discuss what the workflow will be like for contributors. The workflow would include:

• Creating the 3d model
• Rendering the graphics
• Uploading assets to GitHub
• Contributing to this repo

Things that we need to discuss:

• What will contributors have to include in their PR (Object files, sprites, 3D Models, additional source files etc.)?
• How will we structure the repo files?
• How can we make the process of contributing as easy as possible for people less familiar with Git (non-programmers)?

Raptor Source Files

I'm not sure where this should go specifically, but these are all the source files I used to make the RMC Raptor train.
Raptor Project Files.zip

As an official OpenRCT2 custom object, its source files should be somewhere.