December 31, 2017

Books I read in 2017

Each year I write a list of books I read during the year. This is the 2017 list:
  1. The art of game design. A book about how to design games.
  2. Masters of Doom: How Two Guys Created an Empire and Transformed Pop Culture. Is a biography on John Carmack and John Romero, who created the popular games Wolfenstein 3D, Doom, and Quake.
  3. The Unthinkable: Who Survives When Disaster Strikes - and Why. The book will tell you what's happening with your body when a disaster is happening to you. Examples of disasters in the book includes 9/11 (both what was going on in the heads of the people in the buildings and in the airplanes), Hurricane Katrina, the 2004 Tsunami, a restaurant on fire, the 2007 Virginia Tech shootings, and crowd crushes during the pilgrimage to Islam's holy places in Saudi Arabia. So how do you survive a disaster? The basic idea is that you should be prepared and learn what's going on in your body when a disaster is happening.
  4. We Were Soldiers Once...and Young: Ia Drang - The Battle That Changed the War in Vietnam. The book is describing the battle famous from the movie with the same name. If you saw the movie, you should still read the book because a lot in a Hollywood movie is different from what really happened.
  5. The new drawing on the rights side of the brain. If you can't draw pictures you should read this book. The basic idea is that those who suck at drawing are drawing objects, while those who are good at drawing are drawing shapes. The easiest way to draw shapes and not objects is to turn whatever you are drawing upside down. Now your brain won't recognize what you are seeing making it much easier to draw shapes.
  6. Structures: Or Why Things Don't Fall Down. Is a book about how you can design machines and buildings so they don't fall down. It's not a book you should read if you want to learn how to actual design so things don't break - the purpose of the book is to give an overview of the area, but it includes some formula you may use but no examples how to use the formulas. But the book is filled with interesting examples of how structures historically have failed.
  7. Helicopter flying handbook. Is a free book written by the US Department of Transportation and is a handbook written mainly for those who want to become helicopter pilots. It will tell you all about aerodynamics, flight controls, systems, performance, flight maneuvers, emergencies, how to operate a helicopter in different weather conditions, and so on.
  8. Unity 5.x Shaders and Effects Cookbook - Master the art of shader programming to bring life to your Unity projects. This book will teach you about shaders. It will not teach you everything about shaders, but if you are using it together with other shader resources you will learn a lot, including how to write a fur shader.
  9. Low level hell - A scout pilot in the Big Red One. Is a biography on and by Hugh Mills who flew a scout helicopter in the Vietnam war.
  10. Chickenhawk. Is a true story written by Robert Mason, who was a helicopter pilot in the Vietnam war. The battle dramatized in the movie We Were Soldiers was one of the battles he participated in. This book is considered being a handbook for helicopter pilots all over the world. 
  11. Troop Leader: A Tank Commander's Story. A biography on a tank commander in the battle for Europe in 1944 and 1945.
  12. Ambush Alley: The Most Extraordinary Battle of the Iraq War. Tells the story of a one-day battle in the 2003 Iraq war. If you have seen the television series Generation Kill, and remember when they are driving on a bridge and are seeing a burned out military vehicle, that vehicle was destroyed in this battle.
  13. Game Feel: A Game Designer's Guide to Virtual Sensation. Some games just feel better than other games, and this book is trying to figure out why.
  14. Guests of the Ayatollah: The First Battle in America's War With Militant Islam. Tells the story of when Iran took the American embassy as hostage.
  15. The New Science of Strong Materials or Why You Don't Fall Through the Floor. Is closely connected with the above "Structures: Or Why Things Don't Fall Down" but is more about the history of materials used in engineering applications. 
  16. The word of Notch. Is a pdf version of Notch's blog. Notch is the guy who came up with the idea behind one of the world's most popular games: Minecraft. 
  17. The Timeless Way of Building. If you have read this book you have learned a new way to think about architecture - why are some buildings "better" than other? The answer is that you should use patterns when designing a building. 
  18. A Pattern Language: Towns, Buildings, Construction. Is written by the same author as The Timeless Way of Building, but includes examples of patterns discussed in that book. I believe the guy who invented the popular game SimCity read this book and came up with the idea for that game. 
  19. John Carmack Archive - Interviews. Free book consisting of interviews with John Carmack, who created the games Doom and Quake.
  20. Why Did the Chicken Cross the World?: The Epic Saga of the Bird that Powers Civilization. Tells the history of the chicken.
  21. Rush to Glory: Formula 1 Racing's Greatest Rivalry. Tells the story of the Formula One drivers Niki Lauda and James Hunt.
  22. Pour Your Heart Into It: How Starbucks Built a Company One Cup at a Time. Is written by Howard Schultz, who bought a company called Starbucks that was selling coffee beans, and decided that Starbucks should also sell coffee drinks. 
  23. Uncommon grounds - The history of coffee and how it transformed our world. Tells the history of coffee.
  24. Color and Light: A Guide for the Realist Painter. Includes a lot of information about color and light mostly aimed for painters, but 3d artists will also find it useful. For example, the author argues that using only photos as references is not a good idea because a photo is not an accurate representation of the real world. For example, colors and shadows tend to be different in a photo, so you also have to go out into the real world.  
  25. Storey's Guide to Raising Chickens. Everything you need to know about chickens.
  26. Computational Geometry: Algorithms and Applications. A book on how to triangulate points, how to generate convex hulls, etc. 
  27. Leonardo da Vinci. Written by the same guy who wrote the official Steve Jobs biography.
  28. A Thread Across the Ocean: The Heroic Story of the Transatlantic Cable. Tells the story of the first telegraph cable from UK to USA.
  29. The Box: How the Shipping Container Made the World Smaller and the World Economy Bigger. Tells the history of the container.
  30. Shake Hands with the Devil: The Failure of Humanity in Rwanda. Tells the story, from a UN perspective, of the 1994 civil war in Rwanda.
  31. The Path Between the Seas: The Creation of the Panama Canal, 1870-1914. As the title says, it tells the story of the construction of the canal between the Pacific and the Atlantic ocean.

December 21, 2017

Computational Geometry - Part 2

As said before, I've spent some time learning an area called Computational Geometry. This area is big (and some algorithms tend to be complicated) so I've still not learned everything. In this part I've studied algorithms that will cut polygons in different ways.

Sutherland-Hodgman. You can use the Sutherland–Hodgman algorithm if you have a polygon and you want to cut away the parts of that polygon that doesn't intersect with another convex polygon. The polygon you want to cut doesn't have to be convex. The result is the intersection between the polygons:

Greiner-Hormann. The Sutherland-Hodgman algorithm was kinda limited - it could only find the intersection of two polygons and one of the polygons had to be convex. It can be easily modified if you need the outside of the intersections, but the result is not optimal. If you have concave polygons (or convex or one of each) and you want do do other types of so-called boolean operations on the polygons, then you need another algorithm. One such algorithm is the Greiner-Hormann algorithm.





That's it for now. Next up on the study-list is boolean operations on meshes. You can use one of the above algorithms if you want to do boolean operations on meshes, but better algorithms exist.

November 16, 2017

Computational Geometry - Part 1

I've spent some time studying an area called Computational Geometry, which according to Wikipedia is "a branch of computer science devoted to the study of algorithms which can be stated in terms of geometry." Examples include: Are two lines intersecting? How can you triangulate random points? If you are interested in the area, the best book I found was Computational Geometry: Algorithms and Applications. The algorithms I've studied are:

Find the convex hull of random points. If you have some points and you want to find the smallest possible area that includes these points, then you need to find the convex hull of those points.

Triangulate polygons. If you have a convex polygon or a concave polygon, how can you triangulate them? 

Triangulate points. If you have random points, how can you triangulate those?

Delaunay triangulation. If you look at the images above, the triangles look kinda odd. To improve the triangulation you can use an algorithm called Delaunay triangulation.

Voronoi diagram. If you run a stores in different cities, then you can create a Voronoi diagram to find out where those customers live that live the closest to a specific store.

That's it for part 1. Next part will include boolean operations on polygons!

November 11, 2017

Books about engineering you can read on the beach

Engineering is fun and it's also fun to read about other engineers so you can learn something from their mistakes and find inspiration. Engineering is also about math, physics, etc, but this is a collection of books without any math that you can read on the beach. So leave your calculator behind!

A Thread Across the Ocean: The Heroic Story of the Transatlantic Cable. One of the big engineering projects that took place in the 1800's was to connect Europe with America by dragging a 2500 tonnes heavy telegraph cable from one continent to the next. If that was possible, it would take just a minute to send information between the continents, compared to the weeks it took to send the same information with a ship. How this was possible is explained in the book.

Structures: Or Why Things Don't Fall Down. I've always been fascinated by those engineers who worked without calculators. How could they build a ship like Titanic without computers? This book will tell you the history of how to engineer buildings, bridges, ships, and much more.

Fermat's Enigma: The Epic Quest to Solve the World's Greatest Mathematical Problem. Math and engineering are deeply connected. This book will tell you the story of when one guy tried to prove Fermat's last theorem. It will also tell you the history of mathematics.

Clouds of Glory: The Life and Legend of Robert E. Lee. This book tells the story of one of the famous generals from the American Civil War. But little is known that Robert E. Lee was also an engineer, which is maybe the reason he was successful as a general? The book includes a lot about the war, but also about the engineering challenges to build a fort and change the flow of a river.

Wizard: The Life and Times of Nikola Tesla: Biography of a Genius. Nikola Tesla was a famous inventor, and one of Elon Musk's role models, but the problem was that he never made money from his inventions so he died poor. This book will teach you why great engineering is not the end goal - make money is always the goal.

The Martian. What if you are on Mars, then an accident happens which forces your team to leave you behind, so you have to survive with what you have until someone can rescue you? This is of course a made up story, but the author worked as an engineer before he began writing books so the book is realistic.

Alan Turing: The Enigma. One of the great engineering challenges during the Second World War was to break the German codes. He wasn't alone, but one of the persons who accomplished this was Alan Turing, and this is the best biography on him.

Moon Lander: How We Developed the Apollo Lunar Module. It might have been difficult to drag a telegraph cable across the Atlantic Ocean without the help of computers, but what if you want to land on the Moon with only primitive computers? This book is written by the engineer who was responsible for designing the vehicle that actually landed on the Moon, so you will learn all about it.

The Quest for Artificial Intelligence. Artificial Intelligence or smart computers are becoming an increasingly larger part of our life, such as self-driving cars. The area is actually not new, people have always tried to build smart machines, and this book will tell you all about it.

The Innovators: How a Group of Hackers, Geniuses, and Geeks Created the Digital Revolution. This book will tell you the history of the computer - from the first attempt to build a calculator up to the guys who designed Google. It is written by the same author who wrote the best Steve Jobs biography, so you should read both!

The Boy Who Harnessed the Wind: Creating Currents of Electricity and Hope. What if you grew up in a poor place in Africa and decided you wanted to help the community to get electricity. This book will tell you how William Kamkwamba built a wind turbine from scrap.

Skunk Works: A Personal Memoir of My Years at Lockheed. One of the most recognizable planes is the F-117 which was the first plane that was hard to detect on a radar - a so called stealth fighter. This book is written by one of the engineers who built that plane and other innovative aircraft at the company Skunk Works.

Masters of Doom: How Two Guys Created an Empire and Transformed Pop Culture. One of the most famous computer games is Doom, and this book will tell you the story of how Doom was created.

The Box: How the Shipping Container Made the World Smaller and the World Economy Bigger. This book will tell you the history of the container, so it's actually a book on logistics. But it's also a book on product development, and entrepreneurship because it turned out that it was businesses that decided to begin using the container before the governments began to use it for military purposes during the Vietnam War.

The Path Between the Seas: The Creation of the Panama Canal, 1870-1914. One of the great projects during the turn of the twentieth century was the construction of the Panama Canal. The first attempt made by the French failed because they ran out of money and because they forgot to take the human factor into account. Yes it wasn't easy to build the canal from a technical point of view, but it was even more difficult to keep the humans who were building the canal free from illnesses like malaria, so the workers (and managers) died in the thousands. There's also a great quote that says: "Engineers are sometimes the least practical of men, they may be attracted by difficulties." 

Nothing Like It in the World: The Men Who Built the Transcontinental Railroad, 1863-1869. Before the Panama Canal was built, it took 6 months to travel from the US east coast to the west coast. To shorten the time to just seven days they decided to build a railway connecting the west with the east. This books tells the story how they did that.

Inside the Third Reich. Is written by the architect Albert Speer who at age 28 found himself responsible for redesigning Berlin and during the Second World War responsible for the industrial production. The book answers the question how Germany, despite being bombed, could build tanks.

Boyd: The Fighter Pilot Who Changed the Art of War. Tells the Story of John Boyd who began his career as a fighter pilot and ended it as an engineer. Most aircraft engineers are not pilots, but Boyd could use his practical experience to develop aircraft in a way those without any pilot experience couldn't. This book will also give you an idea about the political struggles going on when building stuff for the government.

Predator: The Secret Origins of the Drone Revolution. Tells the history of the most famous military drone. How did they design it to fly for +24 hours without refueling, how can you control it from a container in United States while the drone is flying above Afghanistan, and how can you fire missiles from it?

Humble Pi: A Comedy of Maths Errors. Consists of several examples of where minor mathematical errors have resulted in big and small consequences. For example, ground crew confused the units of measurement when they put fuel in an aircraft, so the aircraft ran out of fuel and almost crashed (the fuel gauges were also broken).

Disney's Land: Walt Disney and the Invention of the Amusement Park That Changed the World. Tells the story of how Disneyland was designed and constructed in less than a year.

The Devil in the White City: Murder, Magic, and Madness at the Fair That Changed America. Tells the story of the 1893 Chicago World's Fair: how it was designed, constructed, and operated, including the story of the world's first Ferris wheel. Every other chapter in the book also tells the story of a mass murderer who killed visitors to the fair.

Thunderstruck. Written by the same author as "The Devil in the White City", this book is also two stories in one book. The first story is about Guglielmo Marconi's struggles to design the wireless telegraph, and the second story is about a murder that took place in London.   

Architects of Intelligence: The Truth About AI from the People Building It. When will we get truly intelligence machines which are smarter than us humans? The author of this book has asked this question to several researchers within the Artificial Intelligence field. So if you read this book you will not just learn what one person says, but what several researchers are saying, so you will get a really broad overview of the latest research within AI.

And finally some shameless self-promotion. If you have read all books about engineering you should also read my book about engineering, which is a biography on Elon Musk: The Engineer: Follow Elon Musk on a journey from South Africa to Mars.

November 4, 2017

Would Leonardo da Vinci have streamed his work online?

Television is 20th century technology and the new way to consume entertainment is to watch streamers on services like Twitch. A streamer is someone who is showing him/herself through a web camera while the person is doing something like playing a game, drawing a picture, or even looking for zebras in South Africa. Why? Traditional television has a broader audience, so the television shows tend to become kinda dull. Watching a stream on Twitch is more personal and you can even interact with the person through a chat. Streamers are also calming background noise, and I was listening to an art streamer while writing this article.

But watching someone else doing art is not something new. I've recently read a biography on Leonardo Da Vinci, written by Walter Isaacson - the same author who wrote the official Steve Jobs biography. He has also written a biography on Albert Einstein, and I've read all three of those books. In the book on Leonardo da Vinci, it's revealed that people were watching him when he was doing art, while he was saying "Drawing in company is much better than alone."
When Leonardo da Vinci was painting The Last Supper, spectators would visit and sit quietly just so they could watch him work. The creation of art, like the discussion of science, had become at times a public event. According to the account of a priest, Leonardo would "come here in the early hours of the morning and mount the scaffolding," and then "remain there brush in hand from sunrise to sunset, forgetting to eat and drink, painting continually." On other days, however, nothing would be painted. "He would remain in front of it for one or two hours and contemplate it in solitude, examining and criticizing to himself the figures he had created." Then there were dramatic days that combines his obsessiveness and his penchant for procrastination. As if caught by whim or passion, he would arrive suddenly in the middle of the day, "climb the scaffolding, seize a brush, apply a brush stroke or two to one of the figures, and suddenly depart."

Here are some other lessons learned from the book on Leonardo da Vinci:
  • You have to observe the real world and this is more important than learning from someone else:
    • If you look around you, you will not see any sharp lines, so why should you paint using sharp lines? "Paint so that a smokey finish can be seen, rather than contours and profiles that are distinct and crude."
    • Use shadows, not lines, and this is the secret to modeling 3d objects on a 2d surface. Leonardo da Vinci spent more time studying shadows (and thus light) than he did on any other artistic topic.   
    • Leonardo da Vinci took this one step further by dissecting human bodies to really learn how to make better paintings. Art and science is interwoven. If you paint someone, you should begin with the skeleton, then the skin, and finally add the clothing.
    • Study the movement of bodies. Many say that Leonardo da Vinci's characters are moving, and he said that "movements should announce the motions of the mind." If he met someone on the street with an appearance he wanted to study closer, he invited the person over for supper. 
    • To remember all observations, he always brought a notebook with him. In these books he wrote what he observed and what he wanted to observe, such as "Describe the tongue of the woodpecker."
  • He failed a lot. In some cases it could take 20 years before he finished a painting, and in some cases he never finished a painting he was working on. Leonardo da Vinci wanted is art to be flawless, so he could never finish them because they were so complicated if you took the lighting into account. In one case he had to dissect a body to learn how a muscle worked before he was satisfied with the painting.
  • Combine fantasy with observation. Leonardo da Vinci is famous for coming up with futuristic machines, like helicopters and tanks. But it turned out most of these machines were not meant to function because he created those machines for theatrical plays. If you want to draw a dragon, it's easier to combine parts from other animals, like the head from a dog, the eyes from a cat, the ears from a pig, and so on.
  • Procrastinate is not always bad. Leonardo da Vinci was having a discussion on how creativity occurs. Sometimes it requires going slowly, pausing, even procrastinating. "Men of lofty genius sometimes accomplish the most when they work least for their minds are occupied with their ideas and the perfection of their conceptions, to which they afterwards give form."

October 1, 2017

Evil pumpkins - or how to simulate subsurface scattering

If you are making a game, it's really important that the game looks good and that the game runs as fast as possible on the computer. It's often difficult to achieve both good looks and speed, so you have to cheat by using various tricks. One of the cheats I read about was how to achieve fast subsurface scattering in Unity. The idea behind subsurface scattering is that light tends to shine through some materials. For example, if you are holding up your hand against a strong light source, you will see that some of the light shines through you the edges of your fingers. To implement this effect I decided to make a Halloween pumpkin.

I began by making a pumpkin sculpture in Blender.

Making a sculpture in a 3D software is not that far from using physical clay. This is why the technique has become popular because it's easier to model something in clay than by adding triangles one after the other. The most popular sculpt software is ZBrush, but Blender has a sculpt part which is also working fine. The problem with a sculpture is that it consists of far too many triangles so it will fail if you put it in a game:

The solutions is that we once again have to cheat by making a less complicated model on the top of the more complicated model. This process is called retopo. The less complicated version looks like this:

But this less complicated version is kinda ugly. To make it look better we can use the more complicated version and "bake" normals and ambient occlusion, which is again a cheat to make an ugly model look better:

...and now it's just a matter of adding the subsurface scattering materials to the pumpkin, and it will look like this:

July 24, 2017

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

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?

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

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: