Let there be widgets

Filling the windows with some (inter-active) content was the next step. As you can see in the picture, the toolbar at the left now has two buttons. If you click at the right one, the window at the right is opened (a first version of the path building interface).

The sizes and positions of all widget elements are computed automatically, so if you change the text (eg use a different language than English) or if you use different arrow sprites, everything is moved around to fit the new sizes.

Note that the slightly shorter titlebar of the path build window is not a bug. The system thinks an 'X' close button is located there, but since there are no graphics for it yet, you cannot see it :)

Adding paths to the program would be a nice next step perhaps. I don't really like the 'build single path tile with each click' idea, so I am still pondering a better system, in particular for building in the air.

Windows

It is slowly becoming useful to be able to communicate with the program by means of pressing buttons, and by reading messages.
We have opted for sprite-based windows, to allow for easier customization. That means tomorrow we can create themed windows just by changing the sprites used to draw the windows.

The code was not really ready for such sprites, nor was it ready for more than a single window. Much of the blitter code (the code that copies the actual pixels to the screen) was rewritten, and the windows updating and managing code was restructured to support several windows being displayed at the same time.

In the image you can see the first result. The blue bar is part of the window manager that I use. At the top-left inside the window, a brown-ish window panel (with nothing on it yet) is displayed by the FreeRCT program, and below it the viewport window with the flat world and the white tile cursor.

Mouse cursor handling


Today FreeRCT learned at what part of the game world you point your mouse. Quite useful for querying information, or edit something. The tile cursor is the first thing that is mouse-pointer aware. It is shown as the partially visible white square behind the bump. It follows the mouse pointer as you move the mouse around perfectly.

The trick that I used is that I re-used the drawing code. Basically, to decide what the mouse pointer points at, I 'draw' a single pixel at the coordinates of the mouse, and keep a record of what sprite gets drawn. Together with the sprite the used world position is stored. The real drawing code uses that position to display the white tile cursor.
The result is a pixel-perfect positioning of the tile cursor.

Since the drawing code itself is used, this will also work for other elements in the game, such as people, stalls, and rollercoaster graphics.

Graphics and Development

Many free remakes of classic games, like OpenTTD/Transport Tycoon and CorsixTH/Theme Hospital, are programmed with the direct aim of reusing all the original game's graphics... By reusing the the graphics from the original game you are guaranteed to capture its look and feel and the immediate availability of graphics lets the coders get straight to work.

While this is an easy way to get straight into development it also restricts the coding of the open source remake. A commercial game and an open source game have very different requirements. A free remake of a game is supposed to be exactly that; free. Being tied to the original graphics means this isn't the case, users need a copy of the original game to get the required graphics files to play the remake. Open source games are also fueled by user generated content; if the coding of the game is tied to using the original graphics then this can push design choices in the coding away from flexibility and extensibility using custom graphics sets, etc., towards a rigid reimplimentation of the original game. Major changes, like designing a large GUI for use with touch screen devices, would simply be impossible if limited to only the graphics from the original game.

Because of these reasons FreeRCT will be coded in parallel to a large drawing project which will make the basic graphics for FreeRCT to use. The graphics will be designed in the same format as the original RollerCoaster Tycoon graphics (i.e. 8-bit paletted graphics, with the same palette as the original graphics) and will be designed to be essentially interchangeable (e.g. the terrain tiles will tesselate into a landscape in the same way the original graphics did). This means that, in the future the original RollerCoaster Tycoon graphics could be coded for use in FreeRCT, but up until that day the coding of FreeRCT is not encumbered by being forced to use the graphics from RollerCoaster Tycoon.

Don't worry though, we do aim to support the original graphics in the future to give people the option of an authentic RollerCoaster Tycoon experience!

 

The 24 sprites that make up the normal terrain with and without gridlines.

Designing all the graphics for FreeRCT from scratch is a challenge, especially when trying to capture the same look and feel as the original graphics. RollerCoaster Tycoon really reached the peak of what was possible with sprite (small 2D image) based graphics before the game industry moved towards 3D graphics. To get its high quality appearance RollerCoaster Tycoon used nearly 30,000 sprites. Fortunately most of the graphics can be generated from 3D renderings and scripted conversion to the correct palette and arrangement into sprite sheets... Getting this working is what my challenge is.

Hi and Welcome

Hi, and welcome to the FreeRCT DevBlog. Here you will find updates (hopefully not too sporadically) on the development of FreeRCT, a free and open source game inspired by the classic RollerCoaster Tycoon.

The home page - FreeRCT.org :: Project hosting at Google code :: FreeRCT on Twitter

You can keep track of updates on this blog via the feeds on the right or by following us on Twitter.