Available playersTop players Chat Forum External sites: Wiki

«

previous 1 2 3 4 5 6 7 next

Pluto

Raider

Offline

Also, just put a quick start guide on the wiki for anyone who is interested: http://weewarwiki.com/tiki-index.php?page=AI+Quick+Start+Guide

Pistos

Raider

Offline

Good work, Pluto.

I've been looking over the publicized Java code you guys have, and I have one comment: Perhaps y'all should be putting shared or even outright duplicate code into one git project as a library which yourselves and other Java programmers can just import. It would probably reduce the size of your projects by a fair amount, and make it easier for others to examine as the first prototype examples of Java-based bots.

I have another question for all of those who already have made bots, but also to bert in particular: In your bot code, do you update your local Java object instances yourselves after each state-modifying action, or do you refresh from server each time? By this I mean, for example, after an attack, do you update the unit counts of your local Java in-memory objects, or do you hit the server to get the new unit counts? Hitting the server all the time would be draining on the server resources and rather inefficient. At the same time, calculating it ourselves all the time has two problems: more work for us and also the chance of being out of sync with the real server data.

I think something that would help with this issue is if the objects had unique id numbers which were passed to us with the response XML. I refer to factions and units -- not so much games and terrain, which already have unique identifying attributes.

This way, I don't have to question whether the new unit that is now at (2,5) is the same unit that used to be at (2,4). The XML would give me an id, and I can line that up with my in-memory data. Even more importantly, each object can be told to refresh itself, rather than building fresh sub instances (units, etc.) all the time on each full-game-refresh.

I hope I make myself clear; the issue is difficult to put into precise, easy-to-understand words.

So yeah, if the units have id numbers, please provide them. If not, I can deal. Thanks.

Pluto

Raider

Offline

Pistos wrote:Perhaps y'all should be putting shared or even outright duplicate code into one git project as a library which yourselves and other Java programmers can just import.


Good idea, and Spadequack and I have actually already started getting something like this going.

In your bot code, do you update your local Java object instances yourselves after each state-modifying action, or do you refresh from server each time?


I think I can answer this. In Bert's original ZappBrannigan code, pretty much all stuff is updated locally. For instance, when you build a unit, you manually subtract the credits that you just spent from your total credits. Also, when you move a unit, you manually update its new coordinate position. I think doing it this way is fine and is actually pretty nice with the way bert set up all the classes.

However, one problem arises when you are dealing with unit quantities. If you attack a unit and want to know the outcome, we can only predict that locally, but you need to call the server to get the true result. Right now, the only way to do that is through the gameState API which of course returns everything about a game and could get quite hefty for large games. This is overkill if you just want to know about a few units.

One solution would be to give each unit an id# as Pistos suggested and then add an extra API call where you can get the information of just that unit by passing the id#. Maybe a simpler way would be to add an API call where you can send in a coordinate and get all the info of the unit that is positioned there... game number and position is also in a way a de facto id# for a unit anyway

Did I answer your question?

This message was edited 1 time. Last update was at 06/06/2008 01:14:21

Pistos

Raider

Offline

I'd argue that game number with position is a stand-in ID for terrain -- but not for units.

Anyway, I otherwise grok your explanation, thanks for discussing.

bert

Staff

Offline

Pistos wrote:Okay, thanks bert, on both counts.

Another question: Is it safe to assume we'll always get an <ok> or an <error> tag in response to our API hits?


We could agree on that and if there is an answer that does not give <ok> or <error> then it could be changed. Yet I can not think of any case where its not one of the two.

This message was edited 1 time. Last update was at 06/06/2008 11:03:32

bert

Staff

Offline

Pistos wrote:Good work, Pluto.

I've been looking over the publicized Java code you guys have, and I have one comment: Perhaps y'all should be putting shared or even outright duplicate code into one git project as a library which yourselves and other Java programmers can just import. It would probably reduce the size of your projects by a fair amount, and make it easier for others to examine as the first prototype examples of Java-based bots.


+1 on that one. This also makes it easier to help as I can concentrate on the util classes once. And I would sure like to help.

Pistos wrote:I have another question for all of those who already have made bots, but also to bert in particular: In your bot code, do you update your local Java object instances yourselves after each state-modifying action, or do you refresh from server each time? By this I mean, for example, after an attack, do you update the unit counts of your local Java in-memory objects, or do you hit the server to get the new unit counts? Hitting the server all the time would be draining on the server resources and rather inefficient. At the same time, calculating it ourselves all the time has two problems: more work for us and also the chance of being out of sync with the real server data.


As I said in a previous post: Hitting the server does not only put load onto the server but also makes your bot slower. Zapp is hitting the server up to tree (or 5?) times for each unit that is in range of less then 5 fields to an enemy unit. Zapp is still pretty fast but not "lightning" fast. I'd say that with more requests a bot will become slow. Especially if you calculate into the future. With Zapp I've been updating the units myself but only in terms of where they are. If a Unit did an attack, Zapp will not deal with it until the next move.

On the other Hand: It's okay to do requests. As long as Bot-vs-Bot games are not created automatically and requests are of no use to humans. If this is what it takes to have a good bot - we're all in. So proceed as you like.

Pistos wrote:So yeah, if the units have id numbers, please provide them. If not, I can deal. Thanks.

Easy. This is what I've been thinking about when I said "take a look at eliza". I can pass the IDs with Units and factions.


One other question: Is anyone already thinking about pro units/maps? If yes: let me know and I'd be glad to upgrade your accounts.

bert

Staff

Offline

Pluto wrote:However, one problem arises when you are dealing with unit quantities. If you attack a unit and want to know the outcome, we can only predict that locally, but you need to call the server to get the true result. Right now, the only way to do that is through the gameState API which of course returns everything about a game and could get quite hefty for large games. This is overkill if you just want to know about a few units.


Isn't the attack command returning something that contains the damage that was done? I can take a look later, but I am pretty sure that I've added the result of an attack to the returning XML.

spadequack

Heavy Tank

Offline

bert wrote:
Pluto wrote:However, one problem arises when you are dealing with unit quantities. If you attack a unit and want to know the outcome, we can only predict that locally, but you need to call the server to get the true result. Right now, the only way to do that is through the gameState API which of course returns everything about a game and could get quite hefty for large games. This is overkill if you just want to know about a few units.


Isn't the attack command returning something that contains the damage that was done? I can take a look later, but I am pretty sure that I've added the result of an attack to the returning XML.


Yeah, the resulting XML returns damage inflicted and damage received.

This message was edited 1 time. Last update was at 06/06/2008 14:27:40

Pluto

Raider

Offline

ok duh, that makes sense. i guess i haven't gotten that far in yet

Pistos

Raider

Offline

bert wrote:We could agree on that and if there is an answer that does not give <ok> or <error> then it could be changed. Yet I can not think of any case where its not one of the two.

Sounds good to me. Let's all agree on this standard, and then have it implemented. Perhaps even for the attackOptions and movementOptions (if they're not already).

This message was edited 1 time. Last update was at 06/06/2008 17:07:53

Pistos

Raider

Offline

bert wrote:As I said in a previous post: Hitting the server does not only put load onto the server but also makes your bot slower. Zapp is hitting the server up to tree (or 5?) times for each unit that is in range of less then 5 fields to an enemy unit. Zapp is still pretty fast but not "lightning" fast. I'd say that with more requests a bot will become slow. Especially if you calculate into the future. With Zapp I've been updating the units myself but only in terms of where they are. If a Unit did an attack, Zapp will not deal with it until the next move.

On the other Hand: It's okay to do requests. As long as Bot-vs-Bot games are not created automatically and requests are of no use to humans. If this is what it takes to have a good bot - we're all in. So proceed as you like.

Personally, I don't mind my bot's speed. Indeed, the network traffic is the bottleneck, but it's not unacceptable. If I cron my bot to take his turn every 3-5 minutes, I'm not going to be tying up my bandwidth or anything. My main concern at this stage is overloading the server; but if you say it can take it, then fine, I am understanding that as a green light to proceed with moderate network traffic if that's what it takes to make a good bot, or at least, makes it easier to program one.

At the moment, I am hitting the server for a full /gamestate/ request after each state-modifying action (move, attack, repair).

bert wrote:
Pistos wrote:So yeah, if the units have id numbers, please provide them. If not, I can deal. Thanks.

Easy. This is what I've been thinking about when I said "take a look at eliza". I can pass the IDs with Units and factions.

Yes; please; and thank you.

bert wrote:One other question: Is anyone already thinking about pro units/maps? If yes: let me know and I'd be glad to upgrade your accounts.

Thinking: Yes. Implementing: No. Probably won't get to programming logic for them for at least a week or so. I want to refine the strategy with the basic units first.

This message was edited 1 time. Last update was at 06/06/2008 17:14:11

Pluto

Raider

Offline

Pistos wrote:
bert wrote:One other question: Is anyone already thinking about pro units/maps? If yes: let me know and I'd be glad to upgrade your accounts.

Thinking: Yes. Implementing: No. Probably won't get to programming logic for them for at least a week or so. I want to refine the strategy with the basic units first.


Same here, but would be nice in the future

This message was edited 1 time. Last update was at 06/06/2008 17:17:57

Pluto

Raider

Offline

bert wrote:One other question: Is anyone already thinking about pro units/maps? If yes: let me know and I'd be glad to upgrade your accounts.


Actually Bert, I was thinking that it would be nice to have a pro account so we can set up some scenarios on custom maps for testing purposes.

This message was edited 1 time. Last update was at 07/06/2008 03:39:32

Pistos

Raider

Offline

Pluto wrote:Actually Bert, I was thinking that it would be nice to have a pro account so we can set up some scenarios on custom maps for testing purposes.

Good thinking, Pluto. +1

This message was edited 1 time. Last update was at 07/06/2008 03:49:30

Pistos

Raider

Offline

By the by, ZappBrannigan is not taking his turns any more...

previous 1 2 3 4 5 6 7 next