arlopurcell / samurai

online version of Honor of the Samurai card game, written in Dart

Bushido - Honor of the Samurai Card Game clone

Currently, it's not really working and isn't deployed anywhere.

samurai's Issues

Improve command output display

Make command history output human readable. player indices can used to get names, and each different command can have it's own format. Additionally, card indices can be used to get which card was played. For example "0 action put 1 samurai" -> "Jim put an Okugata into his samurai's house"

One special case is for the "action play" command, which, based on the card being played, should allow for entirely different outputs. example "0 action play 2 2" could be "Jim dishonored Jeff" but "1 action play 3 4 samurai 0 daimyo" could be "Jess used a Ninja Spy to steal the Noh Theater from Jake (and put it into her daimyo's house)"

Finally, rolls must be considered. I think it's best to have 3 lines, the action (as above), the result of the roll, and the result of the action.

For example it should first say "Jim played a Ninja Assassin on Jeff's daimyo! He needs more than a 4 to avoid the House Guard" or "Jim declared war on Jeff", then something like "Jim rolled a 5", and finally something about the result. Here are the possibilities for assassins and battles, respectively

The assassination was sucessful
The assassination failed
A House Guard sacrificed himself to foil the assassination

Jim's forces emerged victorious!
Jeff's forces emerged victorious!
Jim claims victory and the title of Shogun

depends on #2

perform client-side validation of moves

should improve performance and reduce server load

depends #1

fix re-joining game

socket wise it looks right, but the game never seems to display.

I think the problem is that the re-joining client never sees the "start" command. Furthermore, they never see any of the other commands so they won't have the correct game state. Therefore, I think this depends on #13 so that the server has access to the full game history

improve clarity around who/what action is needed

make it clear when a command is expected of a user and what command is expected. This goes beyond just prepending stuff, because it should be clear that "take" or "burn" is expected when the expected command is "castle" rather than "put" or "play" etc. when "action" is expected.

depends on #4

prepend required data to input command

automatically prepend user input with their player index and the expected command, saving the user from having to input these and avoiding silly use errors

persist games

add some kind of DB back end to store game states. should just be a matter of saving validated commands to a DB and then implementing loading said game.

Pull code out of interface.dart and split validation and execution code

This will put the code in the right, logical place and also allow the client to validate moves before sending them to the server.

InterfaceCallback should have 4 fields: playerIndex, expectedCommand, validator, and executor. The first two args can be used to do common validation, the latter two are functions to do what they say. This would allow interfaces to validate first and then only remove from the queue if successful

Click on game objects to build commands

Fourth, support clicking on cards, houses, and players to input their corresponding names/ids. Clicking on something should highlight it somehow for clarity.

Allow players to have names

Have players send their name along with the game id when connecting. Then include all player names (in index order) in game start (currently "seed") command. Use these names in player display and (pending another issue) in command output display

implement lobby

should be able to see, create and join games in lobby. possibly only admin can send start command.

create full display for command input

This should include highlighing which card is to be played and its destination(s). The primary card and target (card/house/player) highlight should be consistent across all actions, plus a third color for secondary targets (I think the only one is where a spy is putting something after they steal it)

It might even be nice to have arrows, but that'll be a separate issue and might not be necessary, depending on how clear this issue makes things

depends on #8

support partial validation

allow partial validation, i.e. "play ninja_spy " is invalid, regardless of what they're trying to steal or where they're going to put it.

for clicking, validation should occur before adding onto the partial command, so that if validation fails, the partial command is still valid

for click and drag, failed validation should not allow the dragging action to even start

depends on #8
related to #9

support click and drag for command input

support click and drag for

• put card x into house y
• play card x on player y[, house z]
• steal card x and put into [house | discard]
• re-arrange cards in hand/house (have to keep track of separate "real" and "display" indexes on client side or allow commands to server for swapping)

add name support to commands

support card names instead of just indexes. (careful with Okugata and Army, where the name is not sufficient to disambiguate)

we should also support player name instead of indexes (need to make sure there are no duplicate names, including case-insensitively)

depends on #2