The most wanted feature ever...

It's been a long time coming, and due to message-loss (my fault) in the blog registration, has been implemented for a couple of weeks now.

The closebox is here!

Looks good, huh?

EDIT: As of r830, closebox sprite is now the proper colour.

Mountains in FreeRCT

With shops, clicking on stuff and opening a window about it became useful. However, the mouse was always used for terraforming (changing the terrain), so that has to move to its own window first.

While at it, I decided to also add foundations (the vertical walls between the levels, and at the edge of the world).

In the picture an example of the result, at the bottom-left the terraform window, with the main part displaying the size of the area you modify (from a single corner-point to a 10x10 tile area).
You can either level the area (move the lowest parts up or the highest parts down), or move the entire area as-is (preserving the hills and holes within the area).

The other thing that got fixed is the connection of the shop with the path. The path is now extended towards the shop. In the air it was difficult to see whether it worked, so I added platforms under the paths and shops. It looked so great that I also added the supports as well.
It is starting to look very nice!

The code is still somewhat fragile, guests don't know about shops yet, and while preparing the above picture I found that path-building also sometimes gets confused.

Place a shop

Yet another step in the right direction, this time placing a 1x1 shop in the world.

The window at the top allows selection of the 'rides' (only one exists at this time). Click 'select' at the bottom, and optionally rotate it, then move the cursor to where you want to place it, and click again.

The shop can be placed next to a path, or on the ground.


Lack of supports was always somewhat of a problem, and now it has become really useful to spend some time on it, as it is quite impossible to see where you put the shop.

Other issues that must be resolved are the fact that there is a gap in the path just before the shop, the path has to be extended to the front of the shop.
Also, when placing a shop at the ground, you lose the ground surface (you can see this near at the right back of the bottom shop). This is however not a big problem, it just needs a bit of shuffling of data in a voxel, so you can have a voxel with both a shop and ground surface.

Happy birthday FreeRCT

Today, FreeRCT exists for one year, always a happy moment in the life of a project.
Time to look back and reflect a bit on what happened.

The start was pretty quick. After about a month of talking how, what, and when we decided to just go ahead and do it, and created the FreeRCT project.
It has been an interesting ride so far.

I started with some world-display code into the project, while Richard provided some first sprites. (Probably everybody starts with a display of the 2D world in a game like this, I think :) )

Then the real work started. Since the project literally started from nothing, lots of infra-structure got created in the past year:
- A 3D voxel world holding ground and paths (and tomorrow shops and rides).
- Display of the world to the screen.
- A GUI system for creating and managing the windows.
- A string system.
- Mouse, keyboard, and screen handling.
- Time and clock ticks.
- Random numbers.
- Colour/brightness parametrization.

The infra-structure is still not complete (no rides yet), so in the coming year it will be expanded further. Also, existing parts get replaced or expanded when the need arises (like the replacement of the Python code that generates the RCD files, and the string system that got unified with added translations).

The highlight of the past year was of course the moving people video. Your response was heart-warming. A clear sign that many people still like these games. Many thanks for your support, let's hope we get another highlight like that this year.

Last but not least, a sneak preview of what I am working on (very green currently).

Strings and translations

Translated texts

It has been a while, but another small step is made. In this case it's strings.

Remember that one of the aims was that different people could make parts of the game? A consequence of that decision is that every part must have its own strings.

The hard part was to find a way to have all these strings live together, such that you can combine strings from different parts without worries. A second puzzle was what to do with strings in the game windows. Eventually, this proved to be quite simple, see it as yet another part!!

While below the surface and in the build system, a lot has changed around strings (I completely removed the old gui string system), at the surface you don't see it. The windows are the same (including the missing closebox, I really should fix that one day). The layout is also the same as before. The only thing that's different is that you can now switch language (by changing a variable and recompiling the source code due to lack of a window for it). The screen shot proves it. Most strings are Dutch (spontaneously provided by Kenny), while some other strings are still English due to not having a Dutch translation.
(Please don't start sending in translations in your favourite language now, I appreciate the thought, but it will be a long time before they become useful, and quite likely strings I have now are obsolete by then. Better wait until the game is somewhat playable.)

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.

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.