Saturday, 2 August 2014

Queue paths

The second item I have been busy with is paths.

FreeRCT could use a little bit more variety in paths, in particular, it needs queueing paths that you put in front of a ride for quests to wait for a chance to experience the attraction.

The first step was to add different types of paths. The Path build window was extended. As you can see we now have up to 4 different types of path (4 rows). The second step was to denote each path type as being a normal path to walk on, or a queueing path. This is denoted by the two columns. The gui can probably be reduced a bit further by merging some rows.

Adding different types of path, and saying it's a queueing path is one thing. Making it actually work that way is another.

If you build a number of normal path tiles next to each you get a nicely fully covered area as you can see at the left of the picture. It's great for making a grand entrance of the park (although something less dull than grey could be useful :) ). For queueing in front of a ride however, you don't want areas, you want a long path, or in technical terms, each path tile should be connected to at most two other path tiles.

This is what the blue queue path tiles do. They connect to at most two other tiles, preferably other queue tiles. As a result, if you build such a path from the bottom left to the top right (first the bottom lane and then the top lane), you get two separate paths rather than one big area.

Now that you can build queues quite easily, I need to teach the quests about queues. The need to walk behind each other, and stop walking when there is no room in front of them. Finally rides must pickup the first guest from the queue until the ride is full, and deliver the quests at the exit afterwards.

Sunday, 27 July 2014


Got distracted by real life stuff for a while, the dev blog is a bit behind on current developments. On the other hand, the features are nice enough not to summarize in a few sentences, so here goes the first one, namely support for weather.

The weather was a bit of a puzzle to make. The basic idea is to make the world look brighter on a sunny day, and more grey on a clouded or rainy day.

The first requirement was of course the ability to lighten or darken the entire world view. It's like recolouring, but a) every pixel changes instead of only a few, and b) colours only get lighter or darker. The previous step of getting proper recolouring some months ago also solved the gradient shifting, so that was already available.

Interestingly, the more tricky part was deciding what weather should be displayed. In reality, weather "just happens". In a game, you have to program it. To program it, you need an algorithm to decide what weather should be displayed!

In the end I made a table for each month, how often each type of weather in that month occurs. Then by drawing a random number (uniform distribution over the sum of occurrences of all weather types), the 'new' weather is decided.

Immediately jumping to that new weather would be a bit weird however, you'd have sun one day, and thick rain the next. To make the transition more smooth, the change is done gradually in a few days.

The temperature is interpolated between the average temperatures of each month. This may be a bit too simplistic but it will do for now.

With the weather type and temperature decided, smoothly changing to new weather over a couple of days, and connecting the current weather to the gradient shifting, we have bright sunny days and dark cloudy days now as you can see in the pictures. Other effects of the weather still have to be programmed.

Sunday, 25 May 2014

The apple drops

Could watch it for hours, couldn't you? :)
No friction yet, so passengers will have to jump out of the car as it passes through the station, but that's a small price to pay...

Monday, 5 May 2014

Ice creams in all colours!

Hello again,

Until now, only the guests got different colours when they entered. In the original game, many more things could have a different colour, amongst others, the shops.

FreeRCT did have a notion of recolouring for quite some time, but either the graphics didn't allow use of it, or it was not really working.

Today, I committed a set of patches that should fix all that. The 32bpp blitter now also does recolouring. I have also added a dropdown to allow selecting a new colour if the random colours are not to your liking.

Last but not least, there is a new shop, the ice cream stall. It's a 32bpp sprite, and as you can see, it comes in all (re)colours.

Saturday, 12 April 2014

Welcome to the 21st century

We are slowly moving to the less visible features, and the feature I am talking about today is one of them (in a sense).

If you're following the news about SDL (our video and keyboard interface), you know that after many many years, a new SDL version has been released (SDL 2.0). One person found that interesting enough to clone our github repository, and modify the program for the new interface. Unfortunately, he left before I had a chance to look at the changes in detail and discuss them.

Another thing that has come up at times is the question of 32bpp colour (aka full colour) support. At the start of the project, we considered 8bpp colours enough (just like the Rollercoaster Tycoon 1 & 2 programs). However, you see an increasing interest in full colour from users. Also, the video hardware is moving away from 8bpp. In other words, eventually, we will need full colour support for the program. Thus, I took this opportunity to add 32bpp support to the program, together with the switch to the new SDL 2.0 library.

At the top-right you see the before and after images. Looks the same, you say? Well, you're right about the grass. In both images it's the same sprite. The shop however is different, as you can see below at 800% zoom. The left part shows the shop as we had it from the start. The right part is the same shop, but in 32bpp. The right image is much smoother at 800%, without the weird coloured pixels here and there.

Technically, the program accepts and renders both 32bpp and 8bpp images. Our current shop sprite isn't a great example of what you can do with full colour support, but I am sure we will get shiny new colourful graphics somewhen.

Sunday, 29 December 2013

Moving coaster cars

Hello all,

If you are watching the YouTube FreeRCTGame channel, you know already, there is a new video.

It shows building of a small roller coaster, followed by a moving coaster car (at fixed speed, and not rotating along with the tracks). For some reason, the blog doesn't allow me to link to the video directly (thank you so much, smart user interface), so instead I post the url: I hope you like it.

Saturday, 2 November 2013

Car tracks

After tracks, the next step is obviously to have some cars on them, carrying paying guests of course!
In the real world, you just put the car on the track, and it will follow them. In the digital world of make-believe, car graphics don't care about track graphics, and you have to explicitly tell them how to move through the world.

If you remember the original Rollercoaster Tycoon programs, you'll know tracks came in all kinds of bendy shapes, so how to do that?

One answer that should work (we think), is segmented cubic bezier splines. Basically, you define a start and end point in 3D space, and two intermediate control points (also in 3D), and the bezier algorithm computes a smooth line from the start to the end point. For the more bendy shapes, one such spline is not sufficient, you either need a higher order bezier curve (but it's math becomes complicated), or you chain a number of cubic splines after each other. If you do that careful, the cross-over from the end of one spline to the start of the next spline is also smooth.

So far so good, bezier splines gives a line of rope through 3D space for the car to follow. But what about the orientation of the car? (Keep in mind, the car ignores the track graphics!)

Just a line doesn't tell whether the car is up-right or upside-down (or anything in-between). To solve this problem, a track also needs a roll orientation for every point at the line. A smooth path from a starting roll value to an ending roll value (in degrees).... Another segmented cubic bezier spline to express the roll orientation in degrees!

From the direction of the 3D line (for the mathematically inclined, its derivative) and the roll, the pitch and yaw can be computed (hopefully, I haven't actually tried that yet).

For the test rollercoaster track graphics, roll is simply 0 (upright orientation), so that's easy. The path involved a bit more experimenting. I made a small Python program that plotted the path curve onto the existing track graphics, and tuned the start, end, and control points until it all looked ok. You can see the result above.

For example, the path of the level-to-going-down-track in negative x direction (bottom-right sprite) is defined  as

car_xpos: splines { cubic { a: 255; b: 150; c: 100; d: 0;   length: 1000; } }car_ypos: splines { cubic { a: 128; b: 128; c: 128; d: 128; length: 1000; } }
car_zpos: splines { cubic { a: 80;  b: 78;  c:  50; d: 15;  length: 1000; } }
car_roll: 0;

The roll is 0, as expected. The x position runs from 255 (point a) to 0 (point d), with intermediate control points at 150 and 100. The y position is 128 all the time. The z position starts at 80, and ends at 15 (points a and d). Point b at 78 is almost the same height as point a, so near the start the path is almost level. Point c is much higher than point d, so it goes down more steeply.

So far, it all looks good, but getting to the point of a car following the track on the screen will be quite some work. Then we will see whether the above math actually works :)