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.