FreeRCT

FreeRCT copied to clipboard

What's the realistic status on FreeRCT?

I know activity was rather slow back in 2016 when I contributed some pixel art, but I am curious if we'll see the project pick up again in the future or if it's considered dormant (or worse).

Cheers,

Kev

Who knows.

After 5 years I concluded I would have to drag the thing forward for another 3-5 years, which was just too much to do by just me. Clearly something went wrong, if only I knew what.

I do still ponder about alternative paths every now and then, but I have currently no space in my life to actually try it.

Hi

A while back I stumbled over FreeRCT and liked the idea a lot, being a fan of the original RCT1. I have experience coding C++ and if someone would point me to something suited for a newcomer, I could try and contribute code to the project :)

Best regards Benedikt

Unfortunately, the project is essentially dead. Everyone involved either got tired of it or ran out of time. You're welcome to work on what's there though, I don't particularly have any issues assigning ownership to others if that's desirable.

The real answer here is that you should go look at https://github.com/OpenRCT2/OpenRCT2. It was first announced about a year after we got going with FreeRCT and it's been extremely successful - it's quite likely hoovered up any chance of other contributors coming back to this.

Thanks for the reply. I don't mind contributing to a project with few active developers – maybe I can help revive it :) I think I'll start by investigating the assert fail I just encountered in master, and then work on adding some features.

What I don't like about OpenRCT2 is that they provide only the engine and require the original game files. A truly free game should be modder-friendly and never depend on proprietary assets. Even if OpenRCT2 is bigger and more successful, a fully free and independent new-implementation like FreeRCT seems way more appealing to me.

I imagine they'll get there eventually. OpenTTD (which has been made in much the same way) was dependent on the original TTD files for a quite some time as well. (Well, 6 years, when it's now nearly 17 years old, but still)

What I don't like about OpenRCT2 is that they provide only the engine and require the original game files. A truly free game should be modder-friendly and never depend on proprietary assets

There's this: https://github.com/OpenRCT2/OpenGraphics Not sure how complete it is at this point.

Some thoughts what could be done differently.

• Painting pixels on an SDL surface by the CPU is a dead path nowadays, stuff needs to move to the GPU.
• Have regular playable releases.
• Don't have pure CPP code. It's difficult and has few developers. Some mix of CPP and eg Python may have a better future due to more Python programmers being around.

• Painting pixels on an SDL surface by the CPU is a dead path nowadays, stuff needs to move to the GPU.

I don't know if you have anything specific in mind, but IMHO OpenGL would be a good choice. It's pretty standard nowadays and allows efficient and high-quality rendering.

• Have regular playable releases.

:+1:

• Don't have pure CPP code. It's difficult and has few developers. Some mix of CPP and eg Python may have a better future due to more Python programmers being around.

Personally I don't like Python much, though the argument is a good one. But if I may make a suggestion: As a long-term aim the definitions of rides and other assets could be moved to Lua scripts, which offers users the way to easily – and without knowing much programming stuff at all yet – modify the game. This also attracts new developers who start by working with Lua scripting and later eventually learn to code in C++ as well (speaking from personal FOSS experience here).

---

By the way, hoping this is not the wrong place to ask, are there some documents or links a new contributor should read? Like about code style, dos and donts, or other things one should know?

I don't know if you have anything specific in mind, but IMHO OpenGL would be a good choice.

Being a Linux user, OpenGL would be my first choice too, not sure how cross-platform that is.

As a long-term aim the definitions of rides and other assets could be moved to Lua scripts

We may have different views on what should be done in CPP and what should be done in the scripting language.

I dabble in CorsixTH as well, which is a little C++ and a big pile of Lua. In my experience there, indeed, it's simple to write, but Lua is a too small language, it doesn't scale well. Useful if you write simple short programs, but if want to write 3/4 of the program in it, it's going to be a mess with global variables by default, no standard class definition (everyone defines their own class system first), starting at 1 while cpp starts at 0, value 0 not being false, and no way to distinguish between an empty variable and a non-existent variable. Also, Lua tools either don't exist or barely work, the Lua development community is very small it seems. Besides a user-manual, the only useful documentation is the Lua reference manual, which is extremely cryptic at some spots to say the least. So this is why I stayed away from suggesting Lua here.

By the way, hoping this is not the wrong place to ask, are there some documents or links a new contributor should read?

You mean the stuff in /doc ?

I don't know if you have anything specific in mind, but IMHO OpenGL would be a good choice.

Being a Linux user, OpenGL would be my first choice too, not sure how cross-platform that is.

There's a bug that some graphics drivers under windows only provide OpenGL version 1.1.0. Other than that, OpenGL 2.1 has been in use under all common OSs for years in https://github.com/widelands/widelands/ with no major issues.

By the way, hoping this is not the wrong place to ask, are there some documents or links a new contributor should read?

You mean the stuff in /doc ?

:+1: thanks

There are also things like Sokol and bgfx. bgfx especially can be a bit less straightforward than just writing OpenGL which isn't really ideal here, but the positive side is that you get support for a load of different graphics APIs without having to write multiple render paths.

Sokol supports GLES2/WebGL, GLES3/WebGL2, GL3.3, D3D11 and Metal and bgfx supports Direct3D 9, Direct3D 11, Direct3D 12, GNM (PS4 API), Metal, OpenGL 2.1, OpenGL 3.1+, OpenGL ES 2, OpenGL ES 3.1, Vulkan, WebGL 1.0, WebGL 2.0, WebGPU/Dawn.

As it's all 2D, we need very little OpenGL. Mostly one or more layers that display the images at 1:1 (1 pixel image = 1 pixel screen). Layers that may be useful

• GUI windows
• Weather (mostly rain)
• The game world, depth sorting is likely useful here.

Obviously, it can be done all on a single layer by drawing in the correct order, even without depth (as that is currently being done).

I do want to add that 1px image = 1px on screen may not be the best idea with HDPI displays. There should definitely be some scalability

Fair enough. Scaling is the typical programmer solution. From an graphic artist point of view I can imagine that having images at different sizes is much more preferable as it gives higher quality graphics.

But yeah, something to find a path in.

If you stick to pixel art, it should scale nicely regardless 😃

Somewhat it does, but an artist with a bigger image has more space to add details, or make some part just a little better to it's more prominent to the eye. A computer algorithm has no knowledge of what is important in an image, it treats all colours in the same way. It's easy to program (and lacking a higher resolution image likely the least bad option), but it doesn't beat a good artist.

But eh, currently we have neither :)

Can we discuss why Python is a bad choice? If it is about indentation, I really fail to see why not being able to make indenting mistakes is a bad choice, so please explain.

Also, what other options exist? I have run out currently.

Perhaps before settling on a language we should discuss what exactly should be moved out from C++

If we want this for user-creatable content (scenarios, ride definitions, …) then we need a scripting language that can be interpreted at run-time by the engine (which remains pure C++). I suggested Lua because I have some experience with coding a C++/Lua interface (using Eris); but there are plenty of alternatives (though none I've much worked with before personally so I couldn't actually name a good choice now). If we actually want to move parts of the engine to another language – I'm not sure this is the right approach, as then anyone who wants to do a larger change will need to know two languages rather than one.

I expect only a handful people at best that are knowledgeable about C++ and the game code enough to make changes in C++. To bring in more developers, we need a simpler language for the bulk of the code I think.

I don't have a list, but my first rough idea is, move everything that is not low-level (ie OS facing) and not time-critical to the scripting language. Mostly window handling at OS level, and animation can't move.

For user-creatable content, all the RCD data files are for that. You can define a lot, and make your own rides, including graphics. There is currently no scenario-like data iirc, but you could easily setup a level-file and add limitations and win/loose conditions. (Something we should have at some point anyway.)

I am not sure what you want with a scripting language in a scenario. What are useful changes you can make to eg a rollerocaster by script? A second problem is that having third-party code like that is a huge security risk. Sooner or later someone will make an awesome mod, and also install a backdoor, encrypt a few key-files, or simply delete everything at the first Friday in June.

EDIT: Biggest problem, is likely that changes here means throwing away a lot of code that already exists.

In addition to what's already been said, I think setting up a milestone for a 0.1.0 release and deciding what we want to have done for that release would be a good idea. This both would make it easier for new contributors as they know what things they can/should work on, and let us make a first release to get some publicity and possibly have it packaged.

Some ideas for what the 0.1.0 milestone might be:

• Title screen with options to load a scenario or save, play sandbox, settings, and quit
• One or two preloaded scenarios
• Make FreeRCT installable and support global and user locations for things like scenarios, settings, and so on. Partly worked on in https://github.com/FreeRCT/FreeRCT/pull/123 but I doubt we'll see this guy finish it up. Still, his progress might be useful for someone interested in implementing it.
• Fix some relevant bugs

I don't think it'd need to be more than that. We're not a lot of people so let's not overshoot, but I think these would make it feel more like game and make it more viable to package (putting it on Flathub might be a good idea, for example). It'd probably also be a good idea to have a Windows .exe in the release.

Thoughts?

+1 for a title screen and making FRCT installable. I think scenarios might be a bit much for a first beta release, the sandbox mode would suffice for now. More urgently, imho, we could do with one or two gentle rides (that's something I'm eager to work on) and/or thrilling rides (which are basically the same thing; there's no category for those yet, is there a reason for this?).

Oh, new rides! I had a carousel lying around I remembered, just pushed it: https://github.com/Alberth289346/FreeRCT/tree/new-graphics Found a ride entrance and ride exit house too, added that as well.

EDIT: The only reason why we don't have thrill rides is because nobody added it so far :)

So is anyone willing to help maintain, review code, merge prs, etc?

I've set up a PPA with the current state-of-the-art. I'd appreciate it if someone else could test that the packages work out of the box. Packages are available for Ubuntu Bionic Focal Groovy Hirsute Impish. Installing is as easy as typing

sudo add-apt-repository ppa:nordfriese/freerct-daily
sudo apt update
sudo apt install freerct

Then start it with freerct. Late edit: Should this fail with a segfault on startup, please try whether passing -a nds_DE fixes this and report :)

Tomorrow I'll make a PR with the debian rules changes that were required to get the builds working.

Is there anything left that urgently needs fixing or implementing before we can release version 0.1? If there's no reply I'll create the release branch and tag tomorrow.

It depend so on whether we want to have a Flatpak available on Flathub for the 0.1 launch. I would like to have that, but if you don't think it's important we can of course arrange that later.

As announced in my latest email, I created a SocialMedia profile on Mastodon and I'll start presenting the project there. https://mastodon.technology/@FreeRCT

If anyone needs access to that account, too, I'm happy to share the credentials (or change the mail address to some @freerct.net domain so people can reset it if needed).

By the way, the website will show up as verified in the profile when this is added to the homepage: <a rel="me" href="https://mastodon.technology/@FreeRCT">Mastodon</a>

So what's the current plan? On the 19th we tag v0.1 and announce it as the initial release?

Yep! Or in more detail:

• On the 19th, I create a branch named "release/0.1" and adapt its CMakeLists.txt to set the default version string to "0.1". This should probably be the only change needed but something else might turn up in the last minute.
• I tag that commit as "v0.1" and turn it into a release on GitHub. I'll upload the release installer artifacts from the v0.1 CI build there (after unpacking the outer zip wrapper locally, for user convenience).
• The Flathub PR can be updated with the commit hash and merged. If the PR provides a standalone flatpak build (?) this should be uploaded to the GitHub release as well.
• I add links to all those files on the homepage Download page, and a news item on the front page.
• We announce the release to other sites – Mastodon, LibreGameWiki, and any other relevant sites we think of; and look into getting it packaged for more distros.
• The master branch will need a one-liner change to set development version strings as "0.2~…".