May 17, 2019

Parkitect - a management game

0 comments
I'm currently working on a management game so I thought it was a good idea to play-test some other management games and try to figure out what I would have done differently. First out in the play-test series is Parkitect which is a game where you manage your own theme park.

Perhaps the most common management games throughout the ages are city builders like SimCity and theme park games. Parkitect is one of the latest in the series and was released in 2018 after some years of development and a successful Kickstarter campaign. The players have rated it mostly positively on Steam.

Parkitect is made with Unity game engine, which is the same game engine I'm using. It's running on a grid, like in the old days, so the entire map is divided into square cells, so you can't build curvy roads like you can in the game Planet Coaster, which is another recently released theme park management game. But using a grid is not necessarily a bad idea because the game still looks good because they are not aiming for a realistic art style - more of a retro art style. The retro art style is also making the game run faster on my laptop, which is not the worst laptop but still far from the best. I saw a video of someone playing Planet Coaster, which has a more detailed art style, and that person had to stop playing the game because the computer couldn't handle all details even though the map wasn't fully built. You can fill the entire map in Parkitect and the game is still running fine.

Parkitect has a campaign where you play scenarios provided by the game developers. For example, your job is to build a theme park on a deserted airfield and you win if you get 500 customers or whatever the goal is. Each scenario has different goals, but it still feels like the goals are the same after you have figured out what to build to attract new customers. You are basically doing the same on each map: you are trying to make the park-guests happy. They want different type of attractions, they want food, they need toilets, they want the park to be free from garbage, and they want the park to look nice. After a while you have learned what you need to build to make them happy and then you build the same thing over and over again. So you shouldn't play it to get a challenge - you should play it because the game is relaxing.

So why isn't the game challenging? The game has a weather system - sometimes it will rain for maybe a day - and the temperature changes. But I haven't noticed that the temperature affects the customers because they happily ride in the fastest, highest roller coaster even though the temperature is around freezing temperature. Some indoor attractions are more popular when it's raining, but because it's raining for just a day you are never noticing the difference. Neither is the water turning into ice (I tried by dropping a guest into the water so yes you can kill guests) and it's raining even though it should snow. So I think they should have utilized the weather system to make the scenarios more different from each other. If you have a weather system, make sure it affects the game. In this image, the temperature is below freezing, but the game looks and acts exactly the same as when the temperature is 20+ degrees:


To make the guests happy, you need to make sure they can buy food. This is something I was really surprised they added to the game: they have "haulers" that will carry boxes of food to the small restaurants when they are out of food. Most other games assume that the small restaurants have some endless amount of food supply. The problem is that your guest hates to see these haulers so you have to build special access roads to the restaurants so they can deliver boxes without any guest seeing it. You also have to hide these access roads because the guests don't want to see them. So what Parkitect does is that they will provide you with a decoration map so you can see where the guests don't like the looks of your park:


I read through the Parkitect development blog and they are using ray-casting to determine if the decoration is low or not. In the image above, they fire a ray (which is similar to a laser) from the stairs and some rays hit the pink delivery box system, which is considered ugly in the game. So when I added fences around the pink building, the red disappeared. Anyway, the pink building is connected to the main warehouse through an underground pipeline system, which looks like this:


The problem with this pipeline system is that it's annoying to build because it's running in 3d and the heights have to be the same for it to connect. It's often difficult to judge at what height the pipeline system is, so you will sometimes need many attempts to make them connect. What I would have done differently is to have the pipes at just one height, like Cities: Skylines sewer system. Sometimes you have to build pipes above areas you don't control, but it could have easily been solved by allowing pipes below the area you don't control.   

To make your guests happy, you have to make the attractions you build look good, so Parkitect has given each attraction a decoration parameter that can be low, medium, etc. So after you build a roller-coaster you have to use one of the several building blocks to make it look better. This is sometimes confusing. For example, this roller-coaster has low decoration even though I've added rocks, flowers, special fences, and space-style buildings:


The decoration suddenly turned to medium after adding this building in the middle:


This ride also had medium decoration:


So what's the difference? I suspect they are again using ray-casting to determine level of decoration and because the roller-coaster is larger it needs decoration not just at the entrance. But the problem is that it's kinda confusing for the player, so they should maybe have added some color map to show where on the attraction the decoration is low.

To make you guests happy, you have to build different types of attraction. I've notices that they complain if you don't have an attraction with high intensity, and if you build one you will get more customers. One odd behavior I've notices is that some attractions are not popular at all. For example, this ride is free but the queue is almost empty:


So an improvement could have been to tell why no-one wants to ride the attraction. In the image above, it has nothing to do with the type of attraction because it was really popular in another scenario. But now almost no-one wants to touch it even though it's free. And sometimes you see that your new expensive roller coaster is empty while the queue to the Ferris wheel is full.

The game gives you a list of what your guests like and don't like while visiting the park. Sometimes they complain they are broke, which can be confusing because you can add cash machines, so you are not really sure why they are complaining.

To summarize: Parkitect is a relaxing game that's running fine even if you have an older computer. It has some game mechanics you can't find in other theme park management games. Some game mechanics are confusing and should have been easier to understand, and the game could have been more challenging to attract players who want more of a challenge after learning the basics.

Everything you need to know about management games

0 comments
This is an article roundup of all articles related to management games on this blog:

May 2, 2019

Fancy Flying - or how to make a game in 48 hours

0 comments
The Ludum Dare competition was on this weekend and it's a competition where you make a game in either 48 or 72 hours. I've previously participated in the competition eleven times, but I skipped it the last three times, but this weekend I decided to be a part of it again.

The problem with this competition is that it's not entirely fair because of the voting system. Hundreds of games a submitted each time so how can you judge which game was the best? A single team of judges can't play them all, so the participants in the competition will each judge at least twenty games and then the average score will give you the final result. Sometimes you are lucky that the twenty out of hundreds of participants like your type of game, so you will get a good score. There's also a problem with people who vote on your game without even playing the game (to encourage voting your game is displayed higher in a list of all games), which was reported by someone who thought it was odd that he/she got twenty votes but only five people had downloaded the game. So you should participate because it's fun and you want to test an idea - not to win. 

A few days before the competition I was researching an aircraft game I'm working on and read an article about bird strikes. As seen in the the movie Sully: Miracle on the Hudson, which is based on a real even where an aircraft crashed in a river around New York because birds hit the engine, birds are dangerous. So I decided to make an infinite aircraft game where you get points for flying low (to avoid enemy radar) while avoiding dangerous objects like birds, mountains, houses, and radar poles. This was the result:


The entire world consists of a few chunks: mountains, forest, lake, city, which are spawned every 50 meters with some probability, and the chunks are recycled by using a pooling system, which makes it faster. I originally planed to make my own collision system because the game is not physics based, but then I realized that I could use Unity's own collision system even though the game is not physics based, meaning that I use transform.Translate() to move the aircraft and not rigidBody.AddForce(). But if you add a rigidbody to the aircraft and set it to kinematic and then the colliders connected to the mountains should be set to trigger, you can still check for collisions by using OnTriggerEnter in the script attached to the gameobject which also has the rigidbody. The problem is that if you collide with an object, the rigidbody will just continue through it, so you have to make your own collision response system. 

In the first Ludum Dare games I made I didn't include any sound, because you have to make the sound during the 48 hours so it's easy not to prioritize sound if you run out of time. I've gradually added sound to my games with various results, so this time I really tried to add sounds that didn't scare people (or forcing them to turn off the sound because sound was "sooo bad"), and so far no-one has really complained that the sounds are bad. The jet engine sound is from a YouTube clip and I had to make it seamless, which took a lot of time but I learned a lot in the process, which was the point of participating in the competition.

If you want to test the game you can download it here: Fancy Flying

April 18, 2019

Fake fluid simulations in Unity - or how to make the water system from Sprinkle game

0 comments
To research water simulation models I read a PhD thesis called Large-Scale Water Simulation in Games. The author has been working with the water system in Cities: Skylines, so if you want to learn more about how that was done you should read the thesis. But in the beginning of the thesis, the author was discussing different water systems in games. One of the games mentioned was Sprinkle, which is a mobile game where you have a fire truck and your job is to extinguish fires. It looks like this:


I played the game several years ago before I was interested in water systems, but when I saw it now I asked myself "How did they made that water system?" And above all, how could they simulate a water system on a mobile device? To simulate realistic water systems, you have to simulate the Navier-Stokes equations which is taking up a lot of computer power, so you are never doing it in games - and especially not in a mobile game from 2011.

One of the developers has written a blog post on how they made the water system: Sprinkle behind the scenes, and there's also a GDC talk pdf: Constraint fluids in Sprinkle. So what Sprinkle is doing is that they simulate water by using 600 particles and each particle disappears after 3.5 seconds to not make the simulation go slower. To display the particles on the screen they are using a "dynamic particle mesh" which I have no idea what it is, but in the GDC talk they say it's "point splatting with a few tricks." To simulate the particles they are using the built-in physics system together with a simplified Navier-Stokes simulation system. So it looks like this behind the scenes (this is before they add the dynamic particle mesh, so you can clearly see the particles):


To recreate the basic idea I found an article which is implementing something similar in Unity: Liquid Physics. The author is using just Unity's built-in collision system to simulate water, lava, and air. To create the solid surface from the particles, each particle consists of a circle with a gradient circle attached to it. The gradient gets a color (red, green, or blue), and then a render texture is used to capture the different colors:


...and then you use some shader tricks to generate a more solid surface that looks like the element being simulated. To change the type of particle to for example water, you experiment with the rigidbody settings to make something that feels like water. And in the end my version looks like this:

March 21, 2019

Self-driving car 2019 update

0 comments
About four years ago I made a self-driving car in Unity, which is an implementation of the Hybrid A star algorithm. I update it about once a year, except for last year when I didn't update it, so I decided to give it an extra large update this year. The following improvements have been added:

1. Reeds-Shepp paths. The old version used modified Dubins paths to make something that resembles Reeds-Shepp paths, but now I decide to add the real Reeds-Shepp paths. These were really annoying to make, so I've decided to give away the code for free: Download Reeds-Shepp paths for Unity in C#.


2. Voronoi field. A voronoi field tells, from each cell in the grid, the shortest distance to a voronoi edge (which can be seen as the midpoint between two obstacles) and the closest obstacle. This is useful knowledge to help the car find a path through narrow passages between obstacles and it also speeds up the algorithm when you smooth the path and want to find the distance to closest obstacle.



3. GUI. The old version used different keys to display different textures and paths. But now I've added a real GUI to make it easier to change between the different options by just clicking with the mouse.


4. A semi and a semi with trailer. I've also made a Tesla Simulator, and in the last Tesla Simulator update I added the Tesla Semi truck and a trailer. So I thought it would be interesting to see if I could update the pathfinding for cars algorithm, with pathfinding for cars that also drag something behind them. It was easy to add a model to the algorithm that simulates a trailer, but the problem is to make the real trailer follow the path. So sometimes the drag vehicle is colliding with the trailer even though the algorithm is checking for that, so I will in the future try to find a solution for that.


5. Optimized code. I've learned one or two things since the last update, so I've optimized and cleaned the code.

6. Path following. In the old version of the implementation, the car used to follow the path generated by the Hybrid A* algorithm, which uses the rear wheels to generate the path. But to make the car follow the path with greater accuracy, this path has to be moved forward to the front axle. When the car is reversing this path has to be moved to a "mirrored front axle" to make it easier for the car to follow the path when reversing.


You can test it here: Self-driving car.