- Feb 02, 2012
-
-
Sam Moore authored
Why did I make it black????
-
Sam Moore authored
Probably should have committed immediately after I did whatever the stuff was? Not several weeks later? I appear to have improved the vixen AI slightly Aha, I remember! Altered manager program so that two ports are used (4560 and 4561) instead of just one. This means you can use network controllers for both players, not just one.
-
- Jan 21, 2012
-
-
Sam Moore authored
Wasn't thinking straight with the initial approach Basically: - Each stratego program is running ONE AI program locally -> That AI's responses need to be sent accross the network to the other stratego program -> Each stratego program keeps state seperately and sends instructions to its local AI, so actual instructions (ie: "Its your turn") aren't sent - A special controller is needed to recieve the responses So we have NetworkSender, which wraps around an AI_Controller and simply sends its responses (exactly as they are) to the network and NetworkReceiver which waits for responses from the network. As far as networking itself is concerned, its not that important who is the Client and who is the Server. If an IP address is specified, then Client is used, if no IP address is specified, Server is used. NOTE: It isn't possible to use networking for both AI programs yet. (ie: stratego @network @network) will fail when the Blue server attempts to bind the socket already used by the Red server. I may consider fixing this at some point. Going to test on mufasa. I've just thought, if the stratego programs have different timeout sequences, there may be problems. Oh well.
-
- Jan 19, 2012
-
-
Sam Moore authored
Erm, now what?
-
Samuel Moore authored
Derp
-
- Jan 18, 2012
-
-
Sam Moore authored
Slightly confused about the client/server thing Server is going to run red Client is going to run blue Need to get them to talk nicely? Doesn't work at the moment - server can't bind socket, client segfaults (NULL pointer). Blergh.
-
Sam Moore authored
This is a temporary and not entirely effective solution, to prevent AI from spamming CPU useage to make their opponents time out. Yes I could use renice instead, but its just as easy for an AI to get around. I will have to replace this with a better solution. But I don't have one at the moment.
-
- Jan 12, 2012
-
-
Samuel Moore authored
-
- Jan 08, 2012
-
-
Samuel Moore authored
Added link to mailing list page.
-
Samuel Moore authored
-
- Jan 07, 2012
-
-
Samuel Moore authored
Thanks to Hipikat for pointing out some things that needed clarifying. Email matches or post in irc if there is anything else.
-
- Jan 06, 2012
-
-
Sam Moore authored
Previously AIs could respond with "NO_MOVE" whenever they felt like. Officially, now they can only respond with "NO_MOVE" when they have no mobile pieces left. (That is, only Bombs and the Flag are left). However the game should end by a VICTORY_ATTRITION condition as soon as either player loses its last mobile piece. So technically, "NO_MOVE" can't ever be legally printed, because the game should have ended. If it doesn't, there is a bug. Updated webpage, updated manual, updated README Going to email the list later today. Goodluck! PS: The rule change is due to a mean initial setup, for example: ********** ********** ********** BB**BB**BB ..++..++.. ..++..++.. etc Here, Red has placed Bombs in all three "lanes". Red is unable to move. However, as long as Red can use "NO_MOVE", an unsuspecting Blue will lose most of its pieces on the Bombs. (Unless Blue puts a miner up the front...) But anyway, being able to not move is silly and not allowed in the real game.
-
- Dec 24, 2011
-
-
Sam Moore authored
Minor bugs in the manager program fixed. Changed some messages for clarity, can't remember what, look at diff. Added VICTORY_ATTRITION; victory by destroying all of the opponents _mobile_ pieces (ie: Everything except Bombs/Flag) This means we don't get results of DRAW or DRAW_DEFAULT when one AI destroys all the other's mobile pieces. Since those games would last up to 5000 turns, this saves a lot of wasted time. AI should still respond with "NO_MOVE" when they have no mobile pieces. Made timeout value adjustable by an argument switch, '-T' Altered simulate.py to use a timeout variable and supply the switch to the manager program. So now I don't need to recompile and commit the manager program every time I want to test a different timeout value on mufasa! Mufasa is now on game 3 of the test round, out of 12. After FIVE HOURS. This particular game has lasted 1132 turns, with BLUE making "NO_MOVE" for the last 600 or so. The new victory condition will stop this sort of thing :) Merry Christmas!
-
Sam Moore authored
I understand directory structures, cough
-
Sam Moore authored
When INTERNAL_ERRORs occur, the colour wasn't added to the array in the "ALL" results. So when the script looks up agents["ALL"][index][4] (the colour entry), there was an indexing error. Fixed by adding the colour to the result array when INTERNAL_ERROR occurs. TODO: Discover cause of INTERNAL_ERROR - in the manager program It occurs on mufasa, but not on my laptop. I believe it is due to AI timeouts not being handled correctly by the manager program (stratego). On my laptop, things run nice and fast, and since all the AI work properly, there are no timeouts. On mufasa, things run shit and slow, and pretty much every game I tested ended with a move timeout. Timeout causes broken pipe after AI program is told to exit? As a temporary measure, increased timeout to 60s (from 2s). If this doesn't stop timeouts, there must be some other factor making things slow. "The problem is determining where the shittiness lies... is it the shittiness of the VM, the shittiness of python, the shittiness of the manager program..." Running another test round on mufasa over christmas. Hopefully it will finish running by new year. (Assume 60s a move, 300 moves a game... 12 games...) Considering putting my laptop in the clubroom and just running the competition on that.
-
- Dec 23, 2011
-
-
Sam Moore authored
Need to also disable linking with the SDL and OpenGL libraries in the Makefile But those libraries must have pulled in pthread, because then I got link errors until I added that to linking. Attempt #2
-
Sam Moore authored
I need this for mufasa (vm), which doesn't have SDL or OpenGL or even GNOME Besides, it doesn't need it, and attempting to install them did not end well... Still need to test that it actually builds on mufasa
-
- Dec 22, 2011
- Dec 21, 2011
-
-
Sam Moore authored
Now reads the round number from an "info" file, instead of counting number of files in the directory. Fixed errors in simulate.py creating .html files. Made results slightly prettier, moved directory to /web/results Included links to raw log files /web/log for games. Should install an apache server on mufasa, so that people can view the results online.
-
- Dec 20, 2011
-
-
Sam Moore authored
Previously, contact with a Bomb destroyed the Bomb even if the attacker was not a miner. Now, the only way to destroy a Bomb (ever) is to attack it with a miner. Yes, this means that if the enemy Flag is surrounded by Bombs and and AI has lost all its miners, it is impossible to win. This reflects the rules of the original game. My version is now identical to the original game. My original rule was intended to decrease the emphasis placed on Bombs and Miners. Having played a few games, I think the traditional Bomb rule is more interesting, even if it makes things harder for the AI. If there are any problems with this change, please email matches@ I will be happy to revert to the previous rules if there is demand. This also goes for the change to equivelant ranks combat (earlier commit today). Updated vixen agent's scoring to take into account the change. Yet to update asmodeus's scoring. The AI's seem to have a much harder time now that they have to take out Bombs Games often result in draws, because the Miners are easy targets and get killed whilst seeking out Bombs. The AI should probably defend certain pieces with stronger piece combinations nearby. But this is all getting rather complex for a "sample" :P TODO: Implement victory condition when opponent has no mobile pieces (Currently play continues until the player with mobile pieces ends up attacking Bombs because it has nothing else to do at which point the game is a draw because neither player has mobile pieces)
-
-
Sam Moore authored
I was going to create a highly advanced super AI and not reveal the source code. Then I would win the competition! But, turns out it is just as shit as all the others, so I added it to git. Also I made the competition, so that seems fairly self defeating. It was easier to add some extra stuff to basic_python than to force it into the new AI. "vixen" (where do I get these names? Well, a fox is smart, and a vixen is a fox. Therefore, "vixen" is a smart AI. Q.E.D) I basically copied asmodeus' "optimised score" and path finding technique, but I changed the way scores are calculated to include probability. At one point I was adding the scores for paths that began with the same direction. This seemed like a brilliant idea. It was not. After all this, vixen beats asmodeus some of the time, I haven't tested how often, but each AI has beaten the other at least a few times. Most of the time vixen loses seems to be due to losing the marshal or general on bombs. Its pretty good at countering the spy. It turns out writing a decent stratego AI is harder than I thought :P In other news, in the manager program, I removed the automatic hiding of the AI's pieces when a human is playing, because its useless and annoying.
-
Sam Moore authored
I was going to create a highly advanced super AI and not reveal the source code. Then I would win the competition! But, turns out it is just as shit as all the others, so I added it to git. Also I made the competition, so that seems fairly self defeating. "vixen" (where do I get these names? Well, a fox is smart, and a vixen is a fox. Therefore, "vixen" is a smart AI. Q.E.D) I basically copied asmodeus' "optimised score" and path finding technique, but I changed the way scores are calculated to include probability. At one point I was adding the scores for paths that began with the same direction. This seemed like a brilliant idea. It was not. After all this, vixen beats asmodeus some of the time, I haven't tested how often, but each AI has beaten the other at least a few times. Most of the time vixen loses seems to be due to losing the marshal or general on bombs. Its pretty good at countering the spy. It turns out writing a decent stratego AI is harder than I thought :P In other news, in the manager program, I removed the automatic hiding of the AI's pieces when a human is playing, because its useless and annoying.
-
Sam Moore authored
In the first place, should have probably actually tested this AI It was calling "move" with only 3 arguments, when I added a fourth one (multiplier) In the second place, added storing of more information by InterpretResult Also rewrote the code to make it much clearer when I got tired of retyping "self.board[p[0]][p[1]]" every second line... Of course rewriting the code was a bad idea, and caused many stupid errors. But it should be fixed now... Since asmodeus and other python AI inherit directly from the BasicAI class in basic_python, it kind of needs to work.
-
Sam Moore authored
Read the diff Also, forgot to mention progress in simulate.py in last commit. Made progress with total.html results file, and round by round results files. Although since the round number is never updated properly, we only ever get "round1.html", overwritten each round.
-
Sam Moore authored
Changed combat outcomes for equivelant ranks: Up until now, victor was randomly chosen Changed so that result is always "BOTHDIE" Updated manual page for manager Added section on unbuffered stdin/stdout Modified sample agents to take into account MULTIPLIER There is no way for a human player to move the scout multiple spaces yet. Sample agents still play each other fine, but since none of them actually move scouts multiple spaces, this doesn't prove the new code works. TODO: Test properly (add scout movement to asmodeus and see if everything still works?) Updated webpage. Added section on unbuffered stdin/stdout Added some other pointless waffle. Mmmm waffle. TODO: Make simulate.py keep track of the round number properly. I'm sure this is simple to do, but I can't be bothered right now.
-
- Dec 13, 2011
- Dec 12, 2011
-
-
Samuel Moore authored
I want to generate semi-useful results .html pages using simulate.py It doesn't do this yet, but now it stores all the information I might need in a dictionary. The dictionary for each agent replaces the array which I was previously using. I also made some more of the global variables into optional arguments with default values.
-
Samuel Moore authored
I am now accepting test submissions. Maybe someone will read that? (cough)
-
- Dec 11, 2011
-
-
Sam Moore authored
Fixed segfault in manager caused by attempt to print invalid setups to log Fixed SIGPIPE in manager caused by attempt to message non-existant programs. Although I previously fixed a similar SIGPIPE, It is also possible for a file to exist but not have executable permissions set. Controllers set to use such files as executables were returning true for Valid(), but were in fact, not valid at all. Use the access function (thanks stack overflow!) to check for executable permissions and existence in Program::Program. If they aren't set, or file doesn't exist, set pid to -1 which is an "invalid" controller. Discovered python trick which allows me to get rid of stupid "run.py" files for the python AIs. Modified the simulate script to take the number of rounds as an argument. Also made its output slightly prettier. Currently testing simulation of 10 rounds on my laptop at home. "./simulate 10; shutdown -h -P now" I hope it doesn't set the desk on fire while I'm asleep... :S Oh, and the VM is finally setup, hooray!
-
- Dec 08, 2011
-
-
Samuel Moore authored
-
Sam Moore authored
Derp
-
Sam Moore authored
-
Sam Moore authored
Caused by the Program base class attempting to write EOF to programs which had already exited. This caused a SIGPIPE signal. The SIGPIPE handler function Game::HandleBrokenPipe then attempted to log the event by calling Game::theGame->logMessage However, since the program was exiting, DestroyGame had been called and Game::theGame was in the process of being deleted. Fixed by removing the fputc(output, EOF) line in Program::~Program. It is ironic that this only became an issue since I modified the sample AI to actually obey the protocol and exit as soon as "QUIT" is recieved...
-