Art Stream

It’s time for an art stream again! Garret will be streaming the creation of some new art on his Twitch channel on Wednesday from 12pm to 2pm. He plans to start working on a Carousel!

Devlog

It’s been a busy week! We’ve added some new food stalls:

This is Bubble Tea, Chinese Food, Mini Donuts, Popcorn and Ice Cream.

And we added a Mini Coaster:

It’s supposed to be used for fairly relaxed rides through some scenery, so its building options are rather limited.

We put the guest names from the $50 Kickstarter tier into the game, so these uniquely named guests come to check out your park every now and then.

I spent the majority of this week on a rather big feature though - tracked ride blueprints! That means you’ll be able to save your tracked ride for placing it in another park or for sharing it with someone. It’ll also allow us to ship the game with some pre-designed rides eventually (which we’ll also need for the $500 Kickstarter tier).

I initially didn’t write the code with the idea in mind that coasters will ever be moved or rotated around so some bigger changes were required, but it’s almost working now:

I tried to finish it for this weeks $40 tier build, but there’s still a couple things left to do and due to the bigger code changes that had to be done we decided to leave it out for now and properly test and finish it later.
The build still got delayed longer than initially planned due to this, but it’s done now and we sent it off to Humble! It’ll probably take another couple days until they uploaded it though. You’ll receive an email once it’s available :)

Gordon bought a Concertina last month.

He’s still learning but already used it for a song!

It’s another one that’s supposed to play in the background while building stuff.

It’s been a rather unremarkable week for the devlog. Garret has been busy trying to keep the craftsmen refurbishing his new place under control. I’ve had to spend a couple days on bookkeeping and taxes. Gordon has been trying to convince a local theme park of letting him do some sound recordings (with uncertain results so far). He also delivered the sound effects for the remaining flat rides that we have in the game right now, and we got them implemented.

We’re approaching another build now, which means the remaining time went into testing and fixing, so there’s not much to say apart from that really. I guess most notable would be that I finally added some checks to prevent you from building rides and shops halfway into the terrain:

It’s been one of the long-standing tasks that I somewhat procrastinated on - in the end it was trivial to implement! You can still build rides/shops underground, but they have to be completely covered now.

I still need to disallow dragging terrain through existing stuff, though….hmm!

Garret did a spontaneous art stream to test his new internet connection! He worked on the beginnings of a mini train. Here’s the current state:

The entire recording is still available for a while over on his Twitch channel if you missed it.

Garret is currently busy with moving to a new place, so I’ve used this week to do some more experimental technical work.

Probably the biggest and most important system that’s still entirely missing is the scenery visibility checking. I had done some initial tests a couple months ago though, and this week was a good opportunity to push it a bit further to figure out what we can do with it.

Here’s a debug screenshot:

Every white line here connects a path tile with the scenery items that are visible from that spot, taking occlusions into account. Of course it’s just a rough approximation, and it has only been done for the rock objects here for testing purposes, but as you can see that’s still a slightly crazy amount of calculations that need to be done.

You can imagine that it’s not a great idea to test every path tile against every single scenery item in the game world - a method for quickly getting only nearby objects relative to a given point is needed. This can be achieved using space partitioning: for example, imagine that the game world is divided into two halves, A and B, and you have done some calculations beforehand to figure out which objects are inside half A and which are inside half B. If you now want to know which objects are within a certain range of some point you first check how far away that point is from your two halves - if one of the halves is further away than the range you’re interested in, you know that all objects inside that half are outside the range as well and you don’t need to do any distance checks against them individually. Nice!

Now, instead of using just two halves a better and slightly more sophisticated approach is to use a hierarchy of ever-smaller cubes that partition space more fine-grained in areas with lots of objects. This structure is called an Octree, and it’s one of the usual solutions for doing space partitioning (see the linked Wikipedia article if you’re interested in learning more about it!).

To my own surprise we so far got away without using one, but we rarely had to do checks against nearby objects so far (e.g., for checking collisions when building something new - this is only done for one single frame, and checking against every single object in the game world was fast enough so far to not cause any overly noticeable lag).
There are so many scenery visibility checks to do though that it was necessary now, and we would have needed it for bigger parks anyways.

Here’s what an octree looks like in action:

And with that the performance of doing the visibility checks is in a feasible range now (and some older code received a performance boost too!). The main problem left is that recalculating everything when loading a park still takes too long, but before working on that we should figure out for which kinds of objects we’ll use these visibility checks anyways (probably not for every single little stone?), and how much they add to the gameplay.