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.
Thanks for the update Alberth. I wish I could contribute, but I'm little more than a layman when it comes to this level of coding.
ReplyDeleteI wish you and your team all the best, I'l keeping a close eye on the project and can't wait to someday play FreeRCT.
Thanks for your support.
DeleteI cannot wait until it's ready either
I have been meaning to get into the code and take a peak. I am confused about the image loading/drawing problems you are having. Firstly, if you aren't using SFML/SDL, you are wasting a ton of time. I will dedicate some time as soon as I am able to help.
ReplyDeleteImage loading works, drawing works, but in-between you have the problem of deciding what you actually need to draw at what place.
DeleteThe input of this is a 3D data storage of voxels (each voxel is a box, the size of a single tile (and the unit height as well)).
Inside the voxel you store what can be seen at that place in the world.
So far, I have assumed that there is one element to display in a voxel. Also, I assumed that rides are 1 voxel big. Last but not least, I have 3 kinds of voxels (I used to have four, but removed one a long time ago).
All these things are not true any more. In other words, the structure of an elementary voxel is all wrong.
The contents of a voxel is not only used to render things to the screen, it is also used by all components to decide what can or cannot be done, like where is the next path, can I build a new ride at this position, etc etc.
Changing the internals of a voxel thus has a large impact, as there is a lot of code that uses those internals to make decisions.
(and no worries, I do use SDL already :) )
Hi Alberth,
ReplyDeleteIs the problem how to store efficiently, read from and then calculate render order for the voxel environment?
This is something I spent many many months tinkering with myself with IsoMatrix; looking at all the game objects that exist in the world and working out how to do an implementation that would emulate it well.
Perhaps a Wiki style discussion breaking down the problem with pictures and some pseudocoding, and allowing for external community input to methods to solve the issue may help build a solution. It would also serve as a learning tool for others in the future wanting to understand the inner workings of the FreeRCT source.
Keep up the great work!
My current problem is that I cannot represent a multi-voxel track-piece in the world, in particular when voxels are only partly used.
DeleteI have already figured out what structure I need. I have however a code base with a different world storage structure. That needs changing, except it is a bit very large, so lots of things fall over when I move it too fast.
The global structure is pretty simple, there is a 2D array of vertical voxel stacks, one stack for each tile. There is a lowest voxel with content and a highest voxel with content, and the voxels in-between are actually stored.
I think that inside a voxel you need 4 parts, each possibly containing a ride part (one ride may use several parts in a voxel). You also need ground, and foundations. That's about it.
Rendering is also pretty straightforward, stacks are drawn from back to front, going vertically up within a stack. Currently I throw all sprites in a set and sort them before rendering. Since I can change the sort order easily, it's not hard to experiment with different orders of rendering. I know it's not the fastest thing at the planet, but at this stage, who cares.
Once the program has all sprite layers, and I am happy with the display, I may hard-code the rendering order I have at that moment, if it eats too much CPU time.
It's not the planning approach that you prefer, but I have no time to spend large amounts of time on rendering stuff. There are soooo many other things that also need to be done.
For example;
ReplyDelete5000 peeps in the world, running 30fps (lets say 30 game ticks). You need to;
a. Recalculate peep positional movement direction each tick; plus all the other things (behaviours such as phototaking, bench sitting, littering, vandalizing, new pathfinding route to be calculated, peep attribute changes hunger/thirst/nausea etc)
b. For each viewport, determine if peep is within range for rendering.
Thats a lot of calculations to perform in 30fps when peep counts get large.
Within a simple implementation with 50 peeps, not such a problem, but long term, this will stiffle performance. It may also require rehashing the entire engine to enable faster performance, the way rides interact with peeps, the way the renderer works, the way peeps are stored and updated.
Forward thinking and pre-planning an implementation can make the whole process of finding solutions easier and allow external contribution.
p.s A wiki would be great to contribute to. *hint hint*
One thing I have learned about performance tuning is that your prediction is always wrong.
DeleteWhen I need to improve performance, I always guess beforehand what problem will pop up. Invariably, I am wrong. The real bottleneck is at some stupid low-level program snippet.
Note that I do have good performance for larger scale in mind when designing data structures and ways that things need to be accessed. Beyond that however, it is not really predictable any more.
p.p.s
ReplyDeleteI thought I'd upload a video of IsoMatrix showing you where I was at with it, as you never got to try it due to it not running on Linux;
http://www.youtube.com/watch?v=lojZ6O8JXBk
It looks very nice, thank you.
DeleteI still find it a pity that you didn't join us at the start.
In an older post you write that you want to code the game in that way that the player can use the original RCT grafics. Do you plan making it possible to use also the RCT2 grafics? Maybe side-by-side with the RCT1 grafics?
ReplyDeleteGiven that it is mostly the same engine that draws them, if you have one set, you mostly also have the other set.
DeleteIn my view, the primary aim is to make a freely available and open game where you can enjoy building and managing a theme park. Since we have a good graphics artist on the team, I see no direct need to support commercial graphics sets, also because that directly contradicts with the "freely available and open" goal.
Having said that, the game engine makes very few assumptions on the graphics, so I see no fundamental obstacles in converting other graphics sets for use by the game. The more tricky part of such a conversion is however the behaviorial part. Prices of things, effects of food and flowerbeds on the happiness of guests, ride times, path and speed of cars at a coaster, etc.
Another problem is distribution of such a conversion. Unless you can buy the right to distribute the graphics, you are not allowed to give your converted set to other people.
Personally, I have a lot of doubt whether it is worth the trouble, given that we will have a free set of nice graphics as well.
There is another way: a converter that asks the user for his/her RCT1/RCT2 cd and extracts the contents into FreeRCT files. Since these files are the same for everyone one can include metadata for correctly converting anything you mentioned (the 'behavioural part').
DeleteTheoretically, the data set should be the same for everybody indeed. In practice this is not entirely true; different releases my have some fixes included. Different countries may also have different versions (American versus European release for example). Usually this is solvable though, the differences are normally very small.
DeleteSuch a convertor is certainly viable to build. I am sure someone will try it at some point in time.
I understand the issue you have with the current Voxel structure not being able to store different types. I believe that the original software allowed placing two objects on a same tile using a trainer called 8carsPerTrain and both of the objects could be displayed. Even making the 1/4 tile voxel data, it is kind of limiting.
ReplyDeleteI propose that there should be a list of drawable objects in the world with their position as if it was a real 3D world (x,y,z), peeps, trees, rides, anything that isn't the terrain, except for the rain... I think it will be faster to iterate through those objects using an octree structure or anything like that. The objects should have an image data containing the animations and offset, etc.
There is always some limit, no matter what you pick.
DeleteThe advantage of having a simple limit and simple layout of a voxel, is that it is easier to predict what you need to draw (and where).
Arbitrary 3d coordinates sounds very nice (and it is), but it drastically changes the game look and feel. You can basically throw voxels out the window, and do everything in 3d. For a game oriented at the newer rollercoaster tycoon programs, it would be a good move. For a game aiming at the classic look and feel, it seems a bit overkill to me.
I got it running on Mac OS.
ReplyDeletehttp://oi44.tinypic.com/2hz2y5i.jpg
\o/
DeleteCould you post build instructions? I'm having trouble to build it on OS X 10.9.1, as documented on google groups: https://groups.google.com/forum/#!topic/freerctgame/W6Ux2aJJnfc
DeleteI'm sorry to say that I'm not an game developer or something. But therefore I love your initiative to make a free RCT. I played it so much back in the days that my CD broke down. But still I have very much the desire to play the game again.
ReplyDeleteIf you need a beta tester or something, count me in if you like.
And keep up the good work!
With kind regards,
Mark
This is an informative post review. I am so pleased to get
ReplyDeletethis post article. I was looking forward to get such a post which is very
helpful to us. Keep it up. . I know something information, to know you can
click here
Test and Tag brisbane
rcd testing services brisbane