jaysonmendoza / 3004project-team9 Goto Github PK

Game Phase controller will use PlayArea's that act as models in order to conduct their flow of the stage it represents. This should either use an Interface or Abstract Superclass and have Quest, Tournament, and Event concrete controller classes.

These classes may create play area's for each card grouping it needs to track, and must be aware of all the player's play area's.

Phases impose rules on Play area's somehow determining what cards are allowed to be played at a given time.

Player play area's should maintain some sort of association with an active game phase while it is active which must be established by the game phase controller as it's initlized, and disconnected when the phase is concluded.

In short GamePhaseControllers know how to work with various PlayArea's as the two are designed to coordinate with each other.

To complete this the API between PlayArea's needs to be defined.

Map out the overall game sequencing in a scenario graph so that we fully understand the logical flow. This needs to be verified by a partiner using the game rules to prevent error.

Create a space in which you can display a larger version of a card. The user's cards should be selected by clicking on them within the player's hand. It should then display the card (enlarged) with 2 buttons located at the bottom labeled 'play' and 'discard'. Only discard should be implemented for now, it will discard the currently selected card

.

PlayArea's need to exist for all players, and active gamephase stages that use cards.

They should display cards to the user depending on their point of view. If it's a Quest Stage than cards should only show if the stage is active. Only the active stage needs to show in full display. Non active phases might show as a card stack with only card backs.

Player play area's will show all the active cards and allow players to choose and play cards from them. Depending on the game phase that is active, some cards may have an indicator on their border to show they are cards available for play in that phase. However, the client can choose any card to play and the server will decided if its allowed (Cards with active abilities may be played when phases normally wouldn't allow it). Example. Perhaps during a Foe Stage setup, the sponsor's card area will show foes and weapons (White list) with a beige border so they stand out a bit but not too much.

Determine the design patterns that will be used in the system with reference to the February 18 project delivery detailed bellow.

Step 3: February 18th 10PM: one member of your team submits to Brightspace a
pdf document that:

• states your tentative choice of architecture and user interface (taking into
  account the existing expertise of the team and relevant learning curves)
• suggests who is going to do what for each of the iterations described below
  (and possibly reports any team issues)
• explains how you will use (or not) the following patterns in your design:
  o Strategy
  o Observer
  o either Factory Method or Abstract Factory (by mapping what you
  envision onto the pizza example).

Text box with scroll feature in the bottom right of the game board. Purpose is to record various game events throughout the game. (for example, when a player draws a card it would display "playerX draws a card").

Map out the sequences of the Quest phase after the main game enters it. Take care to capture every possible detail in the sequence related to the provided rules. This must be verified by another person to ensure accuracy.

QuestGameController must implement the game sequence indicated in the Scenario Graph (Scenario.Graph.for.Game.Sequence.pdf).

The Quest game controller should deal with player registration, removal, and control the associated game state.

A state machine must be used.

The Git repositiory needs to be setup to with a combined structure that includes the front-end react/JS structures and back-end Java file structures in a way that they do not interfear with each-other.

This issue is about the integration work. The front and back end structures and setup are seperate issues.

• There should be a file sub-structure dedicated to the React/JS front-end components
• There should be a file sub-structure dedicated to the Java/Spring-Boot/Thymeleaf back-end components
• Maven needs to be setup to support these stuctures
• It should be in Intelij file stucture format, but the intelij files that are user-preference specific should not be included. (When someone pulls their preferences should not be overwritten by the repo)
• The node react app should know about dependencies, but not include the node-modules folder

Wireframe gameboard design from players perspective.

Elements to contain

1. Adventure Deck Draw Pile (327x470)
2. Adventure Deck Discard Pile (327x470)
3. Quest Active Card Area with stage slots (Story Cards 327x491) [Organized in a line, see rules for example )
4. Rank Deck Draw Pile (327x491)
5. Rank Deck Discard Pile (327x491)
6. Story Deck Draw Pile (327x491)
7. Story Deck Discard Pile (327x491)
8. Shield Token Pile (327x327)
9. Player Hand [Cards in a line] (Adventure Cards 327x470)
10. Opponent Player Hands [Cards in a line] Uses same format as players, but only card backs. Should see how many cards in hand and can be organized around the edge of the game board. (Adventure Cards 327x470)
11. Game brand marker on center board background
12. Game Main menubar
13. Player Action bar? (Can potentially replace with clicks)
14. Gate state HUD. This should include Active Rank card and shield tokens the player owns. (ex. What phase is the game in, who is the active player)

Design a page in which player(s) wait until 2-4 players have connected. After this condition is fulfilled there should be a button with the option to begin the game, at which point it will take you to the game board and begin the game.

Using the wireframe design approved, create the graphics that will make up the main game board and menu's

This ticket involves the setup of the project's front end tech stack.

• Setup a tech stack for a single page front-end application using React.
• Build a basic controller named named to be the dispatcher. This will initially serve only a single component to verify functionality and make a websocket connection.
• Test that a visitor can see the test page

Once Basic Back-End has been Established the rest will be done in #13

Breakdown the work required to implement the game and it's systems into stories and sequence out those stories. Ensure to indicate which stories are dependent on others. Ensure that any story with pre-requisites that exist require them in order to START. If a story can be partially started without pre-requisites it might be two or more stories.

PlayAreaStore must be implemented and connected to the backend in a 1:1 fashion, allowing for mirrored states(be it players individual play areas or quest stage areas), keeping track of the current play areas (any quest stages, and play areas for each player), and played cards(Taking over some functionality from current Store.js).
Quest stage play area should keep track of stage type, the stage card, any active cards in the area, stage number(as key), quest sponsor, as well as the stages current total battlepoints.
Player play area should store whitelisted cards that can be checked against to allow frontend implementation of playability border indicators.

Must be completed after #82

GameState store implemented to keep track of the current gamestate, updated in tandem with backend state changes, storing game phase name, current active player, taking over some functionality from current Store.js

Create areas to display pick-up and discard decks for story and adventure cards. The discard decks should show the most recently discarded card, while the draw decks should show the back of the cards. Furthermore, having a counter for the number of remaining cards would be ideal.

Create a space where player hands and active cards are contained, and displayed. User's adventure cards should be shown, while the adventure cards of other player(s) should be hidden. (It should display the card back)

The card graphics provided by the professor should be organised into cards of standard sizes based on the deck to which they belong.

• Shield token cards (these can be repeated because they have no difference in value)
• Adventure Deck Cards (Foe, Ally, Weapon, Amour)
• Rank Deck
• Story Deck (Quest, Tournament, Event)

This is not all assets the game will use. This workload is to convert the provided assets into something usable and organize them

Implement the Event system and test that it works

Map out the sequences of the Event phase after the main game enters it. Take care to capture every possible detail in the sequence related to the provided rules. This must be verified by another person to ensure accuracy.

This is a test

• Create a websocket connection with the back-end
• Establish a session with the back-end.

User Interface implementation utilizing PlayAreaStore features
Quest stages: active quest stages maintain a front and center view, while players are made aware of future/past quest stages(grayed out areas, or turned down decks of quest cards).
Player areas: Player hands should have borders that indicate whether a card is suitable for playing according to the whitelist(card should still be playable, but upon rejection from backend card returns to player hand and player is informed).

Map out the sequences of the Tournament phase after the main game enters it. Take care to capture every possible detail in the sequence related to the provided rules. This must be verified by another person to ensure accuracy.

Card Area's coordinate with GamePhaseControllers, and Players as a model, tracking all cards that are in play and being played into the active game phase.

GamePhaseControllers must be able to register themselves with a CardArea so that they begin requesting validation from the GamePhaseController. The CardArea's also recieve white lists from the GamePhaseController determining what cards it is accepting depending on the current GamePhase state. CardArea's will be notified when a GamePhase has ended and should change their behavior accordingly.

CardArea's are responsible for keeping track of what cards must should be boosted at a given time within the play area as some cards such as allies are boosted based on the active quest or other ally cards in play. They must know when that condition exists and update the card boost status accordingly.

CardArea's should also trigger events that inform the client when a card play request was rejected.

CardArea's coordinate with the deck for discarding cards when they are removed from play, or transfer cards to the GamePhaseController if playcard was successful.

CardArea's recieve cards from Controllers. For example the Player will send cards played from the player's hand, while FoeStage play area's will receieve cards from the GamePhaseController after it's accepted into that game statge.

Mainly focus on methods that interact with other entities instead of the game manager

• All story cards and some adventure cards (weapon cards, foe cards)
• An adventure deck and story deck
• The player entity

• Make a Maven with Junit Intelij file structure for the Back-End that will be included in the repository.
• Generate and run a basic project template in Java using the Sprint Boot and Thymeleaf frameworks
• Add any plugin's required to support websockets and sessions. Prioritise use of aformentioned frameworks over introducing new ones.
• Setup server for single page app (all GET request endpoints serve the app)
• Setup classes and API endpoints necessary for coordination with the client in order to setup a session and websocket connection. Keep in mind that the server must associate a websocket connection with a user session. You do not need to create a game engine class yet. We just want to make sure a player can connect.
• Send a "playername is registered" message through the websocket using session information.

• Setup instructions on how a user that has cloned the repository needs to be found in the git wiki including anyt dependencies that needs to be downloaded, installed, and configured externally.

• Study and document the list of events that the game manager will listen to
• Study and document the list of objects that are dependent on each event
• Implement the handlers for each event based on the findings

Issue to be addressed

Split stores into
NotificationStore.js
GameStateStore.js
PlayAreaStore.js
PlayersStore.js

Research on how the component directory should be structured to improve readability expandability

No card back graphics have been provided, so those will need to be created and match the size of the deck.
A card deck graphic for each back should also be created

Needed Graphics

• Adventure Deck backing (327x470)
• Rank Deck Backing (327x491)
• Story Deck Backing (327x491)
• Shield Token Backs (327x327)

Create a ROUGH UML class diagrame Skeleton that Supports the System.

This diagram's purpose is to act as basic requirements for developers implemnting them. The diagrams are not intended to be comprehensive but must express the following.

1. The publicly accessable methods that are to be used by other classes
2. Any key properties that must be tracked by that class
3. The relationship between classes implementing the system described in #19
4. The design patterns described in #20

We need to be able to hide cards from the front end. This means a few changes are necessary

• PlayerPlayArea's need to track the visibility state of cards
• Outbound service must support sending partial group messages with one person recieving a different message than others.

Create temporary buttons to draw cards and end player turns, these should only work while the user is currently in the middle of their turn. The draw card button, should add 1 card to the user's hand (for now not above the card limit), the end turn button should end the user's turn and move it onto the next player.

Develop Code Standards and Update Wiki

Make PlayerHand component rendering dynamic (i.e. use Map or an Array)
Give GameBoard control over the subcomponent's positions

Create a system level diagram that identifies each key component and illustrates the flow of communication required between them for the game to work. This must implement the FLUX archetecture.

• Study and document all necessary endpoints and payload structure for frontend communication
• The socket controller implementation should handle all inbound and outbound messages from the frontend
• Study on how the game manager should be set up to be able to listen to all events in the game to mediate them toward the appropriate objects (for now just focus on ease adding a new event)

Fix the appearance of the CardComponent's Play button

Update the UI with current game state information, indicating what kind of state the game is in (Quest Stage 2, Player 2's turn)

Place connect functions into a single object, and make import * instead of individual names