Since it knew the precise positions of all the balls, it was very easy for it to pot the ball every time. This was fine for the highest level of difficulty, but for easy mode I simply gave the AI a random angular deviation to the shot.

Toward the end of the project, we got some feedback from the client that the AI was “too good.” I was puzzled by this and assumed the person wanted the expert mode to be slightly less accurate. So I changed that. But then I heard complaints about the decreased accuracy, and again that the AI was still too good.

Eventually the clients paid a visit to our offices and tried to demonstrate in person what they meant. It gradually came out that they thought the problem was actually with the “easy” mode.

They liked that the computer missed a lot of shots, but they thought that the positional play was too good. The computer always seemed to be leaving the white ball in a convenient position after its shot, either playing for safety or lining up another ball. They wanted that changed.

The problem was, there was no positional play! The eventual position of the white ball was actually completely random. The AI only calculated where the cue ball should hit the object ball in order to make that object ball go into a pocket.

It then blindly shot the cue ball toward that point with a speed proportional to the distance needed to travel, scaled by the angle, plus some fudge factor. Where the white ball went afterward was never calculated, and it quite often ended up in a pocket.

So why was it a problem? Why did they think the AI was “too good” when it was actually random?

Humans have a tendency to anthropomorphize AI opponents. We think the computer is going through a thought process just like a human would do in a similar situation.

When we see the ball end up in an advantageous position, we think the computer must have intended that to happen.

The effect is magnified here by the computer’s ability to pot a ball from any position, so for the computer, all positions are equally advantageous.

Hence, it can pot ball after ball, without having to worry about positional play. Because sinking a ball on every single shot would be impossible for a human, the player assumes that the computer is using positional play.

Design or Code?

Is this a design problem or a code problem? To a certain extent it depends on the type of game, and to what extent the AI-controlled opponents are intended to directly represent a human in the same situation as the player.

In a head-to-head game such as pool, chess, or poker, the AI decisions are very much determined at a pure code level. In a one-versus-many game, such as an FPS, there is some expectation that your opponents are generally weaker than you are.

After all, you are generally placed in a situation of being one person against countless hordes of bad guys. Other game genres, particularly racing games, pit you against a field of equal opponents. Here the expectation of realistic AI is somewhere between that of chess and the FPS examples.

The more the computer AI has to mimic the idiosyncrasies of a human player, the more the task falls to the programmer. The vast majority of the AI work in a chess game is handled by programmers. Game designers would focus more on the presentation.

In an FPS, the underlying code is generally vastly simpler than chess AI. There is path finding, some state transitions, some goals, and some basic behaviors.

The majority of the behavioral content is supplied via the game designers, generally with some form of scripting. The designers will also be responsible for coding in actions, goals, and responses that emulate the idiosyncrasies of human behavior.

Heads Up!

In some heads-up games, such as chess and pool, the computer has a huge advantage over the player. Modern chess programs such as Fritz are vastly stronger than nearly all human players.

In pool and snooker games, the computer can be programmed to never miss a shot. However, people want to play against an opponent that is well matched to their skills, and so there are generally levels of AI in the game that the player can choose from.
Advertisement

The simplest way to introduce stupidity into AI is to reduce the amount of computation that it’s allowed to perform. Chess AI generally performs billions of calculations when deciding what move to make.

The more calculations that are made (and the more time taken), then (generally) the better the computer will play. If you reduce the amount of calculations performed, the computer will be a worse player.

The problem with this approach is that it decreases the realism of the AI player. When you reduce the amount of computation, the AI will begin to make incredibly stupid mistakes — mistakes that are so stupid, no human would ever make them. The artificial nature of the game will then become apparent, which destroys the illusion of playing against a real opponent.

Remember what we are trying to accomplish: We want people to have an enjoyable experience. No matter what the game, we want the players to feel challenged so that when they win, they feel a sense of accomplishment. We want them to feel that they were playing against an opponent who was really trying to beat them.

By reducing the amount of computation, we create an AI opponent that is trying to win, but has been crippled in a way that leads to unrealistic gameplay. But does the player actually care about what is going on under the hood? What if we don’t cripple our AI, but instead let it play at full strength, but have the AI deliberately throw the game?

Throwing the Game

In sports, “throwing the game” means one side makes a series of intentional mistakes that look natural, but result in losing the game. This behavior is rightly vilified by players and fans, as the agreement is that there be a contest between two equal opponents, or at least, two opponents who are trying equally hard to win.

But in computer games, it’s impossible to have an equal match. It’s humans versus machines. One side has an advantage of being able to perform a billion calculations per second, and the other has the massively parallel human brain.

Any parity here is an illusion, and it’s that illusion that we seek to improve and maintain via the introduction of intelligent mistakes and artificial stupidity.

The computer has to throw the game in order to make it fun. When you beat the computer, it’s an illusion. The computer let you win. We just want it to let you win in a way that feels good.

AI programmers need to get used to this idea. We are manipulating the game, creating artificial stupidity, fake stupidity. But we are not predetermining the outcome of the game.

We don’t set our AI with the intent to lose the game, but rather to give the human player a reasonable chance of winning. If the human plays poorly, the AI will still win, but the player will at least feel like she came close to beating a strong opponent, and thus feel like playing one more game.

Hidden Handicapping

Computer chess expert Steven Lopez (see Resources) describes how in human versus human chess, it’s acceptable for a high-ranking player to give a much lower ranking player an advantage at the start of the game by removing some of his pieces from the board before the game begins.

When the game starts, the master player and the novice player are still playing to the height of their abilities, and yet the game is more evenly balanced. The master player does not have to play “stupid” in order to give the novice player a chance.

However, humans playing against a computer do not like to be given an advantage in this way, and prefer to play the full board against an AI opponent of approximately their skill level.

The programmers of Fritz hit upon a solution that involved the AI deliberately setting up situations that the human player could exploit (with some thought) that would allow the human to gain a positional or piece advantage. Once the human player gained the advantage, the AI would resume trying to win.

At no point here is the AI actually dumbed down. If anything, there is actually quite a bit more computation going on, and certainly more complexity.

The goal of the AI has shifted from “win the game” to “act like you are trying to win the game, but allow the human to gain a one-pawn advantage, and then try to win.” The AI needs to be more intelligent in order to appear less intelligent.

Poker AI

When I programmed the AI for Left Field’s World Series of Poker, the AI computation was basically the same for each difficultly level.

The computer would calculate the odds of winning based on the known cards, and an estimate of the opponent’s hand strength based on betting history. The odds would then be used to calculate a rate of return, which would be used to decide if they would fold, call, or raise.

There were many special case rules and exceptions, but that’s the basics. The AI players would all make the same extensive computations, running tens of thousands of simulated hands through an evaluator to calculate the rate of return.

After these calculations were performed, only then would the differentiation be performed. At that point, the best players would play their best move, and the weak AI players would make intelligent mistakes.

For weak poker AI, an intelligent mistake consists of figuring out what you should do, and then not doing it, so long as not doing it does not make you look stupid.

For example, if the human player just put in a big raise, yet you know there’s a 75 percent chance your hand is the best, then an intelligent mistake would be to fold. The odds are the AI would win, yet we are simulating a weak human player, and weak human players often fold to a large raise when they are unclear on their odds.

Conversely, weak human players often call when their chances are weak. It’s a natural thing to do and allows us to reduce the strength of the AI player, without it looking artificially stupid.

These intelligent mistakes were implemented in a probabilistic manner. The fake-stupid AI would not always fold when the human player seemed to be bluffing — it was just more likely to.

This worked very well in the highly random game of poker, because the player could never tell in any individual situation if the AI was actually making a mistake.

Since the AI was still performing its full set of millions of calculations, it never made mistakes that were inhumanly stupid, but the layer of artificial stupidity brought on by increased recklessness was enough to even the playing field and give the weak and average human players an enjoyable game.

Artificial Inaccuracy

In pool and in shooters, the computer AI is blessed with an omniscient accuracy. The shooter AI knows down to the billionth of an inch exactly where you are, and could shoot your hat off your head from five miles away. Similarly in pool, the AI knows the position of every ball and can calculate where every ball will end up before it takes a shot.

When I implemented my snooker AI, it could perfectly pot any ball off two cushions, and would almost always get a perfect break of 147 every time it played (except when it potted the white due to its lack of positional play).

It was obviously not a fun opponent to play against, so even at the highest levels, the accuracy had to be reduced, and the cushion shots had to be restricted to getting out of snookers.

Simply reducing the accuracy of the AI is not always the best way to improve gameplay. As I found with the “positional play” in snooker, random outcomes that happen to favor the computer are perceived as being intentional. If the ball ends up in a good place, or the poker AI makes a lucky call and wins on the river, it can be perceived as unfair or even cheating.

So instead of reducing the accuracy, I’d suggest, as in chess, we increase the accuracy. In order to provide an exciting and dynamic game, the AI needs to manipulate the gameplay to create situations that the player can exploit.

In pool this could mean, instead of blindly taking a shot and not caring where the cue ball ends up, the AI should deliberately fail to pot the ball and ensure that the cue ball ends up in a place where the player can make a good shot.

In a shooter, the enemy aliens should not simply randomly break from cover — they should sometimes break from cover when the player is close to them and panning toward them. They should “accidentally” throw themselves into the line of fire to make the game more interesting.

Luck of the Draw

Playing against a perfect opponent is no fun. But playing against a crippled opponent is no fun either. To create more interesting gameplay, we have to introduce the concepts of artificial stupidity and intelligent mistakes.

Intelligent mistakes seem like failings on the part of the AI, but are actually carefully calculated ways of throwing the game that make it more entertaining for the player. This does not remove the challenge, as the player still has to have a certain level of skill.

For the programmer, adding intelligent mistakes is much more complex than simply reducing the accuracy of the AI, but provides a much more rewarding experience for the player.

Resources

Liden, Lars. “Artificial Stupidity: The Art of Intentional Mistakes,” in AI Game Programming Wisdom 2, Charles River Media, 2004. http://lars.liden.cc/Publications/Downloads/2003_AIWisdom.pdf

Lopez, Steven. “Intelligent Mistakes,” Chessbase News, 2005. http://www.chessbase.com/newsdetail.asp?newsid=2579

Source:

http://www.gamasutra.com/view/feature/3947/intelligent_mistakes_how_to_.php

[Neversoft co-founder West presents a thought-provoking look at improving the believability of AI opponents in games by upping their use of "intelligent mistakes", in a piece originally written for Game Developer magazine.]

The pitch goes like this: “Learn how to easily add real-time 3D smoke, fog and other fluid simulations to your game without using up the GPU.” That’s according to an Intel Web page entitled Intel at Game Developers Conference. (The CPU is the central processing unit, or main brains of a computer; GPU stands for graphics processing unit.)

The session abstract goes on to say that the “source code to a fluid simulator optimized for multi-core CPUs…can easily be integrated by game developers into their engines to produce unique 3D effects.”

Intel’s argument raises the question, how should the CPU and GPU divvy up their tasks? In games, the CPU can handle things like physics and AI (artificial intelligence), and certain older games actually run some graphics on the CPU. Generally, however, the GPU is much more efficient (that is, faster) at handling most of the high-end effects that the gamer sees on the screen.

But there are exceptions. “Not all algorithms and processes map well to a GPU,” said Jon Peddie, president of Jon Peddie Research. “You have to have a problem that is naturally parallel, and except for the rendering of, say, a water surface and subsurface and reflections, the wave motion equations will run just fine on a CPU,” Peddie said.

Intel may also be seeking ways to make better use of its quad-core processors, according to Tom R. Halfhill, an analyst at the Microprocessor Report. But, he added: “I need to be convinced that a CPU can do those 3D effects better than a GPU can.”

Then, there’s also the Larrabee factor. Larrabee is an upcoming high-end graphics processor due late this year. “I’m sure some of it may also relate to Larrabee, which will include x86 cores, if or when it comes to market,” said Jim McGregor, an analyst at In-Stat.

(This Mythbusters demonstration at an Nvidia conference is oversimplified and self-serving but it crystallizes the difference between CPUs and GPUs.)

In another GDC session, Intel is also pushing the CPU for physics and AI: “How can your game have more accurate physics, smarter AI, more particles, and/or a faster frame-rate? By threading your game’s engine to take advantage of multi-core processors. Intel has built a threaded game engine and demo called ‘Smoke’ that shows one way of achieving this goal,” the abstract states.

It continues: “This presentation examines the Smoke architecture and how it is designed to take advantage of all CPU cores available within a system. It does this by executing different functional and data blocks in parallel to utilize all available cores.”

Intel won’t stop there. It will also focus on the bane of many PC game developers: gaming on Intel integrated graphics silicon–a relatively low-performance platform that prohibits game titles from being displayed in all their glory at higher resolutions. The session will focus on “programming for scalable graphics applications” and cover “performance considerations when programming for integrated graphics in general with specific tips for Intel Integrated graphics.”

source:
Brooke Crothers is a former editor at large at CNET News.com, and has been an editor for the Asian weekly version of the Wall Street Journal. He writes for the CNET Blog Network, and is not a current employee of CNET. Contact him at mbcrothers@gmail.com. Disclosure.

Moments later, a machine gun rings out, and you are cut down in a shower of bullets. Then, as you lie dying, you glimpse the soldier who flanked you from behind while his two buddies drew your attention.

Thankfully, it was only a video game, so in fact you’re not mortally wounded. Still, your ego might well be bruised, because you were not only outgunned but also outsmarted by artificial intelligence (AI).

The game is called F.E.A.R. , short for First Encounter Assault Recon, and its use of AI, along with its impressive graphics, are its prime attractions. The developer, Monolith Productions of Kirkland, Wash., released it in 2005 to rave reviews, including the GameSpot Web site’s Best Artificial Intelligence award. Such recognition means a lot to the game’s creators, who face stiff competition in what has become a multibillion-dollar industry.

The game is a far cry from the traditional diversions that AI researchers like ourselves have long studied, such as chess and checkers. Whereas the goal in the past was to write computer programs capable of beating expert players at such board games, now the metric of success for AI is whether it makes video games more entertaining.

Because a high fun factor is what sells, the video-game industry has become increasingly keen to make use of developments in AI research—and computer scientists have taken notice. A watershed came in 2000, when John E. Laird, a professor of engineering at the University of Michigan, and Michael van Lent, now chief scientist at Soar Technology, in Ann Arbor, Mich., published a call to arms that described commercial video games as “AI’s killer application.” Their point was that research to improve AI for such games would create spin-offs in many other spheres.

The main challenge is to make computer-generated characters—dubbed bots—act realistically. They must, of course, look good and move naturally. But, ideally, they should also be able to engage in believable conversations, plan their actions, find their way around virtual worlds, and learn from their mistakes. That is, they need to be smart.

Today many video games create only an illusion of intelligence, using a few programming tricks. But in the not-so-distant future, game bots will routinely use sophisticated AI techniques to shape their behavior. We and our colleagues in the University of Alberta GAMES (Game-playing, Analytical methods, Minimax search and Empirical Studies) research group, in Edmonton, Canada, have been working to help bring about such a revolution.

The AI of F.E.A.R. is based loosely on an automated planner called STRIPS (for STanford Research Institute Problem Solver), which Richard E. Fikes and Nils J. Nilsson, both now of Stanford University, developed way back in 1971. The general idea of STRIPS was to establish one or more goals along with a set of possible actions, each of which could be carried out only when its particular preconditions were satisfied. The planning system kept track of the physical environment and determined which actions were allowed. Carrying out one of them in turn modified the state of the environment, which therefore made other actions possible.

The designers of F.E.A.R. gave its soldiers such goals as patrolling, killing the player’s character, and taking cover to protect their own virtual lives. The makers of the game also gave each kind of bot a set of possible actions with which to accomplish each of its goals. One advantage of this approach is that it saves the developers the burden of trying to specify a response to every situation that might arise. Further, it allows seemingly intelligent behaviors to appear almost magically—such as the maneuver described above.

In that instance, the three attackers were carrying out two types of basic actions. One is to move to covered positions that are as close as possible to the player’s character. The other is simply to move around obstacles. The combination creates something that was not explicitly programmed into the game at all: a devastating flanking maneuver.

The spontaneous emergence of such complex behaviors is important because it provides a sense of deeper intelligence. That’s really what gets your heart pounding when you play the game. But you’d also like your adversaries to become more cunning over time, and F.E.A.R. has no mechanism for accomplishing that.

Why do bots need to get smarter? Imagine a game of badminton in which your opponent always reacts to your serves in the same way, always falls for your drops, and never attempts to anticipate your smashes. It would be a boring match. Up until recently, AI had been able to offer video gamers no better: the imps of Doom, released in 1993, never shoot their fireballs preemptively, and the civil-protection officers in Half‑Life 2 (2004) always take the nearest cover while reloading their weapons—to mention just a couple of things players experience with two well-known releases.

The standard solution is to add an element of randomness to the code that controls a bot’s decision making. Doing so varies a player’s experience, but the result does not necessarily come across as being intelligent.

A better approach is for the computer to learn about the player and to adapt a bot’s tactics and strategy appropriately. Of course, you don’t want the bot to become so good that it will win all the time; you just want it to give the human player a good run for the money. This capability, known as machine learning, is found in very few commercial games: Creatures, from the now-defunct Creature Labs, employed machine learning as early as 1997, as did Black & White, developed by the UK-based Lionhead Studios a few years later. But most video games are not able to “learn” on the fly or otherwise adapt to the person playing. Our group is hoping to push things forward in this regard using a system we’ve created for research purposes called PaSSAGE, which stands for Player-Specific Stories via Automatically Generated Events.

PaSSAGE, as its name implies, is all about storytelling, which has long been a staple of various role-playing games. But video games of all types rely to some extent on engaging storytelling. You can categorize such games by the way they vary their repertoire to appeal to different people.

Some games— Half-Life (2001), for example—are immensely popular even though they feature just a single linear story. So good scriptwriting can clearly go a long way. Other games, such as Star Wars: Knights of the Old Republic (2003), offer several alternatives to the main plot. This gives you the impression that you can shape your virtual fate—what psychologists call a sense of agency. That feeling of being in control is usually limited, however, because the branching plot lines often merge later on.

Titles like The Elder Scrolls IV: Oblivion (2006) and S.T.A.L.K.E.R.: Shadow of Chernobyl (2007) work similarly, taking one main story and complementing it with episodes drawn from a library of side quests. Other games, such as The Sims 2 (2005), go a step further by dispensing with a scripted plot altogether and creating an open-ended world in which players can effectively design their own happenings.

Although each of these techniques has enjoyed success, they all force the designer to make a trade-off between scriptwriter expressiveness and player agency. The approach we’ve taken with PaSSAGE avoids that conundrum by having the computer learn players’ interests and preferences and mold the story to suit them as the game progresses.

PaSSAGE uses the same game engine as Neverwinter Nights, a fantasy adventure set in medieval times, produced by BioWare of Edmonton. With PaSSAGE, scriptwriters determine only the most general arc to the story and provide a library of possible encounters the player’s character may have. The computer studies the player as he or she progresses and cues in the kinds of experiences that are most desired. For instance, if you like fighting, the game will provide ample opportunities for combat. If you prefer to amass riches, the game will conjure up ways for you to be rewarded for your actions. The software is able to make the sequence of events globally consistent by maintaining a history of the virtual world’s changing state and modifying the player’s future encounters appropriately. The game will therefore always appear to make sense, even though it unfolds quite differently for different people—or even for the same person as his moods and tastes change.

Machine learning can also be used to formulate the tactics that bots use, a job that now must be handcrafted by a game’s designers. Pieter Spronck and his colleagues, of the University of Tilburg, in the Netherlands, demonstrated this ability in 2005 using Neverwinter Nights. Spronck had one computer play against computerized opponents, programming it to get better over time by choosing the combat tactics that most often led to victory.

Members of our research group have been following through on Spronck’s work with Neverwinter Nights, using a different learning algorithm. Other colleagues of ours at the University of Alberta aim to do something similar with a multiplayer online game called Counter-Strike (2003), which pits a group of terrorists against a squad of antiterrorist commandos. Each character can be controlled either by a person or by the computer. As with F.E.A.R., players view the virtual world from the perspective of the characters they manipulate, making Counter-Strike an example of what’s known as a first-person-shooter game.

This project has so far produced a formal system for analyzing and classifying a team’s opening moves. That may not sound like much, but this task proved immensely challenging, because positions and actions are not nearly as constrained as they are in a game like chess. Researchers in our group have used this formalism to analyze computer logs of more than 50 hours of tournament-level play between seasoned Counter-Strike teams. Soon, we expect, computer bots programmed to learn tactics from such logs will play reasonably well—doing things a person might do. It’ll be a long time before these bots will be able to beat expert human players, though. But that’s not the objective, after all—they just need to make for entertaining adversaries.

Jeff Orkin and Deb Roy of MIT are undertaking a similar effort with something they call The Restaurant Game, for which they are applying machine learning to the task of making bots speak and act believably in social settings. In this case, the bots’ behaviors are based on observations gleaned from more than 10 000 sessions of human play.

Machine learning can also pay off for poker, which has become an especially hot game in recent years with the explosion of opportunities for playing it online. The strongest programs for two-player fixed-bet-size poker attempt to calculate the mathematically optimal solution for winning each hand. It turns out that finding such solutions is computationally infeasible, at least right now—there are just too many possible combinations of cards and betting sequences. But members of our research group have devised ways to calculate near-optimal strategies using certain simplifying assumptions. For example, instead of allowing four rounds of betting—which is permitted in competition poker—the program sets the limit at three. By further reducing the complexity of the game in clever ways, the computational burden can be reduced to a reasonable level. BioTools, a commercial spin-off of our research group in Edmonton, has incorporated some of our group’s work in this area in its Poker Academy software.

Although this program plays poker pretty well, it can’t yet do what is most required—spot and exploit the other player’s weaknesses. Figuring out how to program a computer to do that is extraordinarily hard. Why so? Studying an opponent should be easy, after all—and it is, but only if you have thousands of poker hands to analyze. What do you do if you have only a few? To make matters worse, human poker players make a point of changing their style so as to be hard to predict.

Right now, the best poker-playing programs to come out of our research group will make money off your average human player, and they are beginning to beat even some of the best in the world in organized competitions. This suggests that poker is just now joining the ranks of chess and checkers—games at which computers have trounced even world champions.

One lesson that computer scientists learned from working on chess and checkers is that programs must strike a balance in how they decide what move to make next. At one extreme, the computer can look all the way to the end of a game, examine every possible final position, and evaluate whether each one constitutes a win, a draw, or a loss. Then it can work backward from those possibilities, assuming best play by both sides at every stage, to select the optimal move. But searching that far ahead would take a great deal of time—for chess, enough for the sun to burn out.

The alternative is to use an evaluation function that incorporates knowledge of the game, enough to go beyond just recognizing an outright win to sense, rather, the slightest inkling of an advantage. In the ideal case, such a program would play perfectly while looking only a single move ahead. Of course, such a sophisticated evaluation would also require a lot of computational power.

In actuality, chess-playing programs operate somewhere between these two extremes. The computer typically examines all the possibilities several moves ahead and evaluates each, say, by tallying points, having assigned a different number of points to a pawn, a knight, a rook, and so forth. The computer then works backward to the current board position. The result is a ranking of all the available next moves, making it easy to pick the best one.

The trade-off between blind searching and employing specialized knowledge is a central topic in AI research. In video games, searching can be problematic because there are often vast sets of possible game states to consider and not much time and memory available to make the required calculations. One way to get around these hurdles is to work not on the actual game at hand but on a much-simplified version. Abstractions of this kind often make it practical to search far ahead through the many possible game states while assessing each of them according to some straightforward formula. If that can be done, a computer-operated character will appear as intelligent as a chess-playing program—although the bot’s seemingly deft actions will, in fact, be guided by simple brute-force calculations.

Take, for example, the problem of moving around intelligently in a virtual world—such as finding the shortest path to take from one spot to another. That’s easy enough to figure out if you can fly like a crow. But what if you’re earthbound and there are obstacles to contend with along the way?

A general algorithm for determining the best route between two points on a map has been around since the late 1960s. The problem with this scheme—known as A*—is that the amount of time the solution takes to compute scales with the size of the territory, and the domains of video games are normally quite large. So there isn’t time to calculate the optimal path in this way. In some games, the computer needs to move hundreds—or even thousands—of bots around their virtual stomping grounds without the action grinding to a crawl, which means that computation times must often be kept to just a few milliseconds per bot.

To address this issue, our research group has developed a series of pathfinding algorithms that simplify the problem. Rather than considering each of the vast number of possible positions each bot can take, these algorithms seek good paths by using coarser versions of the game map. Some of these algorithms can use a set amount of time for planning each move, no matter how vast the playing field, so they can be applied to game worlds of any size and complexity. They are also suitable for environments that change frequently, for instance when paths are blocked, bridges destroyed, doors closed, and so forth. BioWare will be using some of our group’s pathfinding algorithms in its forthcoming Dragon Age: Origins.

This same general approach can help computers master real-time strategy games, such as the Warcraft series, introduced in 1994, which was developed by Blizzard Entertainment of Irvine, Calif. In this popular genre, players control armies of game characters that work together to gather resources and battle enemies on uncharted terrain. The fast pace and large numbers of bots make these games too complex for today’s AI systems to handle, at least at a level that would challenge good human players.

Our research tries to address this problem by considering only the relatively small set of high-level strategies each player can follow, such as having your army of characters rush the opponent or expand aggressively so as to take over more territory. The computer simulates what the outcome would be, given the current state of play, if each side picked one of these strategies and kept to it for the duration of the game. By taking into account whether its human opponent is using all or just a few particular strategies, the computer can choose the counterstrategy that is most likely to succeed. This approach works better than the scripted maneuvers computers now employ in real-time strategy games when pitted against a human player.

The need for better AI in commercial video games is readily apparent—especially to the people playing them. And their thirst for more computer-generated intelligence will only continue to grow. Yet game makers rarely have the time or resources to conduct the research required to solve the many thorny problems involved, which is why they have come to recognize the value of engaging the scholarly community—a community that is hard at work in such places as Georgia Tech; Simon Fraser University, in Burnaby, B.C., Canada; the University of Teesside, in the UK; and the Technical University of Lisbon, to name but a few of the many research centers around the world involved in this kind of work.

With the increased participation of academics in game-related AI research, it will not be long before major improvements are apparent in the quality of the games entering the market. But there is a more significant reason to applaud the growing interest of AI researchers in the video-game industry—something Laird and van Lent pointed out to us and other computer scientists nearly a decade ago. The work we must do to make games feel more realistic will also take us a long way toward our ultimate goal of developing general-purpose machine intelligence. Now that sounds like a smart move.

About the Author

VADIM BULITKO, JONATHAN SCHAEFFER, and MICHAEL BURO are all part of the GAMES group at the University of Alberta, in Canada. They describe how they are using artificial intelligence to develop the next generation of interactive video games in “Bots Get Smart” [p. 48]. As its acronym suggests, their research group creates software for games, with the goal of beating—or at least seriously challenging—the human competitor. In 1994, Chinook, the team’s checkers program, became the first game software to win a championship against humans, earning it a place in Guinness World Records.

Source:
http://www.spectrum.ieee.org/dec08/7011/2

Intel demonstrated ET: Quake Wars running in basic HD (720p) resolution, which is, according to our knowledge, the first time the company was able to render the game using a standard video resolution, instead of 1024 x 1024 or 512 x 512 pixels. Seeing ETQW running in 14-29 frames per second in 1280×720 has brought up our hopes for Intel’s CPU architecture, since we do not believe that CPUs would deliver a similar performance when rasterizing graphics. For the record, the demonstration ran on a 16-core (4 socket, 4 core) Tigerton system running at 2.93 GHz.

The game itself was vastly expanded when compared to original title. Intel’s Daniel Pohl showed how the engine now shoots three million rays in all directions, enabling collision detection based on rays alone.

Also, during the conversion, some effects were integrated by default, even if they had not been planned. One of those effects was fog shadow on the floor and physically-correct refractions of water. If you ever dived into a swimming pool or sea and looked up, you could have seen that the world is distorted. Now, ET: Quake Wars has the very same effect.

An impressive part of demonstration was looking at glass surfaces. Glass now reflects the environment to the tiniest detail – no LOD trickery here. Seeing a 200-window portal was quite an impressive demonstration of a situation when you are shooting rays into the environment. Check out our gallery to get more detail on this demo.

The icing on the cake was that the game was actually demonstrated running on a 64-bit Linux operating system. Intel stated that with ray-tracing, the company now supports 32-bit and 64-bit versions of Linux and Windows operating systems. We’ll see what will happen with Mac OS X support, but that should be on the cards as well.

Source:

http://www.tgdaily.com/html_tmp/content-view-37925-113.html