A Motion Planning Based Video Game∗

Guillaume Bottesi, Jean-Paul Laumond and Sara FleuryLAAS-CNRS

7 Avenue du Colonel Roche, 31077 Toulouse, France

Abstract— This paper aims at showing how robot motionplanning techniques are today mature enough to be usedin video game. The key challenge with games is to respectconstraints expressed in terms of interactivity, real-timecomputation and space-memory. The goal of this work wasto provide an original video game implementing a scenariothat would not have been imaginable with the common AImethods used in game design.

Index Terms— Motion Planning, Probabilistic Roadmaps,Video Game.

I. I NTRODUCTION

Robot motion planning is an active research area [20].Beyond Robotics, applications include today domains asvarious as Computer Graphics, Bio-engineering or ProductLifecycle Management [21]. This paper aims at demon-strating the potentiality of recent motion planning pro-gresses for the design of video games.

Computer game design stimulates a lot of research inArtificial Intelligence [34], [10] and beyond (see [11],[39], [32] for overviews of the various facets of this richarea). Among computer games, video games integrate 3Dvirtual environments with impressive image and motionrendering. As spatial cognition is concerned automatedmotion planning can play a critical role by providingcomputers with advanced capacities in controlling artifactmotions.

Such a potentiality has been recently noticed in [29].However there is today no game that takes advantage ofthe recent motion planning algorithms.

To demonstrate the added value of motion planningmachinery, the main challenge is:

• to face the constraints specific to video games (inter-activity, real-time computation, small space memoryconsumption), and

• to find a truly demonstrative scenario, i.e. a scenariothat can not be addressed by the common used ap-proaches.

Of course, the game we propose here does not pretendto enter into competition with marketed video games. Itmainly aims at proving that the computation of complex3D collision-free motions can be done in a time compati-ble with dynamic environments and with the interactivityrequired by video games. Another interest of this gamepresentation is to focus on the design issues that deal withmotion planning algorithm integration.

∗This work is partially supported by the IST-2001-39250 Movie projectfrom the European Community

The following section states the motion planning prob-lem in the framework of video games. Section III presentsthe scenario of the game: from a motion planning perspec-tive, programming this game requires to account for 3Dobstacle avoidance, dynamic environments, highly clutteredspaces and articulated systems with high dimension. Thenwe see (Section IV) how the probabilistic motion planningframework provides a set of tools that can be exploitedand combined to face all the constraints of the game. Thesolution consists in compressing all the possible motionsfor the computer controlled artifact in an optimized datastructure (visibility roadmap). Such a data structure isautomatically computed in an off-line phase. It allows faston-line computations. Section V presents complementarytechniques (mainly inverse kinematics) required by the pro-posed scenario. Section VI addresses the implementationand performance issues as well as graphics effects.

II. M OTION PLANNING AND V IDEO GAMES

A. Discrete versus continuous motion control

In its standard version the inputs of a motion planningproblem are:

• an environment cluttered with obstacles to be avoided,• an artifact to be moved under kinematics constraints,

and• a starting configuration and a goal to be reached.

The output should be a collision-free path that respects allthe constraints (Figure 1). As stated is such general terms,motion planning is a continuous problem: it deals with thecomputation of sometopologicalspace properties (mainlyconnectivity properties). To make the story short, becausea computer only manipulates discrete data structures (e.g.graphs), solving the problem by computation requires totransform its continuous dimension into a combinatorialone.

Two types of artifacts are generally involved in videogames: the user controlled entities and the computer con-trolled ones. In real-time strategy games, the user controlledentities do not require any planning computer capabilities.The player can just be helped by a real-time collision-checker that prevents obstacle traversal. Providing com-puter controlled entities with motion autonomy is morecomplex. Two traditional approaches are considered:

• in the design phase, the designer first creates all thepossible motions for the computer controlled artifacts.The approach allows to make use of complex motion

Inputs: an environment and a 6 dof mechanical system, astarting configuration and a goal to be reached.

Output: a collision-free admissible motion.

Fig. 1. The motion planning problem.

libraries (e.g. motion capture based motions) andmotion effects may be highly eye-convincing. Allthe motion sequences are fixed. They are organizedinto a finite graph of behaviors. In this perspectivethe continuous dimension of the motion planningproblem is ignored: the game appears as a (possiblycomplex) sequence of recorded motions. This limitsthe behaviors of the computer-controlled artifacts.

• another technique consists in laying a grid on theenvironment. The obstacles are matched onto thegrid. Motion planning is then performed by a gridsearch algorithm. The approach captures the spatialdimension of the games better than the previous one.Nevertheless it is limited to 2D problems (i.e. motionson a surface) or 3D ones in few cases.

The so-called ”spatial or motion intelligence” of the com-puter controlled entities is then reduced to the use of A∗-like search algorithms using more or less sophisticatedheuristics. Because the space is poorly modeled, the po-tential of these techniques is limited.

Modern techniques developed in motion planning are notyet popular in game design community. The main reason isthat video games impose some specific constraints whichare challenging for motion planning algorithms.

B. Video game constraints

As artifact motion is concerned, video games imposevarious constraints (e.g., the computed motions should berealistic and convincing). Among them we have selectedfour types of constraints which are covered by the proposedgame:

• interactivity is the first criteria to be addressed. Theplayer performs actions in the game environment andthe scenario should integrate them. From a motionplanning perspective, accounting for dynamic environ-ments is the key issue.

• real-time computation is a corollary of the inter-activity constraint. The motions must be computedvery quickly within time cycles compatible with theanimation cycles that fix the liveliness of the game.The issues here deal with the performance of themotion planning algorithms as well as on softwaredevelopment and integration.

• computer memory is not unlimited. Most of the com-puter power is dedicated to image rendering. Anyvalue added by a new function should be evaluatedwith respect to the space memory it requires. There-fore any new motion planning solution must be cheapin terms of space memory.

• game difficulty should be perceived. Computer con-trolled artifact motions should give the player theillusion of computer ”intelligence”. To go beyond thecurrent state of the art of the available game technol-ogy (see above), scenarios should consider articulatedsystems, 3D environments and highly cluttered space.

The scenario below integrates all these four constraints1.

III. G AME SCENARIO: THE MOSQUITO AGAINST THE

OCTOPUS

For some reasons explained in the online presentation ofthe game, a mosquito should kill an octopus by stinging itat five different places (five pimples lying on the octopusbody). Of course the octopus tries to prevent mosquito ap-proaches: its four (not eight. . . ) tentacles are equipped withboxing gloves (Figures 2 and 3). The environment is anundersea cave cluttered with rocks. The player controls the3D motions of the mosquito (velocity, pan and tilt controls)while the octopus motions are automatically computed withthe objective to touch the mosquito with one of the fourboxing gloves.

The octopus appears as a set of articulated bodies. Theroot corresponds to the main body of the octopus that

1Other scenarios have been experienced such a human being walkinga set of rooms populated with numerous computer controlled objects tocatch, in a dynamic environment of doors randomly closed and opened.Nevertheless, even if the related motion planning problems were difficult,there was no evidence that such problems would have not be solved byan experienced game developer with standard grid techniques.

moves in translation in a small box. The tentacles can beviewed as robot manipulators with 7 degrees of freedomeach (3 for the ”shoulder”, 1 for the ”elbow” and 3 forthe ”fist”). The total number of degrees of freedom of theoctopus is then 31.

From a motion planning perspective the octopus shouldavoid both rocks and self-collisions between its tentaclesand body. The problem for the octopus is to select themost promising tentacle to hit the mosquito. Therefore thegoal configuration is defined by running inverse kinemat-ics procedures specifying the whole configuration of thetentacles. Then the configuration space to be explored is31-dimensionated (to avoid self-collisions the reasoningcannot be reduced to a 7-dimensionated configuration spaceof a single tentacle). Because the mosquito is moving,planning queries should run very fast.

The player must be careful not to hurt the environment(i.e. static rocks, octopus body and tentacles) with themosquito. A collision checker runs in real-time to checkwhen the player fails in controlling the mosquito. From thatpoint of view the mosquito appears as a free-flyer cylinderbounding the detailed geometrical model used for display.All the displayed environment bodies (rocks, octopus bodyand tentacles) are not approximated.

Therefore, the scenario induces a motion planning prob-lem in a dynamical environment (the goal configurationschange in real-time), for a 31 dof system moving in anenvironment made of 3500 polygonal facets.

IV. PROBABILISTIC V ISIBILITY ROADMAPS

A. Probabilistic motion planning

After the seminal idea that transforms the problemof motion planning for 3D bodies into a path planningproblem for a point in the configuration of the consideredsystem [27], the 80’s are dedicated to the development de-terministic approaches [20]. Nevertheless such methods donot succeed in facing the combinatorial complexity of theproblem. The idea to relax the strong completeness and ex-actness properties of the algorithms to the benefit of weakerproperties (e.g. probabilistic completeness) appears at thebeginning of the 90’s. The use of random searches appearsin [3], [5]. Their practical successes rapidly stimulatedthe apparition of numerous new methods that give rise tothe so-called ”probabilistic motion planning”. Beyond theirsuccesses in practice, the interest of these methods is to justrequire two simple basic operators: a collision checker anda steering method (or local planner). While the previousmethods required explicit representations of the obstaclesin the configuration space, these new methods explore thespace on the basis of implicit obstacle representations. Thegeometric constraint of obstacle avoidance is processed bythe collision checker, while the steering method accountsfor the control constraint of the considered system. Thetopic may be summarized by two types of techniques:

Pimples on the octopus body are the goals theplayer-controlled mosquito should sting.

The presence of rocks makes the cave very cluttered.

Fig. 2. The mosquito and the octopus.

• The sampling approaches introduced in [16] con-sist in first sampling the configuration space withcollision-free configurations and trying to link themby collision-free paths computed with the steeringmethod. This so-calledlearning phase builds a graph(roadmap) whose connected components tend to cap-ture the connectivity of the topological space. Agiven problem is solved in a so-calledquery phase:both starting and goal configurations are added asnew nodes of the roadmaps; then the existence ofa collision-free local path between and the existingroadmap nodes is checked. Finally the search is per-formed by a graph search algorithm. Any existing pathin the graph corresponds to an admissible motion.

• The diffusion approaches introduced in [12], [18]consist in solving single queries by developing a treerooted at the start configuration towards the goalto be reached. When the diffusion process fails atreaching the goal, new diffusion directions are chosenat random.

How to sample or diffuse efficiently? Such questionsgive rise to numerous variants of the original algorithms(e.g.,[1], [5], [6], [7], [8], [13], [15], [22], [23], [24], [33],[35], [38]).

... Mosquito! (it succeeds in stinging the octopus).

... Octopus!

Fig. 3. ... and the winner is ...

Due to the random searches, the motions computed withsuch probabilistic approaches include numerous uselessdetours. A complementary procedure should be added tooptimize the computed path. This step is not a criticalone. It can be easily done by any optimization techniquesincluding the elastic band approach [31].

All these methods succeed in solving difficult problems,i.e. highly cluttered space with high dimension. Then theymay account for the fourth video game constraint above(game difficulty). On the other hand the off-line time spentin the design phase of a video game is much less criticalthan the real-time issues of the game itself. Sophisticatedroadmaps can be computed off-line in the design process.In such a context, sampling techniques perform better thandiffusion ones. Indeed, because it is done off-line, the timespent by the learning phase of sampling approaches is notcritical. Once the learning phase is completed queries aresolved very quickly. Interactivity and real-time constraintsabove should then be addressed by sampling techniques.In fact, we will see in Section VI that the issues related toboth constraints are less algorithmic than technical.

Space memory saving is a last issue we should consider.In the resolution scheme we propose the roadmap iscomputed off-line and stored in the memory of the gameengine. Now it is not obvious to optimize the size of theroadmap. This issue is addressed by the so-called visibility

roadmaps.

B. Visibility roadmap and motion compression

The visibility roadmaps have been introduced in [35].The term ”visibility” refers to the following definition: thevisibility domain of a node is the set of all configurationsreachable from the configuration-node by a collision-freesimple local path (i.e. a path computed with the steeringmethod that accounts for the control constraints of theconsidered system). Two types of roadmap nodes are thenconsidered. Theguard nodes have in charge to cover theconfiguration space at the best: as a desired property,the union of the visibility domains of the guards shouldconverge to the whole collision-free configuration space.A set of guards is defined as optimal when two conditionsare verified: removing a guard decreases the covering, anda guard does not see any another one. When two visibilitydomains intersect, any configuration within the intersect-ing region is visible from both corresponding guards. Aconfiguration within the intersecting visibility domains oftwo guards is said to be aconnectornode. Then there isa sequence of exactly two collision-free elementary pathslinking two guards through an associated connector. Thisproperty is modeled by adding edges between guard nodesand connector nodes. While guards have in charge to coverthe space, connectors account for connectivity. A visibilityroadmap is built from an optimal guard set by addingconnectors.

The interest of the visibility roadmaps with respect tospace memory saving is illustrated in Figure 4: for thepresented simple example, visibility roadmaps require onlyaround 20 nodes while an average of more than 300 nodesis required by a basic sampling-based roadmap.

Fig. 4. Standard (left) versus visibility (right) roadmaps. Visibilityroapmaps are optimal data structures to capture the topology of thecollision-free space (for display purpose, the 6D configuration nodes ofthe roadmap are represented by the position and orientations of the end-effector).

Existence as well as combinatorial complexity of visi-bility roadmaps are discussed in [22]. We refer the readerto [35] for details about an algorithm to build trees asvisibility roadmaps. Notice that the algorithm performs

well in term of computation time, and even better thansome other probabilistic sampling-based algorithms.

Visibility roadmaps constitutes an optimized data struc-ture for what we can callmotion compression. Indeed, aroadmap tends to ”summarize” all the possible admissiblemotions in a given environment within a single combinato-rial graph data structure. Such a data structure is less spaceconsuming than the motion itself. Not only it allows to storeall the elementary motions computed in the learning phase,but also it allows to computeany motion just by runningthe query step. This is a key property to face interactivity,real-time computation and space memory saving.

V. COMPLEMENTARY TECHNIQUES: TENTACLE

INVERSEK INEMATICS

The objective of a octopus motion planning query isdefined from the position of the mosquito. Such a positionbeing given, the algorithm should select among the fourtentacles the whole configuration of the one which canreach the mosquito with the corresponding bowing glove.The problem is a classical problem of inverse kinematics(IK). We have adapted the models of a 7 dof humanarm. We borrow techniques from biomechanics based ap-proaches where forward or inverse kinematics algorithmsare applied to specify the motions of each of the jointsof the articulated arm-tentacle [2]. The implemented IKsolution comes from [37].

Once a tentacle has been selected, the question isto move the tentacle while avoiding obstacles and self-collision (self-collision avoidance may induce a motionfor all the tentacles). Then the problem becomes a pathplanning problem in the 31-dimensionated configurationspace. This step exactly corresponds to a query phaseperformed from the pre-computed roadmap. If the queryphase succeeds, the solution path is then smoothed to avoiduseless detours.

VI. I MPLEMENTATION AND ANALYSIS

A. Space memory

The visibility roadmap-tree has been computed in aroundone hour2 by using the software platform Move3D, a geo-metric library dedicated to algorithmic path planning [36].The roadmap is a tree including 313 nodes. All the 31331D-configurations as well as the tree are stored within a288Ko data structure.

B. Planning and animating: the parallelism issue

From an implementation point of view, the key problemis to guarantee fluid motions and real-time interactivity.For that the whole process should run at at least 25 fps(frames per second), i.e. less than 40ms per computationcycle. However, this constraint is not compatible with themotion planning of the octopus. Indeed the query phase isnot constant. It usually takes about 300ms but, according tothe complexity of the configuration, it could also require as

2All the following figures have been measured on an Athlon 1.4Ghz,256 Mo SDRAM, Geforce 4 MX 440 (64 Mo DDR, 333Mhz).

much as 1500ms. Overcoming this problem requires paral-lelism. The program has been organized within two threads:Animation and Planning 3. The threadAnimationembodies the reactivity of the game. Within each periodiccycle it must execute the following sequence:

• it reads the input controls from the joystick or thekeyboard,

• it computes the new position of the mosquito andchecks its collisions with both obstacle and octopusbodies, and

• it performs the animation of the whole scene.

This sequence must be less than 1/25s. In our case, it runsat 25ms. The remaining time (15ms) is used by the threadPlanning to compute the next trajectory of the octopus.The number of cycles required for this computation de-pends on the capacities of the computer and the complexityof the planning. In our game it generally takes 20 framesand some times as much as 100 frames.

The produced trajectory is then animated byAnimation . The duration of the animation depends onthe length of the trajetory and the velocity of the octopus.It is between 10 and 25 frames.

In order to hit the mosquito with one octopus fist theplanning requires a goal configuration. Such a configurationis computed by running the inverse kinematics modulefrom the configuration of the mosquito. However, onlythe current configuration and velocity of the mosquito areavailable. Computing and animating the octopus trajectorytakes a given time during which the mosquito is stillmoving under the control of the player thanks to theAnimation thread. A predictive mosquito configurationis then required. Such a configuration is computed withthe simple (and sufficient) assumption that the mosquito ismoving straight line at the constant current velocity. Thiswrong postulate lets his chance to the player (the playershould of course be unaware of the postulate. . . ).

C. Animation tricks

Complementary animation tricks have been developed tomake the game living.

The animation of the mosquito includes the beating of itswings. As soon as the octopus is waiting for planning (i.e.while the mosquito does not enter in a domain reachableby a tentacle), the octopus is animated by small randommotions. All these animations are parts of theAnimationthread.

The critical phases of the game (successes of themosquito or of the octopus) launch special (fixed) behaviorsaccompanied with dedicated sounds. During these specialanimations bothPlanning and Animation threadsstop.

3The threads have been implemented with POSIX for portabilityreasons. Indeed, the program runs under Windows 2000 and XP, Unix(Solaris), and MacOsX.

VII. C ONCLUSION

The game is downloadable at www.laas.fr/∼jpl/gameand may be easily evaluated4. Again, the game scenariodoes not pretend to reach the standard of the marketedscenarios. It focuses on path planning and it should beconsidered as a worked out example of what cannot bedone by classical grid or AI methods.

The game experiences the performance of the recentapproaches to algorithmic path planning. The paper showsthat issues such that 3D collision-checking, inverse kine-matics, configuration space searches. . . are mature enoughto address some of the interactivity and real-time con-straints arising in game design.

Moreover, it shows how the whole process of motionplanning can be decomposed into components makingpossible parallelism with animation processes.

Finally, memory space saving is another issue possiblyaddressed by the visibility roadmaps.

Further challenging works to promote path planning ingame design include:

• integrating dynamics engines into motion planningalgorithms to a better rendering of interactivity,

• planning complex motions for digital actors, and• animating crowds while accounting for obstacle avoid-

ance.

While the first issue remains open, the other ones areemerging (e.g. see [17], [30], [9], [19] for the digital actorsand [4], [14], [25], [28] for the crowds animation).

REFERENCES

[1] N.M. Amato, O. Bayazit, L. Dale, C. Jones, D. Vallejo.OBPRM:an Obstacle-Based PRM for 3D Workspaces. In Robotics: TheAlgorithmic Perspective (WAFR98), P. Agarwal et al. (Eds). AKPeters, 1998.

[2] N. Badler, C. Erignac, Y. Liu.Virtual humans for validating mainte-nance procedures. Commun. ACM, 45 (7), 2002.

[3] J. Barraquand, J.C. Latombe.Robot Motion Planning: a distributedrepresentation approach. International Journal of Robotics Re-search, 10 (6), 1991.

[4] O. Bayazit, J.M. Lien, N.M. Amato.Better group behaviors usingrule-based roadmaps. Algorithmic Foundations of Robotics V, J.D.Boissonnatet al Eds, Springer, 2004.

[5] P. Bessiere, J.M. Ahuactzin, E.-G. Talbi, E. Mazer.The ”Ariadne’sClew” Algorithm: Global Planning with Local Methods. IEEEInternational Conference on Intelligent Robots and Systems (IROS),1993.

[6] R. Bohlin, L.E. Kavraki.Path Planning using Lazy PRM. Proc.IEEE International Conference on Robotics and Automation, 2000.

[7] V. Boor, M.H. Overmars, A.F. van der Stappen.The GaussianSampling Strategy for Probabibilistic Roadmap Planners. Proc.IEEE International Conference on Robotics and Automation, 1999.

[8] P. Cheng, S.M. LaValle.Resolution Complete Rapidly-ExploringRandom Trees. IEEE International Conference on Robotics andAutomation, 2002.

[9] M. Choi, J. Lee, S. Shin.Planning biped locomotion using motioncapture data and probabilistic roadmaps. ACM Trans. on Graphics,2003.

[10] S. Epstein.Game playing : the next moves. 16th NationalConference on Artificial Intelligence (AAAI), 1999.

[11] Special theme : Games Technology. ERCIM News, 57, April 2004(www.ercim.org).

4To make the game interesting, the player should preferably have someskills in moving in 3D game environments. . . For non experienced players,the web page contains video sequences of the game.

[12] D. Hsu, J.C. Latombe, R. Motwani.Path Planning in ExpansiveConfiguration Spaces. Int. J. Computational Geometry and Appli-cations, 4, 1999.

[13] D. Hsu, L.Kavraki, J.-C. Latombe, R. Motwani, S. Sorkin.On Find-ing Narrow Passage with Probabilistic Roadmap Planner. Robotics:The Algorithmic Perspective (WAFR98), P. Agarwalet al (Eds). AKPeters, 1998.

[14] A. Kamphuis, M. Overmars.Finding paths for coherent groups usingclearance. Eurographics ACM Siggraph Symposium on ComputerAnimation, 2004.

[15] L. Kavraki, J.-C. Latombe, R. Motwani, P. Raghavan.RandomizedQuery Processing in Robot Motion Planning. ACM Symposium onTheory of Computing, 1995.

[16] L. Kavraki, P. Svestka, J.-C. Latombe, M. Overmars.ProbabilisticRoadmaps for Path Planning in High-Dimensional ConfigurationSpaces. IEEE Trans. on Robotics and Automation, 12 (4), 1996.

[17] Y. Koga, K. Kondo, J. Kuffner J.C. Latombe.Planning motions withintentions. Computer Graphics, 28, 1994.

[18] J. J. Kuffner, S. M. LaValle.RRT-connect: An efficient approachto single-query path planning. IEEE Int’l Conf. on Robotics andAutomation, 2000.

[19] J. Kuffner.Goal directed navigation for animated characters usingreal-time path planning and control. CAPTECH, 1998.

[20] J.C. Latombe.Robot motion planning. Kluwer Acad. Pub., 1991.[21] J.C. Latombe.Motion planning : A journey of robots, molecules,

digital actors, and other artifacts. Int. Journal of Robotics Research,18 (11), 1999.

[22] J.-P. Laumond, T. Simeon.Notes on Visibility Roadmaps and PathPlanning. Algorithmic and Computational Robotics (WAFR 2000),B. Donaldet al, Eds, A.K. Peters, 2001.

[23] S.M. LaValle, J.J. Kuffner.Rapidly-Exploring Random Trees:Progress and Prospects. Algorithmic and Computational Robotics(WAFR 2000), B. Donaldet al, Eds, A.K. Peters, 2001.

[24] S.M. LaValle, M.S. Branicky.On the relationship between classicalgrid search and probabilistic roadmaps. Algorithmic Foundationsof Robotics V, J.D. Boissonnatet al Eds, Springer, 2004.

[25] T.Y. Li, H.C. Chou.Motion planning for a crowd of robots. IEEEInt. Conf. on Robotics and Automation, 2003.

[26] M. Lin, D. Manocha, J. Cohen, S. Gottschalk.Collision detection:algorithms and applications. in Algorithms for Robotic Motionand Manipulation (WAFR’96), J.-P. Laumond and M. Overmars Eds,A.K. Peters, 1996.

[27] T. Lozano-Perez.Hierarchical model for real time simulation ofvirtual human crowds. IEEE Transactions on Visualization andComputer Graphics, 7 (2), 2001.

[28] S. Musse, D. Thalmann.Spatial planning: a configuration spaceapproach. IEEE Transactions on Computers, 32 (2), 1983.

[29] M. Overmars.Motion planning in virtual environments and games.in [11].

[30] J. Pettre, J.P. Laumond, T. Simeon.A 2-stages locomotion plannerfor digital actors. Eurographics ACM-SIGGRAPH Symposium onComputer Graphics, 2003.

[31] S. Quinlan, O. Khatib.Elastic Bands: Connecting Path Planningand Control. IEEE International Conference on Robotics andAutomation, 1993.

[32] J. Raessens, J. Goldstein (Eds).Handbook of computer game studies.MIT Press, 2005 (to appear).

[33] G. Sanchez, J.C. Latombe.A Single-Query bidirectionnal Prob-abilistic Roadmap Planner with Lazy Collision Checking. Int.Symposium on Robotics Research, 2001.

[34] J. Schaeffer, H. Jaan van der Herik.Games, computers, and artificialintelligence. Artificial Intelligence, 134, 2002.

[35] T. Simeon, J.-P. Laumond, C. Nissoux.Visibility Based ProbabilisticRoadmaps for Motion Planning. Advanced Robotics Journal, 14(6), 2000.

[36] T. Simeon, J.-P. Laumond, C. Van Geem, J. Cortes.Computer aidedmotion: Move3D within MOLOG. IEEE International Conferenceon Robotics and Automation, 2001.

[37] D. Tolani, A. Goswami, N. Badler.Real-time inverse kinematicstechniques for antropomorphic limbs. Graphical Models, 5, 2000.

[38] S.A. Wilmarth, N.M. Amato, P.F. Stiller.Motion Planning for aRigid Body Using Random Networks on the Medial Axes of the FreeSpace. ACM Symposium on Computational Geometry, pages 173–180, 1999.

[39] M. Wolf, B. Perron (Eds).The video game theory reader. Taylorand Francis, Inc., Bristol, PA, 2003.