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)