- Updated Saturday, March 29th 2014 @ 16:23:30
In a class i took a year ago, we had the oportunity to play some games similar to this one (othello).
That time, we had the ability to run our bots from home. How it worked was like this:
A interface was provided to the server (basically an IP adress + port) and we could connect to it. And then we could communicate using the regular std:in etc, but over the internet.
This way, the server only has to handle the simulation, so theres alot less load on the server (allowing us to play more games), further, any language that supports sockets works. Finally it makes debugging ALOT easier, since we play from home.
What do you say about this? It would probably be easy to implement as an alternative to sending our bots to the server.
If admin does not want to do it, I may start a side server so people can play test games on it, but I'd very much prefer to be able to play this way in ranked games!
DeveloperCreated Saturday, March 29th 2014 @ 17:03:21
I don't think we're going to do this, just because it would be such a drastic change. Also we don't have consistent playing of games anymore, which is not something we want.
But for debugging purposes this would be nice. Some people have set up their own game engine with the code we have provided on our github. This is something you can do as well if you want.
- Created Saturday, March 29th 2014 @ 19:11:11
It doesn't really have to be a drastic change; the server can stay as-is.
All that is required is that bots would need to have the ability to "call home". (I don't know if that's possible now, I haven't checked) for example, open TCP connections
You could upload a client bot, that calls home to a server, which return the moves to the bot. The bot then returns the moves like usual.
- Created Saturday, March 29th 2014 @ 19:12:54
Indeed, you wouldnt need to discontinue the current method, simply add another option that works online :)
- Created Saturday, March 29th 2014 @ 19:31:57
I just tried it, but I don't think you can call home now, at least not with C#:
System.TypeInitializationException: An exception was thrown by the type initializer for System.Net.WebRequest ---> System.DllNotFoundException: libc at (wrapper managed-to-native) System.Platform:uname (intptr) at System.Platform.get_IsMacOS () [0x00000] in :0 at System.Net.WebRequest..cctor () [0x00000] in :0 --- End of inner exception stack trace ---
Maybe you can do it with tcp requests instead of using a WebRequest, but I doubt it...
- Created Saturday, March 29th 2014 @ 21:25:53
The difference with my approach is that the server does not need to accept general connections (which would be a security hole, most likely), but only the connections used for the game.
Another upside is that the server doesnt have to perform the length bot calculations, thus saving heaps of time.
- Created Saturday, March 29th 2014 @ 22:40:10
There are several problems with thiz. The first is that the server software would need a major redesign. While the game logic would remain the same, the way the game logic hooks up to the bots would have to be changed drastically. For example, currently, the game only ever plays a single game at a time. Turns can take much longer because of debugging and because of network speeds, which means you would want the server to be able to play multiple games at the same time. On top of that, this system would involve bot builders choosing when their bots play, which has the same requirement. In order to be able to play multiple games at the same time like that, you would have to start storing game states in persistent storage, so you can pause one game and continue another (multithreading gets you part of the way there, but probably just not all the way).
A second problem is that that there won't be a fair playing field because the bots aren't run on the same hardware anymore. For one thing, differing network speeds mean that it'll be quite hard to proper timeout limits as currently happens. Even if you were able to do that, a bot running on state of the art hardware will have a huge advantage over one running on cheap hardware.
Another issue that comes up is that the server will have to give up control over when games are played, which isn't exactly a good thing. It will mean that you can get the number of games up if your ELO rating is low, and limit the number of games when your rating is high, which is a way to game the ELO system.
The server also won't have any access to the code anymore. This means that it can't prevent you from writing a client that has you make (parts of) its decisions and not have it be between bots anymore. It also means you can actually do something that is forbidden (such as changing moves based on who you are playing against) and there will be no way for the AI Games team to check this.
There are probably other problems, but these are the main ones I have found. The advantages I see you bring up are the processing time saved and the easier debugging. The processing time saved will be rather limited, because each bot is already limited to two seconds and this suggestion will actually create a lot of overhead - even just the network latency will be quite a punch (okey, that's not processing power, but the upkeep of the network connections and the swapping between games will be). On top of that, most bots use far less than those two seconds. As for the debugging, you're actually given enough tools to debug at the moment. Of course, you're not given access to a real time debugger or access to your opponent's bot, but you have tools like the standard error and the exact moves of your opponent. If you really want to step through your code, you can always do so by running the server software (which is on github) on your local computer.