Google Code to GitHub, Subversion to Git

Google Code is shutting down.

Although there was no need to rush our decision (the site will not become read-only until 24 August), the FreeRCT dev team began discussing alternatives straight away.

The discussion started with where to move the project to (GitHub, SourceForge, Bitbucket, or self-hosted). Of course, moving the project to one of the aforementioned options also meant a likely change in the version control system (VCS) used (see: allowed).

• GitHub (GH) primarily supports Git (of course), with some Subversion support that we did not think would be worth dealing with.
• Bitbucket would give us more flexibility with its support of both Mercurial and Git; nevertheless, the interface is somewhat lacking when compared to GH, and searching for projects as an anonymous user is not as user-friendly (not helpful for project visibility).
• SourceForge (SF) would allow us to stay with Subversion; of course, this would mean using SF's interface, something that none of the devs seemed particularly excited about. 
• Some other sites and VCSs were mentioned, if for nothing more than to provide a bit of jocularity to the serious discussion. 
• Finally, the team briefly discussed the possibility of going the self-hosting route. Although we may eventually go down this road, it was decided that there is no real need for it in the project's current state.

After receiving feedback from the rest of the team, it was decided to make the move to GitHub. Admittedly, the team was in a state of wonder as to how the entire process would go, especially with regards to how GitHub would handle Google's wiki format and the fact that we already had a Read-only mirror in place at GitHub.

Lucky for FreeRCT, we had the unique combination of our own LordAro, as well as Google's (admittedly fancy) 'Export to GitHub' functionality.

Operation successful: FreeRCT.

With the move to GitHub complete (minus a few small changes being made as I write this), the team can refocus its efforts on making this awesome game.

Hopefully this post gave you a good overview of what was involved in moving the FreeRCT project from one site and system to another. As always, you can continue to stay up to date on FreeRCT happenings through all your favorite sites, including checking here at this blog. :)

Until next time,

The FreeRCT Dev Team

"FreeRCT is really good value!"

Q1 2015 Report

Hello fellow FreeRCTers!

It has been an interesting past half of a year for the FreeRCT dev team, and we wanted to take the chance to update our eager followers with what we have been up to.

Real life aside, the dev team has been contributing as much time as is possible to the entire FreeRCT project, pushing updates ranging from necessary bug fixes and improved continuous integration support all the way up to entirely new features that will excite end users, most of which are highlighted in the Changelog below.

As noted in the upcoming changes sections, there are significant features and improvements in the pipeline (or queue path :D) that we are working hard on and will hopefully be adding to the official project within the next couple of months.

To those eager for more frequent updates, there can, of course, be no promises from us; nevertheless, with this post, the hope is to continue updating you all with the most significant changes as time allows. On the plus side, the less time we dedicate to writing posts, the more time we are probably using to improve the code and assets of the game, as well as brainstorm further improvements and ideas to add to our ever-growing ideas/to-do list. :)

Until our next official update, you can follow us on Twitter (and like us on Facebook), visit our home page, watch for code updates at the official repository, read our other posts on this blog, join our subreddit, check out the wiki, and/or get involved.

Until next time,

The FreeRCT Dev Team

"FreeRCT is really good value!"

Changelog (1 September 2014 - 4 March 2015):

• Guests 'going home' walk to the edge of the world before disappearing.
• Thunder and (ride) state lights (not in game-play use yet).
• More items for shops to sell to guests.
• Toilets (Building and guest visitation support).
• Guest mood changes based on weather and umbrella possession.
• Initial support for guests on rides.
• Guests are informed of ride destruction.
• Guests exit rides.
• Multiple improvements to the renderer.
• Initial queuing for ride support for guests.
• Removal of guests from a ride upon its deletion.
• Guests stop buying food/drink upon bathroom necessity.
• Initial path decoration support.
• Support for Unicode character input and handling key input.
• Underground mode view.
• Support for single tile click (and hold-drag) path placement (and removal).
• Ability to change (override) path type of currently placed path(s).
• Coverity support (Travis CI).
• Numerous bug fixes, documentation improvements, and other behind-the-scenes updates.

Upcoming gameplay changes:

• Ability for persons in the world to handle (walk on) non-path tiles correctly.
• Ability to pick up, move, and drop persons in the world.
• Initial staff (employees) support.
• Further enter / exit ride support for guests.

Upcoming engine changes:

• Replacement of SDL2 with GLFW.
• Replacement of window mouse modes with an improved approach.

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.