Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Prolog for the AI part of games

11 views
Skip to first unread message

thefreesof...@yahoo.gr

unread,
Sep 29, 2008, 5:43:06 PM9/29/08
to
I was wondering if Prolog is used in practice just for prototyping, or
can be used for implementing the AI part of real games.

If the latter is true, are there any examples? Because I'm really
interested in combining Prolog with another programming language (for
example Python) to implement a game. I really like Prolog and hope
that is not just used by logicians or researchers...

Thanks.

pineapp...@yahoo.com

unread,
Sep 29, 2008, 7:10:51 PM9/29/08
to
I am not aware of Prolog use for large, popular, commercial games such
as the 3D first person shooters (Quake, etc) or games with extreme 3D
graphics. The issue is speed, which is deemed a necessity in games
with such extreme graphics.

I have seen Prolog used in games like chess (I even have a Prolog
chess game), but again it isn't used in "famous" commercial chess
programs you've heard about (Shredder, Fritz, etc) - again because of
the speed issue. A faster program written in C, Assembly, etc. (which
these programs are) can search more plies than a slower program, given
the same amount of search time. There is sort of a Darwinism that
goes on among these chess programs - they play each other in
competitions (literally). Titles are awarded, etc. The developers
try to squeeze out as much speed as possible, and optimize as much as
possible.

I was paid to write a small card game for a company. I originally
wrote the entire thing in another language (not Prolog), but went back
and redid part of it in Prolog - the part which compared player's
hands. Not only was that part of the program *much* less complicated,
*much* more easily understood, and *much* shorter than the original
code I wrote, but it actually ended up being faster too. It also
ended up being more correct. I did a test passing millions of
generated hands through both hand evaluators. I would write out any
discrepancies between the hand evaluators to the console. There ended
up being a couple of discrepancies out of millions of hands. An
examination of those discrepancies revealed that the Prolog version
evaluated the hands correctly - there was a very subtle, insidious
error lurking in the complexity of the original code.

Some of the Prolog gurus here might be able to tell you more than I
can. My belief is that processor speed will one day reach a point
where choice of programming language is not constrained for such
applications. If you don't need extreme speed or extreme graphics, I
don't see why Prolog couldn't be considered, all other things being
equal, but opinions vary.

Duncan Patton a Campbell

unread,
Sep 29, 2008, 11:28:59 PM9/29/08
to

Back in the days when assembler and c were common languages to code in
Prolog got a name for being a resource hog.... now however I think a
rethink might be in order. I'd be interested in hearing more about
what you are up to.

Dhu

Daniel Kraft

unread,
Sep 30, 2008, 3:03:48 AM9/30/08
to
thefreesof...@yahoo.gr wrote:
> I was wondering if Prolog is used in practice just for prototyping, or
> can be used for implementing the AI part of real games.

Honestly, I can't answer this; but I can tell you a bit about what I did
with Prolog.

> If the latter is true, are there any examples? Because I'm really
> interested in combining Prolog with another programming language (for
> example Python) to implement a game. I really like Prolog and hope
> that is not just used by logicians or researchers...

I like Prolog very much, for the reasons already mentioned in this
thread, namely that I found it is a "perfect" language for certain (but
not all) problems, where the logic approach produces by far the simlest
and clearest code (sometimes this simplicity must be traded against
speed, but I don't even think this is always the case).

My experience and use of Prolog however was only for solving
mathematical puzzles (although of very different types, so not always
straight searching), so my view is probably very biased :)

Yours,
Daniel

--
Done: Arc-Bar-Cav-Rog-Sam-Val-Wiz
To go: Hea-Kni-Mon-Pri-Ran-Tou

Stephen Horne

unread,
Sep 30, 2008, 6:18:50 AM9/30/08
to

My impression is that the AI used in games isn't really the same as
the AI used in AI, though of course in games it really depends on what
kind of game and things are getting more sophisticated all the time
too.

A lot of game AI probably depends on fairly standard algorithms that
are tweaked and optimised for the job, and which depend on some fairly
close interaction with other game components. For example, pathfinding
is in principle fairly simple (usually based on A*, could possibly be
based on Dijkstra - IIRC A* has a directional heuristic whereas
Dijkstra just searches all possible routes in distance-based priority
order). However, the algorithm needs a graph data structure to
explore, and that is probably closely coupled with the scene
management for the game as a whole.

I've never implemented A*, but implementing Dijkstra is trivial in an
imperative language assuming you already have a priority queue
(usually heap) data structure. The real issue is efficient graph
querying.

Another common game "AI" thing is the finite state machine. Generating
FSMs from regular grammars and algebraically manipulating them is a
useful feature for a digraph library, but I doubt that games FSMs are
handled that way much - I expect they're mostly just hand-designed.
Either way, run-time handling of FSMs is easy in imperative languages,
and there are plenty of FSM code generators which are written in and
generate code for imperative languages - mostly aimed at lexical
analysis of text, but there are exceptions - SMC is not even slightly
aimed at lexical stuff, and Ragel is a very powerful
regular-grammar-to-FSM tool that can handle non-lexical tasks when
needed.

When something is already simple, fast and effective there's little
incentive to change, especially from a widely understood language to
one that is more of a specialist field.

After all, the real "what it takes" of games programming appears to be
the willingness to work 20 hour days 7 days a week for a fairly modest
salary and with no chance of overtime pay, living on a 100% caffeine
diet. Then when you burn out you are thrown out with the trash. All to
produce yet another Doom clone or whatever with prettier graphics and
a bunch of license tie-in contracts preventing any creativity, which
will normally have a full-price shelf-life measured in weeks if it
ever even gets completed.

And since there's a movement towards treating game components
(graphics engines, physics engines, AI engines etc) as commodities,
the highly-skilled games programmer is quite possibly an endangered
species. The only long-term survival strategy may be to stop working
on specific game projects and to work on one of the commodity engines
instead, and some of the best known and most popular are free and open
source, so the real money is probably in writing books for kids who
are dreaming of being games programmers.

Andre LaMothe seems to be quite active in this - at least his name is
on a *lot* of books as series editor - and while I have his "Tricks of
the 3D Game Programming Gurus" (I can dream too) and found it mostly
excellent if a bit long-winded, rumour has it that some are
second-rate versions of non-games programming books written by very
recent graduates with no experience and that newbies would be far
better off buying a decent general algorithms and data structures
book, parsing-and-compiling theory book, etc.

I'd quite like to write games, but not "mainstream" games -
small-scale puzzle games and the like make much more sense.
Potentially profitable hobby rather than Hollywood entertainment
factory version 2. That actually looks like a *sane* ambition.

And *then* you can code using whatever you want ;-)

BTW - why are the big-budget games called "mainstream" when the
long-term best-sellers are puzzle-games such as "Bejewelled"?

Anyway, I can't claim to know enough Prolog (or enough about game
programming) to know if any game AI components could be better handled
in Prolog, but I wouldn't expect any big movements that way soon.

There is probably some real potential for functional programming,
though, in that Microsoft is working on F# - basically an Objective
CAML clone for the .NET platform. DirectX on .NET seems popular with
hobbyists, and .NET also seems a good option for some of the less
speed-critical parts of mainstream games, especially given that a lot
of high-level game logic is programmed using scripts these days.

But then if you like Python, it already has some neat functional-style
features, iterators and generators are good for some Icon-style
goal-directed-search AI code, and IronPython is already available for
.NET.

pineapp...@yahoo.com

unread,
Sep 30, 2008, 6:46:50 AM9/30/08
to
Check out Mercury. It is supposed to be faster than "generic prolog,"
thus possibly more suitable for game design.

http://www.cs.mu.oz.au/research/mercury/index.html

A.L.

unread,
Sep 30, 2008, 8:41:42 AM9/30/08
to
On Tue, 30 Sep 2008 11:18:50 +0100, Stephen Horne
<sh006...@blueyonder.co.uk> wrote:

>On Mon, 29 Sep 2008 14:43:06 -0700 (PDT),
>"thefreesof...@yahoo.gr" <thefreesof...@yahoo.gr> wrote:
>
>>I was wondering if Prolog is used in practice just for prototyping, or
>>can be used for implementing the AI part of real games.
>>
>>If the latter is true, are there any examples? Because I'm really
>>interested in combining Prolog with another programming language (for
>>example Python) to implement a game. I really like Prolog and hope
>>that is not just used by logicians or researchers...

All your postings are really interesting, but they would be much more
interesting if you make them no longer than 1 - 2 not that long
paragraphs.

Actually, I would read them

A.L.

Stephen Horne

unread,
Sep 30, 2008, 11:55:30 AM9/30/08
to
On Tue, 30 Sep 2008 07:41:42 -0500, A.L. <alew...@zanoza.com> wrote:

>All your postings are really interesting, but they would be much more
>interesting if you make them no longer than 1 - 2 not that long
>paragraphs.
>
>Actually, I would read them

One of the adaptations I've made in accepting that I have Aspergers
disorder is that I no longer beat myself up either for being
misunderstood, or for being pedantic or long winded - whether trying
to avoid being misunderstood or just in a windbag mood.

No-one is forcing you to read anything. Freedom cuts both ways. If I'm
really bugging you so much you feel a need to fix me, maybe you should
try using a kill filter, assuming your usenet client supports that.

There you go - two not-that-long paragraphs. At least until I screwed
it all up with this extra one, anyway.

A.L.

unread,
Sep 30, 2008, 1:08:06 PM9/30/08
to


Good luck.

A.L.

rupert...@googlemail.com

unread,
Oct 1, 2008, 7:33:50 PM10/1/08
to
On Sep 29, 10:43 pm, "thefreesoftwaregr...@yahoo.gr"

Bear in mind that you not only have the performance of Prolog to
consider but also the effort consumed by translating to and from
Prolog into whatever other language you are using.

I think Prolog could help with AI for games, application dependent; it
certainly is a good language for prototyping. How about this for an
approach, prototype your AI in Prolog. If its not fast enough to call
from the main game language (C++?), you could always turn it into some
(functional style) 'unit' tests. That is you use the AI in Prolog as a
fitness function, to evaluate the same AI redeveloped in the other
language for performance reasons. The Prolog implementation forms the
model against which you check your final implementation.

Rupert

Duncan Patton a Campbell

unread,
Oct 1, 2008, 11:31:39 PM10/1/08
to

A.K.A. and executable specification.

Dhu

>
> Rupert

--
Duncan Patton a Campbell is Dhu

freeasinfreedom

unread,
Oct 3, 2008, 4:45:18 PM10/3/08
to
Actually, I don't have such ambitions (being a professional game
programmer), that's why I'm not planning to buy a book about game
programming (except if I can find a book that describes implementing
the AI part of a game in Prolog or Lisp!)

And it's because I don't want to burn my brain by programming 24 hours
a day a game and implementing the AI part with a classic programming
language (for example object-oriented), I'm looking for better ways to
do it.

For example, I could use the pygame (http://www.pygame.org/) library
for implementing the graphics of a game (what kind of game? I don't
know yet...), but I would really like to implement the AI part with an
AI language. By the way, if anyone else is interested, we could start
a project in savannah (http://savannah.gnu.org/). A warning: I'm
neither a python guru, nor a prolog master programmer.

PCerkez

unread,
Oct 12, 2008, 1:04:34 AM10/12/08
to
very interesting thread.

If I might offer a suggestion, take a look at Visual Prolog (VIP) by PDC.
(www.visual-prolog.com)

While it is not Clocksin-Melish pure prolog, it does allow you to create
prolog based code, interface with C code (either as the calling program or
the called one), create DLLs of packaged logic, etc. VIP isa 'typed'
impllenmtation of prolog and can be very fast (depending on the way you code
your logic - bad logic will hamper an application in any language)

VIP is relatively inexpensive (free version available for download.)

I have been using VIP in its cvarious incarnations since it was Turbo Prolog
back in 88. I've used it to develop commercial applciations as well as
safety certified ones.

give it a look, you might be surprised.

P.
AI Rules!


*******************************
<thefreesof...@yahoo.gr> wrote in message
news:7e40ed1b-f9ee-40f1...@w7g2000hsa.googlegroups.com...

0 new messages