APOCALYX is a...

free Game Engine based on OpenGL (MAIL) (SITE) (FORUM) (BLOG)
Showing posts with label AI. Show all posts
Showing posts with label AI. Show all posts

Friday, September 12, 2008

Spore prototypes


As you know, the long waited Will Wright's Spore game is on the shelves. There are quite different reviews about Spore, but I think that a game designed by the author of SimCity ans The Sims can't be so bad.

Anyway, I'm not interested in the game itself, but in its development prototypes that are available for free and learn a lot about the step moved towards the real thing.
In particular I'm interested in their interfaces, for example that of the Space prototype, the screenshot of which you can see in this post.


Here is the news release of the Spore prototypes from EA.

Play with our Prototypes
Spore has been a huge undertaking. Along the way we ended up exploring countless design directions in gameplay, simulation and user interface. One of the ways in which we explore possible design directions is by building simple, playable prototypes that we can play around with to get a sense for a particular system. Usually these prototypes are never seen by the public, but we thought some of the more intrepid players out there might enjoy playing around with a few of our early Spore prototypes. Keep in mind these are not tested, supported or even easily explained.

Tuesday, August 26, 2008

Game AI book

Some time ago I listed several papers related to Artificial Intelligence that made use of GUN-TACTYX as the main testing application of their thesis (read the post).
I forgot to mention that also a whole book, devoted to AI applications in computer games, had based its examples on an old version of APOCALYX. The book, published in 2004, describes several AI techniques useful to make the behavior of NPC more believable. The book is "Programming Believable Characters For Computer Games" and includes a lot of examples based on a VC++ version of one of the first releases of APOCALYX.
The author, Penny Baillie-de Byl, says: "Computer games have evolved from simple, little programs to major Hollywood-type productions. And today's player expectations have kept pace with this evolution - they expect truly believable gaming environments with complex stories, characters, and action. To achieve this quality, developers need to incorporate the most cutting-edge tools and techniques available. Programming Believable Characters for Computer Games is written to provide such a resource. It takes current research in artificial intelligence and games and presents both the concepts and architectures through practical programming examples. The book focuses on the higher-level AI needed to develop interesting and believable, non-player characters that can learn and express emotions. With an emphasis on pathfinding, decision trees, finite-state machines, rule-based systems, and goal-oriented action planning, it addresses the current topics in game development. Throughout the book, programmers work through the step-by-step creation of a 3D animated autonomous character. Each chapter covers the theory of the topic and then applies it through practical hands-on exercises. The creation process works from design, modeling, and animation to the development of the artificial brain, which includes techniques for learning, socializing, communicating, navigating, and adapting to its environment. This is a comprehensive resource that brings current games research into the hands of programmers."

Saturday, August 23, 2008

MekaWars' harvesters

Today MekaWars moved a further step forward: the pilots can see the environment and the objects around them, in fact the algorithms to manage a radar and a detector device were finally implemented in the simulator.
The radar is useful to detect enemy vehicles and obstacles, like asteroids, while the detector is necessary to find the resources flying freely all around in empty space.

In the screenshot, that depicts the usual schematic 2D top view, you can see asteroids (yellow dots), two fighters (red dots) and two harvesters (green dots). All the other small cyan and orange dots represent two different kind of resources.
In the sample script, the fighters are instructed to avoid asteroids and other vehicles. To accomplish that task they use the radar and move away from the trajectories of the flying obstacles. In the same script (an if-then selection tests the kind of vehicle and chooses which section of the code must be executed), the harvester is programmed to use the detector and find any nearby resources of the requested kind, then directs the engine towards that resource to collect it. In the picture, there are just two harversters that move towards their nearest assigned targets.
The next step? To give the pilots some missiles and torpedos to shoot. Stay tuned!

Friday, August 22, 2008

MekaWars' pilots

The MekaWars' pilots move their first steps or, better, fly their first flights. As already explained in an old post (read it), in a programming-game like MekaWars, the bots' AI is written in Lua and executed in a sandbox, that is a protected environment where the player's code is executed without affecting in dangerous ways the computer, or the execution of the simulator, or other players' code.

As you can see in the screenshot (always taken from the current simple radar-screen-like viewer), a very short script can already control the vehicle on which the pilot is loaded. In this case, the pilot sets the speed at 75 m/s and every 5 second changes direction by 90 degrees.
The simulator answers to those commands accelerating the vehicle to the requested speed and rotating the direction when necessary. There are also other behaviors managed automatically by the simulator. For example, when a vehicle hits an asteroid, it bounces, but the direction is again rotated, according to the maximum speed of the vehicle, to match the requested direction. Then, after several collisions, the vehicle is so damaged that it explodes and the pilot is lost in space... but this is another story.
Stay tuned for more developments in the structure of the simulator and more complex pilots' behaviors.

Thursday, May 15, 2008

GUN TACTYX at school

I have discovered, from time to time, that GUN TACTYX has been used in universities for researches in the field of artificial intelligence. When I developed the game, I had in mind CROBOTS, a game where several robots fight firing missile in a simplified arena. The AI of the robots is driven by algorithms written by the players: the best script wins. A version that is easier to play on modern machines is my JROBOTS. There C-like scripts are replaced by Java classes and the challenges are executed on-line, thanks to Java applets.
GUN TACTYX is more complex to master than JROBOTS, because the enviroments is more complex, but this is not a problem for researches on AI, because a complex environment is preferred.
This is the reason why you can find papers that cite, or even are based, on GUN TACTYX. Here is a list of some that I've found. The first 2 comes from the Universidade de São Paulo in Brazil and the last from Bournemouth University in UK.

Thursday, May 1, 2008

Steering behaviors

Recently I have described some of the open source libraries included in APOCALYX. This is the time of “OpenSteer”, a library originally developed by Sony that implements steering behaviors for autonomous characters.
At this point you may ask what these steering behaviors are. Do you need to move your characters on the scene in particular ways? This library includes the necessary functions to make your models act in a believable fashion. Starting from the concept of an abstract vehicle, “OpenSteer” defines functions to make those vehicles move in flocks with cohesion, separation or speed matching rules, follow a given path avoiding fixed obstacles or other moving characters, perform pursuit or evasion and more complex behaviors combining different effects.
Imagine to move a platoon of soldiers in a terrain full of obstacles following their chief, or consider a flock of birds or a group of fishes in the background of your level, or people along a road walking in two opposite directions. In all these cases, expecially the last, we want to avoid collisions or wrong interpenetrations. “OpenSteer” does all the necessary computations for you.
Among the demos of the engine, you can find one in DemoPack1 that shows how to drive two columns of armored knights along a path in opposite directions. It’s amusing to see how, in some situations, a group of warriors opens in a believable way to let in a single warrior, avoiding a dangerous collision (or, better, avoinding an unbelievable pass-through). Good flocking!

Thursday, April 24, 2008

Soccer mode in GUN TACTYX

The few core players of GUN TACTYX remember for sure the interesting soccer mode of the game. In soccer mode, Wrokdam, the cyborg whose brain is programmed by the players, does not shoot bullets or grenades, but runs on a field and hits a ball towards the enemy goal, so… it plays soccer.
Only a few players succeeded in developing interesting teams tailored for soccer mode. Those teams were mainly RobyBaggio, VanHimst, Zidane2x2. It’s amusing to see those strange cyborgs follow the ball to push it, but also it’s surprising to see the intelligent-like behaviors programmed in a few script lines.
Now I have found some good MDL models performing soccer players (see the picture above) taken from the “International Online Soccer” MOD for Half-Life 1. I’ve asked for permission to use that model in my game, so it’s not impossible that even GUN TACTYX 2 is going to include a soccer mode. Start to tune your soccer tactics!

In the picture, the “RobyBaggio” team of
Wrokdam players is going to score a goal.

Tuesday, April 15, 2008

The Lua sandbox

In a game like GUN TACTYX, where the players write directly the AI code that manages the behavior of their team of bots, it's important to verify that no malicious code is possible (or no player will load other players' code on his computer).
It's a situation similar to the execution of JAVA applets in a browser: we don't want that any applet can write arbitrary data to our hard disk (e.g. a virus), so applets are confined in a so called sandbox.
Another requirement is the complete control over the code execution, so a scheduler can share correctly the time among different teams, and also the control over the memory allocation, so no team can use too much memory.
In the old version of GUN TACTYX, all these requirements were realized in the interpreter of SMALL scripts, but that language had several disadvantages. In the next release instead, the language that controls the bots is our beloved Lua. In fact, I have created a LuaScript class: it implements a Lua interpreter that includes a memory allocation manager and an execution scheduler.
Imagine two platoons of a dozen soldiers each, controlled by their own AI script written by the players: that is going to be GUN TACTYX 2.