jaysonmendoza / 3004project-team9 Goto Github PK
View Code? Open in Web Editor NEWLicense: GNU General Public License v3.0
License: GNU General Public License v3.0
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:
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.
Wireframe gameboard design from players perspective.
Elements to contain
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.
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
The card graphics provided by the professor should be organised into cards of standard sizes based on the deck to which they belong.
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
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
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
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.
We need to be able to hide cards from the front end. This means a few changes are necessary
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.
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.