Give it a try. See if it's useful/cool/interesting/a big pain.

Currently, none of the server endpoints handles malformed input well. If an exception is thrown, it is neither caught nor logged. The application should:

• Log server-side exceptions somewhere
• Return a useful error to the client
• The client should deal with returned errors gracefully

Motivation

It would be nice to have someplace on the web to run the application, so that other people can play. Heroku is free for small apps and supports at least some types of Clojure applications. Additionally, it would be nice for me to learn more about Heroku since we use it at work.

Acceptance Criteria

• The application is up and running at Heroku

Currently, the app does not check tokens when actions are submitted, which means that in theory players could assert actions for other players without knowing their tokens. The app should:

• Refuse actions that are not available to the player that submitted them
• Display appropriate UI when this happens

Motivation

TODO

Acceptance Criteria

TODO

Motivation

If there were a way to directly invoke actions against the server, it would allow us to test out how the server responds to requests without having to develop the UI simultaneously. Also, it would let us more easily determine if the UI or the game logic were the problem.

Acceptance Criteria

• The browser UI supports a way to send an arbitrary JSON string back to the server.
• Optionally, the browser UI has the ability to see the JSON with an available action.

h2. Steps to Reproduce

Observe that the tuples returned to the HTML front end are sorted by time, entity, attribute, value.

h2. Expected Behavior

Tuples should be sorted by entity, attribute, value, time.

h2. Tech Notes

I tried to introduce a (sort-by (juxt entity attribute value) ...) into api-get in api.clj, but it throws a ClassCastException:

java.lang.RuntimeException: java.lang.ClassCastException: clojure.lang.LazySeq cannot be cast to java.lang.Comparable

I can't figure out why this is, as calling (map (juxt entity attribute value) ...) against the same collection succeeds without exception.

Background

Currently, the color of a player's pieces is determined entirely by the order in which they join the game. It would be nice if players were able to choose a color when setting up.

Acceptance Criteria

• During setup, players can choose a color for their pieces.
• No two players can choose the same color.

Observed Behavior

• Two players join the game
• Both players have pieces called professor:1, ra:1, etc.

Expected Behavior

• Every player's pieces should have globally unique names.

Tech note

This was broken by some bonehead (Craig) with commit b5bc626 when he removed the global/pieces triple. The global/pieces triple contained duplicate information, since it can be derived from each player's list of pieces, but it was being used to determine the unique names.

One interesting approach to solving this problem would involve introducing a richer query language into the triplestore. Maybe something based on a predicate logic language.

Background

Right now, when the game starts, the Artifact logo is displayed. It would be nice to show the game board instead, even if it's not possible to interact with it.

Acceptance Criteria

• After players have joined and started a game, the displayed image is of the game board.

Tech Notes

Any arrangement of the game board is acceptable at this stage, as long as both boards are displayed. Open question as to what it should look like include:

• Should both boards be displayed on the same screen or should there be some sort of tabbed (or whatever) interface for moving between them?
• Where and how should the player's hand be displayed?
• Should there be a status area indicating which players are what colors?

After a player joins the game, the list of available actions is not being updated to remove transitioning to ready from the list.

Motivation

It would be nice if there was a running description of what has happened in the game. Something like, "Player 1 moved their professor to 'scheme 1'". That would give people a way to see what has happened recently.

We also need a way for errors and alerts to be displayed. For example, if a player tries to make a move that is no longer allowable (for example, if someone else has played a scheme card on them), the game engine needs a way for the player to understand what has happened.

Acceptance Criteria

• Every significant move results in a message displayed to all appropriate players describing what has happened.
• When a player attempts to make an illegal move, they are notified of the fact.

Give GMP Javascript engine a try. Create a small application that demonstrates the following:

• Displays a subset of the major action board and a professor piece
• The ability to move the professor piece to some but not all of the spaces on the board

Motivation

The way the game is set up right now , if someone makes a move when you're not looking, there's really no way to figure out what happened other than to simply try to remember what things looked like before. It would be nice if there was a way to see what has happened recently.

Acceptance Criteria

• Players have a way to review what has changed recently.

Tech Notes

One way to achieve this would be to modify the API so it supports getting any point in history. Something like GET /game?time=3. Then we could add UI to the game that lets you step back in time, rendering what it looked like at each point.

Motivation

With the code as it currently is, more than four players could join, but it would have undefined behavior.

Acceptance Criteria

• After four players have joined the game, it should not be possible for any more players to join.

Motivation

As the application grows more complex, the number of entities and attributes, and the semantics around their values increases. Worse, they are spread throughout the code, with no definition of what they are supposed to mean. It would be nice to have a data dictionary somewhere that at least listed (and preferably explained) what the various triples mean and how they should be used.

Acceptance Criteria

• A wiki page is created that lists and describes all existing entities and attributes along with their allowable values.
• An issue is created to periodically revisit the data dictionary to ensure that it is consistent with the changes in the application.

Background

This is a scenario for the design review 1 demo.

Acceptance Criteria

• I can take a card from any of the decks: doctoral/tenured/arcane hazards, scheme, explore, or Americas/Eurasia/Middle East/Legendary Dig Site. When I click on one of these piles, a card is displayed, and I can choose to either put the card in my hand or place it on the Academy Board, regardless of its type.
• No one else sees my card unless I place it on the Academy Board.

Currently, nothing stops a player from joining a game that's already in progress. Once the game state has already started, new players should be disallowed from joining.

Background

Got new UI from Michael and Kevin

Acceptance Criteria

TBD

Background

In the current incarnation of the game, players are assigned a random color. But they don't know what it is until they get into the game and can see what pieces they're able to move. Additionally, they don't know even when they are in the game which pieces they are able to move except through trial and error. It would be nice if they had some indication as to what color they are.

Acceptance Criteria

• When players have joined and are waiting for the game to start, and indicator of what color they will be is shown.
• When players are playing the game, an indicator of what color they are is shown.

Motivation

The calls to api-get and game-page currently require a dosync, even though they're not writing. Although a transaction to stabilize reads makes sense, it would be more functional to simply pass in the data we need to access.

Acceptance Criteria

• get-triple-value is changed to accept a triplestore, not a ref to a triplestore
• dosync calls are removed where they are not necessary

Motivation

I realized that simply taking the existing board and putting it on the web might not be the best approach. It will be particularly problematic on small screens, such as on mobile devices. It might be better to start fresh and come up with a web-oriented approach.

Acceptance Criteria

• A mockup is produced that shows a proposed layout for a web-based UI.
• Bonus points if the UI is appropriate for small screens or mobile devices.

Tech Notes

• PowerPoint might make a good tool for mocking something up.

It would be really handy if there were a way to link changes in a particular triple (or possibly even in the results of a query) to a function that needs to run, associating that function with a piece of state, where that state is likely a UI element. This could be used, for example, to link the ready state of a player to what's displayed on the joining page.

Background

This is a scenario for the design review 1 demo

Acceptance Criteria

• I can move my professor piece between slots on the Major Action Board without constraint.
• I cannot move other players' professor pieces.
• When I move my professor, its position updates on everyone's board.

It makes more sense to join the game if you can already see who's in it. So the homepage and the joining page could be one page, with a list of current players and a place for you to join up.

One difficulty here is that we have been using the URL to capture the player's session. But I guess there could be a single UI that responds at both session and sessionless endpoints.

Another option is simply to display the list of current players on the homepage, and have the joining page remain as-is.

Using crafty.js, create a small application that demonstrates the following:

• Displays a subset of the major action board and a professor piece
• The ability to move the professor piece to some but not all of the spaces on the board

Using jQuery and/or jQuery UI, create a small application that demonstrates the following:

Displays a subset of the major action board and a professor piece
The ability to move the professor piece to some but not all of the spaces on the board

Background

Slingshot is an enhanced throw/catch framework for Clojure. It may have advantages over artifact.error. We should check it out to see if it provides any benefit.

Acceptance Criteria

• A recommendation is documented here on whether or not to convert to using slingshot
• If conversion is recommended, new issues are created to convert the code to using slingshot

Each player should start the game with one professor, one RA and $3.
The Professor should have no position.
The RA should be in the ready position for that player.

The game page should display a table of people that are joining, and everyone should get a chance to say that they are ready. When everyone is ready the game should start, transitioning to the game-in-progress UI.

Observed Behavior

1. Join two players to the game
2. Click ready on player A
3. Observe that player B does not get notified of player A's change in state.

Expected Behavior

• Players should be able to see when the other person becomes ready.

The main page of the game is pretty Plain Jane. It should have a consistent look with the rest of the application.

The page where everyone meets up and gets ready is pretty boring. It should at least look like the rest of the game.

Problem Statement

Currently, the game produces tuples like [1 player:1 icon /images/professor-blue.png]. But this ties icons to players, not to pieces. Players are not visible; pieces are.

Expected Behavior

The emitted tuples should looke like [1 professor:1 icon /images/professor-blue.png].

Background

When the client Javascript watching an item in the game state, if the tuple value is an array, the watch will always fire. This seems to be because arrays do not compare equal even if they haven't changed.

Expected Behavior

• Watches should only fire if something in the array has actually changed.

Other players should not be able to get the token or self attributes (along with any others that make sense).

It's easy for the API to do, and it'll make detecting insertions and deletions a lot easier on the client side.

Background

This is a scenario for the design review 1 demo.

Prerequisites

• #37 - I can take cards

Acceptance Criteria

• If I pull a hazard card, I'm asked to roll dice.

Background

Currently, the game starts whenever every player has indicated that they are ready. This means that the game can start with any number of players. But the game is designed to support either three or four players. It should change so that anyone can start the game once three or four players have entered and indicated that they are ready.

Acceptance Criteria

• Do not allow the game to start until at least three players have joined.
• Do not allow the game to start until every joined player is ready.
• Do not allow more than four players to join the game.
• Any joined player can start the game once everyone is ready.

Motivation

Because game state is updated via asynchronous calls back to the API on a timer, and because we additional have UI events that make calls to the API as well, we have the problem that a description of "old" game state could arrive after the return from some other update, meaning that the UI would flicker between new and old states.

Acceptance Criteria

• When the client merges game state, it checks the value of [global time] to ensure that it is higher than what the client currently has. If it isn't, it discards the update.
• Calls to the API to post information return the newly updated state, and this is merged.
• While a POST is pending, merges of game state are held.
• When the Ready button is clicked, it changes to "pending" (or similar) instead of going straight to ready, and it's the update of game state that triggers the transition of the display.

Motivation

As a way of fleshing out the infrastructure needed for more
complicated behavior, we would like to start with something extremely
simple. Since the game is going to need to have a concept of players
taking turns, we could start by implementing game logic such that
players do nothing but take turns.

Acceptance Criteria

After a game has started with two players, A and B, the game state is
updated such that whenever player A finishes their turn (indicated by
taking the only available action, "finish turn"), it becomes player
B's turn, and then vice-versa, ad infinitum.

Motivation

BrettespielWelt is some sort of hosting engine for online boardgames. It might provide some service, framework, or platform that we can leverage. We should check it out.

Acceptance Criteria

• Look around at http://www.brettspielwelt.de and see if it offers anything that might be of use.
• Document findings here.

Background

This is a scenario for the design review 1 demo.

Acceptance Criteria

• I can place my RAs on the Academy Board without restraint.
• I cannot move anyone else's RAs.
• When I move my RAs, everyone else can see where they have been placed.

There are already too many places where the store is read multiple times, and in the face of concurrency, that's a problem. We should move to using a ref to store game state, and add dosync calls at the top-level endpoints. First, though verify that reads are consistent within a dosync. Maybe by watching my own video. :)

Using spirte.js, create a small application that demonstrates the following:

• Displays a subset of the major action board and a professor piece
• The ability to move the professor piece to some but not all of the spaces on the board