June 2, 2019

Why RimWorld sold more than 1 million copies

RimWorld is a very popular management game where you run a sci-fi colony. On Steam, the game is described as:
A sci-fi colony sim driven by an intelligent AI storyteller. Inspired by Dwarf Fortress and Firefly. Generates stories by simulating psychology, ecology, gunplay, melee combat, climate, biomes, diplomacy, interpersonal relationships, art, medicine, trade, and more.  
The game has been in development since 2013 after a successful Kickstarter campaign, and was finally released in 2018. It has sold more than a million copies. At first glimpse, the game doesn't look like much because it's a 2d game and has no fancy photo-realistic 3d graphics. Why then is it so popular?

RimWorld is an indie-game by Tynan Sylvester. If you play the game you can see he's doing everything he can to market himself: The sub-title at the start menu says "A story generator by Tynan Sylvester," and from the start menu he's linking his Twitter-account and a book he wrote about game development: Designing Games: A Guide to Engineering Experiences. It was published before RimWorld so you will not learn how he designed that particular game, but he used knowledge from the book when designing the game. He has also talked about the game at GDC 2017, which was published on YouTube not long ago: RimWorld: Contrarian, Ridiculous, and Impossible Game Design Methods. If you watch the GDC talk you'll see he had help from multiple people for audio, visuals, and programming, so he didn't make RimWorld on his own.

Lessons learned:
  • It combines manufacturing, survival, and social. According to the Paradox Podcast, RimWorld is a fun game because it combines the games Factorial (manufacturing), Don't Starve (survival), and The Sims (social). In RimWorld you need to manufacture (grow and cook) food to survive, research new technologies to eventually travel home, and you also need to form relationships with neighbors, who for some reason are on the same planet, as well as form social relationships within the group, and build yourself a cozy place to live. 
  • RimWorld is a story generator. Tynan Sylvester explained in the GDC talk how he was inspired by the game Dwarf Fortress - not the graphics, but how Dwarf Fortress can create stories. The player interacts with the game and stories emerge from that interaction. Some players will lose the game, which may be a story because some stories end in failures. This is also why there are no Steam achievements, which would break the story. The thing is that RimWorld hasn't come up with a story generating AI because it's using a concept called apophenia, which is a term that refers to the human tendency to detect patterns in randomness. What's happening is that the game "sends entirely random events the player’s way, and yet it’s easy to ascribe meaning to them," but people don't see it as random events. The characters have no facial expressions so you can't see what they feel, so you have to imagine it based on the situation. In the developer's book he wrote that "Medieval [another game] doesn't really track human courage or familial affection. But the human mind sees stories anyway, given the slightest of suggestions." But making a simple system can also result in trouble as real social relationships are complicated. For example, this article has found that "Men [in RimWorld] are about eight times as likely as women to try and start a romance," so players can become upset at the game if they have other values. So if you implement a simple social system, be careful!
  • All characters in RimWorld feel special to you. In RimWorld you have just a few characters: you start with between one and three, and end up with maybe eight to twelve. Compare this with other games where one character is killed and you don't really care about it. If a character in RimWorld dies, you have the option to build a grave and the other characters will be sad. If a person is wounded, you have to make the decision to treat the wounded or let the character die. If you treat the wounded, the character will use resources like food and medicine while the character is useless because the character can't work, so the other characters have to work harder.  
  • The graphics is not distracting the player. When I first looked at the game I thought it was made by the developers behind another management game: Prison Architect. But it's not. Both games were revealed at the same time so I'm not sure who was inspired by who? Basically the art style is a top-down 2d game and the characters are leg-less blobs (but you can still give them pants). The game is made with Unity (and Photoshop to make the art) and is using the built-in font style that comes with Unity. The UI boxes are just one color with a frame in another color. So it has no fancy realistic 3d-graphics, but the graphics is not ugly so the graphics serves the purpose: you can always see what's going on - even if you have zoomed out. Fancy visuals may sometimes distract the player from the story when many things is happening on the screen. Also making fancy graphics takes a lot of time - and time is also a limit so sometimes it's better to focus on gameplay - there are no animations in RimWorld. Moreover, many people don't have the latest computer so I suspect one reason the game is popular is because you don't need to have the latest computer to play it. Neither does it take a long time to download the game because it's just 500 MB. To make it as simple ass possible for the player to see what's going on, RimWorld is cheating: some objects that should be behind a tree are on the top of the tree:

  • Don't throw away any ideas. While developing RimWorld, Tynan Sylvester was saving all ideas he ever discovered in a document because ideas are easy to forget. If the idea doesn't fit into your current plan, write it down because the plan may change. He then moved these idea to another document which was the more short-term to-do list. 
  • It's easy to learn RimWorld but difficult to master. A saying in the game industry is that a game should be "easy to learn and difficult to master." For example, the game pubg is very easy to learn, but it's really difficult to get a "chicken dinner" (win the game). RimWorld has a short tutorial which covers the basics but nothing more. To learn the rest, the game has smaller hints that you can click through. Making a tutorial is a dangerous balancing act - you can't give the player too much information because then it becomes boring to play because it's fun to figure out some stuff on your own, so the game has a wiki as backup if you are stuck.
  • The game keeps you in the flow channel. The flow channel is an important topic in game development, and it says that to enjoy a game, the tasks have to match the difficulty. If the game is too easy, you will be bored, and if it's too difficult you will not enjoy playing the game - so the game has to keep you in a channel where you will always meet challenges that matches your experience. For example, if you play a shooter: start with good gun which will become boring after a while → add harder enemies which will become boring because it's too difficult → add better gun → add better enemies → and so on. In the beginning of RimWorld, you have to start food production and build a basic shelter. But as the game progresses, and as you learn more, it becomes more and more difficult because some characters will be wounded and can't contribute, so you have to prioritize more and more: should you harvest crops or work on researching new technologies? When you have learned the basics you will realize that you don't have enough resources on the map you start, so you have to form caravans and travel the world to find more resources. So RimWorld becomes more and more difficult to play as you become more and more skilled. Yes, there are dull moments where no disasters (raids, solar storms, battery explosions, etc) are trying to kill you, but you know that you need those pause moments to prepare so you can survive the next disaster. 
  • The weather system is affecting the game. In an earlier article I was complaining about the weather system in the game Parcitect, which didn't affect gameplay in a noticeable way. But the weather system in RimWorld is really out to get you. If there's a lightning storm, forest fires can start and burn down your buildings and you have to hurry out with your colony and extinguish the fire. If it's too hot outside, your food will go bad and you have to build a cooler to freeze the food. Sometimes a sun storm hits you, which temporarily malfunctions the cooler, and you will be really worried that your precious food will turn bad.  
  • Making a game moddable while developing it is difficult. One great way to add more content to your game without spending time nor money is to let other people add it for you by making your game work with mods. The problem is that the code will change rapidly while developing the game, so a better way is to let people add mods when the game has stabilized, or people have to update the mods all the time which is really time consuming. This is what happened with RimWorld: "many creators of bigger mods have given up trying to update their mods every time a new update comes out." 
  • You are directing the characters - you don't control them like drones. It would have been possible to increase the control of the characters. For example, if two characters don't like each other, then separate them. But that would also have been boring and made the interface even more complicated: "The goal of the game isn't for the player to be able to exactly restrict every colonist to do the exact optimal thing. It's to give a certain level of generalized control, and make the player accept some narratively interesting but sub-optimal interactions that might happen within that."
  • Addictive games have responsibilities. RimWorld is an addictive game and to help people not forget about the time in the game, you have the option to enable a clock. I originally thought it would tell the time in the game because RimWorld has a night-day cycle, but it's telling the time in your time so you don't forget an important meeting.
  • Procedural terrain increases replayability if gameplay changes. The basic idea behind the game is to build a spaceship and fly home. This could become repetitive. The goal would have felt repetitive if you had done it over and over again in the same terrain. But RimWorld has procedural terrain and different types of terrain: mountain, forest, jungle, desert, etc, so after finishing the game you ask yourself "Can I also do it in the jungle terrain?" But it's important that the terrain is different and not just procedural. I played the game Bad North which has procedural islands but the game feels the same after a while even though each island is different - but not different enough to change gameplay. In RimWorld, if you first play in a forest area and then play in the desert you need another tactic because you can't find trees easily in the desert. 
  • Gameplay is more important than realism. Why are there no toilets in the game? Would have been a great fertilizer? Why is there no water management? There are smaller lakes with water in the game, but for some reason you can cook food without ever picking up water? It first felt like a missed opportunity before I read a Reddit AMA. Water wasn't added because "colonists have a lot of work to do so the needs have to be a lot more lightweight," meaning that the colonists won't have time to eat food, wash themselves, and do some work because each day in the game is short. Some in the same thread argues they really wanted water management in the game. It's the same with ammunition - each bow has an infinite amount of arrows, so making ammunition would maybe take too much time? In the GDC talk, Tynan Sylvester explained that he simplified everything that wouldn't contribute to the story. It's not realistic to dig metal directly from metal-rocks and then use it directly to build a metal-chair, but adding parts between wouldn't have improved the game. 

What could have been improved:
  • Annoying UI. If you read through the RimWorld reviews on Steam, some complain the UI is not easy to understand. This is true: everything about the game is minimalistic and the UI is grouped in the bottom of the screen. 
    • A better way would maybe be to group the UI with icons on different parts of the screens, like Cities: Skylines or Parkitect. Text is sometimes better to use than icons, but after a while you learn what the icons mean, so it doesn't make a difference in a game. 
    • Some UI elements, such as the UI showing which zone types you have placed in the game is not visible enough - they blend too much with the background.  
    • Why are orders in the architect menu? 
    • Why are build roof in the zone menu and not structure menu?
    • Why can't you see, when selecting which tasks a character should prioritize to do, if the character can increase its skills more than other characters when working with that task. You can only see current skills - not the "passion," so you have to click back and forth between the character's bio UI and work priorities UI.
    • When building for example a chair, you can change the material of the chair from wood to steel or whatever, and it took some time to find this menu because it's just a small triangle in the top-right corner of the chair icon. It should have been included in the tutorial because it's not obvious you can click on the triangle to change material. 
    • When manufacturing, everything is basically text, so sometimes it can be hard to figure out what you are manufacturing. A better idea would have been to use text in combination with an image, so you don't have to tab out and google what it is. For example, what is an "ikwa"? The description is empty (this might be a bug because the ikwa has a description in another place in the game), so you have to tab out, google, and the first result is the RimWorld wiki, which has an image of a spear.  
  • Odd behaviors. Each character has some characteristics, such as being able to treat wounded, or grow plants. One of my characters could for some reason not carry items, such as transporting food from the growing area to the storage area. But on the other hand the character could cook food, so you could see him go to the storage area and pick up food and carry it to the cooking station. So why couldn't the same character carry food to the storage area? I could have accepted that some characters can't do high-tech research, but not being able to carry potatoes from the field to the fridge when it clearly can carry potatoes from the fridge to the cooking station?
  • Difficult to prioritize tasks. A management game is all about prioritizing tasks so it has to be as simple as possible. Currently, you can tell a character to prioritize a task, such as cooking before cleaning. If you want to prioritize a certain tree to be cut you have to select a character and then the tree. But what if you want the tree to be cut by just one of the characters without you knowing which - you just want the first available character. This was solved in the game Oxygen not included, which is similar to RimWorld but you are mining up/down below the ground and not aobe the ground. What Oxygen not included did was that you can click on an object and set a priority to that object. So if you want a tree to be cut by first available worker, you increase the priority of that tree. In the game Settlers, you can prioritize which items to be hauled before another item, which is impossible in RimWorld. It's really annoying when you see a colonist haul a single joint while leaving the precious food to go bad in the rain. I think there's some built-in prioritization because you can see them build defense structures before all other structures, but I haven't found a way to change this prioritization.    
  • Odd parameter values. This is the same problem as Parkitect has: it's difficult to determine what makes a room beauty. In RimWorld you can place floors, sculptures, furniture, flowers, etc to make a room "beauty." But even though you have placed many of these items the characters are still complaining, and if you google you see many other people are confused by the same topic. Perhaps a better idea would have been to use the same system as in Cities: Skylines where you see clearly on a color-map where you need to add more parks. Yes, RimWorld has a beauty display, but it's confusing. For example, why has one part of the drawer a beauty of 1 and the other part a beauty of 3?
  • The storage area need a search function. For each storage area you can set with a check-mark if something should be stored in it, such as food but no weapons. But sometimes it's difficult to find what you are looking for, so it would have been easier if you could search for it. It has a hierarchy, but sometimes you have no idea within which group something belongs. For example, where's the Luciferum checkbox? It's below Manufactured → Drugs. If you click on the Luciferum description it doesn't say anything about that it's "manufactured." So if the search function is too difficult to implement, then it should say in the description where the item is in the hierarchy.  

May 27, 2019

Why did you give the game a bad review after playing for so many hours?

Sometimes when you browse Steam reviews you see a review like this:

If you don't know Swedish, "Recommenderas inte" means "Not recommended" and the customer is not recommending the game Cities: Skylines despite having spent more than 1000 hours playing it. You have to pay roughly 30 USD to get the base game, and how can you say getting 1000 hours of entertainment for 30 USD wasn't worth the money? Understanding this is also something other game designers struggle with. This is a tweet by a product manager at Paradox after their game Imperator: Rome got bad reviews:

When writing reviews, gamers are not measuring the money they spend on a game in relation to the number of hours they play the game: 30 USD for 1000 hours of entertainment wasn't worth it! In Sweden, 30 USD is roughly three movie tickets and a movie is usually two hours long, so if you go to the cinema you get 6 hours of entertainment for 30 USD. So games are very inexpensive entertainment. If you thought the game was boring, why did you spend 1000 hours in a boring game? Maybe you thought the game would be funnier the longer you played? Some games tend are deep and you have to play for some time before you can give the game a review. But you can also find similar reviews of games like Pubg, which is a less deep game and you understand what the game is about in a few hours:

What is going on? While reading the book Designing Games: A Guide to Engineering Experiences written by Tynan Sylvester, who also made the game RimWorld, I found "player's remorse." It's defined like this:
Player's remorse appears after a player spends time on a game that motivates him but does not fulfill him. 
The player has enjoyed playing the game for 1000 hours but then felt empty - what was it all worth? "Why did I waste 1000 hours playing this game?" A parallel is television series. Many were upset with Game of Thrones after what they thought was a bad ending of the last season. "Why did I waste my time watching eight seasons when all I got was that ending?" I bet many people regret watching eight seasons even though they enjoyed all eight seasons except a few of the last episodes of the last season. People spent so much time analyzing what would happen - and to what use? But what would have been a good ending to Game of Thrones when everyone had so high expectations?

Another great discussion on the topic is this Reddit threat: About games that have Steam reviews like this: "[100+] hours on record, Not Recommended", which also links to this article: Sympathy for the… person who left a negative review on Steam for a game they put 600 hours into. To summarize, some reasons to why someone with a high playtime gives a game a bad score are:
  • The developers could have updated the game. Most games, including Pubg, are continuously being updated. So a user may have spent many hours enjoying the game before it was updated and the update made the game worse.
  • It could have taken many hours to really understand the game. The more experience you have, the more flaws you will find. Some games are deep and you need experience to really understand the game. While it's fun to play the game when you are new, it's unplayable when you have 1000 hours of experience. 
    • Cities: Skylines: it takes a lot of time to build a large city and realize that it has flaws because it can't simulate enough population for a large city. 
    • Pubg: if you are really skilled then each millisecond counts and then some say Pubg is broken because it can't always handle these milliseconds because of multiplayer issues. 
    • No man's sky: you were promised an infinite universe, but it took some time for players to realize that yes the universe may be infinite but all the planets look the same, so what's the point of having an infinite universe? 
    • Hearthstone (Reddit comment): "Ultimately it was the insulting "developer insights" that killed it for me. You realise many of the games 'flaws' were intentional decisions to leech more money from the player base (ie. Bizarre and poorly justified balance decisions that pushed you towards buying more cards)"  
  • The game is boring to play but you think it will improve the more you play. You think it will be more fun to play if you reach the next level or upgrade to a better tank, but what if it never happens? You spend a lot of time upgrading to better tanks in the game World of Tanks, but when you finally get a better tank the game will force you to play with other better tanks, so what was the point?  
  • You were addicted to the game. What if you enjoyed a game so much that you quit your job and isolated yourself before realizing you were addicted to the game? Would you give the game a good or bad review? Or as a Reddit comment said: "I wasn’t just playing because I was enjoying the game; I was playing to level up and earn a lootbox, so I could get a chance at that elusive skin, and pretty soon I noticed myself continuing to play in spite of not enjoying it any more. I was playing compulsively."  
  • The game never ends. Neither Pubg nor Cities: Skylines have endings - you either start the game over and over again in a hunt for winning a match in Pubg or you build your city over and over again until you run out of space, so it's natural that a few people after 1000 hours wonder what the point of playing is when it never ends.   
  • The pause button increased playtime. Some people pause their games for various reasons, so having 1000 hours of playtime doesn't mean they played the game for 1000 hours.  

What if it's not the players who are to be blamed, but the review system. On Steam, you can either say the game is good or bad: thumbs up or thumbs down. You played the game for 1000 hours but in the end you didn't like it, but it was still sort-of fun to play it. Now you are forced to pick one of the options: good or bad. Sometimes it's useful with more options.   

May 17, 2019

Parkitect - a management game

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.

Another problem I discovered involves the absence of pathfinding. If you destroy a path while guests are walking on it, the guests begin to walk in a random direction hoping to find a path to walk on. But sometimes they are not finding their way back because they just walk randomly. A better way would have been to do some pathfinding back do the nearest road, which is doable because the entire map is a grid and you know which tiles are roads, so a flow field algorithm would have been a fast solution.

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

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

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

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

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.

March 15, 2019

Download Reeds-Shepp paths for Unity in C#

My side-project is to make a self-driving car in Unity. I've been working on it for about four years and the last update was 2017. This year I decided to make another update because I've learned one or two things since 2017.

A self-driving car is not one algorithm - it consists of several algorithms combined together. The main algorithm in this self-driving car is a path-finding algorithm called Hybrid A*, which is a modification of the classic A* algorithm. Most games are using A* to make characters find their way around the map. But unlike a character, a car can't turn 360 degrees on the spot, so some modifications have to be made. But no matter how many modifications you make, Hybrid A* will never find the target with the exact position and rotation, so we need some kind of path that ends up exactly where we want to go. 

One such path is called a Dubins path, which is the shortest path from point A (with heading A) to point B (with heading B). In total, there are six Dubins paths and you have to measure all of them to find the shortest one. They look like this: 

The problem with those paths is that sometimes a car has to reverse into the spot where it want to go, and a Dubins path is just forward (or just reverse if you make some modifications). If you can both drive forward and reverse, the shortest path from point A (with heading A) to point B (with heading B) is called a Reeds-Shepp path.

While then Dubins paths are six in total, the Reeds-Shepp paths are 48. Also, the original Reeds-Shepp report called Optimal paths for a car that goes both forwards and backwards is not the easiest report to read. Luckily, Matt Bradley has managed to implement the report in C# - but in another game engine than Unity. So I decided to translate the code to make it work in Unity. The main challenge I met was that it took some time to realize that Unity is using a different coordinate system than the coordinate system used in the original implementation.

This is the end result (black means that the car should reverse and white means forward):

You can download the Reeds-Shepp paths (and Dubins paths) here.

February 11, 2019

Tesla Motors Simulator - 2019 update 1

New year and new Tesla Motors Simulator updates are rolling out. In the last update I managed to introduce a bug where the car continued to accelerate for some short time even though you didn't press the gas pedal button. This happened at higher speeds and you felt it most when driving the Roadster 2020. I fixed this bug in this update with maybe 10 lines of code, but it introduced some other inaccuracies, so I had to change the parameters in all cars to make them have the same performance as the real cars.

In the future I might build my own "wheel collider" to have more control over it. I'm currently using Unity's built-in and it's working like a black box where you put in some values and then some values comes out and no-one really know what's going on inside of the box.

In the last update I removed the destruction system that deforms the car when colliding with something. The reason was that I'm using a simplified destruction system and the destruction is sometimes very inaccurate looking from what it would have looked like in real life. But people were sad about it, so I decided to implement it again. I also added dramatic sparks to make it look cooler when colliding. Other games, like BeamNG have more realistic destruction system, which I believe is called soft-body physics. But realism means slower performance and the destruction system I'm using is fast. But I might implement a better one in the future.

The third thing I added was a simple container trailer that the Semi can drag around. The trailer is still a little buggy here and there, sometimes it flips when colliding with some small object, but it's working overall like a real trailer would. I also realized I could take this trailer and add it to my pathfinding algorithm for self-driving cars, so it becomes self-driving trucks!

February 7, 2019

Steering Behaviors - or how not to evacuate a building

One good book I read is The Unthinkable: Who Survives When Disaster Strikes - and Why. It discusses an aircraft accident where many people died even though the computer simulations said they should have survived. What went wrong? The answer is that the computer simulations assumed people move in the same way as water.
For a long time, engineers assumed people would move out of a building like water. They would fill the space they had, coursing down the staircases and flowing out to safety like a river of humanity. Buildings were constructed accordingly. The problem is, people don't move like water.

So if you are trying to model real people, you have to take pain and fear into consideration. People make decisions, they stumble and fall, and they fill up space unevenly. On their way out, they pause to rest when they can. But if you are just trying to make a simple game, you can treat people like water. Treating people like water in games is also known as Steering Behaviors. These individual behaviors are supposed to work like Lego bricks - you can combine several of them to get the final character behavior you need.

Let's say you have a character that's following a path. It will work fine until the character is meeting another character moving in the opposite direction? One solution now might be to calculate a new path with some pathfinding method like A* (A star). But this will take some unnecessary computation power. A better way is to use these steering behaviors, which will make the character avoid the other character and then continue following its path.

The following shows a combination of the behaviors:
  • Seek - move along the flowfield direction
  • Solid obstacle avoidance - is in this case finding the closest point on the wall (the walls are just lines), and if the character is predicted to collide with the wall it should steer away from the closest point)
  • Moving obstacle avoidance - is in this case moving a character away from the character it's colliding with. So it's not a steering behavior but a commonly used cheat to avoid intersecting characters

While researching steering behaviors I learned that the most difficult of the behaviors is avoiding moving obstacles, so there are multiple algorithms trying to deal with the problem. 

Algorithm 1. The most simple obstacle avoidance behavior is trying to just avoid the most dangerous obstacle by predicting where it will be in the future, while ignoring all others.

Algorithm 2. Is trying to avoid all of the dangerous obstacles by predicting where they will be in the future, and then scale the prediction so that obstacles closer to our character are considered more dangerous. 

Algorithm 3. This one has a name and it's Power Law. It's similar to Algorithm 2, but is also calculating an energy. As you can see, the characters are finding their way through the congestion in a slightly more realistic fashion.

Algorithm 4. RVO. This is what Unity is using to make characters avoid each other on their navmesh. I never implemented this behavior but might do it in the future.

As you can see, some of the characters are intersecting with each other. This is a commonly used cheat and the idea is to avoid congestion, you shrink the radius of each character until it's not anymore stuck. This cheat was used in the game Planet Coaster (as explained in this article) and they sold millions of copies, so it should be allowed in your game as well!  

Adventures making a custom navmesh in Unity

I was watching this talk by Oskar Stålberg, who is one of the creators behind a cool indie game called Bad North. In it he said he had fun making a custom "navmesh," and since I had no experience whatsoever from navmeshes, I decided to make my own navmesh. I've earlier got questions if my pathfinding-for-cars algorithm is working on Unity's navmesh (or any navmesh) and I've up until now said "I have no idea" because I wasn't sure how a navmesh is working.

What is a navmesh?
Once upon a time it was common to divide the area, where a character in a game can walk around, into a grid, like a chessboard. The problem with this method is that if you have a big map, you will get a large chessboard, making pathfinding very slow. A better way (in some cases) is to make a navigation mesh (navmesh). You do this by dividing the area into convex shapes, such as triangles, meaning that you will hopefully end up with fewer triangles than cells in the chessboard. This will make pathfinding more efficient because the pathfinding algorithm has to investigate fewer nodes.

How can you learn how to make a navmesh?
To learn how to make a navmesh, I googled "Unity navmesh tutorial." But all tutorials I found were about how Unity's own navmesh system is working - not how to make your own custom navmesh. But why are there almost no tutorials on navmeshes? The reason is not that finding your way around a navmesh is difficult - the reason is that it's difficult to create the shapes, like the triangles, that makes up the navmesh itself. So after much research, I learned that if you want to learn how a navmesh is working, you have to learn the following areas:
  1. How to create the navmesh itself
  2. How to find the shortest path on a navmesh
  3. How to make characters follow the shortest path

How to create the navmesh itself
A navmesh consists of connected convex shapes. The reason they have to be convex is that if you are standing inside of a convex shape, you can walk in a straight line to any other point in that shape. If the shape had been concave you would have to do some local pathfinding inside of the concave shape. These shapes are in many cases just triangles, but some merge these triangles into other convex shapes, such as rectangles, to make pathfinding more efficient.

The problem is: how can you create these connected triangles from the game level you have? You might have these houses and you want some character to find the shortest path between the houses. I believe the answer to that question is Constrained Delaunay Triangulation, which is a big topic, and I've written a tutorial on it here: Constrained Delaunay Triangulation. So now you have something that looks like this:

How to find the shortest path on a navmesh
You have these connected triangles, and now you want to find the shortest path from one triangle to another triangle. To do that you connect the center of each triangle with the center of each neighbor, and then you just run some pathfinding algorithm, like A* (A star), on that graph. When the character is moving between each triangle, it should not move to the center of the next triangle, but the closest point on the edge shared by the current triangle and the next triangle.

The shortest path on a navmesh can be simplified by using a line-of-sight algorithm - the character doesn't have to navigate between the triangles if it can move in a straight line to the goal triangle. But how can you detect if a character can see the goal point it wants to reach? The answer is by using a line-line intersection algorithm. If you draw a straight line from the character to the position it wants to reach, and if this line is not intersecting with any of the triangles edges that are obstacle (has no neighbor), then the character can move in a straight line to the position it wants to reach.

How to make characters follow the shortest path
Now you know which triangles the character has to pass to reach the goal destination. To make it reach the destination, you should learn a set of algorithms called Steering Behaviors. This is what Unity is using to make the characters find their way around their navmesh system. For example, they are using an algorithm called RVO to prevent characters from colliding with each other.

More than pathfinding
Navmeshes are useful for other areas than just pathfinding for characters. While researching navmeshes I read that you can use them to simulate flow. When simulating flow in games you move a texture by using a color and the color determines in which direction the texture should move. For example, if the color is red, then the texture moves in a certain direction. This makes it look like the water is flowing. This colored texture is called flowmap, but they are almost impossible to paint by hand, and what if the flow is suddenly changing direction while the game is running? With a navmesh, you can create dynamic flowmaps.

To make this work you should connect the vertices of each triangle in the navmesh, and then run a flowfield algorithm to find the shortest path from each node to the destination in the triangle you want to reach. As said before, you can use the line-of-sight algorithm to detect if a node can see the goal position. Each node will now get a direction and this direction is used to set the vertex color of the mesh. You can access this vertex color in a shader and thus get the flow direction. Moving the texture in the direction of the flow is kinda tricky and this is a good article on the subject.

This is the dynamic flowmap that determines the direction of flow:

...and then you can simulate something like smoke on the navmesh:

...or water:

Read more
This was just a short introduction, so if you want to learn more about navmeshes, you should read:

February 6, 2019

The art of fake volumetrics - or how to make fluffy red pandas

Most objects in games tend to be kinda flat. The reason is that all objects in games consists of triangles and each triangle takes some time to display on the screen, so you should use as few of them as possible. But what if you need to display something that's not a flat surface, such as hair or smoke? Then you need to use a trick, which I don't think has a name, but we can call it fake volumetrics (I've heard the name "quad stacks" or "shells"). This is how it works:

Let's say you want to make a fluffy red panda:

This panda is flat, while real red pandas tend to be fluffy. To make it less flat you need to fake fur because you cant make each fur straw because it's way too complicated for games. You do this by rendering the panda multiple times, and each time you grow the size of the panda by making the mesh larger along the normals of each triangle. This is done step-by-step around 10 times. Each step you also change the transparency of the fur, so fur closer to the body is less transparent than the fur furthest away from the body. You now get a fluffy panda:

To avoid getting fur in the eyes and the nose you can simply use a texture telling the algorithm not to grow the triangles around the eyes and the nose.

With the same technique, you can make fake volumetric smoke/fog. You begin with a simple plane at the bottom, and then you add multiple planes on the top of the original planes while changing the transparency the higher up you are. And you end up with this:

If you need a better explanation of how to make fake volumetric smoke, you can watch this YouTube video: UE4 VFX For Games: Brute Force Volumetric Gases - Ground Fog & Vapor. The problem with this technique is that if you zoom in really close, you can see the individual fog planes:

To avoid this you can either add more planes, or make sure the player is staying far enough away from the smoke!

February 2, 2019

Lessons learned from the Paradox podcast - Season 4

Paradox Interactive is a company that's both developing and publishing games. In their podcast they talk about the business of video games, and if you want to listen to it on your own, you should search for "The Paradox Podcast" on iTunes or wherever you can find popular podcasts. I've earlier summarized season 1season 2, season 3, and this is season 4:

  • The successful game RimWorld is a perfect "paradox game" they never published/developed because RimWorld is a combination of the games Factorial (manufacturing), Don't Starve (survival), and The Sims (social). 
  • Paradox has acquired the game Prison Architect, which is a game first released in 2015. They acquired it from the company that developed it, so they didn't acquire the developer itself. Prison Architect is a good game because it's a sandbox where you can create your own stories, so Paradox believes they can come up with new content in a similar way as Microsoft is still making money from Minecraft by updating it. Prison Architect is obviously not as big as Minecraft, but both games are similar to each other. Paradox also plans to develop other "Architect" games, such as Ski resort Architect. 
  • Paradox has an idea that to provide free updates to an existing game, they can sell paid updates (DLCs) to game and that will also pay for some free updates to the same game. A seven year old Paradox game is still getting free updates because some people pay for the paid updates. 
  • There's currently a war between developers if they should put their game on the Steam store or on the Epic store. A better idea is to focus on making a good game and put it on a store, and competition between stores is good.
  • Farming Simulator might sound like a stupid game idea - who would want to spend time drive around in a tractor? But it turns out people like to farm, the company behind the game announced they will turn farming into an e-sport, so what you think is boring can be fun if you make the boring parts fun to play.
  • The quality of games released every year is increasing because people can now go to school and learn game development, which is not something you could some years ago. But releasing a good-looking game with no bugs is no longer enough - it also has to be fun to play. And you also need to figure out a way to market the game, which is what Paradox can do for you. 
  • Paradox has recruited Rod Humble to lead a new Paradox studio in US called Tectonic. He has made 200 games (including Sims 3) and has 30 years of experience. 
  • Rod Humble believes in "The Valve style" when making games. Valve is a successful game developer and they believe in: 
    • Small groups
    • Each group members should be specialized in one area while still having a broad range of skills
    • Small amount of documentation (1 page is enough)
    • Moving fast by prototyping ideas without first having to ask if you are allowed to do it and then some manager has to make that decision one month from now 
  • Game developers make art - they sell a fantasy, telling a dream. A game is not like toothpaste which you actually need. 
  • An interview with Wendy Young and her experience of working through the ups and downs in the game industry. 
  • How can you reach a new type of audience that plays another type of game than the audience you already have? Just because you make a game that attracts that type of audience does't mean they will automatically be aware of your game. What Paradox did to make the new audience aware of the new game was to launch a dating app which is an odd thing to do if you are a game developer. But it would make the new audience be aware of the game. 
  • To measure if your marketing idea was successful, you measure of many people found what you wanted them to find. For example, how many watched the trailer, how many media sites wrote about the game, how many signed up for the newsletter, how many pre-ordered the game? But it's still difficult to really measure if it was a success if you have nothing to compare the numbers against.     
  • It's difficult to analyze whether a feature in a game contributes to the number of sales. For example, will adding multiplayer result in more sales? No-one knows. 
  • Paradox has released a new game: Imperator: Rome. It has caused a lot of anger in the community and has bad user reviews on Steam. Some users argue they are tired of the "Paradox way" of releasing a game for full price and then DLCs over the years. It will be interesting to see what happens in the future and the podcast argued it was too early to discuss it in this podcast because they have to first analyze why there's a mismatch between the users and Paradox.
  • There's currently a small war going on between Steam and Epic Store. Some developers have decided to try to make a little more money by releasing their games only on the Epic Store. Many gamers are upset by this decision, and the question is why are they so angry? According to the podcast, the answer is that it's annoying to maintain a friends-list on several accounts, which is why people prefer to buy games just on Steam because it's simpler to have everything collected in once place. Another reason is that the Epic Store doesn't have the same features as Steam has because Epic Store is a younger service. On the other hand, gamers were also upset when Steam was launched, so what gamers actually dislike is change. Another good article on the topic is: Why People Are So Mad About The Epic Games Store
  • Paradox's latest game, Imperator: Rome, has been out for two weeks, and it has received mixed reviews. While the professional game critics like the game, the gamers are not. Who should you listen to? Paradox says you should listen to the professional critics because they will give you the overall state of the game when it's released, while gamers may give the game bad reviews because of some minor details. As you develop the game after release, you should instead listen to the gamers because they will continuously publish reviews as the game becomes (hopefully) better and better. 
  • Paradox's business idea, or the "Paradox way" which has been discussed in the podcast, is to release a complete game and then release content (dlc) to the game over the years, and you have to pay for these expansions. Gamers argue that Paradox has come up with the idea (to make more money) to instead release an unfinished basic game, forcing more people to buy the dlc to get a complete game. But Paradox still argues they developed more than a complete basic game and the players are instead expecting more and more from the basic game. The gamers, on the other hand, argue they should expect more from the basic game because Paradox is now a bigger company with more resources and experience.
  • What should you do when your game gets bad reviews? Paradox went through all reviews on Steam (currently 7658 of them) up to one particular date. You should listen to your customers, but not always do what they say. Then you should come up with a long-term plan and not panic-fixing the game. What Paradox learned is that they have to become better at communicating what a player can expect from a game.   

This article will be updated as they release new episodes!

January 15, 2019

Computational Geometry - Part 3

As said before and before, I've spent some time learning an area called Computational Geometry. One of the algorithms I learned was how to make a Voronoi diagram. The algorithm I implemented suffered from floating point precision issues, so sometimes the Voronoi diagram lost some edges. The reason was that the algorithm was cutting lines to create the diagram, but the more the lines were cut, the worse the precision of the lines became (because of  floating point precision issues) and in the end the algorithm removed lines it shouldn't have removed.

A better way to generate a Voronoi diagram is to use a Delaunay triangulation algorithm. This algorithm doesn't suffer from floating point precision issues and is easier to implement if you know how to implement the Delaunay triangulation algorithm. To create a Voronoi diagram from a Delaunay triangulation you need just 150 lines of code, while the older algorithm needed 600 lines of code.

This is the result. You can also see the Delaunay triangulation (the black lines).

One other area I struggled with last time I studied the area was how to cut triangles in the best way. You may think that there are many algorithms that can cut connected triangles in 2d space in a simple way, but not a single one can be found when searching on Google. The answers on Stack Overflow consists of solutions where you have cases. For example, if a line-segment of one triangle is intersecting two line-segments of the other triangle we want to cut, then we need to create 2 new triangles depending on which lines are intersecting, and the solution becomes more and more complicated.

Perhaps a more elegant way is to use what we used to create a Voronoi diagram: the Delaunay triangulation. But in this case we force the triangulation to include some triangles we want to cut from the triangulation, and we get a Constrained Delaunay triangulation, which looks like this:

You can also use the Constrained Delaunay triangulation if you for example want to make a navigation mesh for your game.