code-reviews

slester 2016-01-21T00:38:33.000411Z

Feeling a bit overwhelmed about how to refactor this: https://github.com/slester/amiss/blob/master/src/amiss/core.clj :[

eggsyntax 2016-01-21T01:09:45.000414Z

@slester: you might want to talk about your intentions for refactoring & the problems you've had (I saw your posts on #C053AK3F9, but not everyone in this channel will have...)

eggsyntax 2016-01-21T01:10:06.000415Z

(just kibitzing; I probably won't get a chance to take a look)

slester 2016-01-21T01:10:27.000416Z

@eggsyntax: fair enough. I'm more or less trying to put these things in their own namespaces to avoid having long words like -knowledge in function names

slester 2016-01-21T01:15:39.000417Z

and because I keep confusing myself as to what's going on when I'm trying to iron out bugs

slester 2016-01-21T01:15:48.000418Z

it may be worth a rewrite 😛

2016-01-21T02:47:01.000419Z

@slester: looks like a cool game

2016-01-21T15:47:34.000425Z

hey @slester, took more of a look and have 2 alternative thoughts to offer in the realm of design

2👍
2016-01-21T15:48:08.000426Z

1. take a step back from the current implementation and try to model the public and private events of the game with data, as messages. For instance, the first draw could be encoded as { :action :draw :player :player1 :card :princess }. Player1 may then take some action in response to that draw, like showing a card to another player: { :action show :by-player :player1 :to-player :player2 :card :general }. That forces a public or potentially private response by the second player, where a private response can be showing ones hand to another player.

2016-01-21T15:48:22.000427Z

2. try to model the different public and private perspectives of each of the actors in the game separately. For instance, an individual player can be modeled with a go-loop, consuming public events, updating its own internal knowledge and inferences of the state of the deck and of the hands of the other players, and then calculating a response or action in cases where it is the players turn, or a “plan” in cases where it is not the players turn. And a “game master” actor can act as the enforcer of rules, delegator of turns, etc

2016-01-21T15:49:28.000428Z

why do this? Right now actions and events are implemented as functional transformations onto a single big state blob, which is fine but at a certain level can complect cause and effect both in terms of semantics and in terms of implementation, e.g. circular dependencies. The current model also complects uber game-level rules and decisions with individual player strategies and can make it hard conceptually to keep concerns separate, and allow for player-specific strategies.

meow 2016-01-21T16:51:56.000430Z

wow - great assessment @jonahbenton - props to you ❤️

meow 2016-01-21T16:52:37.000431Z

caring is caring

slester 2016-01-21T16:58:55.000432Z

Wow, great ideas @jonahbenton! Thank you!