AIArena

[Ali Helmy]

Hey mates,

Anyone up for making our own open-source implementation of BattleCode or something like Project Hoshimi?

Could be cool... could try and make it all the way from a complete RTS (like C&C or WC, but with no human player), or maybe a group of AI players (think Quake, GhostRecon or Rainbow6 team deathmatches with objectives) or maybe even MortalKombat or Street fighter, or maybe all of these together?

Get the big picture? I'm looking to making an AI sandbox that might be fun to implement and playwith... could even use it to try out some Physics simulations... or some ready made Physics APIs... whatever, just for fun and just some random thoughts here...

Anyone interested?

---

Cheers,

seth

<A. Helmy>

One life... LIVE it!

[Ali Helmy]

Safy, mob & elian... excellent, couldnt have asked for a better lot :)

Anyway, here are my first VERY quick thoughts on the topic... 

USAGE:

1- interface will be a simple GUI from which to choose game-type, map, player-ai (more on this later) and all other various settings, and then a button to start the game simulation

2- game simulation: a new window is launched (whatever res) in any rendering engine (OpenGL preferably) which gives the players a view of what is going on in the game, the current turn, health etc... more discussion on this later (2D vs 3D vs isometric... show whole map or only bot-visible parts, etc etc etc)... this interface has 3 main components: a-main area for drawing all the game simulation b-HUD for displaying bot-specific info (health, ammo, armour, etc) c-options pane for user activity

CODING:

1- i think the way project hoshimi worked was ideal... we create an API, and the user then links the header files (yes, i said header, since i think C++ will be more relevant, but nevermind implementation issues now) and compiles with a provided make file to produce a dynamic lib for his/her AI team... then at the gui screen mentioned above, you select the armies u wanna pit against each other, by selecting the lib files...

2- not to get into too much detail here, but just quickly, the user will have two main classes to necessary code (and then any other optional ones he can add as he likes), one is the ArmyAI which is basically his army, on which he controls everything, and the others are bots that inherit a certain BOT class that do everything in the game itself...

3- every turn, the game engine will call all the players' ArmyAI::Think(), which will in return give back and array of actions for each bot on the user army... game engine will take these actions, do necessary math, render results on screen and so forth with the game loop... you can find an oversimplified flow-chart version of the engine attached here in ODG format, or for those of you still stuck in Closed-Source Document Hell, you will also find a PDF of the same...

4- player gets info he needs through a- game object ref, which includes methods for getting the current turn, objectives, etc... and b- his bot objects that have methods to get their stats and methods for states (like CanSeeEnemy() or IsUnderAttack(), etc)

Final Note: all this is just a quick jolt of energy i got right before going to bed... im mostly in favour of using C++, OpenGL & OpenAL... i wish to use them (as well as wanting to write down my own engine instead of using a ready one) because they will help me learn a LOT i wish to get more familiar with (namily, C++, opengl, openal, physics, etc), but hopefully these will be modular enough, so that maybe they can be then replaced down the road by more powerful GFx, Audio & Physics engines...

As always, comments highly appreciated... in fact, they are recommended :)

[Ali Helmy]

Hey mates...

A good long 4 hours sleep, 3 Red Bulls and 2 Pepsi's later... here is the latest episode of the open AI Arena design series... as always, just random thoughts put down on paper (i really should try to get these together in some doc of sorts... just dont really have much time)

ok, now enough of docs and boring c*@p and on to classes and other cool stuff :D

1- Starting & game launcher Interface will mostly be done in Qt (most portable on OS's and quite easy to learn and flexible)... the launcher button will launch an OpenGL window, and the renderer will take on the rest from there...

 

2- Each game will have three classes:

a- map: has information on the terrain & other dimensional and navigational stats

b- game: has info on turn number, score, number of players, etc

c- mission: has info on objectives and their completions

3- Player has an ARMY class, which represents the God-like control of the troops...

4- for the player units, he can have members of either the building class, or the bot class... each can implement all or one of the interfaces: mover, shooter, repairer, builder, gatherer... so for example: 

a- tank factory that can construct tanks and repaier them would be a (Building, Builder, Repairer) while the an ultra-futuristic watch tower that can move would be (Building, Shooter, Mover), etc etc etc

b- bots will also be the same, while inheriting from the bot class, so medics will be (Bot, Mover, Repairer) while the ore-gathering tank will be (Bot, Mover, Gatherer, Shooter) etc etc

5- bot stats will be:

a- Sight: distance that can spot enemies within

b- Cargo: amount of ore/other troops (in case of transport) that unit can hold

c- Accuracy: chance of hitting the target (0 to 1, see later)

d- Speed: steps to move every turn

e- Armour: fairly self-explanatory, but read on later to see how it affects hits

f- Health: when 0, u die... simple

g- Weapons Class: [Optional] current class of weapon bot can carry and use

h- Ammo Count: [Optional] in realistic game modes, ammo can run out

5.1 - bot stats can also be made to increase with use (more shooting => accuracy++, more moving => speed++, etc)

6- Weapons stats will be:

a- Ammo Type: [Optional] to make different weapons use same ammo

b- Fire Delay: how much time bot has to wait before firing again

c- Accuracy: again, chance of hitting target, see later

d- Shot power: how much damage dealt on hit

e- Damage radius: example: bullets have radius = 0, bombs = 5, etc

f- Class: [Optional] to see if bot can carry this weapon... it is calculated from the stats above... the higher the stats, the higher the class, so only more advanced bots can carry it

7- each player must create a spawn point from which, he must first create his first builder bot... and then enjoy from there on...

8- typical player scenario would be to create a number of child classes that inherit from bot and interfaces to define your soldiers... then inherit some buildings and some weapons... then on each Think() tick your Army gets, you call your own AI engine and then return an array of actions of what to do, and whos doing it (2D array of Actions & bots/buildings)... maybe even a very smart dynamic AI that adjusts its bot & building classes on the fly to incorporate new tactics? :D:D

9- building, bot & weapon stats must be limited, so player cannot create super units... like for example, for bots there are 8 stats, each can be from 0 to 10, but a maximum of 30 is allowed in all the stats... and if the player creates a class that violates these rules, game will tell him on game start, and this unit will be discarded from play...

10- Accuracy effect: should incorporate distance of shot, bots accuracy, weapons accuracy and a bit of luck :)

when a bot shoots at another (say BOT1 shoots from [5,12,6] at BOT2 [2,19,-3] )

a- line distance between two points is calculated, lets call it (d)

b- shot offset = (1 - (UnitAccuracy * WeaponAccuracy)) * d, lets call this (off)

c- actual offset = rand, where rand is random generated number, and 0 <= rand <= off... lets call it (accOff)

d- accOff is added to the Shot vector's coords (x,y,z) thus distorting where the shot lands... maybe it still hits the target, maybe it hits nothing and maybe it hits a friendly... this way, it would be better for ill-shooters with bad weapons to shoot from close-up, and good shooters (snipers) would have an advantage shooting from far away

11- Radius Effect: when a shot hits, any bot caught in the effect radius gets affected by shot equal to:

a- line distance between bot and position where shot landed, lets call it (d)

b- shot effect radius, lets call this (r)

c- hit power = ((r - d) / r) * shot power...

so bots at the point of impact would get ((radius - 0)/radius) * shot power, which is total shot power... while those at outer edge will get ((radius-radius)/radius)*shot power, which is 0... anyone outside the blast radius need not be considered

12- when shots do hit bots, effect on bot health will be determined by:

a- if shot power < armour, armour = armour - shot power

b- else, armour = 0 & health = health - (shot - armour)

PS: sorry for the very long mail, thats just a spill of my thoughts & ideas right now... as always, comments highly appreciated

as for when we can meet... well... 

:)

[Ali Helmy]

On 19 Dec 2007, at 04:59, Ali Helmy wrote:

10- Accuracy effect: should incorporate distance of shot, bots accuracy, weapons accuracy and a bit of luck :)

when a bot shoots at another (say BOT1 shoots from [5,12,6] at BOT2 [2,19,-3] )

a- line distance between two points is calculated, lets call it (d)

b- shot offset = (1 - (UnitAccuracy * WeaponAccuracy)) * d, lets call this (off)

c- actual offset = rand, where rand is random generated number, and 0 <= rand <= off... lets call it (accOff)

d- accOff is added to the Shot vector's coords (x,y,z) thus distorting where the shot lands... maybe it still hits the target, maybe it hits nothing and maybe it hits a friendly... this way, it would be better for ill-shooters with bad weapons to shoot from close-up, and good shooters (snipers) would have an advantage shooting from far away

CORRECTION:

the above proposed algorithm would take the distance into effect 2 times, once when calculation, and then once again when the shot is fired, since affecting the vector, means the shot will steer away from target, farther and farther as it moves... 

to correct this distance needs to be removed from the calculation since its effect is present by the alteration of the "bullet" direction...

thus, refined shot algorithm would be:

10- Accuracy effect: should incorporate distance of shot, bots accuracy, weapons accuracy and a bit of luck :)

when a bot shoots at another (say BOT1 shoots from [5,12,6] at BOT2 [2,19,-3] )

a- shot offset = (1 - (UnitAccuracy * WeaponAccuracy)), lets call this (off)

b- actual offset = rand, where rand is random generated number, and 0 <= rand <= off... lets call it (accOff)

c- accOff is added to the Shot vector's coords (x,y,z) (shot direction) thus distorting where the shot lands... maybe it still hits the target, maybe it hits nothing and maybe it hits a friendly... this way, it would be better for ill-shooters with bad weapons to shoot from close-up, and good shooters (snipers) would have an advantage shooting from far away

[Ali Helmy]

On 19 Dec 2007, at 11:50, mobasher helmy wrote:

>>as for when we can meet .. well ... 

do u think this is really gonna work through email only !! ??? here is a big failure .. i think we MUST meet ... a face-to-face discussion of 30 mins is more effective than 30 emails explaining the project ... 
Also, you can't start a project saying "hey, enough old talking and let's jump to the implementation and classes" we must have a design phase, and even before this one, an open discussion phase. 

I don't mean to depress you mate, never ! .. but the point is that if you wanna do things you gotta do them right, right ? 

you ever joke about anything? :)

happy eid ya man

[Ali Helmy]

more quick updates:

Point 1: to make sure bots dont cheat (ie, move farther than they can, etc) bots themselves cannot execute any actions, instead they call the API functions to execute certain actions... 

for example to move, the bot would call Engine.getInstance.move() and then send it a ref of itself and the position to move to... the engine would then check the distance it can move, and check any other collision detections necessary (bots blocking, map limit, cliff, etc) and then return to the bot a point in the world where the actual move made it end up to

to shoot, the bot would call Engine.getInstance.shoot() and also send it a ref of itself and the vector to shoot in direction, etc etc... and then for every hit target, the engine calls Bot.getHit() which takes the value of damage and returns a boolean saying whether the bot died from the hit or not...

this would have 2 benefits from my point of view:

1- it would allow the engine to tell the bots to think, get back their replies and then animate for a while, and then repeat... which would allow us to add in model animations for the gfx side

2- it would make sure bots only execute things as specified by the rules... as mentioned before, the Game object will hold the rules, which might, for example, prevent bots shooting & moving in same tick... this way, if everything goes through the game engine, we can check the rules on every bot

3- again, because everything is centralised, we can later on add plugins (like physics libs, etc) to better enhance the simulation

Point 2: i think it will be best (for viewer purposes) if the simulation is first computed, and then the whole events displayed as a whole... this would have the following benefits:

1- replays can be shared,by sharing the log file (if u wanna show off to ur friends or demonstrate something)

2- separate computations from gfx, thus cooling down on the CPU loads

Point 3: of-course, nevermind the exact implementation details, its just that i, unfortunately, think in code as default mode :)

[Ali Helmy]

hey mates,

after trying out and playing around with parallel programming at work for some time now, naturally im thinking of incorporating parallel processing in the openAIArena... this prob will be two folds

1- using OpenMP to make use of local processor multi-cores (like most of the processors running our machines these days)... these are simple compiler directives that automatically access the c++ runtime and address multi-cores and organize the work... of course, it is not that simple but its one of the simplest parallel programming APIs...

2- the second step will prob take a bit more work and be a bit more advanced, which is to use some sort of Message Passing Interface (MPI), like the one im accustomed with (OpenMPI), to distribute the work amongst a cluster of machines...

the basic idea would be, openMPI distributes work onto machines, and openMP breaks down the work into different threads on every machine

ideas? suggestions?

--
Cheers,
     Seth
     <A. Helmy>
==================
  One Life... LIVE It
==================

[Ali Helmy]

Hey mates,

one more thing... as for the gui, what do you guys suggest we use for the first interface gui (some basic game type selection and some files for loading the ai dlls...)

requirements are:
1- cross platform (win/linux/mac os x)
2- does not need any installation on the target machine, so that user only compiles with the AIArena SDK... this means that the lib has to be fully included with the downloaded files, not having to go through a lengthy install...
3- preferrably open source, but at the minimum, must be free

so, my first choice is Qt... any ideas, suggestions?

[Ali Helmy]

On 28 Dec 2007, at 14:51, ramy emil wrote:

For the first time I participate on this group.
I have some experience with parallel programing and MPI.
I'm willing to participate in this project.
Keep up Ali with your enthusiasm

Welcome aboard mate :)

Yeah, i remember your grad project was about that, so u can definitely be of use... EXCELLENT :D

[Ali Helmy]

just as a side note, i think we also must have some mode of debugging (with both a log file and some console output onscreen or on the console running the program) so we can easily debug problems...

[Ali Helmy]

More points:

1- in the next few days, i will be looking for an online free wiki hosting service, so we can collect all the data in the emails into a decent looking site, and then people from culug or the aisoc can edit it as they please

2- since im learning opengl and wanting to learn more about gfx, i want the design to be modular, so we can later on improve the visual presentation, so here are 2 points regarding gfx:

1- bot models: will all be done using some sort of 3d modeling application (as the artists please) and not directly drawn on scene (with opengl hard coding), so this way, we can later on improve the models and animations... the format for the 3d models will each have to have a plugin for the gfx engine to handle them (more on this later)

2- each bot will have: a body, a head and at least one weapon model... for example, a tank will have its body be the tank and tracks, the head will be the turret, and the weapons will prob be the main cannon and a machine gun... while a mecha robot will have a body (torso+legs) and a head and weapons (maybe attached to the arms)... but this will basically be a bit advanced... for the first step, all will be represented with rectangles... the adjusting of the model for the specific animation (move, look, shoot at certain point) will have to be handled by thought of later on...

3- all of the engine must be composed of building blocks... ie: the gfx, physics, sound and all components can be replaced and are loaded at start-up through shared libs... also, all the engines will be pluggable and extensible, including the rules engine, so one can create new games (by allowing some bots to fly, some to go underground, some to have more than three weapons) etc etc etc

[Ali Helmy]

hey mates, new updates and ToDos...

=============================================

A: in order to be able to parallelise the code more, to allow for parallel and/or distributed execution of the code, here are a few pointers

A.1: players will not have a central Army::Think() command, but rather, every unit (bot or building) that the user has will have a think() function... now the operation will be like this... on every turn, the engine will call Army::GetUnits() which will return an array of all the players' units to be active this turn (user can select to only move "some" of their units by returning a subset)... next, the engine will call the Unit::Think() method, which will then place any number of Command objects into the commands pool... Each command will have an action to be performed, along with optional parameters... so in each turn, a Command Array will be formed indicating what every unit in the game will do in this turn

A.2: to achieve better parallelism, two thread pools will work here... one group of threads will call the Think() method on every bot returned in the array in every army's GetUnits() call... and then, another group of threads will go over the commands and execute them...

A.3: i will, in the future, try to set-up a cluster so that people can do the math there and then download the replay files to view on their clients (more on this in part B)

=============================================

B: calculations and AI decisions should be done APART from the GFx rendering & sound... ie: first the engine simulates the whole match, and THEN it shows the result to the user... ie: there would be some format of game replay, for the engine to be able to run for users to watch later...

benefits:

B.1: free up on CPU power to produce the simulation, then concentrate on cooler gfx, etc

B.2: maybe even use GPGPU in the AI & calculations?

B.3: users might be able to "pause" & "resume" the game calculations at any time, and may also save the state of the computation to continue later

B.4: users may compute the simulations on other dedicated clusters, or maybe download ready made AI source code as well as demos for them in action... 
=============================================

C: Project wise:

C.1: I have set up a free wiki for the project HERE, and i will try and transfer all the knowledge in this thread to over there...

C.2: i will set up a project on some of the free project hosting sites, and then i will set up a code repo (CVS/SVN/etc)

C.3: i am setting up a machine at home to be a build-monkey, that every night will: check if there are changes in the code, download changed files, rebuild project then submit nightly build to cvs server...

=============================================

thats mostly for now... keep u posted

[Ali Helmy]

Hey mates, news updates...

ive finally begun to put down code to the AI Arena and set up an svn account for it and project page at sourceforge.net... however, after careful consideration, im dumping ALL the code tonight, because ive started at the wrong end... coding, rather than design...

anyways, first things first, ill be posting the UML diagrams (mainly class, sequence and state) on the svn server... next, ill be putting down the code sequentially... ive decided on a few main things:

1- revert from my former "reinventing the wheel approach", and use pre-built 3D Graphics & Physics engines and any other libs i can find, as long as they are 100% open source and with a license that keeps the AI Arena free to use, mod and distribute

2- will use Qt 4 for the GUI, but also provide a complete command-line only mode of operation

3- provide a non-graphical mode of operation, where users can run the engine to compute a script detailing how the matches went, and another separate graphical mode to view the match play... this way, it will be possible to have users who only want to watch replays and other peoples strategies, and also maybe in the future build some online cluster to continuously try out different player AIs against each other...

4- approach building the Arena using the extreme programming principles... ie: build a working version very early on, and then build on it and add features with time...

stay tuned for more updates and news