Colourful people

First of all, thanks everybody for your support. It is good to know that so many people like the project. Some people went a step further and submitted graphics and a translation. Many thanks, except it will be a while before it can be displayed in the game.
If you want to drop in and chat a bit, there is now an IRC channel #freerct at oftc.net. As it was recently created (and this is the first advertisement of its existence), it is still very quiet.

As a next step, I decided to add random colours, so different guests can have differently coloured cloths, shops and rides can be painted in different colours, etc.

At the game-side it was no too complicated, and the windows now have colour too (albeit a bit too intense, it needs further work). At the RCD data-file generation side, I wanted more than possible, so I spend two weeks Python code refactoring and extending to allow specifying random recolouring in a nice way (so much for an easy feature :D )

As usual, I have added a picture showing the new features, the windows have different colours (and there is a 'quit' window too!), and the pillar guests now appear in (almost) all colours of the rainbow.

Guests! (Take 2)

After some code shuffling and re-organising of the animation data, FreeRCT now has moving guests.
I did not change the renderer yet, so they are still grey, but it seemed big enough news to let you know anyway!

[watch in higher quality here]

Hello Reddit!

Hello Reddit, thanks for dropping by! If you have any questions about this project please ask away, either in comments on this blog or on Reddit (my username is cr42yr1ch), and I will try to get back to you.

 

Guests!

With paths, it was time to see whether guests could be added. I had no idea how to add it, so it took a while to figure out how to approach the problem. This first attempt is all somewhat experimental. At the right is the first 'real' result, a small figure-like sprite appears at a path at the edge of the field. He follows the path, taking random directions until he gets bored (then he suddenly disappears).

Please note that some of this code is not committed, and never will be, in its current form. The reason why is as follows:

Motion is not fluent, he sort of jumps to a new position every few seconds. Also, he walks next to the path instead of at it. Another problem is that drawing figures is terribly expensive, because the data is not organized correctly.

He is also very much colourless, but that is intentional. The video blitter needs to be upgraded so it can perform recolouring while blitting.

While I am happy with this first result and I have learned a lot from this attempt, I have also decided to re-organize the code and data, so the program can have (hopefully many) more guests without costing a lot of CPU time.

Data files and such

With any project, there is also software which is mostly invisible, and FreeRCT is no exception to this rule. In this case, software for creating data files.

At the start of the project, it was decided to have free graphics that anyone could create and add. To make that a reality, the program needs to accept a known file format, such that a game extension can be stored in a single file (to simplify distribution).
The rcd/data_format.pdf file is the key-file here, as it contains an independent description of the format (separate of any implementation). It serves as the master description of the file format.

At the start of the project, a quick and dirty approach was taken to create the data files. With special-case Python code, and a lot of copy/paste, a solution was coded quickly.
This code has worked well for the past six months in the development of the C++ code, but it was already clear it needed further work at some point.
After finishing most of the path puzzles, I wanted to extend the data format. Doing that in the old and hacky code did not seem very good, thus the time had come to cleanup first.

The data-file format description has been moved from Python to XML. The
actual data is now also captured in XML format.
As an example of what the new format looks like for a graphics artist, consider the fragment from rcd/freerct.xml below (with some small additions to make it a complete XML file):

<rcdfiles>
<file target="buildarrows_8bpp64.rcd" magic="RCDF" version="1">
    <gameblock magic="BDIR" version="1">
        <field name="width" value="64"/>  <!-- Zoom-width -->
        <sheet x-base="0" y-base="0" step="64" step="64"
               fname="../sprites_src/objects/1x1/gui/orthbuildmark8bpp64.png"
               names="ne,se,sw,nw" x-offset="-32" y-offset="-33"
               width="64" height="64"/>
    </gameblock>
</file>
</rcdfiles>

This describes the four arrows used for indicating the direction of path building. The data file is called 'buildarrows_8bpp64.rcd', and the data block containing arrows is called 'BDIR' (Build DIRection). It has five fields. The first field is the tile-width (so you can have different arrow sprites for different zoom-levels). Fields two to five are the four sprites, which are pulled from a sprite sheet, in the order north-east, south-east, south-west, and north-west (see the names attribute).

It is still quite a lot of data, but I think it is a big step forward from coding Python to define both the file format and the actual data.

Long paths

I promise this is my last post about path building for a long time :)

Remember I talked about not liking having to click for every path tile you build? Today I give you an alternative, use the mouse instead!

It works in the following way. After opening the path build window, click at the place where you want to start (the while tile cursor sticks to the position). In the window, click 'Long' (as in 'long build'). Now the system tries to build a path to the mouse cursor position in the vertical plane through the tile cursor. (In the attached picture, the mouse cursor is where I added the red dot.) If you move the mouse, the path changes. When you are happy, click the mouse, and the path is fixated (that is, you can move the mouse without the path following you). Then, like the single tile, click 'Buy' to buy the entire path.

That's much faster, isn't it? :)

The basic idea seems to be working nicely. If you experiment a bit with it, you'll notice there are still some quirks that need to be figured out, but to be honest, I have had quite enough of path building for some time.

Rewrite of the paths, connected path tiles

After the previous blog, I got a message from one Lord who found you could crash the program by building paths off the world (thanks for finding that, Lord).

Unfortunately, fixing proved difficult due to my somewhat naive way of coding it. There were three parties responsible: the world display, the path window, and a helper object that stored some selections. Rather than finding out who to blame exactly, I decided to rewrite it all, making the helper object the central entity. While you cannot see it at the outside, this makes the code much easier to deal with errors, since you know where to look. I fixed the off-world build problem, as well as few other problems.

Also invisible is the introduction of time. The game now keeps track of days, months and years.
Last but not least, the path tile building was changed to extend the edges of adjacent path tiles, which makes a much nicer path as you can see.