Each game has its own state, for us to know what we need to do, depending on the inputs, the best approach would be to create a finite state machine.

Created with Finite State Machine Designer by Evan Wallace

The state machine would be its own class, but the state needs to be stored in Redis.

To recreate the diagram easily one has to edit the local storage on the page and set the following value for the key fsm:

{"nodes":[{"x":266,"y":140,"text":"wait","isAcceptState":false},{"x":78,"y":110,"text":"enter","isAcceptState":true},{"x":408,"y":248,"text":"allocate","isAcceptState":false},{"x":133,"y":345,"text":"pyramid","isAcceptState":false},{"x":562,"y":194,"text":"deal","isAcceptState":false},{"x":213,"y":509,"text":"reveal","isAcceptState":false},{"x":552,"y":367,"text":"bus","isAcceptState":false},{"x":552,"y":552,"text":"deal","isAcceptState":false},{"x":371,"y":485,"text":"sip","isAcceptState":false},{"x":562,"y":110,"text":"end","isAcceptState":false},{"x":91,"y":450,"text":"sip","isAcceptState":false}],"links":[{"type":"Link","nodeA":1,"nodeB":0,"text":"create game","lineAngleAdjust":0,"parallelPart":0.408164437044267,"perpendicularPart":12.623748138025615},{"type":"Link","nodeA":1,"nodeB":0,"text":"join game","lineAngleAdjust":3.141592653589793,"parallelPart":0.5191479969098335,"perpendicularPart":-27.923310873615538},{"type":"Link","nodeA":0,"nodeB":1,"text":"leave game","lineAngleAdjust":3.141592653589793,"parallelPart":0.3785956249641154,"perpendicularPart":-95.64800284891797},{"type":"Link","nodeA":0,"nodeB":2,"text":"start game","lineAngleAdjust":0,"parallelPart":0.5,"perpendicularPart":0},{"type":"Link","nodeA":2,"nodeB":3,"text":"all cards dealt","lineAngleAdjust":0,"parallelPart":0.5,"perpendicularPart":0},{"type":"Link","nodeA":2,"nodeB":4,"text":"cards remaining","lineAngleAdjust":3.141592653589793,"parallelPart":0.6979917118265858,"perpendicularPart":-19.919173623548616},{"type":"Link","nodeA":4,"nodeB":2,"text":"deal out card","lineAngleAdjust":3.141592653589793,"parallelPart":0.47385620915032683,"perpendicularPart":-19.523741203679055},{"type":"Link","nodeA":3,"nodeB":5,"text":"cards remaining","lineAngleAdjust":0,"parallelPart":0.4470863619563878,"perpendicularPart":-35.917883704932756},{"type":"Link","nodeA":3,"nodeB":6,"text":"bad luck booy","lineAngleAdjust":3.141592653589793,"parallelPart":0.7141646660076261,"perpendicularPart":0},{"type":"Link","nodeA":6,"nodeB":7,"text":"cards remaining","lineAngleAdjust":3.141592653589793,"parallelPart":0.4406779661016949,"perpendicularPart":-43},{"type":"Link","nodeA":7,"nodeB":8,"text":"wrong guess","lineAngleAdjust":3.141592653589793,"parallelPart":0.36319880321311265,"perpendicularPart":-12.19818698479238},{"type":"Link","nodeA":8,"nodeB":6,"text":"sipped","lineAngleAdjust":3.141592653589793,"parallelPart":0.40075381437321067,"perpendicularPart":-12.184593577999934},{"type":"Link","nodeA":7,"nodeB":6,"text":"correct guess","lineAngleAdjust":3.141592653589793,"parallelPart":0.559322033898305,"perpendicularPart":-12},{"type":"Link","nodeA":6,"nodeB":9,"text":"no cards left","lineAngleAdjust":0,"parallelPart":0.5766527082797925,"perpendicularPart":82.2957012405102},{"type":"Link","nodeA":9,"nodeB":0,"text":"rematch","lineAngleAdjust":0,"parallelPart":0.5397894166026481,"perpendicularPart":0},{"type":"Link","nodeA":9,"nodeB":1,"text":"no rematch","lineAngleAdjust":0,"parallelPart":0.3305785123966942,"perpendicularPart":70},{"type":"Link","nodeA":5,"nodeB":10,"text":"distribute sips","lineAngleAdjust":3.141592653589793,"parallelPart":0.45494146474271724,"perpendicularPart":-28.704774203511835},{"type":"Link","nodeA":10,"nodeB":3,"text":"distributed","lineAngleAdjust":3.141592653589793,"parallelPart":0.5908011869436203,"perpendicularPart":-7.973342083233425}]}

State out why we use Redis and how to get started with local development. Using Docker or binaries. Maybe Development.md is a good place for this?

Events received via websockets should be dispatched to react-redux immediately. All events must therefore include a type property, which is equivalent to the redux event type.
Consider using socket.io-client for this purpose.

I just detected that there is a src/main/webapp/README.md which describes the usage of next.js. This does not quite work as it was the default-generated README.md (I don't even remember this part to be generated, lol). Update it with the latest configuration and usages related to frontend development.

Why?

• Prevent the productive code from unreviewed changes
• Code reviews for functionality and maintainability
• Tracking of builds with the corresponding commits

How

master - contains the productive code

• Versioned (SemVer) according to releases
• Tagged with the corresponding release version
• Tagged with the corresponding build

develop - the development or canary branch

• Contains the latest changes
• Pull-Requests will be merged into this branch
• Default branch of this repository

Branching strategy

feature/* - for issues labeled with documentation or enhancement

• Prefix the branch name with #[ISSUE_ID] in order to allow a good tracking

bugfix/* - for issues labeled with bug

• Prefix the branch name with #[ISSUE_ID] in order to allow a good tracking

Pull-Requests

Pull-Requests always require at least one review, ideally from code/project owners. Pushes to master are not allowed, to development are restricted to maintainers (but not recommended).
All builds must pass in order to be approved.

Do some research on card game frameworks (in JS or similar) out there. A first version of the game might be hand made and not include many animations but, later on it will get more difficult.
Maybe also take a look at motion-ui (sass animations) which is already included as a dependency of foundation-sites.

Waiting room with WebSocket connection (e.g. redux) to get notified when players join.

I've tried bundling the static pages into the .jar via Gradle:

withType<ProcessResources> {
    dependsOn("src:main:Buessle-Webapp:npmExport")
    from("src/main/webapp/out") {
        into("static")
    }
}

However it seems, that those pages aren't served from the root url (/). Maybe spring-mvc is required as well (to resolve .html files).
And there is a strange out folder in the .jar file. It containins just an _next folder with a single file. This needs some investigation.

Create a sticky footer with a link to a new Impressum page. Also include at least a link to the GitHub repository and maybe one to /issues/new as well.

I think the application requires two endpoints and a websocket.

• A POST endpoint /game/new to create a new game. The payload contains the following items: {name, gameMode}. The response should contain a unique game id, with whitch one can invite friends. The creators session id is immediately assigned to the new game.
• A GET endpoint like game/join/{gameId} in order to join a game with the id created above. The session id will be appended to the current attendants of the game.

The websocket handles/identifies connections via session id (spring-security). It pushes updates to subscribers once moves were done. Endpoint, topics and models (e.g. events) to be defined in this thread.

Das Spiel muess no chli vielfältiger werde.. und Texte sötte dem entsprächend i Sprach-Fäils usglageret werde : )

The main game room. This is where all the fun happens.
Related to, respectively blocket by #26 .

It's hard to test a game without multiple users and a backend (front- and backend development happen separated). A websocket node application which allows one to push events might be a good idea. We could "mock" or better simulate the backend this way and influence the frontend (e.g. trigger redux events) the way one wants.

Currently when developing locally, most of the time one has to wait for the build to finish. This is rather time consuming and should be improved

• check if the build can be done incrementally, e.g. only recompiling things that have been changed
• definetly don't run prettier, linter and coverage in the normal local build

The frontend is barely tested (using one POC test). Important mechanisms should be covered by unit tests (named *.spec.js). The tests are part of our build pipeline and coverage is also reported in every pull-request.

The frontend is barely tested (using one POC test). Important mechanisms should be covered by unit tests (named *.spec.js) what will be done in #24 . These tests are part of our build pipeline and coverage is also reported in every pull-request.
In addition, one might want to test the ui functionality in a more integrated way. cypress would be a good framework to use. It allows you to mock certain things too, which is very useful at this stage of testing (cookies, routes etc.). Because calling the backend is not part of this test scope.
It requires little changes to the build pipeline too (enable Chrome browser on Travis-CI).

The correct project url would be https://codecov.io/gh/bbortt/buessle-app.