July 24, 2017

This self-driving car is now faster with the flow field algorithm

0 comments
So I've made a self-driving car in Unity. The car is using the Hybrid A* pathfinding algorithm along with other algorithms to find its way around a confined area, such as a parking lot. You can test it here or here. The old version was working fine, but one can always improve. The updates in this version are:
  • Added lines showing the waypoints 
  • Fixed a bug where the wrong value was added to the sum or errors in the PID controller, so the car is now following the path much better 
  • Added a cost for switching driving direction, like forward -> reverse, because it would be annoying to sit in a car that constantly is switching driving directions
  • Fixed a bug where the smooth path algorithm optimized the distance to obstacle in 3d space and not 2d space 
  • Added an improved obstacle-intersection algorithm which is faster and more accurate. It's now using rectangle-rectangle intersection instead of circle-circle intersection
  • Added UI where you can display the grid and the flow field 
  • When optimizing the final path, it's now optimizing the distance to the average of the surrounding obstacles and not just the closest obstacle 
  • Cleaned up the code
  • Added flow fields as heuristic and for obstacle detection, which makes the pathfinding much faster 
  • Made so that the Hybrid A star can expand to a cell if this expansion has a lower cost than previously
  • Improved path following so the car is slowing down gradually before it reaches the end or a turning point such as "reverse -> forward". Previously you could often see how the car crashed into walls because it was driving too fast

This is the flow field the car is using to faster detect if it's colliding with an obstacle:


The area is divided into cells, and the darker the cell is, the further away it is from an obstacle. So if you want to check if a car is colliding with an obstacle while generating the path, you can see in which cell it is and see how far away from an obstacle it is. If it can't possible be colliding with an obstacle, then it's not colliding with an obstacle and you don't need to use a slow rectangle-rectangle intersection algorithm to check if it's colliding with an obstacle.

Update 2017-07-26
I realized that a good idea might be to close cells depending on the heading the car had when entering the cell. So the car can drive to the same cell even if it is closed if it hasn't arrived to that cell before with the same heading. The result looks like some abstract art:


...but the algorithm is now finding more solutions and the car can even turn around on its spot. The problem is that sometimes this solution is much slower, so maybe a combination between the slow and the faster algorithm can be used?

July 16, 2017

What happened to John Carmack after the book Masters of Doom?

1 comments
John Carmack is famous for creating the games Doom and Quake. In the book Masters of Doom, you will learn how he created those games and the company id software. That book ended with the game Quake 3, but what has he been up to since 1997? The answer comes in a free 300 pages pdf, which consists of interviews with John Carmack, beginning with Quake 3 and ending with Rage, so from year 1997-2008.

Here are some key lessons learned from the book
  • "The assumption that hiring more people gives a better product is often incorrect. It might (but not always) give you more product, but not necessarily better product." [He argued that the 11 people id software had at the time is the right number of people to do a project and having 50 people would hurt the project]
  • You should listen to the community, but this will also take time, so you have to prioritize. Carmack argued that John Romero (who was forced to leave the company) was talking to the community when he should have been working.
  • "I will always take an aggressively simple approach to things" was his answer to the question if Quake's level should be more interactive.
  • Carmack was working 70 hours a week for six years.
  • "I had this really bizarre conversation with a couple of lawyers and they were talking about 'How do you pick your target market? Do you use focus groups and poll people and all this?' It's like 'No, we just write games that we think are cool.' They're from such a different world that they fundamentally did not get that."
  • "There's plenty of starving artists that are probably talented and hard working, they're just doing something nobody cares about."
  • "The graphics technology everybody looks at is only a quarter of Quake's code, and it's not even the hard part of it. Look at the things that are really unglamorous but really important, like the file extension architecture in Quake."
  • "I tried just a couple of features, like transparency or shadows and reflections. And they just dropped in - it was so wonderful. And that was what really got me crusading for OpenGL. It was like, "This helps me. This is something that's letting me be more creative and try out more things to produce a better architecture than we would have had otherwise." A good API can help you produce better products." [So using a game engine like Unity is not cheating!]
  • How do you handle third-party developers when you license your engines? Carmack: It's, "Here's a CD. Thank you for the half-million dollars. Have a nice life."
  • "All of science and technology is built standing on the shoulders of the people that come before you. Did Newton patent calculus and screw the hell out of the other guy working in it? It's just so wrong, but it's what the business world does to things, and certainly the world is controlled by business interests." [Why software patents is a bad idea]
  • You hear it from the fan base a lot. "Do it right. We'll still be here. We'll wait," and it's tempting to just let things slip. But that's really not OK. If you're doing something cutting edge, you're making fundamental decisions about your architecture, and if you let it slide for a year or two, then it's just not the right decision anymore. Even if you pile on all these extras, it's not optimal. It's not targeted at what you're doing. [Why it's important to ship a game. They planned it would take 12 months to make Quake, but it took 18, which is fine] If we shipped on time, we probably weren't ambitious enough. Quake 2 would take 12 months because "a lot of things are functioning better at the company."
  • "Programming is really just the mundane aspect of expressing a solution to a problem. There are talents that are specifically related to actually coding, but the real issue is being able to grasp problems and devise solutions that are detailed enough to actually be coded." 
  • "I feel bad for some companies out there. The founders, who are these incredible engineers, are now directors of their departments doing management rather than engineering. At the same time most of the people they are managing are nowhere near as good as they were at doing the actual work. That's what I hope never happens to me. I want to stay in the trenches working on the things all the time."
  • "In the last two projects, my time has been split. I'd have about 3 months och pure research, playing around with different stuff. And then after that it's about 16 months of work on the project. It would be nice to shift that more towards research, but I would never want to devote a majority of my time to research." 
  • "It's not the one brilliant decision, it's the 500 smart decisions that really make things good. Even at the end of Quake 3, I had a to-do list of a thousand things that could potentially be improved on. So it's a matter of going through and knowing all these things that could be done, and prioritizing what the "sweet spots" are."
  • "I actually learn from almost anyone. Maybe I was smarter than the [college] professor but it didn't mean that there weren't things I could learn from him. So it doesn't take someone that's necessarily a "better" developer or programmer for them to have things that you can learn from. So almost all the programmers I've worked with, I've learned something from."
  • "There have been flight simulators where you just jump in, fly around and shoot things, and those are fun and interesting. Then there are these serious simulators where you have to convince yourself that you're being entertained. I still like playing a simple, fast game, where you jump in and have a good time, and I think there are five times as many people in the game buying world that also feel that way." 
  • "Sometimes I wind up feeling guilty that I'm not doing more. I'm willing to just ignore a whole lot of things. And that's pretty important, because so many things come in that are potential demands on my time, and it's just easy to see how people that are in a similar situation, wind up just getting their entire days spoken for, and not being able to do any work because every day, there's phone calls and emails from people that want to do something, they want to have an interview, or pitch a business proposal." 
  • On market research: "I don't do a really through canvassing, play everything that's out there. Usually I watch over someone's shoulder when they're playing the hot new game. But I don't spend that much time actually playing other games. I certainly play more Quake 3 than any other games out there."
  • "Too many programmers agree to random feature requests without thoroughly considering the impacts."
  • "There are a lot of arguments that can be made about game design, and I prefer simplicity and elegance. I'm always the one saying we want the minimum number of everything, because I want it to be simple and fun to play." He would later say that he stepped away from id software because "I'm really no representative of what most of our market is now. I did realize that my very simplified game design ethic is not what the market is demanding. [Quake 3] was the id game I probably spent the most time playing and enjoyed the most, but it was actually one of our less successful titles." 
  • "Usually when I set out making the technical decisions I don't know how it's going to turn out. A lot of it is working out what works, and what ideas come to you. We commonly switch gears during our development process when a really good opportunity comes up." 
  • "Once or twice a year I go on "working retreats", where I lock myself in a hotel room for two weeks with no internet connection for completely focused work." 
  • "We try to pick directions that a good number of people will enjoy, then just do a quality job implementing it. Some people will love it, and some people will hate it. The people that hate it usually scream louder."
  • "Tessellation has been one of those things up there with procedural content generation where it's been five generations that we've been having people tell us it's going to be the next big thing and it never does turn out to be the case. What we want is something that you can carve up the world as continuously as you want without any respect to underlying geometry." 
  • "A lot of people don't seem to really appreciate how the vertex fragment rasterization approach to computer graphics has been unquestionable the most successful multi-processing solution ever."
  • "'Oh just thread your application.' Anyone that says that is basically an idiot, not appreciating the problems." 

Update! John Carmack replied to this article on twitter: 

July 11, 2017

Why you need to learn the Flow Field algorithm

0 comments
As said in the last post, I've read a lot about pathfinding. One of the pathfinding algorithms I found was the Flow Field. A Flow Field covers the entire grid (if a cell is not an obstacle and if a cell can be found from the start position), so while A* is finding the shortest path from the start position to a goal position, a Flow Field is inspired by water and is finding a path from each cell to the start position. It looks like this:


In the image above, the darker a cell is, the further away it is from the start position, which is the red sphere. The blue lines is pointing in the direction of the shortest path. But you can also add more start positions, which is actually speeding up the algorithm. So if you want to find the shortest path to the nearest door, then you can use the Flow Field.

A Flow Field is useful if you have a lot of units trying to find their way through your map, and was used in the game Planetary Annihilation. What they were doing was to divide the area into sectors, then use A* to find the shortest path between the sectors, and then they used a Flow Field to find the shortest paths through a sector. It looks like this:


But that's not it. A few years ago I made a self-driving car in Unity after reading a report on the Hybrid A* algorithm. One of the heuristics used by the Hybrid A* algorithm was something they called Dynamic Programming. I realized that Dynamic Programming is actually a Flow Field, so I updated my self-driving car with that algorithm. The 160x160 Flow Field looks like this and is generated in around 0.05 seconds:


You can also use the Flow Field algorithm to help you with obstacle detection. In the Hybrid A* algorithm, it's obviously important to quickly find the distance to the closest obstacle, and you can generate these distances fast once in the beginning. That Flow Field looks like this:


July 4, 2017

Pathfinding best practices and surprising uses

0 comments
Weather is crap, so I've studied a lot of resources related to pathfinding, which is the art of finding a path between two or several points. I've already spent a lot of time studying the Hybrid A* pathfinding algorithm used by self-driving cars, but one can't study enough of pathfinding! This is a summary of what I want to remember and what you also will most likely want to know:
  • A good pathfinding engine can be used for more purposes than just moving units around the world. In the real-time strategy game Empire Earth, pathfinding was used for tasks such as terrain analysis, choke-point detection, AI military route planning, weather creation/movement, AI wall building, animal migration routes, and pathfinding. 
  • Pathfinding can also be used as a flood-filling algorithm. The closed list will store all nodes searched, so you can use it to find which nodes were filled with the flood. In this case you can return the top open list node without searching for the cheapest node to process next because in this case, tile costs mean nothing.
  • Pathfinding can be time-consuming, so it may freeze the game. A solution to this problem is to split the paths up over time. This works well for both static and dynamic maps, and was used successfully in the game Empire Earth, which used paths that supported thousands of units. The solution is to first generate a quick path to get the unit moving because the unit should move the moment the player tells it to move. This quick path uses a pathfinder algorithm that stops after maybe 10 iterations and picks the node closest to the goal-node as the path's end-node. Then you should generate a full path, which is a path from the end of the quick path to the goal node we wanted to reach from the beginning. But this full path may be ugly and look wrong because it begins at the end of the quick path, so you need to add a splice path, which uses the same idea as the quick path by using the unit's current position as starting position and a point on the full path as end position. This point should be experimented with but can be like eight nodes in on the full path.
  • In Empire Earth, if an AI-controlled unit failed to find a path more than 10 times in 30 seconds (perhaps because the unit was walled in), they simply killed that unit.
  • Finding the cheapest node in the open list is often time consuming so you need to optimize the list. To optimize this you can use a sorted heap structure that allows for fast removal, but slow insertion. The second method is to have an unsorted list where insertion is fast, but removal is slow. A third alternative is to have a "cheap" list with roughly the 15 cheapest nodes (sorted). So each time you want to add a new node to the open list, you first check if it's cheaper than any nodes in the cheap list, then add it to that list and sort it, so it can have more than 15 nodes. Otherwise, add it to the list with all the other nodes in the open list, which is unsorted. If the cheap list is empty, add 15 of the cheapest nodes from the expensive list.
  • Iterative deepening is the art of restricting the A* algorithm by limiting the number of iterations allowed or limiting the maximum path length. If A* fails to find a path, the restriction can be increased. This can be used if the map is dynamic. Let´s say you have two agents that want to go through a door. The first agent will find a path, but the second will fail. If you had not used iterative deepening, then the second search would have taken a long time before failure. With iterative deepening, the second search will fail fast, but then it may succeed the next time loop because the first agent may have passed the door.
  • In some environments it might be a good idea to return the failed path if pathfinding fails. If an agent follows a failed path instead of just standing still, it might appear as the agent is exploring the environment. 
  • If everything else fails, let the player add waypoints, and the pathfinding algorithm can find paths between these waypoints. 
  • You don't always have to use A*. What if a straight line to the goal is possible? 
  • If the player can't see the AI controlled enemy units, then you can ignore pathfinding and just teleport the units, so pathfinding is not always needed. 
  • It's possible to pre-compute every single path in a search space and store it in a look-up table. For a 100x100 grid, this will need 200 MB of space. An alternative is to calculate a few paths, store them, and see if the path you create while the game is running can use those paths. A unit will most likely pass through a door, so calculate paths from the door.
  • It's important to optimize the search space, the fewer nodes you have to search through, the better. Maybe you don't have to divide the are into small squares, what if you divide the area into waypoints? Or you can combine both techniques: first find the shortest path through the waypoints, and then find the shortest path between the waypoints by dividing the area into squares. In the game Company of Heroes, the high-level search space representation was a hex-grid, and the low-level representation was a square grid. One way to improve search space is to use Quadtrees, which means merging cells that don't have an obstacle in them into one large cell. It works like this: Pathfinding in an Entity Cluttered 3D Virtual Environment
  • A* demands that you use a heuristic which i admissible, meaning that the h-cost is never larger than the true cost. This will result in an optimal path. But if you don't follow this rule, you can get a faster algorithm but not an optimal path. But why would you need an optimal path, will anyone really notice? You can add this to your game by simply multiplying the h-cost with a constant such as 1.5.
  • The best heuristic to use on a grid is the octile heuristic. It looks like this: max(deltax, deltay) + 0.41 * min(deltax, deltay), assuming that diagonal movement cost 1.41. The problem with the euclidean distance is that it underestimates the cost, while manhattan distance overestimates the cost.
  • When should you use a grid, waypoints, or a navigation mesh to represent the search space?
    • Grids are most useful when the terrain is 2D, when implementation time is limited, when the world is dynamic, and when sufficient memory is available. Don't use them when you have a large open world or when you need accuracy (like when you have a house with an angle that doesn't fit the grid)
    • Waypoints are useful when implementation time is limited, when fast path planning is needed, and when you don't need high accuracy.
    • Navigation meshes should be used when you have time to implement them. But there's no best technique to create an optimal navigation mesh. 
  • No one solution is useful all the time. Navigating open terrain requires a mix of different techniques. Use local collision avoidance techniques for nearby areas and pre-processed data for longer distances. Using multiple techniques that complement each other yields better results than any one technique alone.
  • It's kinda boring if all AI controlled units follow the exact same path. To solve this, each edge between two nodes can have a width, and you need to make sure this width doesn't collide with an obstacle. Then each unit follows the edge but with a certain distance from the edge.
  • While A* is finding the shortest path to a single point from a points, Dijkstra's algorithm will find the shortest path to all points from a point.
  • Pathfinding algorithms tend to terminate when the goal node is the node with the smallest cost, so the algorithm doesn't terminate when it reaches the goal node. But when it first reaches the goal node, then that path is in many cases also the best path, so you could stop the algorithm when it first sees the goal node and not when the goal node is the node with the lowest cost. 

Sources

July 1, 2017

The secrets of Artificial Intelligence in classic games

0 comments
The old classic computer games were fun and often challenging because of the Artificial Intelligence that controlled the enemies. But how could the AI in those old computers be challenging? This will be a short description of how the AI in classic games was working and the tricks they used.
  • Warcraft. The AI was waiting for some fixed amount of time, and then started spawning a wave of units to attack you. It would spawn these units at the edge of the gray fog and not at the base as you first may have thought. It continued to spawn these units until your defenses were nearly overwhelmed - and then it would stop, leaving you to kill the remaining enemy units and win the fight. So the AI didn't have to worry about building buildings, saving money, or building units. 
  • Pac-Man. The AI had two states: normal, which is when the player is collecting dots, and another state when the player has eaten the power-up. In their normal state, each of the four ghosts moves in a straight line until they reach a junction. At a junction, they randomly choose a route to move to next. Each ghost chooses either to take the route that's in the direction of the player (calculated by using an offset, so no pathfinding), or to take a random route. The choice depends on the ghost: each has a different probability of doing one or the other. This sounds like stupid AI, but those who played the game thought the AI was smarter, arguing the ghosts tried to set a trap or group up to attack the player.
  • The Sims. This game put the intelligence in the world and not in the character. The objects in the world, like a fridge or a television, tell nearby sims what they offer, such as food or entertainment. The object will also tell the sims how to perform the action to get the offer. 
  • Starcraft. The game had several pathfinding problems. One of these problems was that the units who collected minerals jammed. The solution was: "whenever harvesters are on their way to get minerals, or when they're on the way back carrying those minerals, they ignore collisions with other units."

Sources

June 27, 2017

Finding inspiration from other games

0 comments
In April this year I participated in the Ludum Dare competition where you are making a game in 48 hours. I made an Aircraft Carrier Simulator, looking like this:



Today, I saw on steam that someone had released a game called Carrier Deck. It looks like this:


In the game you "manage the deck of the Nimitz-class nuclear powered supercarrier, the USS Ronald Regan (CVN-76)." So the game has the same game play, the same view angle, the same carrier type, and the same F18 aircraft as my Ludum Dare game had. I wonder if they found inspiration from my game? That would be cool because I don't mind anyone finding inspiration from my ideas. I had plans to make a complete game out of my Ludum Dare game but decided not to because I thought it wasn't fun enough.

June 13, 2017

Resources if you want to learn more about architecture

0 comments
I've set out to learn more about architecture for a project I'm working on. This will be a collection of the resources I thought were the best. I've learned there is not one "bible" you can read to learn everything about architecture, so you have to use several resources.

The timeless way of building. This book is written by the architect Christopher Alexander, and is the first book in a series of three books that summarizes his ideas on architecture. You might ask yourself why some buildings are "better" than other buildings? Why do you prefer to live in a house but hate to live in another house? Christopher Alexander argues that the reason one building is better than the other is that the building you like was designed by using certain patterns. The main idea is that building a building is an iterative process, and those who will live in the building should be involved in the process. If everyone is aware of this "pattern language" then it will be easier for everyone to participate in the building process, and the result will be a building which feels alive.

Ted talks. Ted is an organization which posts talks, and these talks are supposed to be something extraordinary. It has a search function where you can find several talks on architecture. All of them are not extraordinary, but some are, including one guy who had an idea to stop the spreading of the Sahara desert by using clay buildings.

The Pruitt Igoe Myth. Pruitt Igoe was a housing project in St. Louis. The main idea was to give poor people an opportunity to live in better buildings. But the project failed because the houses were not maintained, so they began to fall apart, which resulted in that the people living in them stopped caring, so they fell apart even more. So the key point from the documentary is that a house on its own is not important, but what's happening with the house when the people have moved in.

June 8, 2017

Youtubers playing Tesla Simulator

0 comments
So I uploaded my Tesla Simulator to itch.io, and then something strange happened: people began uploading videos to YouTube of themselves playing it. No-one has ever uploaded any videos of themselves playing my games, and it's kinda strange to see someone playing your game online. No big youtubers are playing it, but smaller youtubers are, which is better than if no-one is playing it! Anyway, this is a small collection of them:







People are also wondering if I'm going to update it. And the answer is yes. But I have to figure out with what. Someone suggested you should be able to run over people, but that's not going to happen, and someone else suggested a big city, but that will take a looong time to build, so we will see...

June 5, 2017

The ups and downs of itch

0 comments
A few weeks ago I found a site called itch.io where you can upload games, books, and assets. You can either give away the content for free or you can sell it. It's also possible to use the combination by asking people to pay what they want for what you've uploaded. I uploaded my (free) Tesla Simulator as an experiment, and this is the result (May 18th - June 4th):
  • 1956 views and 1240 downloads
  • 307 visitors came from my website, while 99 percent of the rest came from itch
  • 839 downloaded the PC version, 335 the Mac version, and 66 the Linux version. This was really interesting to know because I've previously ignored the Mac and Linux users, but they are also interested in your products!
  • A few people have made YouTube videos showing when they play the game. No-one made a YouTube video of the game before I uploaded it to itch
But what if you also want to make money? As usual it depends on the game you have, but someone on Twitter shared their revenue and it looked like this:


Itch is less crowded than the other channels where you can sell your game, but that's also good because it's easier for people to discover your game. It's also easier to upload your game to itch if it's not finished so you can maybe use itch to get feedback while developing the game and then release it on Steam?

Lessons learned from the development of Minecraft

0 comments
A few days ago I wanted to learn how the team behind Minecraft marketed the game. I made a Google-search and found an article which referenced the blog written by Notch, who came up with the original idea behind the game. I realized it might be interesting to read the entire blog and see if I could learn anything from it. But I wanted to read it from the beginning and Tumblr didn't have that option, so I downloaded the xml file with all blog posts and converted it to pdf with the help of some PHP magic. The result is a 508 pages pdf, which you can find here: The Word of Notch.

It turned out it was really interesting to read the blog from the beginning of the end. Here are some lessons learned:
  • The "blocky" main character was from another game Notch had protoyped, but he thought the blocky design would fit into his new game. That design hasn't changed since much 2009. 
  • The name of the game changed from Minecraft: Order of the Stone. Why Minecraft? Because Notch thought it was a good name.
  • Notch published a lot of blog posts during the development of the game, sometimes two a day or more. Once he published nine smaller posts in one day. Not all post were related to Minecraft - some were movie reviews and other were game reviews. He also posted random ramblings about various topics like the singularity. Sometimes it took 5 days between each post.
  • Notch has always been a fan of the game Team Fortress, so he had a plan to add a similar "Fortress mode" to Minecraft as well as something he called "Zombie Siege." 
  • Notch was programming what he thought was fun to program. Once he had planned to implement multiplayer but got bored and decided to play around with water. This happened more than once. He added blocks like gold and trees instead of any multiplayer code. "I’m getting stressed out over the multiplayer release. It’s not going as well as I’d hope, and as a result, I’ve lost motivation, causing me to work really slow. This is a bit of a vicious circle, and I think I need to relax for a bit."
  • Some posts included stuff like videos and images made by people who were playing the game.
  • He was often struggling with performance problems, that Minecraft wasn't running fast enough. So if you are struggling with that yourself, then don't feel bad!
  • In 2009 Notch explained he had "another job" and didn't have enough time to update Minecraft. He asked for donations: "Also, donate!" 
  • He was asking for feedback. "Please remember to give me some feedback!" And when he got feedback, he showed that he appreciated it. "For those of you who have sent me feedback (ever), thank you very much. You’re the best players a game developer could hope for. You’re honest with your opinions and still understand that I may feel different from you. I listen to all your feedback. Thank you for helping me develop this game."
  • He outsourced the sound and music to a guy called C418.
  • In 2009, he wanted to sell the alpha version of Minecraft for 9.95 Euro, 14.95 for the Beta, and 19.95 for the final version. He also wanted a free demo, which I remember Minecraft had an online version of where you could just place and remove blocks. If you purchased an early version, you would get "to help fund the development of Minecraft," "custom skins," "all future updates". He would later add that those who bought the game got early access to new updates, such as survival mode.  
  • He used a forum while developing the game, and he got comments on the blog. "I think the minecraftforums.net forums are most excellent, and a LOT of good suggestions come out of that place." The forum was run by the community and Notch didn't have anything to do with it. Emails worked fine in the beginning and he replied to all of them. But as the game became more popular he got 50 emails a day and decided to reply to just some of them, but he read all of them.  
  • Most blog posts were short, just a few lines (so much for the SEO talk of long well-written blog posts). Some consisted of just images of someone playing the game or a YouTube video, or a YouTube videos where Notch showed an update to the game.
  • 587 people had purchased the game in June 2009, which is about 2 months since he began blogging, in a later post he said it had sold 990 copies between July 19 and June 13.
  • He was feeling the pressure if being behind schedule (because of an illness, most likely flu) and was "freaking out about making survival mode as fun as I can."
  • He wasn't using a design document, but he had two text files: 
    • bugs.txt - bugs that he couldn't fix immediately but want to fix
    • features.txt - a list of ideas he liked but is afraid to forget if he didn't write them down
  • When coding, his goal was to make what he wanted to make as fast as possible with whatever "ugly" code, and then he improved the code. It "helps motivation to actually see things happening in the game."
  • He spent a lot of the time playing the game. "It's very important to me that the game is actually fun and the only way to make sure they are is to play with it." And if the game is fun, it's also fun to play the game. 
  • When he finished a feature, he tried to release it to the public as soon as possible. Before releasing, he was checking the bugs.txt if there's a bug he should fix. 
  • Version numbering can be tricky to figure out, be he said he would just "bump the version number" when releasing a new version. 
  • He didn't keep a schedule when he wanted to have stuff completed, but "rather keep striving towards my mental image of what I want the game to be like." 
  • If he didn't know what to build next to the game, he played the game as if it was completed, and then "add the first thing that doesn't work yet."
  • "My main method for delivering updates about Minecraft and so will still be this blog" was a quote after he got a twitter account. He was also using irc to chat with people who was playing the game. Irc was one of the software he started at the beginning of the work day and kept it on all day.   
  • "Mostly my free time is fairly normal. I try not to get burned out while doing this." so except for some 12 hour coding marathons, he didn't work himself to death. He was trying not to work on weekends "as much as possible." He also took a three week holiday in Indonesia in the first year of development (no Internet available). While in Indonesia, his service provider almost deleted his database (including information about everyone who bought the game) because his account ran out of money. But he managed to find a wifi on McDonalds and could fix the issue. 
  • When making the game he had a narrow scope, and had plans to add modding support and extra expansions to increase the life span of the game. When the finals version was finished, his plan was to actually make two mobile games (unrelated to Minecraft) and then make another unrelated game, and the continue developing Minecraft, "or whatever else is most requested by the community."
  • At specific points, the game was free. "The reason it's free is to get as much feedback as possible on it, so I can fix bugs and tweak gameplay as good as possible. Once the game is done, it will not be free, except in the form of a limited demo." This upset people who paid for the game, but Notch promised they would get early access to other content (1-3 weeks before other players) and of course the final game. "That's what you've really paid for"
  • A few months into the game development, Notch realized he wanted to hire an artist who could work on the textures and on the models. He also wanted to pay this artist even though he could have found someone who wanted to do it for free. This was the reason: "Some people asked me why I said I wanted to pay, and it’s primarily because I want to make sure it’s a proper business deal so there’s no drama later on. I’ve had that happen before with donated content. But also, I want people to dare charge for their work. I want to be able to do indie games for a living, and I definitely want to help support others to do the same. If someone absolutely don’t want to get paid and make awesome graphics, I can live with getting it for free. ;) And, yes, you will of course get full credits for your art. I’d own it, but I wouldn’t claim to have made it myself." But the first artist he hired would leave after a few months. "However, I went from doing Minecraft on my own to suddenly having to wait for someone else before I could move on. We had repeated problems getting anything animated to load into the game, and eventually I decided to just go ahead on my own."
  • He was experimenting with ads, both on the blog and on the Minecraft homepage but only for those who played the game for free. "In the past, I’ve been dead set on not having any ads at all, but surely there must be a reason everyone else has ads? Thus this experiment." But he realized he would remove the ads because the ads were advertising other game: "But I’m encouraging users to pay for other games, when I would rather have them pay for my game, which is the reason they come there in the first place."
  • He was live-streaming his competition in Ludum Dare live on Twitch. He was scared to develop Minecraft live, because someone could take the source code, but he was doing public play-testing of the game.
  • Minecraft had during the first Christmas a "free copy to a friend deal." During the three weeks this campaign progressed, 1436 copies were given away. Also 361 copies of the game were sold. He also got 2 donations, a total of 67.58 Euro. So it might be a good idea to be transparent with how many copies are sold of the game, because people have this psychological principle saying that they buy what's popular. When Notch married, everyone who bought the game also got a gift code of the game they could give away to someone.
  • He was experimenting with a public TODO list, so people know what's planned and what's going to happen. If he wasn't sure what to do next, he asked the community by using polls. "I put up a poll on what to do next, and posted it on irc and on twitter. Farming got 39% of the votes, so that’s what I’m doing now!" He was also asking how long the day/night cycle should be by using a poll. He was using polldaddy.com. He began using scrum when he hired more people. 
  • People could register for free and registered user #100000 got a free copy of the game and a personal email. Notice that some of those #100000 users were computer bots who registered accounts and thus not real humans. Maybe it helped to sell the game because everyone didn't know that even though he wrote about it in the blog?
  • "I like it when several small but relatively simple individual components [like fire and water] kinda gang up on you and make the game a really complex environment. There’s no need in making each component super complex."
  • It took about a year before Notch realized that Minecraft should have an endless map.
  • He was playing other computer games while developing the game. 
  • He started to sell the game a month after the first engine test.
  • He had server issues and at one point he had to give away the game for free because the server died.
  • "Basically, any developer working on the game [Minecraft] (two people at the moment) can just come up with something they’d want to add on a daytoday basis, as long as the rest of the team thinks it’s a decent idea. If it ends up being fun, it gets added."
  • January 12, 2011: one million sales. April 25, 2011: two million sales.
  • "We stepped on the plane to New York, and the Minecraft server died. While flying from New York to San Francisco, Tobias managed to get the servers back online via the amazing wonder of inflight WIFI."
  • "One reason why Minecraft has managed to get as much personality as it does it that it’s only been a couple of fairly nerdy game developers working on it."
  • They didn't analyze how players played the game: "Right now, the only way we can figure out roughly what people are doing with the game is to track logins. Once you’re logged in, we have no idea what happens."

April 28, 2017

Short April Updates - from forest fires to foam skirts

0 comments

Forest Fire

Many years ago I took a class in Differential Equations. One of the assignments was to simulate the evolution of a forest fire and the result was displayed on a graph. The problem was that you only got the end result and couldn't see how the fire evolved to get to the final result. A few years later I learned Unity, and decided to see if I could simulate a forest fire while at the same time see how it evolved. And it turned out I could.
The forest fire worked, but the visuals didn't. The first problem I had was smoke. A forest fire is large and you need a lot of smoke to cover the entire area - and that is not good from a performance perspective, and the resulting simulation was running in like 3 fps (30 fps is the goal). Luckily, both Unity and I have improved our skills.
The first thing I improved was to replace the fire particles with a glowing-ground-shader. Most of the time, you can't see the fire because of all the smoke, so by having just flat fire instead of fire particles makes no difference. I also decided to use animated smoke particles from Unity's free library of particles: Free VFX Image Sequences & Flipbooks. By using animated particles, the smoke will look more thick and you can use less particles to achieve the same result.
The second problem I had when I created the original forest fire was similar to the smoke problem: a lot of trees will decrease the performance of the simulation. To solve that problem when I created the original version was to combine all trees into a single mesh. This is also a complicated solution because it will make it much more difficult to remove the trees as they burn down. Luckily I could now replace all that code with a single shader called GPU instancing, which is something Unity recently added. If you add one of those materials to objects with the same mesh, Unity will automatically combine them, and the performance will improve. Anyway, this was the result:


Shaders

As said in the forest fire update I added an animated glow shader to simulate the fire. The reason was that I've also improved my shader skills. The first shader skill I learned was Interior Mapping, which is a technique used to simulate floors in buildings. The second technique was Parallax Mapping, which is a technique not that different from interior mapping, but you can simulate more "organic" deformations, such as this:


Tesla Simulator

I few years ago I made a Tesla Simulator to market a book I wrote about a guy called Elon Musk. It was available to the public through Unity's webplayer, which you could run directly in a browser like Chrome or Firefox. The problem now is that most browsers have stopped supporting the webplayer, so I had to make an offline version. At the same time I've cleaned up a lot of silly coding mistakes I made, because the Tesla Simulator was the first project I made in Unity - and I've apparently learned a lot since then.

"Make a boat" tutorial

One of my most popular Unity tutorial I've made is Make a realistic boat in Unity. What the tutorial didn't have was how to add foam to the boat, and I've thought a lot about what the best way is to add foam to a boat. Then I found this tweet:


...which was a cool idea on how to add foam, so I decided to implement it: Add foam. To make that work, I had to learn a technique called Convex Hull, which I wrote a separate tutorial on how to implement: Find the convex hull of random points.

April 24, 2017

Aircraft Carrier Simulator - or how to make a game in 48 hours

0 comments
Ludum Dare was on this weekend. It's a competition where you are supposed to make a game during 48 hours, and you may win fame and glory if you make a good game, so no money is involved. But people have come up with good ideas by participating in the competition, and they have later modified the game, sold it, and thus made money from it. One example is the game Broforce.

There are two different competitions going on at the same time: Jam and Compo. If you are participating in the Compo, you have to make everything yourself, including the textures, models, and sounds. Not a single piece can be found by googling. This is a however a gray-zone. Are you allowed to steal an engine sound from a YouTube video, or do you have to record it yourself? While making my game, I watched a Twitch streamer who was also participating in the competition, and he had a really hard time making sounds for his game. You could see on the stream how he squeezed a coca cola can to make a specific sound, so you have to be a little creative. I usually get my sounds from this site: Bfxr, which is a site you officially are allowed to use. I usually click a million times on the "generate-random-sound-button" until I find something useful and then I modify the sound in Audacity.

Each Ludum Dare competition has a theme. The theme this time was "A small world," so I decided to make an Aircraft Carrier Simulator. You can say that an aircraft carrier is like a small world because you can find everything you need on the ship. A few years ago I made an airport simulator for the same competition. It failed miserably, and I have hopefully improved since then.

This was my 9th Ludum Dare competition. One thing I have learned is that sleep is important. The competition begins at 3 am local time and ends 48 hours later. I have learned that sleeping until like 7 am, work the entire day until like 10 pm, and then go do something else like watching a streamer while thinking about the game until 12 pm which is bedtime, and then repeat the process the next day is the way to go. Anyway, this was the result:





The game idea is that you are in command of this aircraft carrier's aircraft operations. It's your responsibility to steer the aircraft so they can refuel, land, and launch from the catapult so the enemy is not coming closer than zero meters from the aircraft carrier. If the enemy get any closer, you fail! The more aircraft you have in the air, the more difficult it will be for the enemy to come closer. If you think it looks and sounds interesting, you can test the game (and download the source file) here: Aircraft Carrier Simulator.

March 10, 2017

Evolution of helicopters in the Vietnam War

0 comments
The Vietnam War was the first conflict where helicopters played an important role. While the future Cold War battlefield in Europe would have consisted of great tank battles, the jungles of Vietnam prevented tanks from moving efficiently. There were American tanks in the Vietnam War, but their main purpose was to keep roads clear from the enemy by using a tactic called Thunder Run, which is the same tactic that years later would be used by American tanks to capture Baghdad.

Tanks in the Vietnam War were always staying close to roads because a tank in a jungle is a big target for the enemy. But the tanks would clear jungle close to roads if needed. There's an example of a helicopter that crashed in the jungle. To rescue it, tanks on a nearby road were ordered to move through the jungle and secure the crash site. And if the enemy had built a bunker, a tank would drive up to the bunker, stick the barrel into the bunker, and fire. But again, these bunkers had to be close to roads or the tank would simply not be able to get there.    

With tanks out of the picture, the US came up with the idea to use helicopters. In the Korean War, the main purpose of the helicopter was to transport wounded to the rear two at a time. But when the Vietnam War happened, technological improvements had transformed the helicopter to a fighting machine, so they were no longer just transportation vehicles. A guy called Jim Gavin wrote an article called "Cavalry - And I don't mean horses" where his vision was that bigger, faster helicopters could carry infantry into the battle and make it a three-dimensional nightmare for an enemy commander. US decided to add helicopter transported infantry to it weapons of choice, and the recently developed Bell UH-1 Iroquois (nicknamed Huey) was chosen as the main helicopter for this unit:

The Huey

The helicopter transported infantry was sent to Vietnam. But if you've seen the movie We Were Soldiers, you know that helicopter transported infantry wasn't a three-dimensional nightmare for an enemy commander. If the enemy could cut off the few landing zones available in the Vietnamese jungle, where the helicopters could land, the infantry would be on its own. Each Huey has two machine guns operated by relatively unprotected soldiers, so the damage they could make was limited. The solders on the ground could get support in the form of artillery and air support from winged aircraft, but this support wasn't accurate enough to rescue the infantry in all situations. So something else was needed.

The Huey was a great helicopter, so someone realized that it was possible to take the basic engine and rotor, but add a new body to get a helicopter that could support the infantry. So the Bell AH-1 Cobra was quickly developed and would arrive to the Vietnam War.

The Cobra

The Cobra could kill the enemy but it couldn't find it. So someone came up with idea idea that you could combine the Cobra with the smaller, but much more agile helicopter Hughes OH-6 Cayuse (nicknamed Loach). Now you would get a so-called hunter-killer team, where the Loach was finding the enemy and the Cobra was killing it. The Loach could seat five: two pilots and three passengers. But in the Vietnam War, the Loach had either two pilots and one gunner, or one pilot, one gunner, and one mini-gun fired by the pilot. Why not four in the helicopter and a mini-gun? Because that would make it too heavy!

The Loach

One of the pilots who flew a Loach as part of a hunter-killer team in the Vietnam War was Hugh Mills. He wrote about his experiences in the book Low Level Hell - A scout pilot in the Big Red One. A helicopter scout in the Vietnam War had the following jobs:
  1. Find enemy base camps, fighting positions, supply caches, trails, and other signs of enemy movements.
  2. Assess damage made by high-altitude bombers, such as the B-52.
  3. Find landing zones for the infantry carried by the Huey helicopters.
  4. Help the infantry and tanks on the ground by giving them information, such as which terrain is the most advantageous, and if the are moving in the correct direction.

If you are a scout pilot (the hunter), the easiest way to find out where the enemy is hiding is to fly as close as possible to where you think the enemy is and hope that the enemy will fire at you. If you are fired at, then you drop smoke, so the Cobra (the killer) know where the enemy is and can fire the rockets. The result of this suicide tactic was that Mills was shot down no less than sixteen times and wounded three times.
Though I was getting shot at almost every day, I never got used to it. But getting shot at was usually the way a scout found the enemy, and finding the enemy was our basic job.

It might sound strange to sacrifice one helicopter, while the other helicopter is waiting for the scout the be shot at. But the pilot in a Loach has a better view of the surroundings, and the Loach is also a smaller helicopter making it more difficult to hit, so the tactic makes sense. To help the Loach, the Cobra was always staying within sight of it and did everything the pilot in the Loach didn't have time to do. The Loach pilot had to fly the helicopter while having his eyes constantly focused on the ground, so the Cobra read the map and transmitted radio messages.
The good scout pilot never stops talking to his gun [the Cobra] from the moment he goes down out of altitude until he comes back up again. It not only keeps the Cobra happy and informed, but it tends to keep your own guts stabilized when you're down low working and, at any instant, could catch a bellyful of AK-47 fire.

March 5, 2017

One of the greatest intellectual achievements of history

0 comments
How are you making a rope in a computer game? The most common answer to the question is: you approximate the rope with springs. This may first sound a crazy idea because you don't want a rubber band but a rope and a rope is not bouncy. But the truth is that all materials can be approximated with springs. When the famous entrepreneur Elon Musk first wanted to learn how to design rockets, he read the book Structures: Or why things don't fall down. It says:
The idea that most materials and structures, not only machinery and bridges and buildings but also trees and animals and rocks and mountains and the world itself, behave very much like springs may seem simple enough - perhaps blindingly obvious - but, from [Hooke's] diary, it is clear that to get thus far cost Hooke great mental effort and many doubts. It is perhaps one of the greatest intellectual achievements of history.

So if you know how to make a rope, you will also know how to make cloth. To make cloth, you just add more springs in other directions. This is also how Pixar is simulating hair in their animated movies: by approximating hair with springs.

I've been prototyping a helicopter game. The helicopter has a winch so it can winch people up from a stormy sea: 


It took a while to figure out how to make a realistic rope in Unity with C# code, so I've summarized it in a tutorial: How to create a swinging rope tutorial in Unity. You will learn how to make two different ropes:
...and this is the difference between the results: 

Realistic rope

Simplified rope

You should use the more realistic version if you are making a rope with low mass and the rope can collide with the surroundings. But if you increase the rope's mass in the realistic version then you have to increase the spring constant if the rope is going to keep its original length. But now you will encounter something called numerical instabilities, and you will observe how the rope is going out of control and finally "explode." Explode means here that the numbers are growing exponentially until they get so large that the computer can't handle them anymore.

So if you are making a helicopter winch where the wire is made out of metal and you have to winch heavy people out of the sea, then you need to use the more simplified version. The idea behind the simplified version is that you use one of Unity's built-in Spring Joints. If you add more or less rope, then the spring constant and damping constant have to be recalculated, and then you just add the new values to the Spring Joint. To actually add more or less rope you just change the Spring Joint's max and min distance. 

But you also need to make a curvy rope - the rope shouldn't be a straight line from the start of the winch to the basket. Now you have two alternatives:
  1. Use the ideas from the more realistic rope and add it between the start of the winch and the basket. This rope can have "fake" values to avoid numerical instabilities, while still looking as a real metal wire. 
  2. Use a Bezier curve and change the control points based on the rotation of the basket and the rotation of the helicopter. This will look like a real rope, will be fast to generate, but the most important difference is that you will never encounter numerical instabilities when generating a Bezier curve. So this solution is more robust while still looking like a real rope would look like. If you lower the altitude of the helicopter, you will get the characteristic shape of a rope falling down - the rope will bend like a real rope would:

February 26, 2017

The Complete Beginner's Guide to Helicopters

0 comments
While aircraft played an important role in both the first and second World War, you can't remember any helicopters. It's true that Germany had a reconnaissance helicopter Flettner FI 282, nicknamed the Hummingbird, which was introduced in 1942 and is considered the world's first series production helicopter. But only 24 were built and they didn't play an equally important role as the famous Spitfire or the Messerschmitt.

Why did it take so long before the world could fly around in helicopters? Isn't a helicopter as easy to design and fly as an aircraft? The answer is no! Even today it's more dangerous to be a helicopter pilot than it is to fly a normal plane: the helicopter accident rate is 30 percent higher than the accident rate for fixed-wing aircraft.

Helicopter 101
To understand why a helicopter is more complicated than an aircraft, you have to make sure you understand how an helicopter is working. Basically, a helicopter pilot has to use three controls: collective, cyclic, and pedals - and the pilot has to use all three to stabilize the helicopter.


The collective is always located to the left of the pilot and is looking like a car's handbrake. To move the helicopter up and down, the helicopter pilot is moving the collective up and down. When the collective is moved, the angle of the rotor blades are changing. A helicopter's rotor blade are working in the same way as a wing as they have the characteristic wing profile:


A wing profile is producing lift. If the angle of the wing is changing, the wing will produce more or less lift, which will move the helicopter up or down. So a helicopter is not moving up or down by changing how fast the rotor blades are rotating because that speed is always the same. As the angle is changing, the helicopter needs more or less power to rotate the blades with the same speed. In some helicopters, the pilot also has to control this power from the engine to the rotor blades, and this control is also located on the collective. If the lift from the rotor blades is higher than the mass of the helicopter, the helicopter will hover:


As the helicopter pilot is controlling the up/down movement of the helicopter with the collective, and as the power to the rotor is changing, the rotor will also produce more or less torque. To stop the helicopter from rotating because of this torque, a helicopter has a tail rotor. Some helicopters have two rotor blades, either on the same axis or after one another, to stop the torque, but most helicopters have a tail rotor. To control this torque, the pilot has two pedals, which will control the angle of the rotor blades attached to the tail rotor. In the same way as the angle of the main rotor blades produces more or less lift, if the angle of the tail rotor blades change, the helicopter will rotate around its axis.

But a helicopter can also fly in several directions, such as forward, and not just hover. If you look at a helicopter, you see something that looks like jet engines:


You might think these engines produce forward propulsion, but they are only there to rotate the helicopter blades. To fly in a certain direction, the helicopter pilot has a joystick between the legs called the cyclic. The cyclic will again control the angle of the main rotor blades, but this angle will change depending on where the rotor blades are in relation to the helicopter's body. So a helicopter pilot can control the angle of the main rotor blades by combining the collective together with the cyclic. To make this work, most helicopters have an ingenious construction called swashplate, located on the main rotor axis. This is how the swashplate is working:



From the video you can see that the main rotor is rotating forward. This will produce both a lift force and a forward force, which will make the helicopter move forward. But it will also produce a torque because the lift force is not distributed equally across the circle formed by the rotating blades, so the helicopter itself will get an angle, so it begins to lean forward:


Leaning forward is fine at certain low speeds, but at higher speeds, you want to avoid this angle. To make a helicopter fly forward without an angle, most helicopter have a horizontal stabilizer which will help the helicopter to fly straight forward at certain speeds.


Why is it difficult to fly a helicopter?
A helicopter pilot is controlling the helicopter by using the collective, cyclic, and pedals. So why is it more difficult to fly a helicopter than it is to fly an aircraft? The problem is the forces produced by the different helicopter blades. As the main rotor is rotating in different directions, the wind from the rotor blades will affect the helicopter, so to keep the helicopter in a hover position, the pilot has to make adjustments to the collective, cyclic, and pedals. It's said that a helicopter pilot has to develop a certain "feel" for the helicopter. Small deviations can be felt and seen, so corrections should be made before the helicopter actually moves. And even when flying the same model of helicopter, wind, temperature, humidity, weight, and equipment make it difficult to predict just how the helicopter will perform.

This might be confusing, so maybe a real helicopter pilot can explain it. Someone who really knows how it was to learn how to fly a helicopter is Robert Mason, who was a helicopter pilot in the Vietnam War. He has written about his experiences in the book Chickenhawk, and it includes a chapter on how he first learned to fly a helicopter:
"Next thing to do, now that you've got the cyclic down, is to let you try all the controls at once. Think you're up to that kid?"
"Yes, sir."
"Okay, you got it."
"I got it." The cyclic tugged, the collective pushed, and the pedals slapped my feet, but for a brief moment I was in complete control. I was three feet off the ground hovering in a real helicopter. A grin was forming on my sweaty face. Whoops. The illusion of control ended abruptly. As I concentrated on keeping us over one spot with the cyclic, we climbed. When I pushed the collective back down to correct, I noticed we were drifting backward, fast. I corrected by pushing forward. Now I noticed we were facing ninety degrees away from where we started. I corrected with the pedals. Each control fought me independently. I forgot about having to push the left pedal when I raised the collective. I forgot the cyclic-control lag. We whirled and grumbled in a variety of confusing directions, attitues and altitudes all at once. There were absolutely too many things to control. The IP [instructor], brave man that he was, let the ship lurch and roar and spin all over that field while I pushed the pedals, pumped the collective, and swept the cyclic around, with little effect. I felt like I had a handful of severed reins and a runaway team of horses heading for a cliff. I could not keep the machine anywhere near where I wanted it. 

February 23, 2017

How to become the MacGyver of surviving terrorist attacks

0 comments
It's true you're more likely to be fatally crushed by furniture than killed by a terrorist, but preparing for unexpected events is always a good idea. So how can you prepare for a terrorist attack? The government tells you to:
  • Be prepared by observing the emergency exits
  • React quickly and not freeze from panic
  • Make yourself a small target by hiding
  • And if everything else fails you have to fight for your life

But I don't think reading a 4-point bullet list is enough. The list says you shouldn't freeze from panic, but who's voluntarily freezing from panic? Isn't that an involuntarily decision made by your brain? Anyway, last year I read the book The Unthinkable - who survives when disaster strikes - and why by Amanda Ripley. The reason I read it was because a guy on a radio show talked about zombie attacks and he said the book would really help you prepare for the zombies. I'm not a big believer in zombie attacks, but the book doesn't mention the word zombie, and it was actually one of the best books I read during the year. 

The Unthinkable mentions several disasters, including 9/11, the sinking of the Estonia ferry, and a huge explosion in Canada. It's true you can't survive all disasters. If you were caught in one of the floors above the floors where the aircraft hit the Twin Towers, then this book will not help you. But you can maximize the probability to survive if you know what's going on in your brain when you are in the middle of a disaster.

In an emergency situation, your brain will not always help you survive. It can begin to make stupid decisions:
  • You will not accept this is happening to you. It's common to laugh, which in these situations is a form of denial: "This can't be happening to me!" Then you might get angry and then you may become quite, so mood swings are normal. But you will most likely not panic. Most people who die in disasters die from doing nothing at all and not from running around like a wet hen. In hindsight, they might think they panicked, but they only felt afraid and that is not the same thing as panic. So what you have do is to go from the denial phase to the do-something phase while remaining positive. Studies have shown that people perform better under stress if they think they can handle the situation.   
  • You will begin to gather stuff you want to take with you but you will not need. 
  • Your memory and senses will be switched on and off. This is happening at certain key points, so you may lose your vision or hearing. Remember the soldier in the reality-based Band of Brothers series who became blind during combat, but would later regain his vision when things calmed down.
  • You will forget your obligations. One person who survived 9/11 was actually in charge of evacuating the floor, but the person forgot all about it only remembered it several weeks later.
  • You will observe what other people around you are doing. This is the reason why you won't react quickly because you don't always know if you are in a terrorist attack. For example, it's easy to confuse firing guns with fireworks. If you begin to flee and it turns out to just be fireworks, then you will be laughed at and perhaps your fleeing will end up on YouTube. So you will observe what other people around you are doing, and if no-one else is doing something then neither will you. In the past, people have died because they followed the crowd, while ignoring closer exits. 
  • Your brain will freeze. The reason is you have never before been in this situation so your brain freeze while trying to figure out what to do. One person in the book who was under fire began thinking about the The Naked and the Dead, a book about soldiers in combat, because his brain was searching though its archive of experiences. This also happened when Estonia sank. One of the survivors could see how people on the top deck just sat down in chairs and where doing nothing at all instead of trying to reach the life boats, which were very close. 
  • You will come up with stupid ideas. One woman almost died from a fire because the person outside didn't want to crush the window out of fear of getting in trouble for crushing a nice window. 
  • You will follow the wrong leaders. One of the companies with most 9/11 survivors was a company with a security chief who made sure everyone knew where the emergency stairs were, and when the attacks happened everyone listened to him. But following leaders can also be the wrong decision. Firemen have seen people moving along their fire trucks towards the fire, instead of moving away from the fire because firemen are seen as leaders in a disaster.       

But your brain will also make smart decisions. Opposite from what you may first think, you will be more kind than you would have been on a normal day and you will behave orderly. During the evacuation of the towers during 9/11, people were calm and didn't run over each other on the stars on the way down. Your brain can also toughen up itself. Research shows that special forces soldiers tend to have more traumatic backgrounds, so their brains have learned something from the trauma, which makes them more capable of handling stress.   
   
So what can you do? How can you help you brain not to freeze? Remember that your brain is freezing because it doesn't have any experience from the situation. So the solution is to prepare to get experience. One police office from the book explained how his subconscious mind made better decisions than his conscious mind, so he always trusted his subconscious mind when the bullets were flying above his head. When I was in the army I recall how we had to disassemble and assemble our rifles hundreds of times until the process became unconscious. I've luckily never had to perform this process while the bullets are flying, but if you listen to the book it wasn't a waste of time.

But preparing for disasters is easier said than done. The author of the book suggests we should build amusement parks where you can prepare for disasters. Someone in Britain had the idea to install aircraft cabin simulators in airports, so passengers who are waiting for their flight could practice open emergency doors, but they idea went nowhere...

The government bullet list says you should prepare by observing where the emergency exits are. You now know why this is helpful: it will give your brain experience and it will not freeze if something is happening. This is also true when flying. Disaster experts always read the "useless" safety briefing cards because they know each aircraft is different and they know their brain will use this information if a disaster happens. They also test to exit the hotels they are visiting by using the stairs because they don't trust that someone will show them how to escape. This is important: everyone has to know what to do if a disaster happens. Remember the person who survived 9/11 and was in charge of evacuating the floor, but the person forgot all about it? So if you just have key employees in charge of the evacuation, it is not good enough.

You need to forget your experience of what has happened before. This might sound contrary to what I said above: you need experience to survive a disaster. But experience from disasters can also harm you. You may believe that many of those who died in Hurricane Katrina were poor and couldn't escape the city. But the truth is that many of those who died because they had survived previous hurricanes and thought they also would survive Katrina. So many of those who died were not poor, but old. There's also a story about a tsunami that killed people because they had locked themselves in their house because they thought the sound of the tsunami was gun shots because that's what their experience told them.  

You have to learn not only that you should do something, but also why you should do it. For example, we have all listened to flight attendants explaining what to do if the oxygen masks drop down from the ceiling of the plane. They always say you should put on your own mask before helping others. But why is it important to always put on your own mask before helping others? The answer is that in the event of a rapid decompression, your have not more than 15 seconds before you pass out. Now you understand why you have to prioritize putting on your own mask before helping others!

You have to learn how to breathe. Both FBI agents and special forces are taught how to breathe correctly to master their fear. This is how you should do it: breathe in for four counts, hold for four counts, breathe out for for counts, hold for four counts, and repeat all over again. This will help you from hyperventilating or panicking. One police office was playing a tape recording of a police siren while breathing to make it an automatic response to the siren.   

February 13, 2017

Can you design structures that last forever?

0 comments
Structures: Or Why Things Don't Fall Down by J. E. Gordon is a book about how you can design machines, buildings, boats, aircraft so they don't fall down. But the sentence "falling down" is not telling the entire story as the book will also tell you how to design structures so they don't explode. The reason I decided to read it was because Elon Musk, who is famous for building electric cars and rockets, recommended it. When he founded his rocket company SpaceX, he didn't have any experience from designing rockets, and since it's important that rockets "don't fall down," this is one of the books he read to learn how to design rockets: "It is really, really good if you want a primer on structural design."

As Elon Musk said, the book will give you a primer on structural design, so it's not a book you should read if you want to learn how to actual design so things don't fall apart. The author has included a few formulas you can use, but no examples of how to actual use the formulas. But the book is filled with interesting examples of how structures have failed and it will also give you a brief history of the area, so it's a good read in connection with a university course covering then calculation part. I would have really enjoyed reading it when I took a class on the subject a few years ago.

The area the book covers is also known as the strength of materials, and it's not the easiest of areas you can study. I would say that the area is abstract, which is why it's difficult to design structures so they don't fall down. You can't always make calculations to understand what's going on in the material until the structure has collapsed and this can take several years before it happens. This is actually one of the reasons Tesla Motor's first car, the Roadster, was delayed. The Roadster used a transmission that fell apart, not immediately, but after driving many miles. When Tesla Motors thought they had come up with a solution to the failing transmission, they had to drive it many miles to see if it really worked, so it was really time consuming to test new solutions.

I thought the most interesting parts of the book was the examples of how old structures has failed and why some didn't fail. This is an area I've had in the back of my head: if it today is difficult to design a structure so it doesn't fall down, then how difficult was it 500 years ago when they didn't have the computers engineers have today? For example, the Notre Dame Cathedral was completed in 1345 and is still in 2017 standing in Paris:

Notre Dame Cathedral by Matthew F 

The book's answer to the question what engineers back in the days knew and didn't knew is that while it might seem obvious that the medieval masons knew how to build churches, they were actually more priests and chefs than engineers. A medieval mason trusted God and a cookbook with rules of thumb when constructing buildings. The medieval castles were built with rules inherited from the Roman empire: thick walls, rounded arches, and small windows. Following rules of thumb is the way to go when you design buildings because these rules scale, so it's as easy to build a small church as it is to build a large cathedral. But trusting God didn't always work, and this is another reason why we overestimate the medieval masons. While we admire the great buildings that seem to last forever, those buildings that fell down are long forgotten, although the combination exists:

The Leaning Tower of Pisa by Saffron Blaze

So the medieval masons trusted God and rules of thumb, but what about the medieval shipbuilders? While the medieval engineers could build larger and larger churches, the ships had the same size. The reason is that you can't use the same rule of thumbs you did when you designed a small ship as you do when you build a larger ship. They probably tried to build larger ships, but they failed and are now long forgotten. But one of the failed ships that we remember is Vasa, which was a Swedish warship completed in 1628. Vasa sank on her maiden voyage because the shipbuilders deviated from the rules of thumb and their failure is now a major tourist attraction in Stockholm.

Vasa by JavierKohen

Following rules of thumb continued during the Industrial Revolution. The theory engineers use today to design structures that don't (always) fall down were developed at the same time, but rules of thumb was apparently more important than "theory." The result was: more human lives lost. In the 19th century, steamboats were racing up and down the Mississippi river. To win the race, the engineers used an "optimistic" approach to boiler design to save weight. As a result, and in one year only, 27 ships were lost as a result of boiler explosion. The author argues that the idea to ignore theory is to some extend true also today, and that "nine out of ten accidents are caused, not by more or less abstruse technical effects, but by old-fashioned human sin - often verging on plain wickedness."

Historically, we have seen that structures have fallen down because the engineers didn't use the theories we have today. So can we today design a structure that will last forever? The answer is no! The problem is that you can't take everything into account when designing a structure. Some structures are likely to be broken only by an unusual combination of events. A bridge may collapse if on a windy day, there's an unusually amount of traffic on the bridge. It may take years before one of these events happen. A structure that might seem it will last forever, is actually dangerous simply because it has never been fully tried. According to the author:
"It it is impossible, in practice, to plan for a safe life of exactly so many hours or years. We can only consider the problem in statistical terms and in the light of accumulated data and experience. We then build in whatever margin of safety seems reasonable. All the time we are working on a basis of probabilities and estimates. If we make the structure too weak we may save weight and money, but the chance of the thing breaking too soon will become unacceptable high. Contrariwise, if we make a structure so strong that, in human terms, it is likely to last forever - which is what the public would like - then it will probably be too heavy and expensive. Because we are necessarily working on an statistical basis, when we design a practical structure for a realistic life we have to accept that there is always some finite risk, however small, of premature failure."

So remember the next time you are sitting in a plane high above the sea, driving your car on the highway, or riding in an elevator, the engineer has most likely done his or her best to design the structure, but there is always some finite risk, however small, of premature failure.