Hey everyone,

over the last 1-2 months we’ve been preparing a Kickstarter for Parkitect that went live right now!
Give it a look, there’s a trailer video showing our current progress, a bunch of screenshots and GIFs and info on what we’re planning to do. Also some weird mysterious thing called “interactive trailer”, apparently.

If all goes well this’ll allow us to continue working on the game full time, so it would be awesome if you considered backing us and/or sharing the project with your friends!

I did some experimentation on scenery visibility this week. Scenery can improve the ratings of rides and your guests will give a scenery rating of the park. Now ideally scenery shouldn’t simply have a “sphere of influence” where everything within a certain radius of the scenery object is affected by it - for example, what if there’s something between the guest and the scenery object that is blocking the view, such as a hill or a building? In that case the scenery should have no effect.

However, doing this visibility check requires some computation time so we can’t do it every single time a guest gets close to any scenery object. A better approach would be to precalculate once from where the scenery object is visible so that we can later do quick lookups using that information to find out which objects are visible from any given place. Here’s a debug view showing the result of that precalculation:

In the center of the image is the scenery object (it’s a burger stall for testing purposes here). The white lines show from where the object is visible. Notice how there are no white lines in the bottom right corner of the image because the terrain is blocking the view, so this scenery object wouldn’t count towards the rating of any rides placed there and wouldn’t be noticed by guests walking past on that side.

The experiment showed that doing this precalculation still takes a bit too long when loading big parks but I think with some optimization it could work. It would certainly be nice to have this kind of visibility check and would allow some interesting gameplay possibilities.

On to more concrete developments!

I’ve added pricetags to things:

They don’t look nice yet but we’ll get to that when we start working on the proper UI.

Our coaster cars were sometimes not properly aligned with the track, especially in tight curves. You can kinda see it here:

And a bit better when looking at it from below:

It was barely noticeable ingame and required some bigger changes but this week it bothered me enough to finally fix it. As the fix also required some changes to the actual coaster car model I made some debug “art” for testing purposes so I could experiment with it instead of having to bother Garret every time I needed a change:

I made the cars too big but as you can see they are now properly aligned with the track and all that’s left to do is to update the real art:

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):