Web Card Game

2007 (Java) Web Card Game

This is an overview of the project. I will list here only the main points which should first be developed to have a playable test version. 
This document is divided on a few logical sections:

• Functional Requirements
  Here we will find the main ideas of the game and what will be needed to work
• Game Basic Data
  Here we will find the foundation of the game and what are the basic things and their respective properties. This section is just a basic description it is not how the class description.
• Game Frames
  Here we will find how the application should interact with the player. What actions and how the sequence of events.
• Use and Test Cases
  Here we will be more specific. We will describe how the cases should work, what properties to use and how they will be used.

Overview

Personal Objectives

• Create a playable online web game
• Practice project development skills
• Practice Java development skills
• Experience Hibernate and Struts Framework

Functional Requirements

• FR1: Battle between players
• FR2: Cards as main objects
• FR3: Player Challenge
• FR4: Chat with other players
• FR5: Acquiring and Managing cards
  

Non Functional Requirements

• Use Java language
• Use Web
• Use Hibernate and Struts Framework

Functional Requirements Description

This section will only describe the requirements. Here I will only describe the main characteristics of the game. It will not discuss how to create, only explain the basic process. The description of how it should work is on the Use and Test Cases section.

FR1: Battle between players

This game is like a Role-playing Game. The player will be able to use their experience acquired after many fights to improve their attributes. Those attributes will increase their power and their Card Power. However this improvement will be minimal which will result in a possible enjoyable and fun fight between an recently created player and a elder player. This will also be possible because the game will be based on the cards and lucky (how they will appear in the combat and how strong their effects will be).
In the combat, every player will have 7 cards on their hands to use on himself or on a target. Those cards are taken from the player deck which is the 40 combat cards that he is using. Every card can be used only once and when it is finished it will shuffle again.

FR2: Cards as main objects

The cards must be the main objects of the game. They will define combats and how strong each player is. The cards will have a variety of characteristics and one of those characteristics is the experience which will define the strength of the card. Each card will have many actions which will be executed on their targets that can be also friendly targets (to help them), the actions and the strength of those actions will vary according to the Card’s respective experience.

FR3: Player Challenge

Players can fight other players and create challenges to make groups. Below is the description of how the Challenge Process should be.

Simple Challenge View Description

First of all, each player must be in the Lobby Frame and challenge each other to accept the combat. Once the combat is started the user view will change to the Combat Frame. They will fight by selecting actions such as using cards, items or running away. The fight will be turn based, every player will have their turn to do actions and wait for other players to do their actions. After sending the information they will be able to see the action results and then if the combat has finished it will go again to the Lobby Frame.

Ideal Challenge View Description

This is the final object to develop, but first we will create the above description to test. The main difference is that the players will be able to create the Challenge Frame and others players will be able to join the challenge and form groups. The creator of the challenge will also be able to define the rules and properties.

FR4: Acquiring cards

There will be some actions to do with cards. The players will be able to buy and sell cards, to gain from NPCs (quests), to gain from levels and to bet.

Game Basic Data

This section will only list the basic information for every Entity of the game. The characteristics listed here are exactly priority to be develop.

GD:ACC - Account

This will be the information about the player as a person. This will only be needed on later stages when the alpha is finished.

• Real Name
• Address, Suburb, State, Country
• Age
• Gender
• Password
• Email

GD:CHR - Character

This is the basic information of every Character.  An account can have many characters. The character is the player representative in the game (aka Avatar). In the early stages the character will also hold the account information such as password and email.

• Account name (to whom it belong)
• Character Name
• Deck (card container)
• Inventory (card container)
• Effects (non instant actions from the cards which are affecting the user)
• Hit points
• Experience
• Gold

GD:BTL – Battle

• Battle title (if any)
• Battle type
• Battle participants (Characters participating)
• Chat

GD:CRD – Card

Every Character can have many cards. The players will be able to see the description and characteristics and during the combat the card’s actions will be used.

• Card title
• Card description
• Card tags
• Type
• Self
• Close
• Range
• Alignment
• Neutral
• Good
• Evil
• Kind (visualization of the card)
• Sphere
• Ray
• Ball
• Zone
• Splash
• Aura
• Touch
• Item
• Element (kind of imbued power)
• Fire
• Water
• Wind
• Earth
• Vision
• Void
• Physical
• Essence (it is like a physical description of the user action)
• Punch
• Kick
• Hand
• Feet
• Sword
• Mace
• Axe
• Bow
• Crossbow
• Staff
• Shield
• Armour
• Card effects (card actions)
• Card experience (card level)

Game Frames

This section will describe the screens where the player will interact with the application (the Views). This will describe all game views and every possible action of the player.

GF:LOB – Lobby Frame

This is the first screen of the game it is showed when the player is enters in the system. At first, just to simplify, it will only have a simple chat where the player can see every other logged player and do the main actions such as Challenge Other Player, Access his Deck.

Later we will have other actions as for example Access Store, Create Challenge, Train, Status, Change Channel, Clan and Story (it is something to think about it)

GF:CMB – Combat Frame

This is the combat interface. Here we will be able to see all participants of the combat and in the middle we will have the description of the combat. At the bottom the player will be able to select the card to use in his turn. There will be other actions as Run.

Use and Test Cases

This section will describe how the things are going to work and to which Functional Requirement and Game Basic Data is related.

Card Case (FR2, GD:CRD)

There will be many cards. Every player will have likely 100 cards or maybe more (counting with the inventory) and every Card will have one or more action. There is a pattern of the card actions and many cards probably will have similar effects, changing maybe only the intensity. That is why every card and every action will be static classes with only one object instanced.

To execute one Card we will need the person who used (Caster), the target and how much experience this person has with this Card. This experience will define which sequence of actions will be executed on the target. There will be a few effects that an action can cause, those are instant, triggered and temporary.

Challenge View Case (FR1, FR2, GD:CRD, GD:CHR, GF:CMB, GF:LOB)

When one user challenge another we will define a flag and when the other user challenge back that means the user have accepted the combat. Before being accepted, the challenge can be cancelled or denied. The combat will start and the users and all combat details will be loaded in memory.

The combat object is who will control the combat by holding the players, passing and controlling the turns. Every player will have 60 seconds to do their actions, if no action is made the turn will be skipped automatically.  In this stage, the user can Run from the combat, Use a card or Skip the Turn.

Since we are using a web interface the user will have to constantly check the results for chat and to see the other player action, by this check we can also do the timeout.

Challenge Accepted Case

When the challenge is accepted the Battle object will create and every user involved will create its own BattleUser information. The BattleUser object will contain every battle information such as the Hand, Current Deck, Effects and to which battle is this user associated. This way we have both ways, to get the user from the battle and the the battle from the user. Once the combat is started the users will be locked to this part of the site and the Battle will be associated to the user section. This way we will avoid the user accessing other game pages while fighting.

Combat Turn Case (FR1, FR2, GD:CRD, GD:CHR, GF:CMB)

UA (User A) and UB (User B) have challenged each other and they are now in the Combat Frame.  UA will start the combat and he selects the card named Fire Attack. This card has two effects, first it causes instant damage on the target and half of the damage caused on the next two turns.

Now it is UB turn, it receives the damage from the UA’s card and then uses the card Titan Skin. This card have also two effects: first, it will increase his strength for the next physical attack that he do and second it reduces all received physical damages for a few turns. This means that UB has now three effects on him, two are temporary and another is triggered.

Then starts the UA turns, and he uses the card Slash Attack. This card has only one effect which is to cause a physical damage on the target. However, UB has a temporary effect on himself and this damage will be reduced.

Note: triggered effects are not priority.