There has been an unexpected turn of events last week, which significantly altered the nature and scope of the project. Long story very short, I've been asked to look into creating an AI for the Risk ruleset (currently under development by a fellow GSoCer), which I gladly accepted, due to the persistence of a nasty bug in RFTS (unable to utilize colonized planets), which refuses to get mended. So what I've decided to do, is leave all the support for RFTS in my client, and add to that libraries, which will represent the game-world of Risk, and play it.
This presented an unexpected challenge, and a sobering realization. I really did try to organize the project into logical units, which were "modular", and meaningfully connected to each other, but what I realized when beginning to make this whole thing more generic (to allow for more than one ruleset), is that the overall design was far from optimal. This required a substantial re-organization of the different classes and libraries, which I'm still in the process of finishing. This was a really interesting and even somewhat enlightening experience, one which made me re-think the way I normally do things. (Definitely more planning from now on!)
This process should not take more than an additional day or two, and from then on I'll have to start building logic and game-world representation into the Risk modules... did anyone say that the project's due on the 18th of August?
Later!
____________________
Victor Ivri (vi1985)
Blog address: BLOG
You can find the project in the git repo here: REPO
Tuesday, July 29, 2008
Friday, July 18, 2008
== July 18 == TP04 Support
The midterm rush is over, and I'm a bit ashamed to admit that this week I took a bit of a rest, compared to the usual pace. I spent my working hours this week on moving from a client that supports TP03 to a client that supports TP04. A good part of it is done, but I'll need to spend some time on interpreting Objects next week. Also, I added some logic to the normal operation of the game, and locally set up tpserver-cpp 0.5.1. Seems to be working just fine! ;-]. Next week I'm hoping to finish the move to TP04 as fast as possible, and continue on the AI logic.
Till then!
____________________
Victor Ivri (vi1985)
Blog address: BLOG
You can find the project in the git repo here: REPO
Till then!
____________________
Victor Ivri (vi1985)
Blog address: BLOG
You can find the project in the git repo here: REPO
Friday, July 11, 2008
== July 11 == Midterm Report
This time I'll be brief.
For the past week I've been working over-time to get the project in great shape for the midterm. This included work on pretty much everything...
I'll let the 'official midterm report' do the rest of the talking : <<>>
There's a screenshot there as well, for the graphically oriented ones ;]
Till later,
____________________
Victor Ivri (vi1985)
Blog address: BLOG
You can find the project in the git repo here: REPO
For the past week I've been working over-time to get the project in great shape for the midterm. This included work on pretty much everything...
I'll let the 'official midterm report' do the rest of the talking : <<>>
There's a screenshot there as well, for the graphically oriented ones ;]
Till later,
____________________
Victor Ivri (vi1985)
Blog address: BLOG
You can find the project in the git repo here: REPO
Friday, July 4, 2008
== July 4 == Ye Famous Travelling StarFleet Problem :)
It's that time 'o week again for me to write about my progress. The previous post is only three days old, but I got some stuff to blah about ;].
So, for the most part I've been splitting my time between getting the client ready, and preparing the actual robot for some action. I've been having some issues with the ruleset and the low-level library (see last post), but mostly they've been resolved (except for the annoying bug of being unable to colonize!), and now it's a matter of some time until the client gains complete functionality.
In parallel to that, I've started to work on the actual AI mechanism and infrastructure (by infrastructure, I mean creating the necessary framework for the robot to function). I have decided to forgo the original plan of running a natural-selection mechanism for actions on each and every move for the sake of a simpler, more conventional, but still (I think) very elegant solution (which still implements a genetic selection process, only this time during its creation).
The reason for this was twofold: first of all, I discovered a couple of problems in the design that were hard to overcome; the simulation of each move would've been a real issue, and the mechanism for illegal-move sifting would not have been very difficult to implement, due to "hypothesizing" game-eventualities many moves ahead. Another, equally important reason for me to change the plan, is that this was really a two-fold project, as I had to spend (and still do, to some extent) an incredible amount of work on getting the Java client started, even before getting started on the robot. Hence, de-facto I've only started work on the robot almost at the midterm-point, and I need to simplify the design a bit to get it in good shape before the fat lady sings! ;].
I'll have much more to say on the alternative solution by next Friday, but in short it will be a four-part project: a) the client and game library, b) robot logic, c) a robot-factory for creating new robots, and d) an evolutionary framework for optimizing them. Each robot will have 'behavioural characteristics', by which its behavior will be guided, and which will be susceptible to mutation in the evolution-simulator.
Here, I guess that's it for this week.
PS - Do check out the code in the repo in the "ActionMethods" class for a home-brewed solution of Ye Famous Travelling StarFleet Problem + some mathematical analysis on it! (It's not very tested yet, but I've got faith in it).
Till the dolphins leave,
____________________
Victor Ivri (vi1985)
Blog address: BLOG
You can find the project in the git repo here: REPO
So, for the most part I've been splitting my time between getting the client ready, and preparing the actual robot for some action. I've been having some issues with the ruleset and the low-level library (see last post), but mostly they've been resolved (except for the annoying bug of being unable to colonize!), and now it's a matter of some time until the client gains complete functionality.
In parallel to that, I've started to work on the actual AI mechanism and infrastructure (by infrastructure, I mean creating the necessary framework for the robot to function). I have decided to forgo the original plan of running a natural-selection mechanism for actions on each and every move for the sake of a simpler, more conventional, but still (I think) very elegant solution (which still implements a genetic selection process, only this time during its creation).
The reason for this was twofold: first of all, I discovered a couple of problems in the design that were hard to overcome; the simulation of each move would've been a real issue, and the mechanism for illegal-move sifting would not have been very difficult to implement, due to "hypothesizing" game-eventualities many moves ahead. Another, equally important reason for me to change the plan, is that this was really a two-fold project, as I had to spend (and still do, to some extent) an incredible amount of work on getting the Java client started, even before getting started on the robot. Hence, de-facto I've only started work on the robot almost at the midterm-point, and I need to simplify the design a bit to get it in good shape before the fat lady sings! ;].
I'll have much more to say on the alternative solution by next Friday, but in short it will be a four-part project: a) the client and game library, b) robot logic, c) a robot-factory for creating new robots, and d) an evolutionary framework for optimizing them. Each robot will have 'behavioural characteristics', by which its behavior will be guided, and which will be susceptible to mutation in the evolution-simulator.
Here, I guess that's it for this week.
PS - Do check out the code in the repo in the "ActionMethods" class for a home-brewed solution of Ye Famous Travelling StarFleet Problem + some mathematical analysis on it! (It's not very tested yet, but I've got faith in it).
Till the dolphins leave,
____________________
Victor Ivri (vi1985)
Blog address: BLOG
You can find the project in the git repo here: REPO
Tuesday, July 1, 2008
== July 1 == Problems, Solutions & Starting the fun part
Ahoy. I wanted to post this report on Friday, as usual, but due to some extraneous circumstances (coupled with a 3-day wilderness trip Saturday-Monday) I was only able to get one out today.
In the past week of coding I have encountered several problems. First of all, there are a couple of issues related to the ruleset, which are still standing. First of all, there is the issue of mapping numeric-to-actual ship-types. I was hoping that it would be hard coded (e.g. scout is always 1, Mk.1 destroyer is always 3, etc) , but nash suggested that it might be determined by the server at runtime. I'm still waiting for the final word from xdotx on that.
Another issue with the ruleset I encountered, was the complete inability to produce anything on newly colonized planets, since any amount of colonists magically disappears from the surface, and no resource-points are being generated thereafter (although I still apparently own the planet). This observation was made on tpclient-pywx, and confirmed by my own client. I'm still waiting for word from xdotx for what this might be. (Smells like a bug, but perhaps I'm missing something?)
Finally, there was an issue with sending orders, that was related to the proto-library, which jezuch quickly remedied, and now I'm able to successfully pass orders to my assets in the game-world. I proved this by implementing the "fleet-move" order, and successfully moved my fleet around the universe.
So, what is still missing in terms of client functionality (out of the stuff that I really need, that is), is production, fleet merge, fleet split orders, and numeric-to-actual ship mapping. What I want to concentrate now on, is the actual logic and overall architecture of the bot. I already introduced some convenient algorithms into my representation of the universe map (get n-closest star systems, get contents of star system, get distance). I will be adding to these as I go along developing the robot logic, and hopefully by the end of the week I'll have a good skeleton to build on, and some concrete algorithms to control the behavior of the bot.
Later,
Victor.
____________________
Victor Ivri (vi1985)
Blog address: BLOG
You can find the project in the git repo here: REPO
In the past week of coding I have encountered several problems. First of all, there are a couple of issues related to the ruleset, which are still standing. First of all, there is the issue of mapping numeric-to-actual ship-types. I was hoping that it would be hard coded (e.g. scout is always 1, Mk.1 destroyer is always 3, etc) , but nash suggested that it might be determined by the server at runtime. I'm still waiting for the final word from xdotx on that.
Another issue with the ruleset I encountered, was the complete inability to produce anything on newly colonized planets, since any amount of colonists magically disappears from the surface, and no resource-points are being generated thereafter (although I still apparently own the planet). This observation was made on tpclient-pywx, and confirmed by my own client. I'm still waiting for word from xdotx for what this might be. (Smells like a bug, but perhaps I'm missing something?)
Finally, there was an issue with sending orders, that was related to the proto-library, which jezuch quickly remedied, and now I'm able to successfully pass orders to my assets in the game-world. I proved this by implementing the "fleet-move" order, and successfully moved my fleet around the universe.
So, what is still missing in terms of client functionality (out of the stuff that I really need, that is), is production, fleet merge, fleet split orders, and numeric-to-actual ship mapping. What I want to concentrate now on, is the actual logic and overall architecture of the bot. I already introduced some convenient algorithms into my representation of the universe map (get n-closest star systems, get contents of star system, get distance). I will be adding to these as I go along developing the robot logic, and hopefully by the end of the week I'll have a good skeleton to build on, and some concrete algorithms to control the behavior of the bot.
Later,
Victor.
____________________
Victor Ivri (vi1985)
Blog address: BLOG
You can find the project in the git repo here: REPO
Subscribe to:
Posts (Atom)