Hello all,
If you are watching the YouTube FreeRCTGame channel, you know already, there is a new video.
It shows building of a small roller coaster, followed by a moving coaster car (at fixed speed, and not rotating along with the tracks). For some reason, the blog doesn't allow me to link to the video directly (thank you so much, smart user interface), so instead I post the url: http://www.youtube.com/watch?v=aqBzyJIvrrg I hope you like it.
Bits and bobs about the development of the free and open source game inspired by RollerCoaster Tycoon
Sunday, 29 December 2013
Saturday, 2 November 2013
Car tracks
After tracks, the next step is obviously to have some cars on them, carrying paying guests of course!
In the real world, you just put the car on the track, and it will follow them. In the digital world of make-believe, car graphics don't care about track graphics, and you have to explicitly tell them how to move through the world.
If you remember the original Rollercoaster Tycoon programs, you'll know tracks came in all kinds of bendy shapes, so how to do that?
One answer that should work (we think), is segmented cubic bezier splines. Basically, you define a start and end point in 3D space, and two intermediate control points (also in 3D), and the bezier algorithm computes a smooth line from the start to the end point. For the more bendy shapes, one such spline is not sufficient, you either need a higher order bezier curve (but it's math becomes complicated), or you chain a number of cubic splines after each other. If you do that careful, the cross-over from the end of one spline to the start of the next spline is also smooth.
So far so good, bezier splines gives a line of rope through 3D space for the car to follow. But what about the orientation of the car? (Keep in mind, the car ignores the track graphics!)
Just a line doesn't tell whether the car is up-right or upside-down (or anything in-between). To solve this problem, a track also needs a roll orientation for every point at the line. A smooth path from a starting roll value to an ending roll value (in degrees).... Another segmented cubic bezier spline to express the roll orientation in degrees!
From the direction of the 3D line (for the mathematically inclined, its derivative) and the roll, the pitch and yaw can be computed (hopefully, I haven't actually tried that yet).
For the test rollercoaster track graphics, roll is simply 0 (upright orientation), so that's easy. The path involved a bit more experimenting. I made a small Python program that plotted the path curve onto the existing track graphics, and tuned the start, end, and control points until it all looked ok. You can see the result above.
For example, the path of the level-to-going-down-track in negative x direction (bottom-right sprite) is defined as
car_xpos: splines { cubic { a: 255; b: 150; c: 100; d: 0; length: 1000; } }car_ypos: splines { cubic { a: 128; b: 128; c: 128; d: 128; length: 1000; } }
car_zpos: splines { cubic { a: 80; b: 78; c: 50; d: 15; length: 1000; } }
car_roll: 0;
The roll is 0, as expected. The x position runs from 255 (point a) to 0 (point d), with intermediate control points at 150 and 100. The y position is 128 all the time. The z position starts at 80, and ends at 15 (points a and d). Point b at 78 is almost the same height as point a, so near the start the path is almost level. Point c is much higher than point d, so it goes down more steeply.
So far, it all looks good, but getting to the point of a car following the track on the screen will be quite some work. Then we will see whether the above math actually works :)
Saturday, 19 October 2013
Quick update
Just a quick update to let you know we're still here!
Thanks
Lord Aro
Recent changes
Languages
You can now change language ingame, via the new settings window. Language strings appreciated!Bug fixes
There had been a nasty bug for quite some time where FreeRCT crashed whenever a guest visited a shop. Since that is still basically our main 'feature', it was somewhat important that we got that fixed.
Numerous other minor fixes, including a memory leak in rcdgen.
Build System
As some of you may have noticed, FreeRCT's build system has been switched to a CMake system. This makes cross-platform much easier (Build Instructions here). However, there are some notes:- Existing checkouts may be broken, due to CMake not recognising existing generated files. To fix this, you must delete the existing generated files
With svn, this can be done with:
"svn st --no-ignore | grep '^I' | awk '{print $2}' | xargs rm -rf"
Remember to backup your freerct.cfg !
- Please test the build system on your OS, whatever it is and report any problems you have, to the bug tracker. FreeRCT should build on all Operating systems now, but there might be some problems with the build system initially. Note that we cannot help you with regards to installing individual libraries, as we have no idea ourselves, but if you manage it and the process is particularly difficult, tell us how so we can add it to the wiki.
Thanks
Lord Aro
Saturday, 7 September 2013
Birthday surprise: Coaster tracks!
Hello all,
Time sure flies when you're busy. Next week it is the second birthday of the project.
Look at the right what present we got?
Indeed, you can build tracks of a roller coaster. It's still very rough version. Delete doesn't work, back and forward doesn't work either. Platforms are still invisible. But who cares, One big step towards getting a playable game!
Time sure flies when you're busy. Next week it is the second birthday of the project.
Look at the right what present we got?
Indeed, you can build tracks of a roller coaster. It's still very rough version. Delete doesn't work, back and forward doesn't work either. Platforms are still invisible. But who cares, One big step towards getting a playable game!
Monday, 20 May 2013
Hurdles
It has been a while since the last blog about the development.
Those of you that follow the commit logs, know development has not stopped.
The main reason not to post anything is that there is not much to show to you. All changes are preparation for the next step, namely getting a roller coaster rolling. It looks like it's going to be a long ride with a lot of hurdles.
After getting all the nice coaster ride sprites from Richard, the first hurdle was getting them loaded in the game. The Python RCD file generator didn't want to co-operate, so I spent a month on ditching the thing. We now have a shiny new C++ implementation. Not only is the generation process faster (which will be useful with larger roller coasters, the number of sprites is going to explode!), it also means you don't need Python any more to build RCD files. This is very useful for whoever is going to enable development at windows.
The next hurdle was making room for coaster data inside the game. A roller coaster is a 'ride', just like the shop (with both, a guest enters, does something, and leaves again). Thus logically a coaster belongs next to the shop. The code however did not agree sufficiently, so I have been pushing it into a better shape for some weeks. The game can now load the coaster sprite data (it contains a lot more than just the sprite, the shape of every piece is also stored, and which piece can be connected to which other piece).
The previous hurdle is still causing some small trouble, but that's manageable. The next hurdle I somewhat expected, but yesterday I found out how large it was exactly. It is not a pretty sight :(
Once you can load pieces of track, the next thing you want is to allow the world to display it. (Basically, you want to be able to say "draw that track piece at this position in the world".) Displaying it is the stepping stone to making a GUI window for editing coaster tracks in the world. (And having a rollercoaster ride in the world is in its turn the stepping stone to adding cars, and adding physics so the cars move in virtual gravity.)
Unfortunately, the current display storage doesn't even look right. It will need a lot of restructuring to push it into any usable shape. It might be easier to just write the thing again. What's worse, there is a lot of code attached to that display storage. Paths decide how they connect, shops decide where they can be placed, guests decide where they can walk. A small change in the display storage has already a large impact, let alone a major restructuring like I need to do.
So this is what is happening. We're not dead, far from it.
There are 'just' an unknown number of hurdles in the way, and I am fighting with a big one for the next weeks or months.
Those of you that follow the commit logs, know development has not stopped.
The main reason not to post anything is that there is not much to show to you. All changes are preparation for the next step, namely getting a roller coaster rolling. It looks like it's going to be a long ride with a lot of hurdles.
After getting all the nice coaster ride sprites from Richard, the first hurdle was getting them loaded in the game. The Python RCD file generator didn't want to co-operate, so I spent a month on ditching the thing. We now have a shiny new C++ implementation. Not only is the generation process faster (which will be useful with larger roller coasters, the number of sprites is going to explode!), it also means you don't need Python any more to build RCD files. This is very useful for whoever is going to enable development at windows.
The next hurdle was making room for coaster data inside the game. A roller coaster is a 'ride', just like the shop (with both, a guest enters, does something, and leaves again). Thus logically a coaster belongs next to the shop. The code however did not agree sufficiently, so I have been pushing it into a better shape for some weeks. The game can now load the coaster sprite data (it contains a lot more than just the sprite, the shape of every piece is also stored, and which piece can be connected to which other piece).
The previous hurdle is still causing some small trouble, but that's manageable. The next hurdle I somewhat expected, but yesterday I found out how large it was exactly. It is not a pretty sight :(
Once you can load pieces of track, the next thing you want is to allow the world to display it. (Basically, you want to be able to say "draw that track piece at this position in the world".) Displaying it is the stepping stone to making a GUI window for editing coaster tracks in the world. (And having a rollercoaster ride in the world is in its turn the stepping stone to adding cars, and adding physics so the cars move in virtual gravity.)
Unfortunately, the current display storage doesn't even look right. It will need a lot of restructuring to push it into any usable shape. It might be easier to just write the thing again. What's worse, there is a lot of code attached to that display storage. Paths decide how they connect, shops decide where they can be placed, guests decide where they can walk. A small change in the display storage has already a large impact, let alone a major restructuring like I need to do.
So this is what is happening. We're not dead, far from it.
There are 'just' an unknown number of hurdles in the way, and I am fighting with a big one for the next weeks or months.
Monday, 6 May 2013
Contributing and Info
It has become apparent that some people who would like to contribute to the project are unable to do so, as they do not know what needs to be done. Short answer: Everything!
Seriously. The project is still in its early stages, and any contributions are welcome. A guide to contributing is located at our wiki, specifically here. Hopefully all the necessary information is there. Comment below if you feel something is missing.
Also set up recently was a 'Google Group'. You should be able to use this to discuss things and future content etc. (Although what you'd actually usefully discuss is somewhat unknown at this time)
Oh, we also have a FaceBook page. It's, umm, quiet.
In FreeRCT development news, preliminary work is being done to add the first Roller Coasters!
Any other questions, leave a comment below!
Seriously. The project is still in its early stages, and any contributions are welcome. A guide to contributing is located at our wiki, specifically here. Hopefully all the necessary information is there. Comment below if you feel something is missing.
Also set up recently was a 'Google Group'. You should be able to use this to discuss things and future content etc. (Although what you'd actually usefully discuss is somewhat unknown at this time)
Oh, we also have a FaceBook page. It's, umm, quiet.
In FreeRCT development news, preliminary work is being done to add the first Roller Coasters!
Any other questions, leave a comment below!
Monday, 14 January 2013
The Graphics Guy
As the guy who draws the graphics I don't get to show off amazing videos of building paths, modifying terrain or opening shops, though all the graphics in those videos are my work. As I said before we are aiming to produce all the graphics ourselves. This may seem like a crazy huge task, but it will give us more flexibility and ease in getting the fundamentals of the game up and running - we can custom make any and all the graphics exactly as we need. "Home made" graphics certainly doesn't mean we are compromising on quality though!
It is likely that about 20,000-30,000 separate images will be needed for all the game graphics. This is a huge number but through smart use of 3D software and automation making these graphics is comparatively simple. Since starting the FreeRCT project I have been working on several projects with similar graphical requirements to FreeRCT. These projects have let me work out streamlined workflows for creating this type of image; my last major project was an extra zoom level graphics set for OpenTTD. If you are interested you can read more about that project at these blog entries: Making a Massive Graphics Update, Moving to 3D, Automation, The Finished Product.
Basic track tiles
It is likely that about 20,000-30,000 separate images will be needed for all the game graphics. This is a huge number but through smart use of 3D software and automation making these graphics is comparatively simple. Since starting the FreeRCT project I have been working on several projects with similar graphical requirements to FreeRCT. These projects have let me work out streamlined workflows for creating this type of image; my last major project was an extra zoom level graphics set for OpenTTD. If you are interested you can read more about that project at these blog entries: Making a Massive Graphics Update, Moving to 3D, Automation, The Finished Product.
The very first shop
So far land, cliff/foundation, water, path and path support graphics for FreeRCT are made (although there are some technical issues that still need working out). The next big challenge will probably to make templates for track rides, in particular the track pieces which stretch over more than one tile.
Saturday, 5 January 2013
We're in business!
(At 3:05 and 4:17.) The recording program had some trouble around 3:38 apparently, the delay and speed-up was not at the screen.
Subscribe to:
Posts (Atom)