protocol

[maartenvd]

Is the protocol somewhere documented?
I'm also a bit confused, are you allowed to query a couple of parameters and then send your next move to the server which will execute that command when all commands from all bots are received or does it run and react real-time to user commands. (and if it's the latter, how do you limit the amount of scan commands that can be sent?)

Why wasn't opted for sending a struct of parameters (the eventual results from scan, shoot and your x,y and movement speed) instead of the current solution (different commands to get your x, y position and your movement speed,...)?

I'm interested in re-writing the server in another language to allow deploying on windows too and rewrite robots.c in a few other languages.

[bonzini]

Hi! Yes, you're allowed to query and then send a command. However, in every 10ms "cycle" a robot is only allowed to send one action command. When an action is sent on the socket, execute_cmd returns true in the .cycle member, and the poll loop will not examine that socket any more for the rest of this cycle.

result = execute_cmd(robot, buf);
....
if (result.cycle)
    pfd->events = 0;

Why wasn't opted for sending a struct of parameters (the eventual
results from scan, shoot and your x,y and movement speed) instead
of the current solution (different commands to get your x, y position
and your movement speed,...)?

Because this was a university project and that's what the students opted for! :)

And more importantly, because if you do a sleep(1) your x/y/speed/damage probably have changed since the last time a command was sent to the server.

[maartenvd]

Ok, thank you very much for clarifying. I'm new to crobots but I really like the concept. I will start playing with it a bit more next week.

I wish my university did such fun projects :)

[maartenvd]

I used telnet and the available source code to reconstruct the protocol and I have a D version working (I also ported rook.c to D).

It works wonderfully. I'm going to document the protocol (finally gonna learn latex) and add a java version later on.
Probably also going to rewrite the server somewhere along the way in D (it will then be portable across windows, linux and mac.

One thing I don't understand is the cycle command. What is the use of calling cycle when not sending a packet will also let the server cycle a turn? Moving and calling cycle till we reach our destination has the same effect as moving and sleeping till we get there.

I realize you were the coordinator of this project a couple of years ago, but do you still remember why it was added? backward compatibility?

[bonzini]

Thanks for reporting your progress! cycle is there because it is the shortest pause that can work. It is much more reliable than sleeping, and more portable as well.

Documenting the protocol would indeed be great. This was a mostly educational project, so it's great that you found it and use it for that purpose!

Can you post what you have on github? Could you make a Python version of the client library?

It shouldn't be hard to use gnulib to port the server to Windows, BTW.

[maartenvd]

I will post what I have so far on github. I have only written small scripts in python and never done any real socket communication but I think I can add it.

After looking at some crobots games (http://crobots.deepthought.it/home.php?page=screenshots&link=3) for example I notice that rockets normally have a certain speed so you can outrun them. However, in this implementation, rockets land instantly. I like the original idea of rockets not landing instantly more so I'll also have to change the server (and consequently the clients because cannon won't report if the missile has hit).

I think it's smarter to first change the server and later on create multiple clients instead of having to rewrite the clients.

While I'm at it I might as well implement all rules described here : http://www.gamerz.net/c++robots/

I'll keep updating every now and then :)

[maartenvd]

I decided to go with a more object-oriented approach and most is already written. The only things left to do are writing the scanner implementation and creating a loop that listens to every client socket. (the network part in other words)

I've went with a turn-based approach. This way you can garantee that a person with a huge network latency also has a fair chance at winning and that the data he gets from the server is precise.

I don't know what happens when a client sends to the server while the server isn't listening, if it doesn't get stored in some buffer then I'll have to go with a different server setup. Luckily, everything is pretty modular so I'll eventually be able to end up with a working concept.

A big surplus is that it utilizes the same protocol, that way I the clients for netrobots will also work on my server.

[bonzini]

In the turn-based approach, can a "sleep(1000);" in the client deadlock the server? Note that the clients and server are meant to run in a LAN.

[maartenvd]

The idea is to limit the amount of time a client has to react (but keep it reasonable for high latency). I would make it around 1 second each turn. That way the server won't deadlock and it's not limited to lan. (Although, admittedly, battles out of lan won't be a common scenario).

[bonzini]

One second is a lot. It is common to have battles of 10000 cycles or
more. Really, we tried a lot of this! :)

[maartenvd]

Indeed, looking back at it, that will give incredibly long battles. Maybe 200ms will be good enough :)

[maartenvd]

My code is finished in that all components seem to function properly (but I'll have to go through them to clean everything up a bit more, add more asserts, etc). The socket part however feels like an ugly "hack" so I'll have to work on that a bit more.

Fighting works perfectly, I've ran some fights with the pre-packed robots from netrobots and they seem to be killing each-other just fine :)

I think I will even be able to make turn-based an option that is configurable at startup time using a compiler flag.

[mathias-baumann-sociomantic]

@maartenvd is your stuff available somewhere? Especially the D-Port would be interesting to me :)

[maartenvd]

I started porting (iirc it is rather straightforward. The client is a line
by line translation but instead using std.socket) but the fact that a bot
can spam commands as fast as possible annoyed me. The performance of a bot
is dependent on the pc it is run on if you do that.

So I tried doing a turn based approach with a timeout and port the server
to vibe.d but school got in the way.

2015-11-17 17:28 GMT+01:00 Mathias Baumann [email protected]:

@maartenvd https://github.com/maartenvd is your stuff available
somewhere? Especially the D-Port would be interesting to me :)

—
Reply to this email directly or view it on GitHub
#1 (comment).