Jump to content

RollerCoaster Tycoon: Classic (Android & iOS)


Recommended Posts

I saw it last night. I thought at first this was the result of Chris Sawyer's RCT2 port to mobile, until I saw the publisher was Atari.

I haven't tried it yet. It looks like Atari might have finally come up with something good, though.

Also I noticed an easter egg in the screenshots on the app store:

RCTCEasterEgg.PNG

Chris S.=Chris Sawyer
Simon F.=Simon Foster

Edited by YoloSweggLord
  • Like 1
Link to comment

So, 14 dollars for a 20 dollar PC deal? Seems OK to me.

Also, just got this last night, already ran my tablet's battery to 5%. I really coulden't ask for more out of it.

Though, the lack of a "Classic" UI option, Junior lift turns, and go-kart hills do annoy me slightly, however that's comparing a penny to the Empire State Building.

Link to comment
37 minutes ago, imlegos said:

I keep saying this, but chances are, we're gonna have to redo the entire game's graphics and sound at some point, just as OTTD did.

It'd be nice to have the game not dependent on vanilla assets, but I think the primary reason to do this is that trying to make custom sprites match the existing ones is really difficult - sometimes, I feel like a total replacement of everything might actually be easier in the long run. It would be a lot of work to replace them all, but once done, we could add new ones easily.

  • Like 1
Link to comment
50 minutes ago, Broxzier said:

@X7123M3-256 There is this repository with files for blender that have the correct view and projection matrices (you made those too, right?)

That's not my repository, it was set up by someone else. It does provide a toolchain you can use to render sprites though. I'm not sure how it handles x/y offsets - those are difficult because standard image formats don't support them, which is one reason why I wrote my own rendering code (and the other is remap colors, something most rendering tools don't support).

The problem with my approach is that the quality of the output is not up to par, and if I can't improve it I'll likely have to give up with any attempt to replace the base sprites, or perhaps delegate the rendering to a more sophisticated renderer (but it would need to be something command-driven - maybe POV-Ray?).

Another issue is consistency - we'll probably need more than one person to work on it, and we want those sprites to have a consistent look, so having everyone using a different toolchain isn't desirable from that perspective either. However, I can see track sections especially being very tedious to do without automation (perhaps it would be better implemented as a Blender plugin, but I have no experience with that).

I think, if we want to do this, we should first find out who is interested, and then create a single repository for the effort. We should put together a list of what needs replacing (I'd start with the sprites in g1.dat, because that's the bare minimum to run the game), and what models are needed to do that. We should agree on a single toolchain for rendering, and work to make it as straightforward to set up as possible. It would be nice to have a repo full of models, and then a shell script you can run to generate g1.dat. Then as soon as you've made a model, you could see it in game. I might look into getting something like that set up, if I have time and if anyone is actually interested.

Edited by X7123M3-256
  • Like 1
Link to comment
14 hours ago, X7123M3-256 said:

That's not my repository, it was set up by someone else. It does provide a toolchain you can use to render sprites though. I'm not sure how it handles x/y offsets - those are difficult because standard image formats don't support them, which is one reason why I wrote my own rendering code (and the other is remap colors, something most rendering tools don't support).

The problem with my approach is that the quality of the output is not up to par, and if I can't improve it I'll likely have to give up with any attempt to replace the base sprites, or perhaps delegate the rendering to a more sophisticated renderer (but it would need to be something command-driven - maybe POV-Ray?).

Another issue is consistency - we'll probably need more than one person to work on it, and we want those sprites to have a consistent look, so having everyone using a different toolchain isn't desirable from that perspective either. However, I can see track sections especially being very tedious to do without automation (perhaps it would be better implemented as a Blender plugin, but I have no experience with that).

I think, if we want to do this, we should first find out who is interested, and then create a single repository for the effort. We should put together a list of what needs replacing (I'd start with the sprites in g1.dat, because that's the bare minimum to run the game), and what models are needed to do that. We should agree on a single toolchain for rendering, and work to make it as straightforward to set up as possible. It would be nice to have a repo full of models, and then a shell script you can run to generate g1.dat. Then as soon as you've made a model, you could see it in game. I might look into getting something like that set up, if I have time and if anyone is actually interested.

I don't really see why there is a need for replacing the assets. If money to buy RCT2 is really the barrier they can just use the demo (unless this is changed now). Only advantage I could think of is rendering everything at a higher resolution for high DPI displays.

Anyway, here are some solutions I came up with:

For tracks an easy solution could be using Bezier Curves and the Curve modifer in Blender. Doing this makes it only required for a small straight piece of the track to be moddeled which then can be extended using the Array modifier and will follow the made Curve automatically (See attachments). All Track pieces of the same type (ex: all sharp turns) can follow the same pre-made curve to save time and make sure you don't get weird turns that don't look like they should. The problem is that AFAIK there is no way to make objects fit a Curve exactly. So unless your model's length can be multiplied to fit the Curve exactly will two pieces never connect properly. Although someone could probably write a plug-in to do this though.

For consistency someone could make a template (an empty Blender file with everything set up correctly). Assuming the modeler knows what he/she is doing and doesn't make crappy models ofcourse :P.

RCT Track.png

TrackRender.png

Edited by Fredfuchs285
Link to comment
27 minutes ago, Fredfuchs285 said:

I don't really see why there is a need for replacing the assets. If money to buy RCT2 is really the barrier they can just use the demo (unless this is changed now).

The way I see it, there are a number of reasons:

 

  • Replacement assets would make OpenRCT2 a standalone game. Since OpenRCT2 does not distribute the assets it requires, you have to have RCT2. The demo works but it doesn't contain all object files so it will be unlikely to work with parks others have made.
  • We don't have access to the original models, which presents a consistency problem. It's extremely difficult to make custom content that keeps the visual style of the original assets, and as the game expands, we're going to need more and more custom sprites.
  • If we want 32bpp graphics or extra zoom levels, we have to replace the assets (and both of these have been requested in the past).
  • Replacing the assets used by the expansions could make them not shit.
    27 minutes ago, Fredfuchs285 said:

    For tracks an easy solution could be using Bezier Curves and the Curve modifer in Blender.

    I was unaware of this feature. It does essentially the same thing as my track rendering script does. However, not all the track pieces are Bezier curves; in particular, many curved pieces are circular. You can approximate them pretty well though, and I think Blender might have support for NURBs, which can represent circles exactly.

27 minutes ago, Fredfuchs285 said:

The problem is that AFAIK there is no way to make objects fit a Curve exactly. So unless your model's length can be multiplied to fit the Curve exactly will two pieces never connect properly

No matter what size the model is it won't fit all track sections exactly, because many of the ratios are irrational. The way I handle this is to calculate how many track sections will fit, and then scale the model to absorb the leftover. It seems to work out well in practice - and I'm pretty sure a similar approach must have been taken for the original sprites.

Edited by X7123M3-256
Link to comment

What exactly is the advantage of NUBS over bezier curves? Considering we are using polygonal models will you never get a perfect circle no matter what you do.

And looking at the assets in RCT it seems that these arent always perfect either. So it indeed seems they had to do something similair as you described.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...