|
|
|
| An AI Competition |
|
Crazy Photon
Member #2,588
July 2002
 |
Quote: I would think it is better if you create a program which uses a library interface, and ask programmers to build a library fitting the one used in the program (that is, you need to create the functions the program uses) to do something (in example, a path search function, a hide and seek algorithm, etc). Man, that was part of my compilers coursework PS.: One week before 25th all the tickets to Buenos Aires were already sold ----- |
|
Eric Love
Member #846
December 2000
|
A few years ago I went in a comp at C++ Home in which a game was provided, and you had to program a player for it. I worked out the optimum strategy for playing against the sample opponent, but didn't realise that it wouldn't be optimum against every opponent. |
|
BAF
Member #2,981
December 2002
 |
I think a better method would be a simple lib, where you loop getting messages + processing them. You use that to compile your AI to a dll / shared object, which is loaded when it is your AI's turn to go. |
|
Steve Terry
Member #1,989
March 2002
 |
Here is what I propose, a simple message system of inputs and outputs like any robot. It would be simple like move forward, rotate x degrees left, etc. Inputs would be that a sensor detects a wall or that the robot reached the goal. The actual board would be a simple maze with a goal, the robot would have somewhere like 4 sensors, 3 front, 1 rear, and circular in shape, it could simply be rendered as a colored circle with a line showing what direction it is pointed in. A simple game event would be something like this: Input: Of course it will be storing internally where it has been so it doesn't run back over a place it hasn't been. Then again a robot like this would never be able to solve a maze because it woudn't know where things branch off, but if you are smart enough designing it you could have it bounce off the walls as it goes in order to discover those branching walls. ___________________________________ |
|
Marcello
Member #1,860
January 2002
 |
So basically, virtual lego mindstorms? |
|
Steve Terry
Member #1,989
March 2002
|
Ok maybe that's too simple, but that's the basic inputs/outputs. Maybe I'm thinkign too robotic AI and not game AI, how about giving the players each goliaths and have them battle it out? ___________________________________ |
|
ImLeftFooted
Member #3,935
October 2003
 |
Quote: What's the point with having to log onto the server and watch? This will effectively exclude all dial-up contestants without any real reason. Hm, this is a valid point. I suppose both a video recording of the event and allowing people to log in and watch could solve this problem. That and designing the engine to use low bandwidth. Ok, so how many people would be interested to participate after a framework has been designed? Fyi, the framework would include functionality to find nearest players / allies / enemies as well as iterating through all visible players and possibly visible powerups if they're going to be in the contest, a simple tilemap engine and interface, some form of direction and speed interface as well as contest specific weapons / actions. So it would leave pretty much only AI code left to do along with maybe a few sin/cos to discover which direction to move in, fire, and understand where the other players are located. That is unless enough people who are participating would like the framework to be different somehow. |
|
kentl
Member #2,905
November 2002
|
Dustin Dettmer said: Fyi, the framework would include ... I bet you 5SEK that it will never be finished with the features you proposed. It's based on experience with other complex ideas presented as "It's just this, and this, and this" |
|
Steve Terry
Member #1,989
March 2002
|
The framework I think would be insanely simple with a message system, all the base system has to do is dispatch a few simple messages, the rest is done by the AI, a simple linked list and a function pointer is all you need. How about a battle tank game? Like the old atari classic, can't remember the name. You have a simple room with some walls, the bots start out on opposite corners and have to kill one another, we could give them 10 hit points or so and maybe even powerups randomly placed. The inputs would then be MSG_TARTET_IN_SIGHT and MSG_POWERUP_IN_SIGHT. There woudl be a small 30 degree "vision" area in front of each bot extending for some pixels. ___________________________________ |
|
Arthur Kalliokoski
Second in Command
February 2005
 |
I tried that A.I. stuff a few years ago, but it got way too expensive. They all watch too much MSNBC... they get ideas. |
|
Steve Terry
Member #1,989
March 2002
|
Heh we could have the winning bot yell out "I did not murder him!" at the end ___________________________________ |
|
Wetimer
Member #1,622
November 2001
|
I like the tank idea, I'd even be interested in helping to create the framework. My thoughts are, that perhaps we should use LUA as the language in which all the bots would be written. The program would expose a few very simple commands to the script, and call a single MsgIn() function for input. My second thought would be not to have a server. Rather, for each "contest" all AIs would be packaged along with a randomnlly generated seed. If everything is kept determinsic or based on that seed, then that is all that would be needed for everybody to run/view the simulation on there computer. It seems to me that would be simplest/cross-platform method of doing things. <code>if(Windows.State = Crash) Computer.halt();</code> |
|
ImLeftFooted
Member #3,935
October 2003
|
Winston I ran over the same idea of seeds myself, and maybe it is a fesible idea. It would certainly cut down on the development time and effort of the framework. I thought the networked idea would be cool and fun, with a little chat room embedded aswell. I suppose the question is how much effort / time do we want to put into the framework. Another problem with the seeding is making sure that people aren't seeding things themselves. And it feels like theres something I'm not seeing that will mess it up.. But maybe there isn't. The LUA idea sounds interesting. I think it might discourage people from joining the competition though due to having to learn a new language. Also I'm not familar with LUA but is it as powerfull as C / C++? How hard is it to make an interface from C to LUA? Would you have to reconstructed linked lists? What about data type incompatibilities? It just seems like a bit much to worry about, but its an idea. Oh and Winston, thanks for offering Edit: Grammer fix. |
|
Steve Terry
Member #1,989
March 2002
|
Oh I see you want like a process of elimination? Where two bots go at it and the winner moves on to the next round with a different bot? Final bot left is the winner? It does bring up an interresting idea on seeding though as I'm sure some randomness will be involved, as long as srand is not used it could be ok? That or you could run the competition real time and record every event from each bot and play back the replays that way, then it doesn't matter. ___________________________________ |
|
Wetimer
Member #1,622
November 2001
|
Quote: I thought the networked idea would be cool and fun, with a little chat room embedded aswell. I suppose the question is how much effort / time do we want to put into the framework. My thought: Design for the possiblity of later adding it, but at least for the first version, leave it at a local level. Quote: Another problem with the seeding is making sure that people aren't seeding things themselves. And it feels like theres something I'm not seeing that will mess it up.. But there isn't. Well, people can put any seed they feel like into it. But, there would only be one official seed, and probably you wouldn't be able to get people's programs to try against until a certain time. So as to prevent you from learning too much about the other bots and training to kill them specifically. Quote: The LUA idea sounds interesting. I think it might discourage people from joining the competition though due to having to learn a new language.
That is a good point. I'm inclined to say that people really ought to learn LUA. But, do we want to trust just any C/C++ code running on our computers? Especially those of us with "inferior" operating systems? Quote: Also I'm not familar with LUA but is it as powerfull as C / C++? I know that some people essentially just write low-level performance criticla function in C/C++ and then create the rest of their game in LUA. So, I believe while slower then C its probably just as capable. Quote: How hard is it to make an interface from C to LUA?
Its the Zen of programing... Just about. int FunctionCalledFrom(lua_State * l) { string s = lua_tostring(l,-1); lua_pop(l,1); int a = lua_tonumber(l,-1); lua_pop(l,1) // do funky operations lua_pushstring("Allright!"); lua_pushnumber(42); return NumberOfArgumentsReturned; } The only thing easier would be if Lua could call the C function directly. Some extra libs will even automate that process. (probably too complex for our purposes) Quote: Would you have to reconstructed linked lists? I've never actually needed to pass a list into or back from Lua (usually I do a lot of simple types, if the script wants to store them it can). Lemme check the docs... lua_newtable(L); foreach in list { lua_pushnumber(index); lua_pushstring(value); lua_settable(L,-3); }
Quote:
Oh and Winston, thanks for offering Do you want some alternate contact information? [edit] Quote: the framework would include functionality to find nearest players / allies / enemies as well as iterating through all visible players and possibly visible powerups if they're going to be in the contest, a simple tilemap engine and interface, some form of direction and speed interface as well as contest specific weapons / actions. So it would leave pretty much only AI code left to do along with maybe a few sin/cos to discover which direction to move in, fire, and understand where the other players are located. Ok, you were thinking it seems more along the lines of a omniscient tank. I was thinking more along the lines of a limited sensory input. So, in my theory, you wouldn't be just able to point and fire at anything, you'd have to scan and locate it first. <code>if(Windows.State = Crash) Computer.halt();</code> |
|
ImLeftFooted
Member #3,935
October 2003
|
Sure, which would you prefer. I have aim, icq, irc or phone. Email too but its a bit too slow. Edit: Quote:
I said: Another problem with the seeding is making sure that people aren't seeding things themselves. And it feels like theres something I'm not seeing that will mess it up.. But there isn't. Well, people can put any seed they feel like into it. But, there would only be one official seed, and probably you wouldn't be able to get people's programs to try against until a certain time. So as to prevent you from learning too much about the other bots and training to kill them specifically. That was supposed to be "But maybe there isn't." Quote: Oh I see you want like a process of elimination? Where two bots go at it and the winner moves on to the next round with a different bot? Final bot left is the winner? Hm this is a good idea. The system I had in mind was some form of dividing into teams and possibly dividing the winning teams again untill there was a winner. But your idea sounds more fair. |
|
Wetimer
Member #1,622
November 2001
|
I'm wetimer on AIM <code>if(Windows.State = Crash) Computer.halt();</code> |
|
kentl
Member #2,905
November 2002
|
Actually the whole tank idea is what RoboCode is, except implemented much better than you ever will be able to do in time. RoboCode started as a project at the R&D department of IBM and after a couple of years (this february) went to be GPL. Why not use it instead? If we are still going to have to learn another language why not go with Java instead of LUA? |
|
ImLeftFooted
Member #3,935
October 2003
|
I think we're going to stick with C / C++ as they are the native languages for Allegro. |
|
kentl
Member #2,905
November 2002
|
Just as LUA? Anyway good luck and start a thread about the competition when you are done with the framework. |
|
Specter Phoenix
Member #1,425
July 2001
 |
With everyone's college time schedules and personal lives I don't see how this would become a successful competition. It is a great idea but unfortuantely I am busy with my college classes so I wouldn't be able to partake in anything right now. I even had to back out of joining SpeedHack '05 this year:(. If you get the rules together and this becomes an annual thing then maybe I'll do it otherwise I won't have time for it.
|
|
Marcello
Member #1,860
January 2002
|
javascript >>>>>> LUA. In other words, LUA has got to be one of the worst scripting languages out there. Popular != good. Marcello p.s. jsgen makes c++<->js interaction easier than pouring a glass of water p.p.s. if the thing were written in java, you could link in rhino for javascript, and the java<->js communication is automatic via reflection. even easier. p.p.p.s. in fact that is an awesome idea, something like this as a java applet would be perfect. people could upload/download their codes, edit/run in realtime against other peoples' without downloading installing anything. p.p.p.p.s. so awesome I'd even be tempted to do it if I didn't have enough projects as it were. would be slick to do in processing with 3d. |
|
Wetimer
Member #1,622
November 2001
|
Big Blue Mean Man say mean things about my favorite scripting language... I like Lua.... Lua is like Ice Cream in the middle of August. Javascript is like sunglasses which make the world like dark and dreary... At any rate, the current plan is to provide a C interface, but perhaps to allow some scripting language to be allowed in as well. Probably LUA, and if Blue Mean Face is nice to us we'll think about javascript, my precious. <code>if(Windows.State = Crash) Computer.halt();</code> |
|
Carrus85
Member #2,633
August 2002
 |
I still like the server appraoch... Mainly because locking people into a single language sucks... sucks bad. Yes, it would introduce a large number of technicalities that would be hard to handle. And yes, it would mean "saved games" would be much harder to create (unless some sort of Client/Server based Random Seed Generator was used. Hmmm.....). But it would prevent "language lockdown" which is one of the most annoying things about almost all of these AI systems currently implemented. As for "it would make it more complicated than necessary," I'd agree, but only to some extent. The languages that are used more often (read: C/C++/Java) would have more people using them, and hence would have more of a user base that might be able to contribute a "language specific" iterface for the given library. So, for example, a C++ interface could wrap all the necessary inputs/outputs into classes that automatically handle the networking stuff behind the scenes. Java could behave similiarly, as well as python, ruby, even PHP. The coolness factor about this approach is that it allows people to even develop "interactive bots" that can interface with a GUI displaying stats for debugging, etc. or even allow human players to interact with the "bot world" to test their bots using their own inputs. Of course, this means the human would have to design a usable interface and make some sense of the inputs... but that could be fun all by itself. Of course, implementing this would be a pain in the royal donkey, but it would be cool none-the-less. Especially if one could actually design the specifications of the bots or something (for example, number of inputs, input types, number of outputs, output types, etc.)... Then again, I'm getting a little bit carried away
|
|
CGamesPlay
Member #2,559
July 2002
 |
The problem with making this too extravagent is just that. Presently, I'd say stick with a single program which runs all the AIs concurrently, with a C++ and optionally a C interface. -- Ryan Patterson - <http://cgamesplay.com/> |
|
|
|
(and coincidentaly, the something was "robot wars" 
, which inspired me to choose the topic for my thesis).
