next »

[King Tetiro]

That is a good question. Will there be mod capabilities for the game?

EDIT: Also, you made it on Kotaku

http://www.kotaku.co.uk/2014/08/27/return-theme-park-simulator

[Sebioff]

That would certainly be awesome - scenery at least shouldn't be a huge problem I think, but more advanced stuff like rides or shops I don't know yet. They sometimes need custom code, so there would have to be some sort of API? Hmm. Got no experience with modding, so no idea yet how that would work...LUA maybe?

I'm currently not getting much development done, sadly, but I had some time to play around with Ambient Occlusion (AO), an effect to darken corners of things that can help to make things look more real/interesting:

Left: no AO, right: AO baked into vertex colors

Screen-space AO (SSAO)

Vertex-color AO would be really nice - no need to unwrap the model (faster art production), no extra textures (faster rendering), so we can basically have this for free. Obviously it does have some problems though: notice how that front pillar is way to dark? That's because there's not enough polygons on it - the vertices at the top are slightly occluded, and this darker color is then interpolated all the way down to the bottom. We'd have to change the geometry or add a couple more polygons to it just to fix this :/
On the other hand, the gradients make it look somewhat more interesting - maybe we can use vertex colors for manually putting gradients on some things.

SSAO doesn't really add much and has its own problems as well. Better than nothing I guess?

[kruxus]

If you are going for a cartoon style I would opt for no AO I think. Vertex-colouring can be good though, let the artist hand-paint some AO where needed (for example where the pillar meets the ground).

SSAO is never really perfect, it works in some games, but here you have a lot of tiny details which will probably just turn the AO into a flickering noise.

[Instant Mix]

Some AO would definitely be nice, as it certainly gives some idea of depth. I think textures, albeit basic ones are needed - similar to the artstyle of "No Man's Sky". Basic, bland textures with only one or two colours, but with some subtle detailing within.

I'm assuming if you are looking for "realistic rides", you'll be changing the spines and making cars that are similar to current ride manufacturers?

[JobLeonard]

Realism isn't even the point of using AO here, IMO.

I think that the example on the right has too heavy AO in general, but a little bit of AO will help a lot with readability, especially if you stick to the "low-poly, simple texture"-esque look you have now (which I find quite charming). It will also make the imagery look a bit "softer" as a whole, compared to a harsh, flat look, which feels like it fits the overall family-friendly mood the game is going for.

[Sebioff]

Yes, the AO is not supposed to make it look more real, but to improve readability and make it look slightly more interesting (a bit of variation in the coloring vs. everything being the exact same shade).
"No Man's Sky" is a good example for this mostly textureless style.

[King Tetiro]

Yes, the AO is not supposed to make it look more real, but to improve readability and make it look slightly more interesting (a bit of variation in the coloring vs. everything being the exact same shade).
"No Man's Sky" is a good example for this mostly textureless style.

Actually No Man's Sky does use textures. I think what you mean is a minimalist size

Oh by the way, you have almost reached 50% in your first week!

[brokeit]

Long post incoming, regarding scenarios and campaigns.

Now this might take up a lot of development time, but I just thought of a sort of campaign mode that could be pretty cool.

There's a map of the game world, and throughout the game world there are already numerous parks, some big Disneyland type parks and some smaller, local parks. You play as an investor and have to buy land where available and build your park there. You will have to compete with the other parks around you to determine how much guests you will get. If you want to build a huge Disneyland type park, you better not build it too close to the park that already exists, unless you're willing to take a risk, because you might struggle to get guests to your new park. You can also visit (but not take any action) any of the other parks to see how they're doing. Maybe they have lots of cool rides but the park overall is dirty and barely has theming; then these are flaws in those parks and you can spend extra attention on it in your own park so guests will prefer yours more over theirs.
If you become wealthy enough, you can even buy out competing theme parks (for a hefty price).

All this information could be shown from the main menu which works as a map of the game world where you can see all the parks, and hoover over them to get a bit more detail on how they're doing. Each park also has lines of influence so you can see how far out in the game world they attract most of their guests.

This campaign would provide very interesting financial management options too. You could have an overall finances panel, and from there, appoint funds to your parks that need it most, decide their budgets etc. One park isn't doing too good? Decrease the budget of another park, to inject that park with some much needed fresh resources and give it a good boost. Maybe now the employees from the park whose budget you just decreased will now be a bit more unhappy so there are consequences to doing this.

I guess there should be an overall goal for this kind of campaign, like succeeding in becoming a succesful group of theme parks. ("Have at least 5 theme parks running with a quality level of ..%")
This could be tied with achievements really well, you could achieve the overall goal mentioned above, but there could be achievements to get even better quality levels etc. Or how about "Buy out every competing theme park in a set radius around your first park" or "Buy out every park in the game world". Possibilities are endless with this. One thing people like in games, it's going for that 100% completion level, so this gives every park infinte replayability, as you'll never be truly finished .

As I said at the beginning of this post, it might take up way too much development time, but it would make this game unique in the theme park genre and really make it stand out on its own. Rather than just completing park after park, there's always the bigger picture to keep in your mind, and it gives you a reason to revisit previous parks you've worked on to improve them. There's not really a reason for this in the current games of this genre; you complete a park and you move on.

Sorry for the length of this post

[deanr201]

Just two quick question Sebioff; sorry if it has been asked previously

I noticed the the GUI and from various screen shots you have the option to add a "loop" to you coasters.

Will this be expanded to allow for more types of inversions such as, half loops, corkscrews / half corkscrews, inline and heatline rolls etc.

Or is this something we can do by adjusting the elevation and backing of the track?

Will their be a range of scenery added to the game so that we can make our own coaster stations, buildings and generally build a proper theme park.


Having user content could be could be great, provided it matches the same art style as the game. looking at some other games which allow user content they often have very varying art style which makes the game look very broken.

[Lejving]

If you guys could do a big roller coaster update, showing us the inner workings of the wooden coaster and the steel one what they can/can't do, that'd make me happy in my pants.

[Sebioff]

@brokeit: Cool We have some similar thoughts, but yeah, as you said that'll require a lot of development time and we'll not get to that until we're much further ahead, so we'll see if that's possible.

Will this be expanded to allow for more types of inversions such as, half loops, corkscrews / half corkscrews, inline and heatline rolls etc.

Yes, we want to have all standard coaster elements - just not sure about heartline rolls yet, they might not be possible to fit into the grid system.

Or is this something we can do by adjusting the elevation and backing of the track?

Some can be done like that (-> inline rolls), but many will require special track pieces (-> loops).

Will their be a range of scenery added to the game so that we can make our own coaster stations, buildings and generally build a proper theme park.

That's the plan, but we haven't done any work on that yet.

Having user content could be could be great, provided it matches the same art style as the game. looking at some other games which allow user content they often have very varying art style which makes the game look very broken.

Well, that'd be in the responsibility of content makers

If you guys could do a big roller coaster update, showing us the inner workings of the wooden coaster and the steel one what they can/can't do, that'd make me happy in my pants.

Well, we're posting pretty much everything as soon as we got it working, so they can do what we've shown so far: straights, 45°/90° curves and 45° hills with adjustable length and banking, stations, lifts, loops. As written above there's more to come.
The only difference between wooden and steel right now is that wooden can't do inversions.

[Whyman]

I must say game looks much better with baked AO. Its the way to go I think!

[King Tetiro]

How is the progress on Parkitect? Its campaign is going strong. You might want to do an update soon

[Sebioff]

Regarding development progress, last weeks update is on our official devlog. Regarding KS progress there's a new update up on KS.

[Sebioff]

I'm currently working on intersection checks for coaster tracks, that is, finding out whether a piece of track can be placed somewhere - or not because it intersects with something (other piece of track, ride, scenery, ...).
The way I approached this is by creating a "virtual corridor" along the track (a triangle mesh, essentially) against which I can then perform intersection checks.
Here's a debug view to give you an idea (virtual corridor marked by the light green lines):

The neat thing about this is that it is really accurate - the corridors size can be dependent on the width and height of the coaster cars running on the track, so there shouldn't be any cases where you can't built a segment although it would fit, or where you can build segments and then get cars clipping through scenery.

The downside is that intersection checks against triangles aren't exactly fast and this gets noticable with longer track segments (which have a lot of triangles in their corridor mesh). However, I think I can drastically reduce the resolution of the corridor mesh without losing much precision and chop it into multiple shorter pieces for long track segments, so it should be fine.

Let me know how you would solve this, it's an interesting problem

[Quarry]

I believe that in addition to reducing the collision mesh resolution, you can also perform the checks only when you are placing a single piece (if that's not what you are already doing)

[JobLeonard]

IIRC, there are actually compsci papers dedicated to efficient hit detection of chains. Myabe worth looking them up?

[Sebioff]

I believe that in addition to reducing the collision mesh resolution, you can also perform the checks only when you are placing a single piece (if that's not what you are already doing)

Yeah - also the usual optimizations, checking against a bounding volume first, spatial partitioning...

IIRC, there are actually compsci papers dedicated to efficient hit detection of chains. Myabe worth looking them up?

Thanks, took a quick look - the ones I saw used cylindrical colliders. Using some more simple shapes for approximation is of course an option if everything else fails.

[JobLeonard]

I'm surprised the spatial partitioning doesn't already solve the scaling issue. What type of partitioning strategy do you use? Fixed grid? Octree? I assume the issue is that there's too many track segments in one bin to compare against?

I actually had to tackle a pixel-perfect chain intersection problem for a 2D situation once. I had not yet heard of spatial partitioning solutions at the time, and came up with some kind of "subjective binary tree" solution of my own:





Because colour flowed through the line and inverted at line intersextions, I had to find tese pixel perfect intersections of a line. My solution was to create a binary tree of ever smaller segments - the root was the whole line, its first leaf the first half of the line, its second leaf the second. Then, the two leaves on the first half would divide in two again. And so forth. I repeated this until I reached a certain segment size (I guestimated 100 pixels). Every node would contain the bounding box of that particular segment.

So if I drew a line and wanted to check for every placed pixel if it intersected with another, and which one, I would walk this tree of bounding boxes until I reached the point where it was certain there was no intersection anymore. If I reached minimum segment size I would simply check agains every pixel of that segment, because linear comparison is faster at that point. For two lines, I would compare to the tree of the other line.

I'm calling it "subjective binary tree" because unlike, say, a quadtree or a fixed grid where the binning depends on the global coordinates, this binary tree was dependent on the lines, and not even on coordinates but on pixel number in the line.

It actually scaled quite well for very long lines, but in retrospect I suspect that spatial partitioning of line segments, and simply comparing to all segments in the same bin probably would have been easier and faster

[Sebioff]

Not using spatial partitioning yet (will be Octree though I think). Was just testing collisions against a single segment (not even a very long one), so I was pretty surprised how slow this is as well.
I just took a peek with the Profiler - turns out the problem is the Garbage Collector because I somehow manage to allocate 24MB of memory for each check
Probably it's something silly like calling a Unity member that's actually a memory-allocating get method. Will be fun to debug tomorrow