Update 4

This week started with a bit more AI, in particular decision making for guests. There’s a ton of decisions they have to make (“Do I want to go on this ride?”, “How much am I willing to pay for this burger?”, “Where should I go next?”, …) so this is somewhat of an ongoing task for the entire duration of development.

AI is quite interesting to do and important to have, but it’s all under the hood - I felt the urge to also work on something that’s a bit easier to show for a change. So I made guests raise their arms on flat rides if they’re enjoying it:

Next, Garret requested a terrain leveling tool. The main challenge turned out to be finding a proper visual representation for it. We started with a simple plane that’d show how high the terrain would be after terraforming:

This turned out to be super confusing though - although you can somewhat forsee the result of the leveling it’s hard to tell which tiles are actually affected, especially when leveling somewhat higher hills.

So we tried highlighting the affected tiles instead:

This felt much better! It doesn’t tell you the final height, but you can easily see the affected tiles. The terrain gets flattened to the height at the location where you start dragging, and since you know where you clicked this is alright. The rendering of the highlighted area was quite buggy though as you can tell from the gif (notice the flickering and how the edges of the highlighted area get stretched). After using a different method for the highlights we ended up with our final version:

Lastly I started writing some calendar code for tracking the current season and how long you’ve been playing the park. We thought it’d be neat if the lighting changes depending on the time of the year - it’s just an experiment so far and will need more work, but this should give you an idea (sped up for demonstration):

Update 3

I continued working on staff AI, mainly making sure to handle situations where tasks can’t be completed.

For example, imagine there’s an employee, tasked with transporting a delivery crate containing resources from storage to a shop.
Let’s see what could possibly go wrong!

  • the employee is at the other end of the park. The task should ideally be assigned to someone who is close instead. But it can’t just be assigned to “the closest employee”, because what if they are all far away? There’s probably something else they can work on closer to where they are, it’s not very efficient to call one of them all the way over. This should only be done if no available employee has been found in close range for some time (the range can gradually expand over time).
  • the employee might not be able to reach the storage because there’s no path. Calculating paths requires relatively much time and the employee most likely won’t be able to reach the storage within the next few seconds or so either, so instead of trying to reassign the task to the same employee over and over again it should be given to another one instead without retrying (for a while).
  • eventually, some employee managed to pick up the crate and is on his way to the shop. But what if the player is doing some rebuilding and removed some paths, so the employee now can’t reach his goal anymore? He should bring the crate back to the storage. The task most likely can’t be completed for some time, so it should receive some cooldown time before trying to complete it again (performance!).
  • but what if now he can’t reach the storage anymore either? Maybe there’s another stroage he can reach and take it there? But if there’s no reachable stroage? There’s really nothing he can do, so he should probably just drop the crate, carry on with some other task and have someone else pick it up later. Here’s where the Behaviour Trees from last weeks post come in handy, as they allow to quite easily define a range of different strategies.
  • what if the shop doesn’t exist anymore? The task for delivering the resources has to be cancelled and they wait in storage until they are needed elsewhere.

So that’s mostly what I did this week - ensuring we have systems in place to handle cases like these.

Update 2

I continued to mainly work on behind-the-scenes stuff.

I made sure path supports work properly on sloped terrain; the fundaments wouldn’t appear before:

Next I made sure that when drag-building paths already occupied spots are highlighted red and aren’t build (and you don’t pay for them again):

Garret made some new cursors for the terraform tool, and I extended the tool by the ability to raise multiple tiles at once or just individual corners. It still needs more work and requires additional features, for example the ability to flatten a whole area of land to the same height, but for now this is pretty usable.

I made trees subtly sway in the wind (so subtle it’s barely visible in the gif except for the cut):

Then I started implementing shopkeepers, but so far they don’t do more than walk to their shop.

The rest of the week was spent on researching and implementing Behaviour Trees - I don’t want to get too technical here (see the link for a pretty nice explanation), so the short summary is that this is a method for structuring AI code into many smaller reusable parts that can then be plugged together to tell an agent what to do. For example, the code that tells the shopkeeper to walk to his shop looks like this:

new Sequence( // do the following actions one after another
	new FindPathAction(), // find a path to the destination
	new FollowPathAction(), // walk to the destination
	new RotateToQuaternionAction() // turn around to look outside window

I can’t imagine more comfortable code than this, and so far it looks like it’ll be a great tool for creating our AI behaviours :)

Update 1

Hi! Someone asked for updates on what we’re working on, so I’ll try to ideally post one each weekend.

This week I mainly worked on behind-the-scenes stuff - cleaning up and improving code, improving some internal tools. I’ve added a small tool that gives us an overview of the rides in the game and their stats so we don’t have to keep an external spreadsheet updated with that. It’ll surely be handy for balancing ride stats.

I’ve also updated our tool for wrapping bounding boxes around objects. It looks like this:

These boxes define how much space an object needs around it in the game.

The curves of our coaster tracks weren’t perfectly circular so far, which I fixed:

They smoothly connect with each other now. The cross beams are still spaced a bit unevenly though.

I then took care of building previews and animations. Here’s some older ones first that haven’t been posted here before:

Building paths:

Building shops:

Since then I’ve added building benches and other stuff that goes on the path:

You can build these either individually on a side of the path or automatically on all free sides.

I finished the week with previews and animations for planting trees:

- Sebastian