代写Java，CS编程、代做Python编程语言、c++，Java程序代写

日期：2020-12-12 01:01

Monster Trading Cards Game

This HTTP/REST-based server is built to be a platform for trading and battling with

and against each other in a magical card-game world.

a user is a registered player with credentials (unique username, password).

a user can manage his cards.

a card consists of: a name and multiple attributes (damage, element type).

a card is either a spell card or a monster card.

a user has multiple cards in his stack.

a stack is the collection of all his current cards (hint: cards can be removed

by trading).

a user can buy cards by acquiring packages.

a package consists of 5 cards and can be acquired from the server by paying 5

virtual coins.

every user has 20 coins to buy (4) packages.

the best 4 cards are selected by the user to be used in the deck.

the deck is used in the battles against other players.

a battle is a request to the server to compete against another user with your

currently defined deck (see detail description below).

Setup

Users can

register and login (token based) to the server,

acquire some cards,

define a deck of monsters/spells and

battle against each other.

Hereby you can trade cards to have better chances to win (see detail description

below). The data should be persisted in a postgreSQL database.

Further features:

scoreboard / user stats

editable profile page

user stats

ELO (+3 points for win, -5 for loss, starting value: 100; higher

sophisticated ELO system welcome)

Security

A token-based login should be implemented (see: curl script "authorization"-header).

During the registration process (not perfect, but to keep the project simple) a token

is generated which needs to be checked at each call on the server-side (also

identifies the user).

To keep the token usage simple we geneate the token with simply adding a string "-

mtcgToken" to the user name.

User: "altenhof" Token: "{Username}-mtcgToken" (Monster Trading Card Game Token)

HTTP-Header to add on the client: "Authorization: Basic altenhof-mtcgToken"

HandIns

Create an application in Java or C# to spawn a REST-based (HTTP) server that acts as

an API for possible frontends (WPF, JavaFX, Web, console). The frontend is not part of

this project! You are not allowed to use any helper framework for the HTTP

communication, but you are allowed to use nuget/mvn-packages for serialization of

objects into strings (vice versa). Test your application with the provided curl script

(integration test) and add unit tests (~20+) to verify your application code.

Add a unique feature to your solution e.g.: additional booster for 1 round to 1 card,

spells... (be creative) Keep in mind: you are not allowed to change the pre-defined

REST-API calls (don't do breaking changes) as defined in the curl script (but you can

add further calls, but don't depend on them; the further calls need to be optional!).

Hand in the last version of your source code as a zip in moodle (legal issue) with a

README.txt (or md)-file pointing to your git-repository.

Add a protocol as plain-text file (txt or md) with the following content:

protocol about the technical steps you made (designs, failures and selected

solutions)

explain why these unit tests are chosen and why the tested code is critical

track the time spent with the project

consider that the git-history is part of the documentation (no need to copy it

into the protocol)

Intermediate Submissions

Be able to present your solution during the course (in the exercise lessons (de:

übungen)) at the beamer.

Goals:

after lesson 1 (OOP):

Choose a language (C# or Java) and get your environment up and running.

Start creating the business layer and design/develop the corresponding

classes.

Test with command line.

after lesson 2 (Testing):

Check your code and add unit tests to critical parts of your

implementation.

Explain the difference between unit testing and the usage of the curl

script.

Implement register / login and the user profile methods with focus on

security (see the "Authorization" headers in the scripts) and test these

aspects using unit tests.

after lesson 3 (Networking / Parallel Execution):

Implement the TCP-Communication over HTTP and be able to communicate

with the testing script provided.

The server should be able to read the most important headers and read

the body correctly.

Consider parallel execution here and prepare a method to test this

(e.g.: console.log and parallel running curl scripts).

after lesson 4 (Collections / Files / Streams):

Explain which collection type is chosen for each purpose and why (add

this to your protocol to hand-in)

Implement the package and card (+deck) handling

after lesson 5 (Json, Databases):

Implement the trading possibility.

store all relevant data in the database (use SQL only; no O/R-Mappers

allowed).

after theory lesson 6 (Recap):

implement further requirements (90% of the project should be finished)

Consider that theory questions are asked and that these intermediate presentations are

graded as well. Always be prepared to test edge-cases and to extend your curl script

for the given purpose, BUT be prepared that the curl script can be extended by the

lecturers as well (new versions might test further error cases eg: check for invalid

decks).

The Battle Logic

Your cards are split into 2 categories:

monster cards

cards with active attacks and damage based on an element type (fire, water,

normal). The element type does not effect pure monster fights.

spell cards

a spell card can attack with an element based spell (again fire, water, normal)

which is either

effective (eg: water is effective against fire, so damage is doubled)

not effective (eg: fire is not effective against water, so damage is

halved)

no effect (eg: normal monster vs normal spell, no change of damage,

direct comparison between damages)

Effectiveness:

water -> fire

fire -> normal

normal -> water

The starting player is chosen randomly. Cards are chosen randomly each round from the

deck to compete (this means 1 round is a battle of 2 cards = 1 of each player). Pure

monster fights are not affected by the element type. As soon as 1 spell cards is

played the element type has an effect on the damage calculation of this single round.

Each round the card with higher calculated damage wins. In case of a draw the

attacking card loses the round. Defeated monsters/spells of the competitor are removed

from the competitor's deck and are taken over in the deck of the current player (vice

versa). Because endless loops are possible we limit the count of rounds to 100.

As a result of the battle we want to return a log which describes the battle in great

detail. Afterwards the stats need to be updated (count of games played and ELO

calculation). Attention: both players must be actively involved (open call to server)

in the game (blocking call) to compete against each other.

The following specialties are to consider:

Goblins are too afraid of Dragons to attack.

Wizzard can control Orks so they are not able to damage them.

The armor of Knights is so heavy that WaterSpells make them drown them

instantly.

The Kraken is immune against spells.

The FireElves know Dragons since they were little and can evade their attacks.

(Use inheritance to solve this problem)

Trading Deals

You can request a trading deal by pushing a card into the store (MUST NOT BE IN THE

DECK and is locked for the deck in further usage) and add a requirement for the card

to trade with (eg: "spell or monster" and "min-damage: 50"). Define: Spell or Monster

and additionally a type requirement or a minimum damage.

Optional Features

With optional features implemented you can compensate possible errors in the

implementation above. Nevertheless it is not possible to exceed the maximum number of

points (= 100%).

Trading system: trade cards vs coins

Further card classes (eg: trap cards ~ passive spells)

Further element types (eg: ice, wind,...) including additional dependencies

Friends-List (play against friends from list, manage friends by username)

Card Description

Extended Scoreboard: see ELO or WHR

be able to add virtual coins to your system (with stats on spent coins)

transaction history

define a plugin system to extend monsters (needed skills: reflection;

dependency injection, service locator)