siggame / cadre Goto Github PK

Currently the game server sends its hostname to the clients for gamelog urls.

That's silly, the clients already know the hostname, they use it to connect to!

So instead, send some string to be replaced by the Hostname, e.g. %%%HOSTNAME%%%

"MS&T" is used a few times in the README, but that is not one of the university's official abbreviations.

Please update usage according to the university standards: http://marketing.mst.edu/brand/name/

Currently, clients can send the run command. Competitors who are more time conscious have asked to batch these runs together. My idea would go as follows:

Before:

gameObjectA.callSomething();
gameObjectB.callSomethingElse();
gameObjectC.callSomethingYetAgain();

That right there has 3 times it talks to the server. If the competitor is slick and doesn't care to get their game state updated right away they could do:

this.startBatch();

gameObjectA.callSomething();
gameObjectB.callSomethingElse();
gameObjectC.callSomethingYetAgain();

this.finishBatch(); // actually sent now

The game objects calls would return some default value, such 0 for numbers, "" for strings, null for complex types, etc. Then when they finally finish their batch commands they send them all, and we run them all.

Server should ping clients to get a pong back. This lets both know they are still connected, and the code we want is still running. If one does not hear from the other after some timeout, they disconnect.

There needs to be a Java Client (Joueur.java) for this framework to be viable as a replacement.

Merging delta states will be fun without dynamic typing...

When we tell a client to merge a delta, that time to execute that merge is currently held against them. We send the delta then the response to the order/run, and start ticking their timer. If deltas merge slowly, we may be taking AI time against them for merging deltas, so they could tell us once they start back up.

Obviously this implied clients are sending server time to add back to them... which competitors could lie about and modify their client to claim it needs extra refunded time for a trivial delta merge. So this is a dangerous idea.

Apparently on Mac OS X gamelog files are not generated. Logs are using the --log arg, but even though no errors claim to happen no files are dumped in output/gamelogs according to @takaaptech in siggame/Joueur.lua#2. Basically run two lua clients against each other playing checkers. We expect a gamelog to be generated. Instead none get output.

As I don't have access to this OS, could someone with an Apple machine check this out? takaaptech theorized that maybe the game session thread process was not properly sending data back to the main thread.

I'm more than willing to sit down with any devs to sort this out.

There needs to be a C# Client (Joueur.cs) for this framework to be viable as a replacement.

Merging delta states will be fun without dynamic typing...

Currently, all clients use an argparse like library to parse command line arguments. However all the arguments are used for the Joueur to figure out what AI to run, what game to play, what server to play on, etc. Competitors have no control over their own custom command line arguments.

It would be nice if they could add their own command line arguments. However, we want to avoid collisions, e.g. -s being server for the Joueur, and -s meaning silent console output to them.

So we do not give them all arguments, instead we expose --aiArgs "{url parms formatted string}".

This would be just like --gameSettings, where the string is a url parms formatted string. This was they can pass their own custom dictionary with no collisions, e.g.

./run Chess -s r99acm.device.mst.edu --aiArgs "s=true"

There, we know what server, and the AI is told the "s" flag is "true".

AI side, we'd need to expose some simple dictionary getter, e.g.

this.getArg("s");

This would always return a string. If they know the value should be an int or something they can parse the string themselves.

In the arena, it would never use the aiArgs flag. We would tell competitors to make constants or a config file.

The current ReadMes and Markdown Info seem to be out of date for most systems or are inconsistent.

There needs to be a C++ Client (Joueur.cpp) for this framework to be viable as a replacement.

Merging delta states will be fun without dynamic typing...

AI's currently have the assumed attributes:

player
game

Per game it may be useful to have attributes, just like GameObjects, e.g. AI.opponent

Or just rename player.otherPlayer to player.opponent