Devlog Update 196

Art Stream

Come join us on Garrets Twitch channel on Wednesday (May 30th) at 1pm PDT to chat while watching some new Parkitect art being created.

Devlog

The multithreading stuff seems to be fairly stable right now! We will still be running a bunch of tests this week, but it looks like it will be possible to release it with Beta 7 already.
Having more guests messes with the financial balance of the game quite a bit, so we started adjusting that. As usual it will take many tiny tweaks over a longer period of time to get that feeling right again, so don’t expect that to be perfect just yet with the next update.

A more reasonable amount of guests for this test park

The audio team delivered a few hundred new sound effects, so all the props and rides that were added in the past half year or so got their sounds now!
Gordon also finished a new calm ride music track which will be very nice for the most low-intensity rides.

Comments
Parkitect

Devlog Update 195

Garret made the existing concrete and wooden walls recolorable, which makes them a whole lot more useful:

I continued working on moving the AI code to a separate thread this week. It still needs a ton of testing, but overall work is going a bit faster than expected. The guest AI is ~95% done, pathfinding is running on its own thread as well now, and I’ve started working on moving the staff AI (which should not be too problematic overall since I can reuse most of the work done for guests).

There have been some requests for properly documented and more detailed benchmarks last time, so here’s one. These are the systems I tested on:

Low-end system:
Mac Mini 2014, Intel i5 @ 2.6GHz, integrated Intel Iris graphics
A system that’s pretty close to our minimum requirements. The main bottleneck is the lack of a proper graphics card - this system can’t even render an empty screen at 20 FPS at full resolution. Since we’re interested in the games CPU performance instead of the integrated graphics performance (and I got no other system to test with) I’ve lowered the resolution to the point where it can render an empty screen at ~55 FPS.

High-end system:
Windows 10 PC, Intel i7-6700K @ 4GHz, NVIDIA GeForce GTX 1060
A fairly recent and decent system.

I don’t have a mid-range system available for testing but it should be save to assume that performance would accordingly fall between the results from these.

All tests were run with the exact same scene and camera position in the Eastern Highlands demo park with 3.000 guests. This is a rather detailed park and that guest count is higher than it will be in the end for this park (we haven’t done a proper balancing pass yet to account for the improved performance, but something around 2.000 - 2.500 guests is probably more reasonable).

There have been some requests for “removing the guest cap” last week so I want to point out again that the game has no guest cap. If you build a park with better/more rides then there will be more guests.

The “Old” results are with the currently released Beta 6 version and the “New” results are with the upcoming multithreading version.

A fairly modest improvement of 10-15% for this specific scene. Not amazing, but nice. Worth pointing out though is that in the old version there can be some spikes occasionally where single frames take a bit longer to calculate, whereas in the new version it’s all very stable.

Improving guest performance is not only interesting for being able to have more guests in general, but also because the game allows speeding up time. Running the game at x3 speed means running the guest AI 3 times as often, so running a park with 3.000 guests at x3 speed is roughly comparable to running a park with 9.000 guests at x1 speed. This is where the performance improvements become more apparent.
Here’s the same test as above, but running at x3 speed.

The old version takes a pretty significant hit, whereas in the new version it barely has any performance impact at all.

Comments
Parkitect

Devlog Update 194

One of my favorite things in simulation games is seeing your creation come alive and just sitting back, watching all the bustling activity.
In Parkitect it’s mostly all the guests running around who are responsible for creating this effect, and it’s not quite yet where we want it to be. “The more the better” has been a sort of unofficial motto throughout development for us, whether it be object counts, park sizes or the amount of rides - the more we can add the better it’ll be for this game.

Guest counts are still lower than we’d like though and right now is the last good time to properly solve this, since increasing the amount of guests also affects the money balance and the entire campaign.
Improving guest performance has been a constant task nearly every month throughout development and it’s at a point now where the only significant further improvements can be gained from multithreading. The main hurdle there is that Unity, the game engine we’re using, is making multithreading really difficult. They are currently making very impressive progress to improve that for the future, but it’s too late for Parkitect to use the solutions they are working on. So I have finally started with finding my own solutions for these difficulties. It’s a very annoying task that requires going through the entire guest AI code and making it compatible, but so far it looks like it’ll be worth it!

As a first smaller improvement, overall performance in Beta 7 will be up to 15% better in busy parks.

The really big improvement will not be in Beta 7 just yet, but I hope I can release an experimental version for anyone interested in testing sometime during June. In the first tests it looks like we should be able to have quite a few more guests while at the same time having better performance overall. Here’s a small teaser:

That’s 8000 guests in a pretty detailed and big park (Northern Highlands), with roughly 1500 guests on screen, running at 65 FPS!

This is just a stress test of course and we won’t increase the guest count anywhere near this dramatically, because 1) it turns out “the more the better” has a limit where it stops being fun and 2) the game needs to run on weaker systems as well. Comforting to know though that guest performance should never be an issue again after all of this! You should also actually start seeing guests complain about long queue lines…

Comments
Parkitect

Devlog Update 193

We’re back to working on the campaign again, so you know what that means - not too much to show right now :)
We made some good progress on figuring out and implementing how scenarios are going to be unlocked this week.

Since this would be a very short devlog update otherwise, let’s talk some more about the campaign, and first of all who’s working on it.
We’re extremely lucky to have two very talented builders from the community working on scenarios for the campaign: Silvarret and Joshua Tjarks. You have probably seen some of their work already, and so you’ll know that they are great park designers and very passionate about theme park games :)
Our main goal for the campaign is to make every scenario feel different in some way - especially of course by giving scenarios unique settings, but also by varying the starting conditions and goals and having a nice difficulty progression.
These two have been busy for 6-8 months now and they came up with so many ideas that in the end the campaign grew a bit bigger than we originally expected…

As a sneak peak to give you an idea what to expect, here’s a quick look at one of the scenarios - Coaster Canyon by Silvarret:

As a slightly easier scenario this park has lots of flat space for building huge coasters, and there’s also some space at the top of the canyon as an interesting option!

Building on a blank canvas can be difficult, so most maps come with some small pre-built structures to set the mood and hopefully provide you with inspiration for your own additions! We can’t wait to see what you’ll come up with :)

Comments
Parkitect