Guests, paths, and park borders

Until yesterday, guests were randomly walking around over the paths, buying things when they happened to pass a shop that sold something they needed.
They also didn't care about park borders, walking in and out of the park wherever the path went. Luckily they didn't have to pay an entrance fee!

I added an "activity" to a guest, a short term goal of what they aim to do. The first activity of a guest is now "enter the park". As soon as it reaches land owned by the park, the activity changes to "wander around in the park". Eventually, other activities will be added, such as "go to a ride", or "go home".

Making a guest stay in the park was then quite easy. Whenever a guest is "wandering", block any path leading to a tile that is outside the park. Since a guest starts wandering when it is inside the park, blocking the paths to non-owned tiles makes it stay in the park.

Having an activity such as "enter the park" is nice, but how does a guest find out where to go? For us it is easy usually, we see the paths, and can often immediately point out the shortest route to the destination. A computer can list all path tiles very quickly, you can teach it when two path tiles are adjacent, but it does not know easily which tiles to use for quickly getting in the park.

Luckily, three smart people figured out a solution to this problem a long time ago, and created an algorithm for it, which is known as A*. Basically, you try every possible direction that you can go at the same time (making copies of yourself to walk in different directions is easy in a computer). With every step (or tile) that you walk, you measure the distance that you walked, and you estimate the length of the remaining path. Since paths in FreeRCT are either in X direction or in Y direction (ignoring height for simplicity), the manhattan distance to the destination point is used as estimate. You add both numbers, and the position with the lowest sum is the best to try taking the next step. The rationale behind it is that if you walk in the "wrong" direction, the length of the walk increases, but the estimate also increases. The sum of both numbers thus gets bigger rather quickly. If you walk in the "right" direction, the length of the walk increases, but the estimate decreases (since you get closer to your goal), so the sum of both numbers stays more or less the same.

Positions in walks in the "right" direction get a lower sum, and are more favourable to explore further. Taking such steps continue until you found a position at the destination (or until you tried all paths that you can reach). When you reached the destination, the path is also known, and the guest at the junction knows whether to go left or right to enter the park.

You see both things in action in the picture. The two guests outside the park are trying to get to the park as quickly as possible, and walk straight rather than turn left to enter the park more to the north.
Guests inside the park 'bump' into the park ownership boundary, and wander back and forth on the three tiles that they can reach.

Developing using Visual Studio on Windows

If you prefer to develop on Visual Studio over using Linux, there have been some improvement in this area recently. If you like Linux better, then you can continue to enjoy that. The point here is not to claim that one is better than the other.

On the wiki, we have documented a number of steps that you need to carry out in order to compile using Visual Studio 2013 with the source code changes that were recently committed. The level of documentation is intended for programmes familiar with Visual Studio. The list is not as short as I would like it to be, but it is a first start. At some point we will probably look into providing a package with pre-compiled libraries for building FreeRCT instead of shamelessly referring to OpenTTD-utils for zlib and png. It may also be possible to add some code to CMakeList.txt so that we can just point to where FreeRCT utils bundle is to set up all library paths in one go.

Still, while the current list is a bit long, most steps are only needed on the first compile. If you re-generate the project files, no manual tweaking is needed.



If you are just interested to play in Windows and are not familiar with programming, you can of course try to follow the instructions, but I'm sorry this is just the first step on establishing a development environment for people who like to develop on Windows. But this means that hopefully there will be binaries for you to try later on.

Fences

Some time ago I started to work on the task to add park borders. The first thing I did was to add land ownership which I guess some of you have seen when you tried to build things near the border of the map and suddenly there is an invisible border there. I’m sorry for anyone who may have been upset about that.

Well, now this border is not invisible anymore, because finally my work on fences has resulted in park border fences. I think it is now more than 8 months ago that I started with the fences. Then got busy with other things, got back to it a few times and then now finally got the time to finish it up so that you all can enjoy not hitting the invisible wall.

The fences in FreeRCT now come in 4 types. A park border type which you cannot build yourself, and 3 types that you can build yourself using the new GUI for building fences. A feature that I don’t remember if RCT had, is that you can use the landscaping tools on a tile and the fence and the fence will adopt to the new slope.

I have also worked on making paths and fences aware of each other, and had it working quite nicely 7 months ago, but this patch is now in a broken state and needs fixing.

On the technical side, one of the challenges with fences is what to do with sloped tiles. As you might know, the world is composed of voxels. For flat tiles, it is easy, store the fences in the ground voxel. However, if the slope have two raised corners and a fence between those corners, then that fence actually belongs to the voxel above. Furthermore, in FreeRCT there is also so called steep slopes that cover two voxels. This adds more special cases that all needs to be handled to build, draw and update fences correctly when the landscaping tools are used.

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.

Weather

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.

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...

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.

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.