Sdl_ai?

Hi. This is just an idea that I’d like to float to the SDL community.

I have what I can safely claim to be a long history in artificial
intelligence. I’ve started using SDL at the moment as I wish to write
some educational games for my son. However, if there was sufficient
interest in the SDL community, I was wondering if there would be scope
for an SDL_AI library.

What I would be suggesting is a module allowing people to write simple
rule-based programs controlling the behaviour of characters in their
games. The way I imagine it would work at the moment is that there would
be some sort of load method, that would return a SDL_KnowledgeBase, say

CharacterMovement = SDL_AI_LoadKnowledgeBase( "myrules.txt" );

There would then be some sort of binding between variables in the rule
base versus variables in the C program

SDL_AI_BindVariableUInt32( CharacterMovement, "characterx",
			       &char_x );
SDL_AI_BindVariableFloat( CharacterMovement, "damage",
			       &char_damage );

(with char_x and char_damage being variables of the C language program).

There would probably be a need to bind C functions to rule base
variables to functions in C so that when the rule base tries to read
some abstract property of the game environment (such as the number of
enemies that can be seen), the C function is called to calculate it.

SDL_AI_BindFunctionUInt32( CharacterMovement, "numEnemies",
			   numEnemiesCountingFunc );

Once those bits were set up, the rule base could be called somewhere in
the game loop.

SDL_AI_Update( CharacterMovement );

Calling the rule base would run the program, which would affect various
C language variables, resulting in things happening in the game (such as
the character moving).

A rule base (stored in a file) might look like this:

if characterx <= 0 and xmove < 0
then xmove = -xmove.

if characterx >= width and xmove > 0
then xmove = -xmove.

if charactery <= 0 and ymove < 0
then ymove = -ymove.

if charactery >= height and ymove > 0
then ymove = -ymove.

OK, so this would just bounce a character off the walls, but I hope
people get the idea.

I’d like to see what people say. Would anyone be interested in this sort
of thing. I don’t think it would be a good idea to try to aim for a
state of the art artificial intelligence component because it would be
too big and complex and take a long time to learn. Neither can it be as
simple as the rules above because not enough could be done with them.
But, if people were interested, perhaps we could start discussing it,
and see if there is some sort of suitable compromise.

As, if this worked out, I could probably get a publication out of such a
system, I could write it on work time! :slight_smile:

Comments?

Cheers,

Ross-c–

Ross Clement (Dr)
Senior Lecturer in Artificial Intelligence
Harrow School of Computer Science
University of Westminster
Northwick Park
Middlesex
UK HA1 3TP

clemenr at wmin.ac.uk
+44-20-7911-5000 ext. 4159

Hi Ross,

I think this could be a good idea. Almost every games need some AI or at
least something basics. I’m student/teacher at JAC College in Canada and
would be glad to contribute in my spare time to a project covering SDL_AI.
I got 8 years of programmation experienced beside me and have been working
with SDL for personnal or school project. I’m sure some other people will
find this interesting. Gimmie news about it as soon as you can.

Alexandre Cayer_______________________________________________
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Hi. This is just an idea that I’d like to float to the SDL community.

I have what I can safely claim to be a long history in artificial
intelligence. I’ve started using SDL at the moment as I wish to write
some educational games for my son. However, if there was sufficient
interest in the SDL community, I was wondering if there would be scope
for an SDL_AI library.

What I would be suggesting is a module allowing people to write simple
rule-based programs controlling the behaviour of characters in their
games. The way I imagine it would work at the moment is that there would
be some sort of load method, that would return a SDL_KnowledgeBase, say

CharacterMovement = SDL_AI_LoadKnowledgeBase( “myrules.txt” );

There would then be some sort of binding between variables in the rule
base versus variables in the C program

SDL_AI_BindVariableUInt32( CharacterMovement, “characterx”,
&char_x );
SDL_AI_BindVariableFloat( CharacterMovement, “damage”,
&char_damage );

(with char_x and char_damage being variables of the C language program).

There would probably be a need to bind C functions to rule base
variables to functions in C so that when the rule base tries to read
some abstract property of the game environment (such as the number of
enemies that can be seen), the C function is called to calculate it.

SDL_AI_BindFunctionUInt32( CharacterMovement, “numEnemies”,
numEnemiesCountingFunc );

Once those bits were set up, the rule base could be called somewhere in
the game loop.

SDL_AI_Update( CharacterMovement );

Calling the rule base would run the program, which would affect various
C language variables, resulting in things happening in the game (such as
the character moving).

A rule base (stored in a file) might look like this:

if characterx <= 0 and xmove < 0
then xmove = -xmove.

if characterx >= width and xmove > 0
then xmove = -xmove.

if charactery <= 0 and ymove < 0
then ymove = -ymove.

if charactery >= height and ymove > 0
then ymove = -ymove.

OK, so this would just bounce a character off the walls, but I hope
people get the idea.

I’d like to see what people say. Would anyone be interested in this sort
of thing. I don’t think it would be a good idea to try to aim for a
state of the art artificial intelligence component because it would be
too big and complex and take a long time to learn. Neither can it be as
simple as the rules above because not enough could be done with them.
But, if people were interested, perhaps we could start discussing it,
and see if there is some sort of suitable compromise.

As, if this worked out, I could probably get a publication out of such a
system, I could write it on work time! :slight_smile:

Comments?

It could well be interesting/educational to write, but I can’t see that
anyone would incorporate it into a game in the way that people use
graphics, sound, font or network libraries. The way that AI
works, and the way that it interacts with a game’s main loop, is so
entirely different from game to game that it would be more
effort to incororate an external library for such things into a project
than it is to just write your own.

Plus, the idea of a single SDL_AI_Update() function is totally opposed
to the idea of object orientated programming. Not that there’s anything
neccessarily wrong with a C as opposed to C++ game, but it just means
it’s even more unlikely that it’s going to see much use by other
peoples’ projects.

If you want to do it out of interest, go ahead, but I don’t think they’ll
be people queing up to put it into their games.

JamesOn Wed, 11 Feb 2004 10:44:40 +0000, Ross Clement wrote:

#Plus, the idea of a single SDL_AI_Update() function is totally opposed
#to the idea of object orientated programming. Not that there’s anything

Just out of curiosity: how would a more “object orientated” way of
doing this look like? Character.update()? If that is the case, I
think the difference is merely superficial…

Also, SDL is a C library, not a C++ library, so I don’t think bringing
in those C++ wrap-arounds is a great idea for an SDL add-on library.

Mark: I think it would be of some use to simple-AI-games, which is
quite some games. I think the key to get users, at least beginner
users, actually choosing SDL_AI instead of writing their own ad-hoc
c-code AI is simple interface and, foremost, good documentation. Why?
Because it is abstract, and for beginner game programmers that is of
key importance. An example of excellent documentation is Shawn
Hargraeves Allegro.txt for the same-name game programming library. An
example of a not-so-excellent (pardon me) documentation is that of
SDL…

/Olof

The beauty of SDL is its simplicity. I would hate to see SDL become a
feature-bloated monster. A generic AI library would be much more useful than
one dependent upon SDL.> I was wondering if there would be scope

for an SDL_AI library.

Hi. This is just an idea that I’d like to float to the SDL community.

I had to read this twice to get the idea of what you are trying to do.
First off, I like the idea.

My first observation is that there is nothing in this idea that is
specific to SDL. It could be done in a generic form that can by used by
anyone in any situation where AI is needed. Tying it to SDL might
actually keep people from using it in applications where it would be
very valuable.

There are a few other things that worry me. How do you provide for the
AI inspecting the environment of the character? For example how do you
decide to move down corridor A instead of corridor B based on seeing a
gold bar down corridor B? How do you do navigation based on BSP tree or
KD tree data?

Personally, I would rather see your system translate the rules into C
that I can compile and link into my program. Doing that would make the
interface easier, just declare the variables that can be inspected and
let the compiler/linker hook them together. It would also let me
#include the code as methods in a C++ class so that I can easily use it
in multiple unique contexts. (For example, each of the 200 wandering
monsters executes the AI code in their own class context.) Doing that
would make it easier to use and much more flexible. Doing that would
keep the C++ enthusiasts happy and let you use the code in C programs
and also build it into scripting languages. It would also keep me from
having to load it at run time. I hate waiting while a game loads a bunch
of files…

All in all it looks like a worthwhile project. Please let me know what
you decide to do with the idea and keep me informed of your progress.

	Bob PendletonOn Wed, 2004-02-11 at 04:44, Ross Clement wrote:

I have what I can safely claim to be a long history in artificial
intelligence. I’ve started using SDL at the moment as I wish to write
some educational games for my son. However, if there was sufficient
interest in the SDL community, I was wondering if there would be scope
for an SDL_AI library.

What I would be suggesting is a module allowing people to write simple
rule-based programs controlling the behaviour of characters in their
games. The way I imagine it would work at the moment is that there would
be some sort of load method, that would return a SDL_KnowledgeBase, say

CharacterMovement = SDL_AI_LoadKnowledgeBase( “myrules.txt” );

There would then be some sort of binding between variables in the rule
base versus variables in the C program

SDL_AI_BindVariableUInt32( CharacterMovement, “characterx”,
&char_x );
SDL_AI_BindVariableFloat( CharacterMovement, “damage”,
&char_damage );

(with char_x and char_damage being variables of the C language program).

There would probably be a need to bind C functions to rule base
variables to functions in C so that when the rule base tries to read
some abstract property of the game environment (such as the number of
enemies that can be seen), the C function is called to calculate it.

SDL_AI_BindFunctionUInt32( CharacterMovement, “numEnemies”,
numEnemiesCountingFunc );

Once those bits were set up, the rule base could be called somewhere in
the game loop.

SDL_AI_Update( CharacterMovement );

Calling the rule base would run the program, which would affect various
C language variables, resulting in things happening in the game (such as
the character moving).

A rule base (stored in a file) might look like this:

if characterx <= 0 and xmove < 0
then xmove = -xmove.

if characterx >= width and xmove > 0
then xmove = -xmove.

if charactery <= 0 and ymove < 0
then ymove = -ymove.

if charactery >= height and ymove > 0
then ymove = -ymove.

OK, so this would just bounce a character off the walls, but I hope
people get the idea.

I’d like to see what people say. Would anyone be interested in this sort
of thing. I don’t think it would be a good idea to try to aim for a
state of the art artificial intelligence component because it would be
too big and complex and take a long time to learn. Neither can it be as
simple as the rules above because not enough could be done with them.
But, if people were interested, perhaps we could start discussing it,
and see if there is some sort of suitable compromise.

As, if this worked out, I could probably get a publication out of such a
system, I could write it on work time! :slight_smile:

Comments?

Cheers,

Ross-c

±--------------------------------------+

#Plus, the idea of a single SDL_AI_Update() function is totally opposed
#to the idea of object orientated programming. Not that there’s anything

Just out of curiosity: how would a more “object orientated” way of
doing this look like? Character.update()? If that is the case, I
think the difference is merely superficial…

One imagines a character makes AI decisions based not only on facts about
the outside world, but also on facts about themselves (position, health,
weapon, shield level, colour, friendliness, obesity, etc).

OO would try to keep access to these variables from outside the character
class down to a minimum.

Also, SDL is a C library, not a C++
library, so I don’t think bringing
in those C++ wrap-arounds is a great idea for an SDL add-on library.

I wasn’t saying it should be C++ rather than C, I was just saying it
wouldn’t be of much use for C++. Unlike SDL itself, where the fact it
is in C is pretty much irrelevant.

JamesOn Thu, 12 Feb 2004 11:00:20 +0100, Olof Bjarnason wrote:

I would beg to differ… SDL being in C is very relevant; C code can be used
by both C and C++ natively, while C++ code can only be used by C++.On Thursday 12 February 2004 16:42, James Gregory wrote:

Unlike SDL itself, where the fact it is in C is pretty much irrelevant.

Unlike SDL itself, where the fact it is in C is pretty much irrelevant.
I would beg to differ… SDL being in C is very relevant; C code can be used
by both C and C++ natively, while C++ code can only be used by C++.

I meant irrelevant in a positive way, “irrelevant for C++ applications”.

JamesOn Thu, 12 Feb 2004 17:41:32 -0600, Tyler Montbriand wrote:

On Thursday 12 February 2004 16:42, James Gregory wrote:

Alas, it seems I lost the original post to reply to to
keep the meta tags correct… but the reply I wanted
to make:

SDL stands for Simple Directmedia Layer. AI is
definately not media. If you want to implement an AI
library, no one’s going to stop you - if you want to
encourage new users to use it, no one’s going to stop
you - but this should not be part of SDL directly.

Don’t get me wrong, assuming something good is
developed, I would support having it linked on the sdl
website.

But, don’t call it SDL_AI. Maybe SAI instead (for
simple AI). After all, a good AI library shouldn’t
have to depend on any of the rest of SDL at all, and
could be used for anything.

   -Mike__________________________________

Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.

Hi. This is just an idea that I’d like to float to the SDL community.

I have what I can safely claim to be a long history in artificial
intelligence. I’ve started using SDL at the moment as I wish to write
some educational games for my son. However, if there was sufficient
interest in the SDL community, I was wondering if there would be scope
for an SDL_AI library.

You could use a scripting language called Lua to program the characters’
rules (and almost everything else related to game logic). It does everything
you need: load programs and bind functions and variables to and from C. It
has some utilities developed by the community that parse C files and
automatically generate the binding code to C structures and classes that you
can compile and link to your code. It also has some nice extensions
libraries to do networking, read XML, access databases, mutithreading etc.

Take a look at http://www.lua.org/ and http://lua-users.org/ for more info
on Lua.

Andre de Leiradella

Many people thinks more that SDL is today as like a game library
like Allegro. At the beginning SDL was made especially for games.
So I understand the idea to create a SDL_AI lib. But if you think
that it’s a problem with the definition, it could also be renamed
to SAI, but I hope it would be as so easy to use.

saf
ps: Please add the A* algorithm in this new lib.On Thu, Feb 12, 2004 at 09:42:01PM -0800, Michael Rickert wrote:

Alas, it seems I lost the original post to reply to to
keep the meta tags correct… but the reply I wanted
to make:

SDL stands for Simple Directmedia Layer. AI is
definately not media. If you want to implement an AI
library, no one’s going to stop you - if you want to
encourage new users to use it, no one’s going to stop
you - but this should not be part of SDL directly.

Don’t get me wrong, assuming something good is
developed, I would support having it linked on the sdl
website.

But, don’t call it SDL_AI. Maybe SAI instead (for
simple AI). After all, a good AI library shouldn’t
have to depend on any of the rest of SDL at all, and
could be used for anything.


saf at http://TrashMail.net/
No more spam, free disposable email addresses.

I just want to toss my two cents into this.

  1. I agree with Mike partly. If think inside the box, SDL should be
    "media" focused.
  2. However I also see AI as part of an advanced implementation of a media
    offering.

As a side not, several people have worked on very similiar projects for AI
before (including myself, I was attempting an AI lib for opengl). However
most fail as it takes alot of time and effort. There is alot to do to
make AI libs useful.

I say go for it. I won’t discuss the whether it should be "properly"
integrated into SDL, but if it remains exteriorly (is that a word) it
would still be of great use to people.

RonOn Thu, 12 Feb 2004, Michael Rickert wrote:

Alas, it seems I lost the original post to reply to to
keep the meta tags correct… but the reply I wanted
to make:

SDL stands for Simple Directmedia Layer. AI is
definately not media. If you want to implement an AI
library, no one’s going to stop you - if you want to
encourage new users to use it, no one’s going to stop
you - but this should not be part of SDL directly.

Don’t get me wrong, assuming something good is
developed, I would support having it linked on the sdl
website.

But, don’t call it SDL_AI. Maybe SAI instead (for
simple AI). After all, a good AI library shouldn’t
have to depend on any of the rest of SDL at all, and
could be used for anything.

   -Mike

Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

  1. However I also see AI as part of an advanced
    implementation of a media offering.

I see AI as an abstract processing act. The core SDL
library is a direct access layer - You get input and
send output with it.

SDL_* libraries that I see under the libraries link
fall into the category of either adding more types of
output (like SDL_sound), more abstraction to the
output layer (like SDL_stretch, _gfx, _prim, _ttf,
etc) or rely completely on it (SDL_websrv).

I don’t see how AI falls into the category of
affecting the result displayed on the screen, heard by
the user, or anything of the sort. There is no reason
for an AI library to rely on SDL, except for
mutexes/multithreading, which IMHO should not be a
requirement for an AI library to run.

A good AI lib would be useful, but I don’t see it
being SDL_AI. If I found a project called “Windowed
Screen AI” I’d laugh.

If I found a project called “Simple Directmedia Layer
AI” I’d laugh.__________________________________
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.

Many people thinks more that SDL is today as like a
game library
like Allegro. At the beginning SDL was made
especially for games.
So I understand the idea to create a SDL_AI lib. But
if you think
that it’s a problem with the definition, it could
also be renamed
to SAI, but I hope it would be as so easy to use.

I don’t see how SAI_CreateAI() would be harder to use
than SDL_AI_CreateAI(). Heck, it saves 3 characters
worth of typing.

Calling it SDL_AI would alientate, for example,
DirectX programmers, or clanlib programmers, or
_______ other library programmers, where _______ is
any sort of abstraction layer that overlaps SDL in
functionality.

Alienation causes lack of support, lack of support
causes lack of contribution, lack of contribution for
an ambitions project such as a general purpouse AI,
even if just for games, would be fatal to the project.

Also, which is easier to skip read and know the
difference of:

SDL_Something();
SDL_AI_DoSomething();
SDL_DoSomethingElse();

where the 4th character is almost allways varying, and
we have to check if it’s A…

or

SDL_Something();
SAI_DoSomething();
SDL_DoSomethingElse();

where the 2nd character only varies when using
different libraries, and it’s either A or D?

?

Calling it SDL_AI imposes readibility strain, extra
typing, and alienates non SDL users. Even if it were
media, AI would deserve it’s own entire library.

  -Mike__________________________________

Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.

id like to see someone code a couple types of neural networks into a library
(:

all you see out there is scientists trying to code in C++ which ends up in
terribly ugly code that isnt free (source or $ etc, one way or another not
free)

yucky :stuck_out_tongue:

but it would be cool if there was a library that people could use to set up
"learning" capabilities as well as pattern recognition, sure would rock (:> ----- Original Message -----

From: mrickert85@yahoo.com (Michael Rickert)
To:
Sent: Friday, February 13, 2004 10:26 PM
Subject: Re: [SDL] Re: Re: SDL_AI?

Many people thinks more that SDL is today as like a
game library
like Allegro. At the beginning SDL was made
especially for games.
So I understand the idea to create a SDL_AI lib. But
if you think
that it’s a problem with the definition, it could
also be renamed
to SAI, but I hope it would be as so easy to use.

I don’t see how SAI_CreateAI() would be harder to use
than SDL_AI_CreateAI(). Heck, it saves 3 characters
worth of typing.

Calling it SDL_AI would alientate, for example,
DirectX programmers, or clanlib programmers, or
_______ other library programmers, where _______ is
any sort of abstraction layer that overlaps SDL in
functionality.

Alienation causes lack of support, lack of support
causes lack of contribution, lack of contribution for
an ambitions project such as a general purpouse AI,
even if just for games, would be fatal to the project.

Also, which is easier to skip read and know the
difference of:

SDL_Something();
SDL_AI_DoSomething();
SDL_DoSomethingElse();

where the 4th character is almost allways varying, and
we have to check if it’s A…

or

SDL_Something();
SAI_DoSomething();
SDL_DoSomethingElse();

where the 2nd character only varies when using
different libraries, and it’s either A or D?

?

Calling it SDL_AI imposes readibility strain, extra
typing, and alienates non SDL users. Even if it were
media, AI would deserve it’s own entire library.

  -Mike

Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Many people thinks more that SDL is today as like a
game library
like Allegro. At the beginning SDL was made
especially for games.
So I understand the idea to create a SDL_AI lib. But
if you think
that it’s a problem with the definition, it could
also be renamed
to SAI, but I hope it would be as so easy to use.

Calling it SDL_AI would alientate, for example,
DirectX programmers, or clanlib programmers, or
_______ other library programmers, where _______ is
any sort of abstraction layer that overlaps SDL in
functionality.
But why call it SAI if it’s NOT tied in with SDL? Just call it AI. That is,
unless you’re actually USING the nifty features that SDL has for libraries:

*Macros for exporting shared libraries under nearly anything, anywhere
*Universal endian conversion
*Integers of guaranteed sizes(S/Uint8, S/Uint16, S/Uint32, S/Uint64)
*Simple crossplatform timers
*Simple crossplatform threads
*Simple crossplatform mutexes and semaphores
*Generalized streaming I/O without the braindead C++ garbage
*Crossplatform error reporting
*Crossplatform methods of loading shared libraries(SDL_loadso)
*Crossplatform routines for using shell variables the same way everywhere
*Libraries to turn bool winapi(MS *specific) into int main(int argc,
char *argv[])
*and more!

Let’s face it, there are a hell of a lot of REALLY GOOD REASONS to use SDL as
a library base. :slight_smile: As far as I’m concerned, SDL’s the multimedia equivalent
of stdio.h. Why reinvent the wheel? And it would still be possible to port
this library to things like clanlib if you want.

And if it’s using SDL, I think it should be clear that it’s using it.
Nothing pisses off programmers more than finding out this nifty new
program/library requires ten billion weird dependencies that weren’t even
implied. (cough madplay cough) Calling it SDL_AI_whatever() makes it’s use
of SDL pretty clear, I believe.

Alienation causes lack of support, lack of support
causes lack of contribution, lack of contribution for
an ambitions project such as a general purpouse AI,
even if just for games, would be fatal to the project.
I would wager that SDL is more popular and supported by many more platforms
than libraries like Clanlib and Allegro. I remember when I released the
makefiled source code for my SDL Crossfire remake - a few days later, some
guy emailed me to report my game had built itself, installed itself, and run
flawlessly under Solaris Sparc running SunOS! Libraries don’t GET any more
compatible! :slight_smile:

Also, which is easier to skip read and know the
difference of:

SDL_Something();
SDL_AI_DoSomething();
SDL_DoSomethingElse();

where the 4th character is almost allways varying, and
we have to check if it’s A…
You are assuming it would be used with SDL. Under libraries like Clanlib and
Allegro, we would want it to be clear that it’s using SDL functions and
features.

SDL_Something();
SAI_DoSomething();
SDL_DoSomethingElse();

where the 2nd character only varies when using
different libraries, and it’s either A or D?
It is easier to type, but very very vague. I can just imagine myself writing
code with it, then rereading my own code years later. “SAI… …SAI?
Simple Audio Interface? Streaming Arithmetic Instruction? See Apes and
Immolate?” :wink:

Calling it SDL_AI imposes readibility strain, extra
typing, and alienates non SDL users.
I don’t think typing three extra keystrokes will damage my poor left pinky
very much, nor do I think it’s difficult to read - quite the opposite, the
name tells more about what it is. :slight_smile: There is nothing stopping anyone from
porting it to Clanlib or Allegro either, if they want to.

Even if it were media, AI would deserve it’s own entire library.
I’m afraid I don’t follow you. Using SDL would make this library MORE
portable, not less; Why retread ground that’s been tread before, code
functions that’ve been coded before, fight bugs that’ve been fixed before,
and cross-compile to platforms that’ve been ported to before?
“Compatibility?”

You’d wind up making a library 10 times larger, twice as ugly, and
considerably LESS portable and stable than if you’d just used SDL.

“Use the control panel, Luke. Advanced microelectronics designed for hitting
teeny tiny targets. That’s what it’s THERE for.” ;)On Saturday 14 February 2004 00:26, Michael Rickert wrote:

Many people thinks more that SDL is today as like a
game library
like Allegro. At the beginning SDL was made
especially for games.
So I understand the idea to create a SDL_AI lib. But
if you think
that it’s a problem with the definition, it could
also be renamed
to SAI, but I hope it would be as so easy to use.

Calling it SDL_AI would alientate, for example,
DirectX programmers, or clanlib programmers, or
_______ other library programmers, where _______ is
any sort of abstraction layer that overlaps SDL in
functionality.

But why call it SAI if it’s NOT tied in with SDL? Just call it AI.

I think it means “Simple AI” - that is, nothing to do with SDL,
really. Just a way of reducing the risk of confusion with any other
AI library projects.

That is, unless you’re actually USING the nifty features that SDL
has for libraries:
[…]
Let’s face it, there are a hell of a lot of REALLY GOOD REASONS to
use SDL as a library base. :slight_smile: As far as I’m concerned, SDL’s the
multimedia equivalent of stdio.h. Why reinvent the wheel? And it
would still be possible to port this library to things like clanlib
if you want.

And if it’s using SDL, I think it should be clear that it’s using
it. Nothing pisses off programmers more than finding out this nifty
new program/library requires ten billion weird dependencies that
weren’t even implied. (cough madplay cough) Calling it
SDL_AI_whatever() makes it’s use of SDL pretty clear, I believe.

I think calling libs SDL_ should be strictly reserved for
libraries that really depend on SDL for good reasons. Anything else
is just confusing, and implies that it would be futile to try and use
the lib without SDL.

For example, the Unnamed Audio Engine of Kobo Deluxe, that eventually
became Audiality, could have been called SDL_aengine or whatever.
However, it soon got support for other I/O backends (actually, OSS
audio was there before the SDL audio support!), and the next release
will probably make the SDL support optional. Having “SDL” in the name
would just be misleading.

I think an AI lib is even more likely than Audiality to eventually end
up without requiring SDL, especially since it doesn’t really seem
like an AI lib would depend on anything strictly SDL related in the
first place. (Threading, integer types, endian handling and that kind
of stuff is hardly multimedia specific, and there are plenty of other
APIs and libs for it.)

Alienation causes lack of support, lack of support
causes lack of contribution, lack of contribution for
an ambitions project such as a general purpouse AI,
even if just for games, would be fatal to the project.

I would wager that SDL is more popular and supported by many more
platforms than libraries like Clanlib and Allegro. I remember when
I released the makefiled source code for my SDL Crossfire remake -
a few days later, some guy emailed me to report my game had built
itself, installed itself, and run flawlessly under Solaris Sparc
running SunOS! Libraries don’t GET any more compatible! :slight_smile:

That’s a good point, and a good reason to at least support SDL, even
if your lib isn’t strictly or directly multimedia related. It is
pretty likely that your code won’t compile on some platforms if you
rely on POSIX or other Un*x related standards, or even stdint (!), so
using SDL when it’s around is an easy way of improving portability.

Obviously, it also makes a lot of sense if it’s likely that many users
of your lib will use SDL as well, which I think it the case with an
AI lib.

Also, which is easier to skip read and know the
difference of:

SDL_Something();
SDL_AI_DoSomething();
SDL_DoSomethingElse();

where the 4th character is almost allways varying, and
we have to check if it’s A…

You are assuming it would be used with SDL. Under libraries like
Clanlib and Allegro, we would want it to be clear that it’s using
SDL functions and features.

Why? The next release might support stdint and POSIX stuff as an
alternative to SDL, and then it would just be confusing to have "SDL"
in the name and/or symbols…

SDL_Something();
SAI_DoSomething();
SDL_DoSomethingElse();

where the 2nd character only varies when using
different libraries, and it’s either A or D?

It is easier to type, but very very vague. I can just imagine
myself writing code with it, then rereading my own code years
later. “SAI… …SAI? Simple Audio Interface? Streaming
Arithmetic Instruction? See Apes and Immolate?” :wink:

Doesn’t that apply to SDL or any other TLAs as well…? :slight_smile:

Calling it SDL_AI imposes readibility strain, extra
typing, and alienates non SDL users.

I don’t think typing three extra keystrokes will damage my poor
left pinky very much, nor do I think it’s difficult to read - quite
the opposite, the name tells more about what it is. :slight_smile: There is
nothing stopping anyone from porting it to Clanlib or Allegro
either, if they want to.

Except that you’ll have to do some silly search’n’replace in both the
lib and applications for no real reason…

I used to think APIs were supposed to abstract lower levels and
internals away, but I could be wrong. :wink:

Even if it were media, AI would deserve it’s own entire library.

I’m afraid I don’t follow you. Using SDL would make this library
MORE portable, not less; Why retread ground that’s been tread
before, code functions that’ve been coded before, fight bugs
that’ve been fixed before, and cross-compile to platforms that’ve
been ported to before? “Compatibility?”

Good point, but it has nothing to do with the AI lib’s name or symbol
naming conventions…

You don’t don’t have to call all games using SDL SDL_, do
you? Why should that apply to libs - especially when they have no
strong reason to depend specifically on SDL and only SDL?

You’d wind up making a library 10 times larger, twice as ugly, and
considerably LESS portable and stable than if you’d just used SDL.

Uhm, I think an AI lib would need like one or two pages of “#define
spaghetti” to cover what it needs that isn’t ANSI/ISO C… That’s the
case with EEL (the scripting engine of Audiality), and I think that’s
pretty similar to an AI engine in this regard. It should be
possible to do entirely in ANSI/ISO C, but then you’d have trouble
with stdarg, signal handling, file path manipulation and some other
stuff that tends to differ slightly across platforms.

“Use the control panel, Luke. Advanced microelectronics designed
for hitting teeny tiny targets. That’s what it’s THERE for.” :wink:

…but he did just fine using the… uh, source, right? :wink:

Which is actually a rather close to what I’m getting at, I think.

SDL is a source matter; not an interface matter, seen from the POV of
a library. You’re supposed to use SDL - not tell the world about
it, enforcing funny naming conventions upon applications that don’t
really care how you get the job done. Leave that to marketting, if
you want to flash that nice new SDL logo. :slight_smile:

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
http://olofson.nethttp://www.reologica.se —On Saturday 14 February 2004 19.42, Tyler Montbriand wrote:

On Saturday 14 February 2004 00:26, Michael Rickert wrote:

This thread is off topic, so I’ll sum up:
Great idea, lots of people could probably use such a library, but it’s
not specifically tied to SDL so it should probably use a different
naming convention.

Please send other replies directly to the author of the e-mail.

Thanks!
-Sam Lantinga, Software Engineer, Blizzard Entertainment