Assessed Coursework
代写report | java | oop | 代写project | unity代写 | AI代写 | 作业assignment | react – 这是利用AI进行训练的代写, 对AI的流程进行训练解析, 是比较典型的report/java/oop/unity/AI/react等代写方向, 这是值得参考的assignment代写的题目
####### Course Name IT/SD Masters Team project TCG 2021
####### % Contribution to final
####### course mark
####### 100 %
####### Solo or Group Solo Group ^
####### Anticipated Hours 100 hours per person
####### Submission Instructions
####### See details under Submission
####### Please Note: This Coursework cannot be Re-Assessed
####### Code of Assessment Rules for Coursework Submission
Deadlines for the submission of coursework which is to be formally assessed will be published in course
documentation, and work which is submitted later than the deadline will be subject to penalty as set out below.
The primary grade and secondary band awarded for coursework which is submitted after the published deadline will
be calculated as follows:
(i) in respect of work submitted not more than five working days after the deadline
a. the work will be assessed in the usual way;
b. the primary grade and secondary band so determined will then be reduced by two secondary bands
for each working day (or part of a working day) the work was submitted late.
(ii) work submitted more than five working days after the deadline will be awarded Grade H.
Penalties for late submission of coursework will not be imposed if good cause is established for the late submission.
You should submit documents supporting good cause via MyCampus.
Penalty for non-adherence to Submission Instructions is 2 bands
####### You must complete an Own Work form via https://studentltc.dcs.gla.ac.uk/
####### for all coursework
IT/SD MASTERS TEAM
PROJECT 20 20 – 2021
java Tactical Card Game
This assignment has a weighting totalling 100 % in your grade for the course. Further details are provided on the Moodle page.
Context
Online collectable card games are a popular type of multiplayer video game. Collectable card games were originally physical card games played between people. The first collectable card game was Magic the Gathering, developed by Richard Garfield for Wizards of the Coast in 1993, and is still one of the most popular collectable card games today. Various online variants of these physical games were developed and tested in the 90 s and 2000 s, but failed to get significant traction (usually due to poor UI design). This changed in 2014, with the release of Hearthstone by Blizzard Entertainment, which was a smash hit, primarily because it was not attempting to directly translate a physical game to the online medium, but was built for that online medium from the outset. Since the release of Hearthstone, there have been a large number of other successful collectable card games, such as Magic the Gathering Arena and Shadowverse.^1
Most online collectable card games are heavily inspired by the innovations brought by Hearthstone. In particular, they are configured as a 2 – player card battle game. Each player has a deck of cards that they can customise, where they draw cards from during the game (usually one at the start of each turn), forming the players hand. During each turn, players can spend a regenerating resource to play cards from their hand, which either summon units into the game board or have some other (beneficial) effect. Units on the board tend to have two core statistics, attack and defence/health. If a unit started the turn on the board, they can typically be used to attack the opponents units or the opposing player directly. Each player has a health total, and when that health total reaches 0 they lose the game.
One of the more unique online collectable card games to be developed was Duelyst, released in 2016 and is now discontinued. What makes Duelyst different to other collectable card games is that it utilizes a more complex board. Most collectable board games use a simple x by 2 layout, where each player has x slots into which they can summon units. Duelyst instead uses a 9 by 5 layout, adding depth in gameplay by enabling units to move and gain positional advantages. Duelyst also places a players avatar on the board, rather than having them sit at a board edge.
You will be implementing a simplified version of back-end logic needed to play a single Duelyst match.
(^1) Their success is also a contributing factor to the proliferation of loot-box systems in modern video games, as collectable card packs are the original form of loot box.
Aim
The aim is to design and build a computer program to allow a user to play a simplified single Duelyst match following the game rules against an AI opponent given a deck. You will only be required to build the back-end game components in Java (game logic, game state tracking, card logic implementations and the AI player logic). You will be provided with a Java template project (after you have finished your system design) that implements the user interface logic for the game.
Functionality
The solution you are to develop needs to enable only a single game to be played. You do not need to implement any of the surrounding systems that usually accompany a collectable card game (e.g. menus, deck creation or match making), You also do not need to implement the user interface for playing the game. That will be provided for you in the form of a Java template project. Instead, your solution needs to monitor event messages that the user interface sends to your solution indicating the user has interacted with the UI, and send commands to the UI to display game state changes to the user. From a high-level perspective, the core functions that you need to develop are:
- Core Game L oop Logic : A set of classes that implement the game rules (see the Game Rules Description Slides on the Moodle) and are able to interact with the provided UI application programming interface to enable a game to be played (see the Messaging and the Provided API Specification for Commands and Events Slides on the Moodle).
- Game State Tracking : As the game progresses you need to write classes to store and update the state of the various elements of the game (e.g. the board state, player states, cards, etc.)
- Card Logic : You will need to extend the Card base-class to implement the logic and rules associated for 20 Duelyst cards (see the Cards to be Implemented Slides on the Moodle).
- Player 2 AI : You need to implement a semi-intelligent AI that is able to follow the game rules and provide the human player a basic level of challenge.
You should familiarize yourself with the design document slides provided on the Moodle, as these provide more detailed information:
- Game Rules
- UI API Definition
- Card Descriptions
Note that this is not a fully featured version of Duelyst that you are implementing, so be careful of looking at external online descriptions of how the game is played, as there are differences.
Project Phases
Working in a team of 4 or 5 students, you are required to design and implement a Java program with the above functionality. The project is divided into two phases or parts:
- Part 1 : Team Setup, Requirements Capture, System Design (2 weeks) o During this first phase, you will be assigned a team and you need to produce the initial design for your solution given the provided documentation. o You will submit three design documents at the end of this phase (a set of story cards, a class description document and a process flow description for a single player turn), which contributes 30% of your overall marks for the course. o Submission: 9am May 31st
- Part 2 : Solution Development (5 weeks) o During the second phase you will develop your solution in Java. You will undertake a development Sprint each week and produce a sprint report at the end of each week (following the agile Scrum methodology). o At the end of this phase you submit your sprint reports and code-base. The sprint reports contribute 10% to your mark, while the code contributes the remaining 60%. o Submission: 9am July 12th
Pre-Project
Prior to the start of the project period (the 17th of May) you will have the opport unity to register a team via the
Moodle. Teams can have a maximum of 5 students, although some teams may have 4 members if the number of
students does not match up. We do factor in the team size when marking the projects, so a four-person team is
expected to produce a less polished solution than a five-person team. We will endeavour to accommodate team
formation requests as provided on the Moodle. Students not in a team will be automatically added to teams. A
spreadsheet with team members will be released on the 17th of May. Changes can be requested on that day. The
teams will be locked on the 1 8 th of May.
Part 1: Team Setup, Requirements Capture, System Design
######## 17 th May 28 th of May
During the first part of the project you will be meeting your team and performing the design work for your solution. Here are recommended activities:
Week 1 (starting 17th of May) o Check you are part of a team via the spreadsheet on the Moodle o Set up an initial meeting with your other team members, have a discussion about their prior programming experience and skills. You will want to nominate a team leader to make decisions if consensus cannot be reached. o Attend the launch lecture on Wednesday the 19th of May at 11am (UK time) o Read through the product documentation slides on the Moodle in detail o Watch the Story Cards Introduction video on the Moodle o Organise a team meeting and based on the project documentation produce story cards describing the main functionalities of the desired system (to be submitted, 10% of your marks)
Week 2 (starting 24th of May) o Allocate each team member a subset of the story cards and have them produce a list of the Java classes that they think will need to be developed to support each card, along with a sentence or two for each, summarizing the key functionality those classes need to provide. o Organize a team meeting to discuss the classes produced and combine into your full class list (to be submitted, 10% of your marks). o As a team write a summary of the process flow for your solution for the human players turn as a set of bullet points representing a timeline of interactions. This should include interactions that the user makes with the UI and how your game logic will react to those interactions (to be submitted, 10% of your marks). o Remember to submit all three pieces of documentation to the Moodle before 9am on the 31 st of May
Part 2: Solution Development
######## 31 th May 11 th of July
At the beginning of Week 3 ( 31 st of May) we will release the Java template project to you. In particular, we will create a Github source code repository on https://stgit.dcs.gla.ac.uk for each team and upload the template to there. At the same time, we will also provide some additional instructional videos on how the template project functions. You will need to extend this template project with classes of your own design to provide the needed functionality. Additionally, we will also release a set of story cards to all teams, this is so you can check that you have not missed any key piece of functionality prior to starting development. The project should be developed using the agile Scrum methodology, with 5 sprints each lasting 1 week.
Recommended Activities Each Week:
- At the start of the week, you should have a meeting to allocate one or more of the story cards to each team member.
- Each team member is expected to work on the development and integration of classes associated to the card(s) they are assigned for that week. It is expected that team members may need to work in pairs at times, as one class may be used by multiple stories/story cards.
- At the end of the week, the team should write up a 1 A4 page sprint report, which summarizes who did what, challenges encountered and include a plan for how these will be rectified in future sprints.
You need to submit your sprint reports and final code-base before 9 am on the 12th of July.
General development guidance:
- Do not be tempted to add functionality that is not actually required.
- You are marked on whether the code is functional and whether it is well designed and documented.
- If your team has difficulty meeting the deadline, it is better to submit a working program that omits some of the functionality, rather than a non-working program that attempts all the functionality.
- You will need to share code between members of your team. The Software Engineering course will likely introduce techniques for managing code, it is recommended that you use them.
- Teams are required to build on top of the provided Template Package during development.
- You are required to use the Git repository provided for committing your code. Each student should commit their work regularly using their own account and with meaningful commit messages. The git logs will be considered during marking for calculating student effort deltas.
Submission
All submissions will be performed via Moodle. Only one member of the team needs to submit.
By 9 am on the 31 st of May you need to submit:
- Story Cards : A document containing the story cards you extracted from the design documents
- Class List : A document containing your list of classes to be developed along with 1 – 4 sentences for each summarizing their core functionality
- Game Round Process Flow : A document containing the bullet point timeline of user and class interactions involved in a single round of the game
By 9 am on the 12th of July you need to submit:
- Sprint Reports : Your sprint reports (either 5 or 6 depending if you worked on the project during the reading week)
- Source Code : Your final source code, compressed as a zip file (downloaded from the git repository).
- (Optional) Team Member Deltas : You may optionally submit a score for each team member (including yourself), scores should add-up to 100. These should be used to indicate if you believe a team member should be rewarded for extra effort provided or to penalize a member who underperformed. These will be considered during the last step of marking (Student Delta Calculation).
The Universitys standard penalty (2 bands per working day or part thereof, up to at most 5 working days) will be applied for late submission.
Marking Criteria
The marks for the submitted project are divided as follows:
- Story Cards (10%): You are being marked on the correct formatting and completeness of the full story card list.
- Class List (10%): You are being marked on to what degree your class list as a whole covers the functionality needed by the system and whether it follows good object-oriented design practices.
- Game Round Process Flow (10%): You are being marked on whether the process flow described represents a feasible solution and is correct given the game rules.
- Sprint Reports (10%): You are being marked on whether you have included a suitably detailed summary of the work done, issues encountered and remedial action to be taken.
- Source Code (60%): o Code Quality (20%) : Is the structure of the software meaningful and is the code suitably documented? o Game Correctness (20%) : Can a full game be played? Does the system enforce all of the game rules? o Cards and AI (20%) : Are all of the cards implemented correctly? Does the AI provide a reasonable level of challenge (i.e. does it consider different options and decide which to take based on the board state)?
Marking Process
Projects submissions for part 1 and part 2 are marked by two independent assessors using the above marking criteria
out of 100. A team grade is then calculated, which is usually the average of the grades calculated by each individual
assessor. Once the team grade has been decided, marking moves to the second stage: student delta calculation. It is
anticipated for some teams the amount of work contributed by team members will not be even. The process for
calculating deltas is as follows. In all cases the course coordinator will check the sprint reports and git logs to check
that each member has contributed to the project. If team member deltas have been submitted then these will also
be considered. If given the above evidence the course coordinator believes that particular students have under or
over performed then they have the option of applying a band delta (i.e. to increase or decrease that students grade
by one or more bands). For reference, this is usually one or two bands in size. However, this delta can be significantly
larger if there is limited evidence of a student contributing to the project (i.e. if a student does not engage with the
project they automatically fail).