kenan-rhoton / card-game Goto Github PK

Clean up the frontend/src/components/Game.vue component in frontend (probably into different Hand and Board components), cause it does way too many things already (essentially does the whole game itself)

Right now, having both players the same hand, making both hands public would let the players have information that they still can infere visually available. If we keep equal hand we should think about implementing it.

Currently we have 4 API calls:

• POST to /games: Returns an entire game-as-player object, when only the game-id and player-id are needed.
• POST to /games/:game-id/: Returns an entire game-as-player object when only player-id or error are needed.
• POST to /games/:game-id/player/:player-id: Returns (guess what?) and entire game-as-player object when only ok or error are needed. Also, this should be a PUT call (my bad).
• GET to /games/:game-id/player/:player-id: Returns an entire game-as-player which is exactly what we want.

So 3 of the 4 calls return unnecessary stuff and on top of that actually require specific logic to implement returning this unnecessary stuff (save-game has an extra line *just to return the saved-game object`)

We should limit the calls to only return what they need. This will possibly require some frontend adaptation.

We want to be able to limit the number of cards each player can play on each row.

To begin with, rows should have a limit of 4 cards per player.
This number must be easy to change and make it different for each row.

Now that we show the number of rows won, it would be great to show how many points each player has on each row.

It would be great (not sure if it should be another Issue) to also visually show who's winning for each row, maybe by highlighting his number (and the same for the number of rows won).

To follow DYR, most (if not all) error and status messages are on backend/src/configs.clj (maybe it should be nested somewhere else?)

There are still some of those hardcoded on frontend/test/unit/Game.spec.js (lines 16, 26 and 29).
(I couldn't find any other case where that happens)

Those should make reference to what's on backend/src/configs.clj.

Right now I'd been putting the answers we gave to the lenses on the Wiki (https://github.com/kenan-rhoton/card-game/wiki/A-Wiki-of-Lenses)

It would be great to:

• Find a way to capture the most important things on the main page (rather than having to go to every Lens' page to know it)
• Be sure the format is appealing to everyone. For every game design duscussion all discussers should be taking the discussed lens into account.
• Translate everything to english (wouldn't it?)

Fix random backend periodic errors (NullPointer Exception in responsify within api_handler.clj:41).

No clue on source or what is going on, it doesn't seem like responsify could actually be causing them...

dropOnRow on frontend/src/components/Game.vue is really confusing and requires an IQ of over 9000 to fully understand.

Ok, I think we need to reorganize and clarify the project structure, this is what we currently have:

• backend
  • doc: why does this even exist?
  • src: Where the backend production code lives
    • card_game: Where the backend production code lives, except configs.clj for some reason.
      • api: Were we define how frontend or any other client can communicate with the system
  • test: Where the backend test code lives.
    • card_game: Where the backend test code lives.
• e2e: Where the end-to-end tests live.
• frontend
  • public: Where the... um... index.html lives?
    • img: Images?
      • icons: icons?
  • src: Where the frontend javascript production code lives.
    • components: Where the javascript... components... live?
    • views: I give up, what's the difference, again?
  • test: Where the frontend tests live.
    • unit: Where the frontend unit tests live

I feel like we could do much better and have a clearer organization with something like:

• backend
  • src: Where the backend production code lives
    • rules: Where are the rules logic lives (currently "core")
    • api: Where we define how frontend or any other client can communicate with the system
    • persistence: Where we define how we store persistent data
    • configs: Where we load our configuration
  • test: Where the backend test code lives.
    • api: Api tests
    • rules: Rules tests
• e2e: Where the end-to-end tests live.
• frontend
  • static: Where static stuff (images, stylesheets, whatever) lives.
  • src: Where the frontend production code lives
    • lobby: Where all the Game Creation/Game Joining logic lives
    • game: Where the actual gameplay occurs
  • test: Where the frontend test code lives
    • lobby: Where we do all the lobby tests
    • game: Where we do all the game tests

Any thoughts or ideas? This would be a pretty big change, and since it is about understanding the system and having everything in a clear place, I would like everyone to say something about it 🙃

Right now the frontend allows you to attempt to play cards to the opponent's side of the board, both dragging or clicking, and in both cases shows that you're "waiting for opponent".

However, the rownum sent is null for those rows, so backend correctly doesn't allow it.

We need to modify frontend so that such an action is not possible and simply ignored.

Right now, under /backend/src/card_game/victory_conditions.clj we have these two functions:

get-points -> Tells how many points each player has on each row
most-points -> Tells which player has the most points

We need to add another one as a step to solve the issue #18 .

The function should be named "get-total-points", it should return the number of rows won for each player (eg the number of points for each player), and it should be placed between get-points and most-points.

Also, we should change how most-points is coded in order to re-use the content of the new function and simplicity.

v0.2.0 should be released with the following default configuration:

• Hand: 10, 9, 8, 7, 6+1, 6-1, 4+2, 4-2 (+/- x means it changes another card's value).
• Row-limit: 4 on each row.

This probably won't be doable until #41 and #42 are solved.

Add a visualization for the next-play (probably by putting a different background color on the card or outline or something).

Right-now there is no indication that you even made the play correctly.

This issue is related to #41, and requires a thin layer over alter-card

We need a function that takes a game-state and a path to a card and can increase/decrease that card's power (or ideally execute any function on it).

Create a Contributing.md file (which is standard for Open Source projects) that clearly delimits:

1. Project architecture and structure
2. Technologies used and their motives
3. Guidelines for development

So the Sample Game e2e test is currently "flakey" (it fails randomly) and this is always an indication of bad test design (and I say this having written it myself).

It must be fixed ASAP

It's an unnecessary dependency in our project (caused by me) that provokes:

1. Weird frontend structure
2. Less intuitive and readable code in the frontend
3. Less flexibility to do things like #44
4. No great advantage (it does provide some) to making our game better

We should instead apply the same philosophy we do to backend: no new dependencies until it's absolutely unavoidable, and attempt to keep everything as clean, organized and simple as possible.

If we do this, we'll have to stop and close all frontend issues to undertake this, and it would be a team effort (I can split the tasks among different issues).

It would have the added benefit that if we all actually work on the frontend base, we'll better understand it, especially if we try to avoid "magic libraries" for as long as possible.

Game is getting complex, and is now a prime target for TDD thanks to #73 giving us webpack to work with.

We can set up Jest to run unit tests on this component and probably take the time to rethink some implementations.

We need to have a clear Game Manual.
This must be a document explaining the rules in a clear and easy to understand way, that encompasses any possible game situation.

This manual is on the Wiki (https://github.com/kenan-rhoton/card-game/wiki/0.-Troll:-Card-Game-Rules).
It is very important that everybody reads it (otherwise I can't see how any rule can be correctly implemented). Also, any opinion regarding how to organize it or its clarity will be very well recieved.

Right now our E2E tests cover what I think is sufficient for the lobby parts, but way less than ideal for the game itself.

Right now we have a single Game test called "Sample Game" which simulates a draw by playing on the same row with each player constantly.

At the very least we need tests that simulate a victory for each player.

This will also require extracting much of the test logic into independent functions (which is a great thing).

Right now all 12 cards have power 10.
It should be changed to 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15 and 16.

In fact, they only work with a running docker-compose up and a manually modified /etc/hosts that maps frontend and backend to localhost.

This needs to be improved.

I am becoming even more convinced by the minute that importing dependencies through (:use in the namespace is an idea spawned by the devil.

It makes the following code "unreadable" in the sense that you have to know by heart whether the function comes from that namespace or is imported from another.

My proposal is to modify all uses of:

(ns card-game.whatever
  (:use card-game.potato
        some-library.module.lolcat))

to:

(ns card-game.whatever
  (:require [card-game.potato :as potato]
            [some-library.module.lolcat :as lolcat]))

so that we reference (potato/random-function instead of (random-function.

If the module name is too long and annoying, shorten it but keep it readable:

(ns card-game.whatever
  (:require [card-game.potato :as potato]
            [some-library.module.breakfast-at-mcdonalds :as breakfast]))

For #41.

This requires there be an E2E test in place, and that the feature works as expected. This is the final step in implementation of issue #41.

Right now there is no hard limit that disallows you playing a card despite your opponent haven't played (or even despite not having an opponent yet).

It would be nice to implement:

1. You don't see your cards until an opponent joins with (add-player
2. Whenever you play a card, you opponent doesn't see it until he himself plays a card (for simultaneous turns)
3. You cannot play a card after playing a card already, unless your opponent has already played the card (and therefore you see both cards now on the row).

Number 3 in particular will be hard because some current tests abuse the fact that you can do it and will have to be rewritten.

Frontend "works" but cannot reasonably be used by a human.

This would be fixed by:

• Applying CSS styles to frontend/src/views and components or,
• More likely: importing Bootstrap in Frontend/public/index.html and using Bootstrap classes to make everything nice in the components and views.

Some weird warnings which I have no clue about their source when running the yarn test.

To solve #42:

Frontend should not allow a player to play a card in a row in which there are equal or more than its limit cards owned by him.

Also it should give some visual explanation to explain why a play is ignored due to this.

Make the scores in frontend actually mean something. Right now my-score and opponent-score do absolutely nothing in frontend/src/components/Game.vue

We need to clean up the backend project structure.

In particular I'm worried about:

• API: I think we should split api.clj into two files (with one of them only containing the actions directly reference in api_handler.clj and the other containing the "helper" functions. In any case, I think they should be in a subdirectory and all be contained within a card-game.api.* namespace.
• Tests: Seriously, api-test and core-test are both over 150 lines. Also the `(defexpect' groupings are kinda random. We need to restructure the tests to be more clearly focused on different functionalities by file. Also, "API" is not a functionality, it's just an interface...
• Core: I think we should also split up this file but I'm unsure how.
• Build Card: We should burn this with fire. Both the tests and its functionality and replace it with whatever it does. I don't know what I was smoking to think it was necessary for some reason.

We want to be able to have cards that change the value of other cards (in our hand or in the board).
Cards will be able to have negative value due to this.

The card which power will change have to be chosen (not random nor predifined) when the card is played.
How much the power will change must be an attribute of the card.

Right now rules/create_game.clj always use hand/ini-hand for the initial hand.

We are planning row limit (#42) and power-changing cards (#41), that we will need to put into the game.

But trying to make all the tests handle all the possible cards and rows configurations will be impossible.

For that I suggest being able to have some options when creating new-games (maybe having different configs to test different things?). That will allow us to design tests targeting what we wanna test, and not spending a lot of effort to solve problems not related to the test.

Probably this Issue should be addressed before #42 and #41.

To solve #42:

Backend should not allow a player to play a card in a row in which there are equal or more than :limit cards owned by him.

Upon playing a card there an error should be returned.

Game should allow players to have different initial hands, so no player has perfect information.

Right now cards can only be played by dragging them onto the boardgame.
They should be playable also by clicking them and then clicking on the row.
That would imply marking them while they are "selected" (Probably should be worked with #16, for using an outline in both cases, but with different color).

Because of #41, sometimes cards will be played with a target.

Change the play-card behavior so that it more clearly delimits which card is who's instead of the very ugly "Owner" tag.

One options is to divide the play area into TWO areas (my-area and opponent-area) and make cards go there. Bonus points for symmetry.

Due to #41, this is the frontend presentation issue.

I've realized many backend tests have more dependencies than needed (effects_test really does NOT need to call create-game for anything) as well as some that can simply be greatly improved in style and clarity.

It would help a lot to have another pass and maybe establish concrete guidelines for unit tests.

We need to be able to play among ourselves!

This will mostly be a DevOps style task, and I'm not sure yet if we'll put it on v0.2.0 or v0.3.0, but I want it to be visible!

To solve #42:

We should be able to configure a row limit for each row.
Rows should be something like: (:rows game-state) => [{:limit 4 :cards []} {:limit 4 :cards []} {:limit 4 :cards []} {:limit 4 :cards []} {:limit 4 :cards []}], with that default limit found in configs/rows.clj

We are changing almost everything (mostly backend) so we have an array of all the cards (therefore, identified by an independent index). Cards in this array will have an attribute showing the zone in which the card is. That means a change from "Zones with cards" to "Cards in zones".

Everything from backend/src/rules is already changed, including tests.
backend/src/api needs to have the tests changed so they use the format "one-test-file-per-src-file".
Now the following needs to be done:

• Double-check backend tests (and add any that's needed/missing)

• Tests for api/base.clj: Put the current ones together.

• Tests for api/base.clj: Test (play-card-as-player

• Tests for api/conversions.clj, api/generators.clj and api/handler.clj. This should be pretty easy, since most of those don't do much.

• Adapt all tests on backend/old_tests/ (this should be covered by the previous two points, but just in case...)

On board/board.js, setBoard(boardState) we clear all rows before putting all cards on each row again.

Problem is that actually this process of cleanings seems to not work.

gameRows.forEach(function (gameRow) {
    console.log("cleared")  //Added to see that it actually never entered here
    helper.clearChildren(gameRow);
})

Ok, this mistake is the cause of #28 and #20. It's also stopping #13. In fact, it's a miracle we've even had ANY passing Travis builds with this thing.

In frontend/src/components/Game.vue we have this near the end:

  created: function() {
    this.updateGame();
    setInterval(
      function() {
        this.updateGame();
      }.bind(this),
      1000
    );

This makes the browser poll the this.updateGame once per second but this is NEVER KILLED. It would normally be killed when the browser leaves the page, but since the Vue router abuses the # on the URL, you technically never leave the page.

We need to make sure the function can be killed and is killed whenever we navigate away from the page via router.

This is done via beforeRouteLeave as described in https://router.vuejs.org/en/advanced/navigation-guards.html

To solve #42:

Frontend should show the row limit for every row.

Right now, on the backend cards of both players are put on the same vector, regardless of their owner (using the attribute :owner).

On frontend we already want them divided by owner.

For Issue #42, we will want to know how many cards each player owns on each row. I think that, before addressing that it is interesting to divide rows like we do on frontend.
Right now rows are: [[] [] [] [] []], i propose [[[] []] [[] []] [[] []] [[] []] [[] []]]
I think such change will make all functions that need to know the cards of a single player way more readable.

Due to #41 we want some cards to have an effect when they are played, in particular the effect of modifying other cards.

We need to keep track of our discussions regarding Game Design.

Right now this is being done on the Wiki (https://github.com/kenan-rhoton/card-game/wiki/A-Wiki-of-Lenses).

It's very important to have the document updated and easily referenced, so we can check what we decided when working on new aspects of the Game Design.

I think it would be great to have an AI asap for two reasons:

1. At some point we will probably want to create one anyway, for single-player experience

2. To find best strategies. Right now we don't have neither enough players nor time to really find the best strategies. That means that almost surely we will miss huge balance issues, or always-winning strategies. Having an AI will help a lot in finding those strategies and see what rules need to be tweeked.