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
Saturday, June 21, 2008
== June 21 == Last couple of hurdles before the Good Stuff :)
Hello,
So, it seems like the big re-structuring I've been vaguely referring to last post finally came to pass in our generation (i.e., last week), and not without some headache, mind you. The reason for it, was that I put too much responsibility on the 'Client' class on the one hand, and diffused responsibility for communicating with the server on the other.
The first issue was problematic since the class threatened to grow out of proportion, and take over pretty much everything that was going on in the client as a whole (a big no-no in OOP ;) ). The second issue was problematic, since diffusing responsibility for client-server communication meant an uber-headache every time there is an update in protocol... plus it was just un-aesthetic the old way ;) . Now there is a class which handles the logical operation of the client (solution of the first issue!), and also now all client-server communication is handled by the 'Client' class, which makes code much more readable, class-contracts much more focused on the task-at-hand, and will save lots of headache when the protocol will change. Whew :)
There still remain a couple of things that lack support in the so-called 'game-library', which is a client-side library representing the game-world (see previous posts where it's discussed!), namely support for orders and resources, but this is a minor issue, and should be resolved without much fuss early next week. Afterwards, it's Robot Coding Time! Although I have a decent idea of the design, it will need to become concrete Java code. So, the main task for next week, will be to build all necessary infrastructure for the AI bot, and start work on it... finally!
I guess this sums it up nicely. I'll keep you posted!
____________________
Victor Ivri (vi1985)
Blog address: BLOG
You can find the project in the git repo here: REPO
So, it seems like the big re-structuring I've been vaguely referring to last post finally came to pass in our generation (i.e., last week), and not without some headache, mind you. The reason for it, was that I put too much responsibility on the 'Client' class on the one hand, and diffused responsibility for communicating with the server on the other.
The first issue was problematic since the class threatened to grow out of proportion, and take over pretty much everything that was going on in the client as a whole (a big no-no in OOP ;) ). The second issue was problematic, since diffusing responsibility for client-server communication meant an uber-headache every time there is an update in protocol... plus it was just un-aesthetic the old way ;) . Now there is a class which handles the logical operation of the client (solution of the first issue!), and also now all client-server communication is handled by the 'Client' class, which makes code much more readable, class-contracts much more focused on the task-at-hand, and will save lots of headache when the protocol will change. Whew :)
There still remain a couple of things that lack support in the so-called 'game-library', which is a client-side library representing the game-world (see previous posts where it's discussed!), namely support for orders and resources, but this is a minor issue, and should be resolved without much fuss early next week. Afterwards, it's Robot Coding Time! Although I have a decent idea of the design, it will need to become concrete Java code. So, the main task for next week, will be to build all necessary infrastructure for the AI bot, and start work on it... finally!
I guess this sums it up nicely. I'll keep you posted!
____________________
Victor Ivri (vi1985)
Blog address: BLOG
You can find the project in the git repo here: REPO
Friday, June 13, 2008
== June 13 == Goals for midterm and other livestock.
This post will be divided into two parts: First of all, I'll be discussing my progress for the past week and some thoughts about the process in general. Then, I'll *officially* state my goals for the midterm evaluation, as formulated by me and my project's mentor, Kryzstof (aka Jezuch).
So, let's head off without further adieu to the "What I've been up to this week" rubric:
a) I finished the main chunk of work on client-functionality. It has demonstrated the ability to receive any and all kinds of data from the server. From now on, I'll be implementing stuff on a need-to basis, and concentrating on other things. I am considering a re-structuring of the contract of the client, but this will come later on, when it becomes more obvious how the system will operate as a whole.
*** This calls for a "whoo-hoo" ;)
b) I have decided to implement a "game-library". It will represent the game-world in a way that will be more straightforward for an AI to work with. I have almost finished work on it (perhaps a couple of days more). While this seems like a waste of time, I am actually saving myself a lot of hassle later on, since it's tailored to be more convenient to use, plus this way the AI player will stand independently of the client and of any protocol implementation.
c) I have finally gotten around to running games locally. My client successfully connects to, and interacts with the local server. Running local games will play a huge role in integration-testing, and in perfecting the robots.
Plans for next week: Finish implementing the "middleman" game-library. Make overall architecture better. Start work on AI. This will consist of two parts: First of all, it entails starting work on the robot itself. Also, I will begin working on a framework for building, and for testing different robots.
~~~ NOW FOR THE SECOND PART: My Goal for the midterm ~~~
Date for deadline: Friday, July 11, 08. This gives both me and Kryzstof some buffer zone, as the official deadline is on July 14.
As agreed by Kryzstof and me, (is it "and I"? hm... don't think so) a good "minimum" would be to have a basic, functional robot, which will implement the desired architecture for the final product. The robot will have an internal logic to it's actions, it will be able to manipulate its assets, and thus play the game (in a limited way). I will try my best to exceed this goal, and have an elaborate inner logic, and an evolutionary framework ready in time for the midterm as well.
That's all for now. Stay tuned for updates! B-)
____________________
Victor Ivri (vi1985)
Blog address: BLOG
You can find the project in the git repo here: REPO
So, let's head off without further adieu to the "What I've been up to this week" rubric:
a) I finished the main chunk of work on client-functionality. It has demonstrated the ability to receive any and all kinds of data from the server. From now on, I'll be implementing stuff on a need-to basis, and concentrating on other things. I am considering a re-structuring of the contract of the client, but this will come later on, when it becomes more obvious how the system will operate as a whole.
*** This calls for a "whoo-hoo" ;)
b) I have decided to implement a "game-library". It will represent the game-world in a way that will be more straightforward for an AI to work with. I have almost finished work on it (perhaps a couple of days more). While this seems like a waste of time, I am actually saving myself a lot of hassle later on, since it's tailored to be more convenient to use, plus this way the AI player will stand independently of the client and of any protocol implementation.
c) I have finally gotten around to running games locally. My client successfully connects to, and interacts with the local server. Running local games will play a huge role in integration-testing, and in perfecting the robots.
Plans for next week: Finish implementing the "middleman" game-library. Make overall architecture better. Start work on AI. This will consist of two parts: First of all, it entails starting work on the robot itself. Also, I will begin working on a framework for building, and for testing different robots.
~~~ NOW FOR THE SECOND PART: My Goal for the midterm ~~~
Date for deadline: Friday, July 11, 08. This gives both me and Kryzstof some buffer zone, as the official deadline is on July 14.
As agreed by Kryzstof and me, (is it "and I"? hm... don't think so) a good "minimum" would be to have a basic, functional robot, which will implement the desired architecture for the final product. The robot will have an internal logic to it's actions, it will be able to manipulate its assets, and thus play the game (in a limited way). I will try my best to exceed this goal, and have an elaborate inner logic, and an evolutionary framework ready in time for the midterm as well.
That's all for now. Stay tuned for updates! B-)
____________________
Victor Ivri (vi1985)
Blog address: BLOG
You can find the project in the git repo here: REPO
Subscribe to:
Posts (Atom)
