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.

Path building, part I

Laying a path in your park is the first step to getting visitors. In the past weeks I have been busy implementing creation of paths. At the right you can see the first result.

When you open the path build window, the cursor changes to a white (rotated) square, and allows you to select a starting tile or path.

Then you can select a build direction with the arrows in the gui which is shown as a flashing arrow in the world display. The arrows at the gui always correspond with what you see at the display, even if you rotate the world.

Next you can press a slope button (at the top of the gui). (I do have sprites for them, but they were not loaded yet.) If you click at another tile or path, the build continues there.

Finally, by pressing 'Buy' you buy the path, and the white square and the arrow move onto the new path (so you can 'buy' again).

I called this entry "part I" as the gui is not finished yet. The other buttons currently do not work, path sprites are not extended to their neighbours, and they need platforms to the ground, and a bar so people don't fall off.