May 20, 2016

How to achieve seamless infinite random terrain

I've made a prototype of an infinite terrain system for a project I'm working on. This is how it looks like:

The terrain is infinite and random, and I'm using Perlin Noise to generate it. If you are interested in making something similar then you should watch the beginning of this tutorial series: Procedural Landmass Generation.

To be able to distinct between sea, sand, land, and mountain, you have to discretize the continuous noise into squares because you can't have an endless amount of squares. So you will end up with something looking like this:

This is one so-called chunk, which the terrain is made up of. To generate an endless terrain you just add more chunks to coordinates around this square. But if you generate the noise at another position you will realize that the noise will not be the same.

In the image above I've moved the terrain left, and you can see that the bottom of the mountain now consists of 2 squares and not 3 as before the movement. Where did the last square go? The answer is that it's there but I've discretized the continuous noise at another position, so it now believe there's land where it used to be a mountain. This is how discretization looks like:

You discretize at the center of the square (the blue lines). But if you move the noise (the curve) then the noise in the same square may have changed. This is not a problem if you are generating terrain like the terrain in Minecraft where one square doesn't really depends on what's going on in the next square, so you will not notice strange seams. But if you're using an algorithm like Marching Squares to smooth the otherwise blocky terrain, then you will need to know what's going on in the next square, or you will end up with very ugly seams. To solve this mess you have to generate noise in a square with a border which is 1 longer than the original size of the chunk:

The values in the border have to be the same as if you had generated it in another of the surrounding squares. So first you are generating the noise for the center of the square, which is the same values as you generated before creating a border. Then in the right border (which is one of the borders you added), you generate noise as if you had moved the center of the square to the position of the square to the right. So in the right border you have to have the same noise as the noise in the left side (without a border) of the square to the right of the square you are generating noise for:

...and the opposite for the left side (and the top and bottom border):

And when you have generated the extra noise for the 4 borders, then you generate the mesh with the Marching Squares algorithm (or whatever algorithm you have). Finally you simply cut the extra border you added, and you will end up with a perfectly seamless endless terrain:

You can test the results here.

May 7, 2016

Making a realistic boat in Unity - Part 2

Let's say you want to make a boat float inside of your computer. There are multiple ways to make a boat float in a computer, but most of them are not realistic models. One example is that you could add a simple collider slightly above the water line, but it's still a cheat. The reason is that making an object float in a realistic way is super-difficult. When I was in engineering school I took a class in fluid dynamics and in it I learned that it can take several hours to just simulate a little bit of water around a boat. And that's too long time if you for example want to make a boat game.

But about a year ago, I found an article called Water interaction model for boats in video games. The article told how you can develop a computer model to make an object, like a boat, float in a realistic way by adding the real physics equations. This is how it works: All computer 3D models consists of triangles:

To make an object float you have to figure out which of the triangles are below the water line. If only a part of the triangle is below the water line, then you have to cut the triangle into pieces. It looks like this in Unity:

You can see that the model cuts the hull into two pieces: the yellow one which is the part of the hull that's above the water line, and the red one which is the part of the hull that's below the water line. You can also see that the model has modified the triangles that are only partly submerged by dividing them into new triangles.

When you know which triangles are below the water line, you can add the buoyancy force to make the boat float. But the buoyancy is not the only force acting on a boat. What you need is also the resistance forces. Luckily, the guy who wrote the first article published another article called Water interaction model for boats in video games: Part 2, describing the forces that you should add to make the boat behave more realistically in the water.

The forces you have to add include: viscous water resistance, pressure drag, and slamming force. But that's not enough, you also have to add the fifth force: air resistance, which is acting on the part of the boat that's above the water line. But since you now know which part of the boat is above the water line, then that force is easy to add. When you've added all five forces, the boat should behave in the water like this:

And if you don't want to figure out how to write the code yourself, I've written a tutorial on how to do it in Unity with C# code: Make a realistic boat in Unity. In the tutorial you will also learn how to make an endless ocean with waves.

May 2, 2016

How id software marketed Doom

I'm reading the book Masters of Doom: How Two Guys Created an Empire and Transformed Pop Culture, which is a biography on John Carmack and John Romero. They founded the company id Software where they created the popular games Wolfenstein, Doom, and Quake. All these games were popular, in fact so popular that the two Johns each could afford a few customized Ferraris. But why were the games so popular? One reason was that John and John (and the rest of the id Software team) were good at making games. The other reason was that they could market the games. A good game is not enough - people also have to buy it.

This is how they marketed Doom:

Word-of-mouth. First of all id Software realized that calling big papers and magazines wouldn't work. These magazines were not interested, in part because the game included violence not seen before. Instead they established a toll-free number to held orders and set up a deal with a fulfillment house that would package and send Doom to whoever ordered it. Id Software already had an audience who wanted to pre-order the game. Having a small initial audience is always good because they will talk about the game with their friends and so the game will market itself with the help of word-of-mouth.

Shareware. Id Software decided to self-publish Doom to make more money: they would make 85 cent for every dollar sold. To self-publish they decided to go shareware, so they would give away the first part of Doom for free and if a customer wanted more of the game the customer would have to pay for the rest of the game. This will increase the probability that a customer will test the game because the customer is not forced to pay for what's maybe a bad game.

Let someone else pay for the paid marketing. To distribute the shareware id Software contacted retail stores. This was before fast Internet speeds, so even though some customers downloaded the Doom for free from the Internet, all customers couldn't just download the game. Instead they had to buy it. At the time, retail stores were selling shareware and were forced to pay a royalty to the creator of the shareware because the store made money from the otherwise free shareware. But id software decided to not demand a royalty from the retail stores, telling them:
"Take Doom for nothing, keep the profit! My goal is distribution. Doom is going to be Wolfenstein on steroids, and I want it far and wide! I want you to stack Doom deep! In fact, I want you to do advertising for it too, because you're going to make money off it. So take this money that you might have given me in royalties and use it to advertise the fact that you're selling Doom."
So the retail stores would pay for all the paid marketing of the game and id Software wouldn't have to pay a single dollar for it. But id software decided to pay for one small ad in a gaming magazine - you can't get everything for free.

April 23, 2016

I've made myself a swarm

"So you've made yourself a swarm," you say. "But what's a swarm?" A swarm is an algorithm for producing natural-looking movement in large swarms of creatures. Another similar algorithm to use in similar situations is Craig Reynold's flocking algorithm. But the flocking algorithm is computationally expensive, so a swarm is a better alternative if you don't need accuracy, but a convincing organic movement of hundreds of creatures. The swarm I've made can easily run smoothly with 500 creatures.

The creatures can both run on the ground and fly, and you can include animations. When you zoom in you can see that the spiders's legs are moving and it's not decreasing the performance. If the creatures reach an obstacle they can climb (or fly a little higher), and when they reach the end of the obstacle they fall down. The climbing part is not yet that great because sometimes they will climb up but not always with the correct angle. But that's a later problem! They can also reach obstacles that can't be climbed and in that case they just turn around 180 degrees.

The creatures are running towards you, and when they reach you they slow down and begin to circle your position while trying to attack you.

It's also super-easy to reverse the roles: they hunter becomes the hunted. With a single button you can make it so the creatures disperse and run away from you.

They will also run away if they are injured, like if they touch a flame, and then die after a few seconds.

So what's the secret. First of all I got the idea from the article "Simple Swarms as an Alternative to Flocking" by Tom Scutt. You can find it in the book AI Game Programming Wisdom. But the basic idea is simple: use randomness:
  • The creatures have random top speed, which is how they spread out
  • The creatures have each a different random turn speed they can turn with
  • The creatures are using more randomness make their paths less straight and more natural-looking

Looks interesting? You can test it here: Swarm Algorithm.

April 19, 2016

Lessons learned from 10 game postmortems every developer should read

Even though computer games might look simple, they are extremely hard to design. A book I read summarized this perfectly when it described a computer game as a combination of everything. You have to be a psychologist to understand your users, you have to be an engineer to meet the technical demands, you have to be a designer to make the game pretty, you have to be an architect to design realistic environments, and so on.

A good way to improve your skills is to study what other developers have learned. I've already studied the game Antichamber: Breaking down the seven-year development of Antichamber by Alexander Bruce, and Chess: Why is Chess so popular? But now I've found an article called 10 seminal game postmortems every developer should read. It links to 10 other articles where game developers are summarizing what they learned when they developed their games. This will be a summary of the most important lessons learned:

1. Deus Ex
  • Don't give up your ideas. If there's a game you really want to make, don't give up on it. Someone will be foolish enough to give you the money eventually.
  • Follow the rules of role-playing, including: 
    • It's not fun to watch an NPC do something cool. If it's a cool thing, let the player do it.
    • If there's no need to look up and down - constantly - make a 2D game!
  • You have to be willing to change your thinking and goals. Part of the challenge of the game development process is making the tough decisions along the way, leading to many difficult junctures when you have to determine that something that can't be done right in the game shouldn't be done at all. These questions are knotty and solutions are far from obvious. To answer these questions you should:
    • Build a "proto-mission." This is the first implemented mission, playable start to finish, and it should capture everything you want your game to be. Get this mission working as early as possible, so you can see all the things you thought would work that didn't. For example, they thought the real world would be interesting as a gaming environment. But the answer was a tough-to-swallow "not very." So decided to not use the real world.
    • Have an early milestone. When you have reached this milestone you will understand the elements that really make the game work. They could go through their 500-page design document and cut everything that was extraneous, ending up with 270 pages. Less game? Not at all. What was left was the best 270 pages - the stuff that worked. If you wait until a few months to go before the ship date, it will be much more difficult to make changes.
  • By licensing technology, you will not always save time. You'd think cutting a year or more of engine-creation off a schedule would result in an earlier release date. On Deus Ex, that didn't prove to be the case. Time that would have been lost creating tools was lost instead to learning the limitations and capabilities of "foreign" technology.
  • Know your limitations. Always work within the limits of your technology rather than trying to make your technology do things it wasn't meant to do. Big budgets, lots of time, and freedom from creative constraints are seductive traps. Don't fall into them. Don't settle for less than greatness, but don't think too big. Balance should be the goal.

  • Using your own game engine is both good and bad. The engine exposed them to bugs that another team introduced (who used the same engine in their game), but it also gave them the ability to fix bugs and add new features to the engine. It allowed them to change it to support the game's specific features in ways that a general engine never could.
  • Know your limitations. They first analyzed the game engine's technological capabilities and then they decided on a design that would work with it. This process is almost mandatory when reusing an engine. Many of the times when they did deviate from this rule they had problems.
  • Finish the game on time. They focused on moving forward, and they didn't allow themselves to be bogged down because they desperately wanted to ship a game. While there are features in System Shock 2 that could have been better if they had not rushed them, they still believe that the game as a whole was made better by their resolve to finish it on time.
  • If you don't have the resources, use simple, reusable game-play elements. When you throw together many such systems, you end up with a lot of game play. They didn't have the time, resources or technology to develop the scripted cinematic sequences used by the then popular game Half-Life.
  • Keep what's working and improve the rest. As the name of the game says, System Shock 2 was a sequel, so they identified the key elements that made the first System Shock a good game and reinterpreted those elements using current technology.
  • Understand that running a business while participating in the development process of the game will be difficult. Neither of the founders started the company to be businessmen - they wanted to make a game. But you also have to make payroll, organize taxes and expense reports, and participate in business negotiations and contract disputes. So they decided to work harder, which destroyed their personal lives, even though they still devoted less time than they desired to every aspect of their work.

3. Diablo II
  • Provide a constant source of simple pleasures. Offer a steady stream of goals and accomplishments, and try to make every single action fun:
    • Players continually kill monsters and get rewarded with treasure and experience
    • There's always a quest that's almost finished, a waypoint almost reached, an experience level almost achieved, and a dungeon nearly cleared out 
    • Moving around inventory items produces pleasing sounds 
    • Monsters die in spectacular fashion, like piƱatas exploding in a shower of goodies
  • Randomness is your friend. Use randomly generated levels, monsters, and treasure. The player will more likely replay the game, but randomness also makes each player's game his or her own. They will tell their friends about what they have just done in the game, knowing for sure that their friends have not done the same thing.
  • The game should be easy to play. They used the "Mom test:" could Mom figure this out without reading a manual? Many games have different controls and key combination for all different actions when simpler is always better.
  • Make the game playable as soon as possible. Their initial priority was to get a guy moving around on the screen and hacking monsters. This is what players would be doing most of the time, so it had to be fun. For example, they realized that players would be killing large amounts of the same monsters, so they could plan for multiple death sounds and monster animations. If they hadn't experienced the core gameplay as early as they did, combat would have ended up feeling more repetitive.
  • Be the audience. You should like the game you are making. If after two years of making it (while playing it), and you are not bored to death, the game is clearly going to be a winner.
  • But randomness is also your enemy. Testing a game with randomness is not an easy task. The QA team created a web-based bug-reporting database through which they categorized and tracked all bugs, balance issues, and gameplay suggestions. In the end, this list included more than 8,300 issues and suggestions.
  • Make it easy to upgrade the game. Diablo II got criticism for having outdated graphics. When they began producing art for the game they had to use a specific graphics system. But when they released the game, the graphics was outdated. "We probably should have built in a scaling technology to take advantage of hardware that could display the same graphics at higher resolutions."

4. Thief: The Dark Project
  • Make it as easy as possible for everyone to contribute. Their goal was to create a set of tools that enabled programmers, artists, and designers to work more effectively and independently. Non-programmers should have a high degree of control over the integration of their work, without requiring the direct involvement of programmers. Designers with moderate programming skills should be able to create complex object behaviors.
  • Focus, focus, focus. Their original plan was full of features, including various multiplayer modes. But they discarded these ideas to instead focus on creating a single-player, linear, mission-based game centered exclusively around stealth.
  • Solve major problems as fast as you can. The game had problems with the AI, which was a core part of the game, but they didn't act fast enough. They had to throw away 80 percent of the AI code, and after a 12-week stretch the AI was ready for real testing.

  • When developing a sequel you are measured differently. You have to make the game better, and not just to make the same game over again. To do that you need a mechanism to quantify your previous mistakes and learn from them. If you don't figure out what you did wrong last time, you're not likely to fix it the second time around. They used post-project reviews to analyze both the strong and weak development areas of their earlier projects, and they also asked the fans what they wanted to see in the next game.
  • Use design guidelines. To make everyone work against the same goal, use a set of design guidelines, like "The player must always feel as if it is HIS actions that are making him succeed. He should feel that through his smart decisions and actions that he has solved a puzzle or battle." You can see their entire list here. But these are only guidelines - and not the law!
  • Don't forget your fans and the game after you have completed it. One of the most important things they have learned in their years in the industry is how important it is to support the fans that buy their games. This means first shipping a bug-free product, and second being completely available to help people that are having trouble with the game: on message boards, via contact emails, and everywhere else. What's the point of making games if you can't make sure people can play it - and who's better to work through technical issues than the people who made the game?

  • Do more with less. It doesn't take 50 people to create a major cross-platform software title. For example, they had no big quality assurance department because the public did the testing for them, and they listened to them as seriously as if they were coworkers on the project.

  • An update can become a real game. After the original Unreal was completed, they wanted to update the game with a multiplayer mode. But as the feature list grew and patches to Unreal were released, the add-on turned into a complete and independent game.
  • Use the community. They held polls on popular Unreal message boards to decide what to add or remove. The results of these polls were taken into consideration when the feature in question was implemented. But they also read the discussions of the fans of their lead competitor's game Quake III. 
  • Don't always use the community. The hardcore community is very vocal, but small. Designing a game to appeal to that community alone is a mistake. When they designed tutorials, they tested them on the parents and grandparents of team members to demonstrate that the tutorials were useful for attracting and keeping new players.

8. Age of Empires II: Age of Kings
  • Don't make any bold promises. Their original plan was to finish the game in a year, which failed, and it didn't make the publisher Microsoft happy. But they managed to save the day by making an expansion for the original Age of Empires. 
  • Take care of your employees. Crunch time is a period where you realize you have f*cked up so you have to work really hard (sometimes for months) to finish the project. But your social life will suffer. They solved this by scheduling crunch time well in advance at multiple points in the development process. The hours were 10 a.m. to midnight, Monday through Friday, with Wednesday nights ending at 7 p.m. so they could go home to their families. They had weekends off and meals were provided during the week.
  • Monitor your play-testers. They discovered that a play-tester had turned cheats on, playing to win not to test, in almost every game for over a month, which invalidated all the feedback from that group for the prior two months.
  • With success comes a responsibility to behave appropriately. Nothing lasts forever (the company shut down in 2008). Behaving in an exemplary manner and being friends with the industry at large is far more important than chest-beating about your current success.

9. Rainbow Six
  • A good license won't help a bad game. But it can give a good game the visibility it needs to be a breakout title. 
  • Rely on proven technology. Their external unproven solutions for rendering and networking both fell through and had to be replaced with internally developed code late in the development cycle.

  • Begin small. A core team of about six was formed, and at the start of Lionhead they worked in Peter Molyneux's own house. 
  • Take risks. At the time they started, you couldn't have done what they did. No-one knew if the graphics could run on the computers, no-one knew if the AI would work.
  • Everyone has bugs. At one point they had 3000 bugs, and for each bug they fixed, three more appeared.