nijoakim / chakes Goto Github PK

The file Chess.lua tries to load this file but fails to find it. Seems to be missing from repo.

The path seems somewhat strange to me, should there really be a lib folder under rules?

If the dependency on the missing file Util.lua is commented out (see #2), the script will run until the load of the first rook where it will crash with nil pointer exception.

The offending line where piece.name evaluates to "chakes.Rook0" and name to "Rook".

globals.set(piece.name, globals.get(name).invokemethod("new").arg1)                 // Add piece to Lua 

The error message with only the relevant parts included.

org.luaj.vm2.LuaError: @rules/games/Chess.lua:64 attempt to call nil
    ...
    at org.luaj.vm2.LuaValue.invokemethod(Unknown Source)
    at chakes.game.Board$LuaLibChakes$LuaLibFun_CreatePiece.call(Board.scala:284)
    at chakes.game.FourArgFunction.invoke(Board.scala:479)
    at chakes.game.FourArgFunction.invoke(Board.scala:473)
    ...
    at chakes.game.Board.<init>(Board.scala:81)
    ...
    at scala.App$class.main(App.scala:76)
    at runtime.Main$.main(Main.scala:27)
    at runtime.Main.main(Main.scala)
    ...

It would be convenient to have a move function that given a destination square, e.g. e4, executes the correct move providing it is unambiguous. In case of ambiguity, an exception is thrown. It will operate for the current player. This will shorten syntax in places.

The function should be implemented as an alternative to the current movePiece not as a replacement. Overloading of functions seems not to be a great idea in scala (http://stackoverflow.com/questions/2510108/why-avoid-method-overloading), so the name should be distinct from the previous function.

I suggest the current function movePiece remain, corresponding to the semantic action move from square a to square b and introducing a new function moveTo corresponding to the semantic action move whatever to square b.

// Assume it is white to move
moveTo("e4")   // Moves King  side pawn
moveTo("Nc3")  // Moves Queen side knight

The lua part then needs to support letter conversion, both for board squares and for piece names. This is neither unreasonable nor unimplemented. (Letter to board number are currently in scala. Piece to letter is the symbol function of the lua piece. A reverse mapping of this in the game file is all that's needed.)

Note: If this is ever implemented it would be some time in the far off future. The idea is provided as a fundament for discussion and food for thought.

To prevent cheating construct a hash of the current class (implementation) and the state of the object to be synchronised.

Two clients enjoying a match can verify that they are seeing the same state and using the same functionality for modifying the board, determining who wins etc. by comparing hashes with each other. As long as the hashes are the same the clients can agree that they are playing the same game by the same rules. Should the hashes mismatch a recovery operation could be tried (if for example a tcp packet is slow in propagating a state change).

After some arbitrary timeout it is determined that the game is in an inconsistent state and one of the clients is using modified software. But which one is cheating? This is determined by a peer-to-peer majority vote by the collection of online players.

References: http://stackoverflow.com/questions/8867766/scala-dynamic-object-class-loading

To be elaborated on.