akaidiot / lobotomy Goto Github PK

Handy new function, desperately needs decent tests.

Initial version could simply hard code the functions calculating the cost of an action, though these need to make sense. Playing around with a few different options should yield some usable values that are both fair and keep strategies non-trivial to perfect.

Later versions should include the calculation of costs in some initial world info state.

A client can send an arbitrary amount of data ([a-z, 0,9]) without an EOL to the server, which can cause the server to run out of memory.

In the 'hit' command, the final parameter is called 'charge' in one space and 'yield' in another. Furthermore, 'charge' is already used to indicate how much energy a robot regains on each turn. I suggest the following:

• Call the regeneration rate 'heal'
• Call the 'yield'/'charge' just 'charge'

To make searching for detected players or players within a particular blast radius easier and more efficient, a spatial index will need to be implemented.

The current idea is to create a quadtree where stored points are made aware of the region they operate and regions are traversable both ways, allowing a point to 'walk' the tree when it is moved, while keeping the O(log4 n) lookup complexity.

To make things properly awesome, some wrapping functionality that deals with a wrapping space is needed to deal with scans and fires that would cross the border of the internal battlefield representation.

Due to any kind of indexing structure not being needed, Donald Knuth is right again: premature optimization is the root of all problems...
Removing it for the time being should fix the annoying KeyErrors and make things a lot easier to debug.

Refernces #2

The current example bot is written in Python, not covering the interests of the complete target audience (ignite ALL the nerds! o/). Simple, sumbed down example bots should be included written in

• Python
• Java
• C#
• PHP
• Perl
• …

Every action taken by any player should be logged to file, along with the absolute positions of players, so players can analyse their performance after the game was finished or visualisations can be made of the game as a whole.

For games that are of no real impact (non-league games, so to say), an internal web server could serve an initial static page that visualizes the battlefield on a web page, periodically updating the view to correspond to the internal state changes made by players.

Additionally, a single player could be tracked by filtering the retrieved data down to the set that the player's client would receive, effectively visualising the game from the client's point of view

State transitions and corresponding state variable assignments are scattered between the server and player handler code, making the current state (harhar) of the server side code resembling spaghetti carbonara. While that shit is totally delicious, in code it's not such a good thing...

The command line starter should be able to write a game log to file and filter output to stdout in some semi-smart way. Using the new event emitter should help with that.

In its current state, a Player is nontrivial to serialize as it contains icky things like sockets. The state information that is required for serialization is simple and readily available though, so creating something that will turn it into a dict-like thing with the player's name, energy and (x, y)-coordinates will help with a variety of things:

• Serializing game state to a log file;
• Caching game states as in #16;
• Console output in debug mode;
• ...?

Simple task, needed for the benefit of all.

Reading from a socket as if it were a file (for line in socket.makefile()) is all well and good, but poses a problem when a client connects and does nothing, hogging the socket's system resources and possibly 'sitting' on a particular name. There seems to be no timeout for sockets that are idle, and the LoBotomy server will never detect the remote end has closed a connection as it will never have to write to the socket...

Possible solution: set a timed action to check whether a client has reached a state that will require constant output. If such a state has not been reached, send an error message and close the socket to free the system and naming 'resources'.

Logs created per #3 should be replayable by a simple game viewer. The simplest UI for this would probably be a static web file, allowing code from #4 to be reused. 'Uploading' the log file to a local web file should be possible, right? :)