Brain Research:

Silver linings always nice but I believe you should reconsider your position there, Dan. Min's not complaning just for fun, he brings up an actual problem with the interface that limits developers ability to produce anything even slightly close to what has been done one the Mac (possible though, eh)

It also should be pointed out that paid, professional programmers are not needed to bring results.. it will take time regardless.

DANTHEMAN! wrote:

So, I'm saying that if I scroll around, SOMETIMES you can't see your lgm on the screen... same goes for an lgm that is touching a wall... you can't see it touching a wall. Perhaps your brain should be checked.

You know, sometimes your lgm can be on a different area of the map.

The brain interface isn't given the exact location of your lgm when its not within the scrollable area around your tank.

Min

DANTHEMAN! wrote:

I've expiremented with building a brain in the past, not seriously, but merely as a recreational activity and like you, to learn some C. I understand Min's complaints about the brain interface, but I don't think they will be a real obstacle for somebody who is merely attempting to have some fun.

if your just looking to 'have some fun' then your correct, nothing in the brain interface will become a problem, your brain will just suck. Just like all the other current winbolo brains.

DANTHEMAN! wrote:

However, Min feels the need to bitch, and I have no issue with that.

actually, opteron asked a question, and I responded, it has nothing to do with my 'need' to bitch, I hope that jm changes some of the brain interface, but I'm fairly certain he's happy with how it currently functions. but i've had this discussion with jm, and I have no real need to say it again here.

DANTHEMAN! wrote:

I don't believe that winbolo brains will ever be as good as human players unless some serious, paid, proffesional full-time developers are put on the project, which is highly unlikely. Therefore, I see no reason for a perfect brain interface to be implemented.

I've been paid to proffensionally code programs in the past, I've spent some serious time looking at the brain interface, and determined it will not support a AI player even as good as a human player, period. At least not in its current form, a few small changes to how the object list is updated, and I'd definately give it another try.

Min

Operon wrote:

Probably I did... So tell me, this information is there, even if it's a lot of extra work to process, correct?

The information I want, isn't availible, period. The information I want, is weither a pillbox is in a tank or not, there are some other related information bits I also want, but can't obtain. The way winbolo deals with letting the brain know about different objects, is if the object is within viewable range (scrollable distance from the tank, 24 squares if I recall correctly) The object is listed in the 'object list' this is defined as 'ObjectInfo *objects;' in the brain.h header file. However, the pillcounter gives human players basic information like if a pill is dead, or not dead, in a tank or not in a tank, this information isn't provided in the object list, only objects -on- your screen are shown, such as bullets, bases, tanks, and pills, if the pill is on your screen, it will be shown there, so the logical thing to do is setup a array to keep track of base and pillbox locations and ownership right? ... well, lets say you kill a pillbox, its listed in the object list as 'dead', you die, its no longer on your object list becuase you can't see it, lets say an enemy tank runs over and picks it up, this information isn't related to the brain in any way. So there is no way for the brain to know weither that pill is still dead, or alive, or captured, unless you drive close enough to notice its not there anymore, and update your pill list. This makes it extremely difficult to actually program the brain to do anything strategical, like for example you kill a pill, die, respawn, and think that pill is still dead even though an enemy just picked it up, so if you code the brain to run over there and try and recover the dead pill, well, it doesn't realize its already been picked up, nor does it know if the pillbox is in a tank or not, so if your fighting a brain, and you keep all your pills in your tank, it won't know about any of them, and think they just don't exsist. This makes it pretty damn hard to program a brain that does anything more than hardline every pill it see's. If the object list was updated in a way that actually provided relevant data, like having the pills listed in the object list, but have no coordinates, or have a flag that says its in a tank(enemy or ally would be useful) then I'd give another go at building a brain that can actually give a human player a hard time. All I want, is the relevant counter data that any human player has, to also be given to the brain, like when a base changes hands, or a pillbox changes hands, even if you can't see it, the brain should know. However, I definately recommend trying to build a brain if your a beginner programmer, its definately an enlightening experiance, just don't expect to build something impressive until the interface is changed.

Min

Min wrote:

...However, I definately recommend trying to build a brain if your a beginner programmer, its definately an enlightening experiance, just don't expect to build something impressive until the interface is changed.

Min

The information you feel is lacking would be required for a Brain to truly compete with a skilled human player - or even participate as a team with other humans versus humans. Human players have an edge on information with regard to bases and pill status. No argument there...

However, I just ran a little experiment on an old Mac emulator I got working - a 4 brain bolo game with two ladma .6s vs two indy 3.1s. To make a long story short, the Indy 3.1 was efficient, intelligent, and if something was developed to that level, I'd consider it quite successful.

My in depth analysis... :)

Indy 3.1 was obviously superior to Ladma. It would occasionally "hardline" pillboxes, but more often it would use walls or even team up with it's allied partner and easily take pills. Even when it hardlined, it would only do 1 run, then build a wall, line it up and finish it off taking no further damage. They would shoot friendly pills to anger them when enemy tanks were nearby, they would "clean up", by retaking friendly pills that were placed in a tank battle but doing no good away from a base, they intelligently placed pills around bases (somewhat), and would spike enemy bases to sometimes decent effect. The brains had all the bases on Everard Island - I didn't have any map packs and this map presents significant pathfinding challanges - within a few minutes of game start and immediately moved on to taking pills and challanging the other teams bases...

More in the vein of our discussion, however, Indy and ladma brains BOTH send messages to allies on base status and pill location each time they come across a new object or if it's status had changed significantly (base stocks/pill health). It also appeared they could not tell the difference between neutral and enemy player pill, or whether another tank carried pills or not. Sometimes when full strength they would ignore a damaged enemy player tank even if it had pills on board and go take a base or something else. Ladma seemd more intelligent in it's handling of existing pillbox placement as it would occasionally switch to a pillbox view and check status, Indy didn't appear to do this.

So here's my thoughts on what you can do...

You can still track pills on board of the brain tank and allied "brain" tanks by either tracking bearing and distance of a destroyed pill and your own tanks vector and position. When they all converge within a certain minimum, you know the tank has picked it up and can store that. Friendly tanks running a similiar brain could pass info along on their own on-board pill status the same way. Tracking team pillboxes is also easy, you can cycle through the pillview and simply count them. Determining the total of enemy held, neutral, and carried pillboxes is simple subtraction from the your teams total, you just don't know how many of each category. You could technically keep track of neutral pillboxes that are taken as you get the flag on whether a pill is neutral or enemy controlled when you see it. If the brain gets the positions of all neutral pills at the beginning, it's can simply track each time it passes where a neutral pill was whether it is still present or not. Even if it was taken and rebuilt on the same spot, the flag would be enemy and not neutral.

So despite the fact you could never give an experienced player too much of a fight, you could handily take on a newbie for now... Just leave in commented out code for the extra features so someday if they are added in it's simple to add functionality?

I thought the bot was called Ladmo. I could be wrong, though.

It also appeared they could not tell the difference between neutral and enemy player pill, or whether another tank carried pills or not.

From the "How to write plug-in brains.txt" file:

Bit 0 of the info field (OBJECT_HOSTILE) is set if the object is hostile, and clear if it is friendly.
Bit 1 of the info field (OBJECT_NEUTRAL) is set if the object is neutral -- ie it is not currently 'owned' by any player.

So I guess they weren't able to properly figure out how to distinguish between enemy and neutral in terms of pillboxes.

And the second part of your sentence permits a huge problem to bots and is something that Min -- as you can tell already -- has huge gripes about. In the type of game that 1.14 has brought about, pills are the center of the game. If a bot cannot make a decision from lack of information, it can be fatal.

Sticks wrote:

I thought the bot was called Ladmo. I could be wrong, though...

You say Ladmo, I say Ladma, but yeah, I think you're right... So yeah, I agree, you could not make a really competitive bot w/out the stuff Min wants... However, that doesn't mean it can be coded in and commented out until implelmentation of possible new features occurs. In the meantime, you can make a pretty decent brain that at least serves to provide cannon fodder and/or fill up a human team game with "random elements" :)

It would be cool if someday Bolo supported (maybe it does already) persistant type dedicated servers that would load and unload brains as human players joined or dropped and if a map was won or all the human players dropped, it could automatically reset itself...

I've already coded a brain that can wander, pathfind, collect bases fast, once I got to the avoid pills stage, I realized that it was pointless to continue. If you want a brain that might be able to beat a newbie, thats what ryan2 is for, I have the indy code, its not that comphensive, and wouldn't give even a new player much of a challenge in a winbolo setting. My goal was to build a bot that can destroy a newbie on a popular map like chew toy 3. Becuase I can't even build a array that will sufficiently detect pillbox movement (becuase the only way to tell if a pillbox has moved locations from the place you recorded in your pillbox array is to drive close, and see if it appears on the object list again) I decided it wasn't worth further effort. You have a very limited amount of time to do calculations ever think call, otherwise the game will crash (if I recall correctly, 10milliseconds or less) and I don't want to be wasted time doing a ton of checks for pillbox movement. You can build a bot that hardlines a pill or 2, and plants them beside a base, then dies, and tries it again randomly someplace else on the map, but this sort of bot will get annhilated vs even a new player who plays serious strict tournament games. I've played and easy beaten 15 ryan2 bots vs me ... and in short, thats pathetic.

Min

Min wrote:

I've already coded a brain that can wander, pathfind, collect bases fast, once I got to the avoid pills stage, I realized that it was pointless to continue...
Min

You know, I wonder... Could you kinda do a hack to get the information you need? In other words, seeing as the information isn't currently available, but it is in the network packet, could you write an application tha intercepts each network packet to extract the data a player gets and then pass it onto the brain function? Obviously, I don't know how much about the structure of dlls and if multiple executables can be linked to them or whatever... But it'd be a cool way around the problem if one could do it.

Of course that would all assume the network organization has been released from the author...

As far as ryan2 goes, I'm sure it's an ok brain, but it's infantile compared to what I saw the indy 3.1 do... Even considering the Indy bot had the same info limitations, it appears to have a variety of single and multiple pill takes to reference and would succesfully complete them in an amazingly short amount of time... ryan2 is rather pathetic in that regard imo.

Operon wrote:

You know, I wonder... Could you kinda do a hack to get the information you need? In other words, seeing as the information isn't currently available, but it is in the network packet, could you write an application tha intercepts each network packet to extract the data a player gets and then pass it onto the brain function? Obviously, I don't know how much about the structure of dlls and if multiple executables can be linked to them or whatever... But it'd be a cool way around the problem if one could do it.

maybe, but if I recall correctly, you have to agree to terms and conditions when you install the game, and I'm pretty sure it says in there you can't hack the game. Also it would require intercepting a packet and dissassembling it, hoping to find out exactly what kind of information is stored in one, and if the info packets are serialized, it might be a bit tough to get any relevant information from them.

Operon wrote:

Of course that would all assume the network organization has been released from the author...

It hasn't been.

Operon wrote:

As far as ryan2 goes, I'm sure it's an ok brain, but it's infantile compared to what I saw the indy 3.1 do... Even considering the Indy bot had the same info limitations, it appears to have a variety of single and multiple pill takes to reference and would succesfully complete them in an amazingly short amount of time... ryan2 is rather pathetic in that regard imo.

ryan2 sucks bad, it just goes on land, and hardlines the nearest pill or tank that it see's. I don't really see the point of coding a bot that can do a couple pilltakes, but then can't do anything after that. I was just getting into pill avoidance in the brain I was building, pill/bullet avoidance. And also coding in some semismart base running techniques.

Min

Min was looking towards the bigger picture and upon seeing that he could not succeed at his goals with the given limitations, decided to drop it. If he wasn't actively putting his time and skill into a similar effort, I would call him a flake.

If you ever stumble upon my "brains" you'll find they only do one thing (and do it really crapily). I tried to build bots that would do one thing and one thing only. One was to find an enemy pill, build blocks, line up the aim correctly, and kill the pill. The other was to find any neutral bases, take them, and rape and kill any enemy bases found.

Point is, we both had different scopes of what our bots should do. I firmly believe in building a bot with a high cohesion and low coupling. A problem with what you say, Operon, dealing with writing code now and then just uncommenting it later is that for one, we have no idea what the interface will be! Therefore, we cannot write actual code, just psuedo. Another problem would be that with our new-found access, I'm sure that this code would find it's way into may other "components" or functions. So writing a block of psuedocode won't really do much when it's scattered all over and relates to functionality that we have no idea if it will be implemented or not.

Min wrote:

If you want a brain that might be able to beat a newbie, thats what ryan2 is for, I have the indy code, its not that comphensive, and wouldn't give even a new player much of a challenge in a winbolo setting.

You have the AIndy code? The one brain that seems to be above all? The one that seemingly can learn and do pilltakes on it's own?

If so, give that shit up so I can take a crack at porting it.

Sticks wrote:

You have the AIndy code? The one brain that seems to be above all? The one that seemingly can learn and do pilltakes on it's own?

If so, give that shit up so I can take a crack at porting it.

if I had Aindy, I would have distributed it to you already sticks, you know that. I have the Indy code. And as I said, not that spectacular. Just a finite state machine with "explore, build base, get pills, refuel" in it basically, and then hardcoded behavior for each.

Min

Min wrote:

Not that spectacular. Just a finite state machine with "explore, build base, get pills, refuel" in it basically, and then hardcoded behavior for each.

Sounds an awful lot like FI.

CF

Is there a reason we can't get the source for aIndy? I mean, Bolo's all but dead and whatever life is left exists in WinBolo. Reading Wayback's cache of the MIT project says that they gained the source for Indy 2.02, aIndy, and Std Autopilot simply by asking for it. Could it be that easy?