next »

[JobLeonard]

Yikes . Yeah, no need to optimise the CPU yet if that's the cause.

(and that, kids, is why you should profile your code)

[The_RonJones]

I've always loved Theme Park sims... Can't wait for your game GOOD LUCK!

[Paul Jeffries]

Presumably the 'virtual corridor' is essentially a rectangular sweep along a spline.  As a first (or second/third, after partitioning/AABBs etc.) pass you could find the closest point on the spline to the object you're checking intersections with.  That will tell you whether further checks are needed and if so which section of track an intersection is most likely to occur on.

[Sebioff]

Good idea! With the bug fixed it's not a performance issue for now, but it might be interesting in the future.

[JobLeonard]

That gif is really satisfying to look at, for some reason.

[danieru]

Yeah, it is almost comforting, and somehow a quite linear rate of movement.

[Sebioff]

Hey guys,
don't have too much to talk about over here at the moment as we've recently more been working on adding a bit of content rather than doing technical stuff, but I thought it's time for a quick update anyways

First of all, we reached our Kickstarter goal with a couple days to go! Yay! :D

I've got building through wooden coaster supports working:

This also uses the "corridors" I wrote about earlier.

We did some work on wing coasters this week:


And I've added coaster breaks:


I tried two different ways to implement these - my first try was to basically give the break segment a higher friction as long as the train is faster than a userdefined speed limit. This approach has the downside though that it's hard to find a good value for how strong this friction should be...if it's too low the train won't reach its target speed, if it's too high it stops too abruptly. Letting the player set the friction value would be annoying. No matter what predefined value I would choose there would always be some speed at which the friction would be too low to be able to decelerate the train to its desired speed. At first I thought that might be acceptable since it seems somewhat realistic that a brake can't reliably slow down a train from 300kph to 10...but from a gameplay point of view it'd be really annoying if you build a brake and don't get the speed you want. It would seem like a flaw of the game that you don't receive what you're requesting it to do.
So what I'm doing instead is to interpolate between the speed the train has when it enters the brake and the speed it should have once it exits the brake...so the train is guaranteed to not be faster than whatever speed you want it to have. So, if you want it to decelerate from 300kph to 10 you receive that...and it's your fault as the coaster designer that nobody will ever ride that thing due to crazy G forces. And I think that's how it should be.
What's really nice about this approach is that it also works really well with our "user-defined track segment length" system - the longer the brake segment is the smoother the deceleration will be. So basically this gives the player an intuitive way to control the friction force.

[Thomas Finch]

You could also set the friction to a division of the current speed, so no matter what speed the coaster is at, it slows down at a good rate.

[Sebioff]

Yeah, that's what I'm doing for station brakes - actually, you could say I'm also doing it for the brake runs, with the divisor being dependend on the difference between entrance speed and desired exit speed and segment length instead of a fixed value (otherwise it'd have the same problems as my first try).

[brokeit]

Probably nitpicking here, but that that wing coaster manages to go over a hill that's higher than the lifthill. So it seems like the train goes too fast, but I guess that was done just to show off the gif really loving the look of that coaster. Will probably build lots of these!

Nice to see you make good progress!

(By the way, wasn't this topic like 50 pages long, or am I just imagining things?)

[Switchbladed]

Congratulations on your funding, I've been watching this project for a while, looks like a great game and although I didn't back in the Kickstarter, I will be purchasing the game at a later date.

I can see it's still possible to pay with PayPal via Humble, which I may do, although I was wondering if you plan to release a playable version before August 2015?

[qwurp]

Congrats guys! Backed the KS and excited to see what you guys are gonna accomplish with the funding.

[nikki]

congrats on the kickstarter !

[Sebioff]

Thanks everyone Really sorry I'm not posting as much over here anymore, but I think it's kinda pointless to simply copy everything over from our "public" devlog? :/
Although - Garret is currently busy with UI design and redesigning the guests, so I'll probably do more tech stuff soon in the meantime, we'll see.

Actually, I've got a question for you Unity users! Remember that coaster G force visualization?

I'd like to know your take on how you would implement something like this, where you decolorize the entire world except for some specific parts that are colorized in order to visualize some data?
The way I did it seems kinda insane and hacky - I'm iterating over all objects in the world and assign a new material to them. It does work but clearly is not an ideal solution. I had to do it like this though since there's no access to the framebuffer in Unity Free, but now that we've got Pro there must be a better solution.
Shaders are a bit of a weak spot of mine, but how does this sound: render the framebuffer with some shader that decolorizes everything except for stenciled parts (the coaster tracks in this case), and only assign a new material (with a "data visualization shader") to the coaster tracks? Could work?

So it seems like the train goes too fast

That was a bug actually I'm calculating coaster speeds in m/s and forgot to convert from meters to the scale we're using.

I can see it's still possible to pay with PayPal via Humble, which I may do, although I was wondering if you plan to release a playable version before August 2015?

We had special "early build" tiers for that on the KS (releasing it to everyone would probably be a bit overwhelming).

Finally, here's a little something for you at least - we recently made the balloons on the balloon stall resemble it's stock content:

So if a guest buys a balloon it actually disappears from the stall. Just a tiny detail but we thought it'd be fun.

[danieru]

I'm not a Unity user but I hope you won't mind if I try.

We do something similar in Super Battlelands so I hope that qualifies me to give advise.

As you can imagine replacing materials will cause a GPU pipeline stale. So whatever you do: don't do that.

In SB when map area is out of view range those tiles get shaded darker. To transfer this knowledge CPU -> GPU we use a map sized texture (one pixel per tile). This works for us because the maps are sizes like 8x8, 10x10, or at the extreme end 400x400. Then in the vertex shader we run the math and find a vertex's map coordinate. In the fragment shader we take this coordinate and index into that map sized texture. This gives a good 32bits where we pack game state.

For example we pack in:

• Visibility
• Unit ownership
• Tile ownership
• Can the tile be moved to by the selected unit?
• Can the tile be attacked by the selected unit?
• What direction would the unit move if you moved through the tile?
• City capture progression

32bits holds more info than you might think.

Parkitect will need the g-force info packed on a per vertex basis. Best tool there is to dual-use the vertex color. The Ambient Occlusion does not need 4 Billion shades of grey so shuffle that down to 16bits and use the remaining 16bits for the G force visualization. This lets you colorize the track without swapping materials or doing another pass over the framebuffer.

In fact 16bits is still too generous. Better compress that down to 8bits each. Then the track color can use 16bits instead of separate materials. That should reduce the drawcalls by batching the geometry.

The non-track objects can be decolorized by setting a bool in the uniform. This will cost a branch in the shader during regular running but since 100% of everything branches the same path each frame the branch predictor will make this cheap.

So to summerize: bit packing + uniform = super fast mode switching. You may even want to start altering colors for other uses, like day-night cycle or seasons. Once you get a taste of shader programming it gets addicting.

Hope this was applicable.

[Paul Jeffries]

As a structural engineer, I'm duty-bound to ask: are you planning on modelling the effects of the forces on the tracks themselves?  It would be cool if as well as cars derailing poorly-maintained tracks and rides could also fly apart at inopportune moments.

[Krux]

you definitely have my attention, because I am a roller coaster tycoon fan, and your game looks a lot like roller coaster tycoon (RCT). But RCT is written entirely in assembler by one single genius who optimized at that in basically doesn't need resources. I would like to know on what basis you are building your game, so that I can believe you that it doesn't suffer the same performance problmes as RCT3 which is by far not as optimized as the predecessors.

[Sebioff]

@danieru: Hey thanks! Interesting ideas. From my experience changing any of the mesh data is crazy slow in Unity and the G-force data is updated a lot, so that might not work for me...will give it a try though, would be nice if it works. I'd also like to avoid having to code the decoloization into every shader...
I gave the stencil approach a try, works fairly well With that I only have to swap the materials on the tracks and can leave the rest of the world alone, so that's an improvement. Just got some problems in occluded places that I don't entirely understand yet (see the base of the supports):

As a structural engineer, I'm duty-bound to ask: are you planning on modelling the effects of the forces on the tracks themselves?

Mhm...that'd also depend on the support placement then, right? I don't think I want to go that far.

But RCT is written entirely in assembler by one single genius who optimized at that in basically doesn't need resources. I would like to know on what basis you are building your game, so that I can believe you that it doesn't suffer the same performance problmes as RCT3 which is by far not as optimized as the predecessors.

Not exactly sure what you mean with the "basis I'm building on" - I'm using Unity if that's the question. Definitely not gonna switch to Assembler
You can check out our "interactive trailer" if you wanna know how well it runs on your PC:
Browser build (requires Unity Web Player) | Standalone build (Windows, 64bit)
It's obviously just a small park and only running with a subset of the features we'll have in the end, but yeah...let me know if that answers your question

[Sebioff]

Hey everyone,
I finally found some time to write a post about how the coasters work that I promised before, so here it is!
I hope it's not too technical but not too simplistic either.

Defining the shape of the track pieces

If we want to simulate a coaster the first thing we need is some method for defining the shape of the track. We want to have a mathematical description that allows us to model coaster elements like straights, curves, hills and more in 3D space. It has to ensure that there's a smooth transition without sharp edges between individual segments and should ideally be fairly intuitive to use.
One such method (that, along with others, is also used by real coaster architects) are cubic Bézier curves. They look like this:


You're probably already familiar with them from vector graphics programs or other programs that allowed you to edit a curve.
The curve is defined by four control points P0, P1, P2, P3. It always goes through P0 and P3. The direction from P0 to P1 defines the tangent at P0, the direction from P3 to P2 defines the tangent at P3; they're drawn in yellow above. The longer these yellow lines are, the stronger the curve gets "pulled" towards the tangent.
For defining the entire coaster track we stitch multiple of these curves together (to a "Bézier path"). If we are careful with the tangent at the end of one curve and the tangent at the beginning of the next curve we always get a smooth transition between segments (that is, P2 and P3 from one segment and P0 and P1 from the next segment always have to be on one line):


Alright, we have those four control points, but what we really want to have are the points on the curve - how do we get those?
We evaluate the function for cubic Bézier curves for that:
C(t) = (1–t)³*P0 + 3*(1–t)²*t*P1 + 3*(1–t)*t²*P2 + t³*P3

This function uses our four control points to return a point on the curve depending on the parameter t.
t goes from 0 to 1 with C(0) = P0 and C(1) = P3 and everything inbetween being the points on the curve between them:


Awesome, now we have a method for defining the shape of the track and are able to position our train on it!

Tangents

For calculating the acceleration force acting on the coaster train we'll need the tangent of the curve at any given point. We get the tangent by calculating the first derivative which is fortunately very easy for Bézier curves:
T(t) = 3*(1–t)²*(P1-P0) + 6*(1–t)*t*(P2-P1) + 3*t²*(P3-P2)

Divide by the length of the vector to normalize.


Orientation
We need one more thing, and that's the up vector defining in which direction the passengers heads are pointing. This one's actually kinda tricky - we know that it has to be perpendicular to the tangent, but that's still an infinite amount of possibilities...

So far I simply took the cross product between the tangent and world up vector to get a horizontal binormal...

...and then computed the cross product between that and the tangent to get an up vector.

This worked fine so far, but fails of course if the track goes vertical (since the tangent points into the same direction as the world up vector then and we can't get a perpendicular binormal anymore). I tried a couple of approaches so far but am not entirely satisfied with any of them (any suggestions? ).


That's it for now Let me know if this kind of post is interesting for you (more details? less details?) and I'll try to write some more.

[Ouren]

[heavy breathing]