You are on page 1of 7

Heroes of the Forge CISC 226: Final Report

Serban Marin, 05866887 Kenny Luc-Vuong, 05899135 Jordan Van Der Kroon 05914732

Executive Summary
We at Lizzard Entertainment are happy to present our final report on our game; Heroes of the Forge. HoF is a turn based strategy game that pits players against each other using a diverse set of spells and classes to do battle on a grid based battlefield. The way players gain advantage over each other is by casting different combination of spells available to them. Some spells will deal damage, some will heal, some will support your own units and some will debuff the other players units. It is up to the player to decide which spells are worth casting and when. Players form a strategy around the three spells they bring to the battlefield and pit their strategy against each other. The game pits two players against each other in a head to head matchup. The target audience for this game would be an older crowd 18-40 with an enjoyment for strategic and battlefield planning games. Each player is in control of multiple units that make up their team. Each unit has different attack damage values and attack ranges depending on their class types. There is also a spell caster unit which is able to cast a variety of spells to damage and disorient the other team.

Game Design
Vision Statement
Our goal is to give our players a dynamic player vs player turn based experience. We are looking to accomplish this with our balanced turn based combat. Players will control their units consisting of the warrior, archer, and mage against each other. The player who can combine their spells with strategy better will be the one that comes out on top.

Gameplay Synopsis
The game pits two players head to head in a game of strategy and wits. Red player always goes first. In each players turn a player can move and perform an action with each of their units that are on the board. Each team starts with an identical set of units set up across from each other. Performing an action is based on either casting a spell or attacking an enemy unit.

Players are expected to combine the spell mechanics along with the units they are given to go to battle and best the other player and his combination of spells and units. Teams are deployed on a battlefield grid, they are given one action per turn to move and attack or cast spells with the units they have. The key here is to move your units across the board to come into range to attack the enemy without getting out maneuvered by the opposing player. A player wins the game by completely wiping out all of the opposing players units.

Our game is to be set in a medieval fantasy setting. Swords and shields, bows and arrows, magic wands and wizard hats are not an uncommon sight on the battlefield of Heroes of the Forge. A true forge master will need to learn to master all three of their unit types to overcome the opposing player. We are trying to keep the graphics as simple as possible with emphasis on the magic spells particle effects to make them feel truly powerful.

Target Audience and Platform
Our game will feature two players matched against each other in player vs player gameplay. This is to allow us to set the stage for fun and strategic battle arrangements and focus mostly on balance as opposed to focusing on an AI that would give the user a challenging and fun experience. It will also give two player a good opportunity to experiment with the forge and create different spells and see which combinations are truly the most powerful. Since there will not be a “recipe” list available to player to know which essences create which spells it is up to trial and error and playing multiple games against different opponents for a player to truly work out a playstyle that works for them. We are hoping this will give our game an appeal to have players keep coming back for more.

The game play is focused on our combat. A player’s team is made up of three unique units. Warriors make up the meat of your army and have the most health of any unit, they also have a few defensive spells to cast on your own units such as heal and defend. Archers deal very good damage from a distance, they can move faster than most classes as well as acting as a force multiplier for your team. The archer can haste one of your own units to allow him to move an extra square. The archer can also mark enemy units for them to take increased damage from physical attacks. Archers can attack from a distance but cannot take as much incoming damage as the Warrior. Mages can take even less punishment but they have the opportunity to cast very offensive magic Players take turns moving and uses actions with each of their units. An action is used each time a unit attacks or casts a spell. A player controls this by selecting units on the board with the mouse, it can then move to a range shown on the grid or use an action with the range shown on the grid for the currently selected action. The objective here is to eliminate all of your opponents units off the board while taking minimal damage yourself. The game ends once a team has been completely wiped off the board.

Game Characters
This class had few the smallest health pool of all the classes and the weakest attack only available in melee range. Its abilities were fireball which gave it an opportunity to attack enemies from a distance and ice ball, which slowed the targeted unit down(next turn they would have their movement reduced to one). The iceball ability turned out to be the most fun spell. It allowed the mage to kite his enemies giving the mage the edge when fighting a warrior or another mage.

Fireball: 10 Damage, no effect Iceball: 5 Damage, Cold effect(slows movement range to 1)

The archer had a ranged physical attack allowing him to do damage at a distance. The archer ended up best being played as a support unit due to its abilities. Haste is a spell that can be cast on any unit(including the archer) that adds 1 to movement. The effect would allow a mage in round 1 to get close enough to attack the enemy if cast before the mage moved. The archer’s second ability, Mark, adds a negative effect on an enemy unit that causes the enemy unit to receive twice as much physical damage from any unit. This effect turned out to work very well with the warrior’s strong melee attack.

Haste: used on a friendly unit to increase his movement range by 1 Mark: Used on enemy units to increase the attack damage they receive

The warrior has the most hp on the board and has the strongest attack, however it can only attack when it is in melee range making it defenseless against classes that can kite. The warriors first ability heal permanently increases the allied unit’s health. It can also be used on the warrior himself and can help a wounded unit survive another round. The shield ability will reduce the damage taken by an allied unit to half. This is the warrior’s only defense against units kiting him beside his teammates help.

Heal: Heals targeted ally unit by 10 hp Defend: Reduces incoming physical damage

Story and Gameworld
Our story and gameworld is very simple to allow us to bring the multiplayer aspect of Heroes of the Forge to players right away. If time permitted we would’ve like to develop both a storyline and a game world that a single player could adventure through. Unfortunately something like this involves developing a fairly sophisticated AI system to play our game against a human player. This is something that was not in the scope or this project.

Media List
Our sprites are very simple. We have adopted the timeless battle of Red vs Blue. With our units being represented as a red or blue circle accompanied with the equipment for the class they represent. Warriors enter the battlefield with a sword and shield, archers have their trusty bow and arrows, and a mage never goes anywhere without his wizard hat.

Game Implementation
Our current game implementation has a 7x7 gird with 3 unique units belonging to two different teams (blue and red) set up across the board from each other. The two teams take turns moving and attacking each other and casting spells until one team is eliminated. Our combat system uses random numbers that give a range of attack values when a unit attacks another unit. This random number gives a range of -2 to +2 on their base attack damage. The combat system works on constants and modifiers. Each unit has a constant value for their attack damage, movement range and hp values. There are also modifiers that let the game know a unit may be under the effect of a spell that increases or decreases their movement. Hp is added or subtracted depending on whether a unit is healed or taking damage. The damage multipliers such as the archer ’s mark and the warrior ’s defend were integer based constants that would be multiplied into the damage calculating algorithm when a blow is struck. This value is normally set to 1 and gets reset every turn as the effects wear off. Using these modifier values we originally wanted to implement a large number of spells all with a different effect that could be applied to a unit. This was a simple way of keeping track of it all in the game engine itself.

Testing procedure and results
We had two different types of testing sessions. We got different yet valuable information from both of them. In the initial tests we would have a random person with very little background knowledge of the game try to play one of the three developers of the game. This led us to the understanding that someone with very little information on what all the spells and units do is never going to be able to beat someone with a strong knowledge of all of the core game mechanics.

When we pitted two users who were both new to the game we had quite a few interesting results that made us reconsider the way we thought about our game design. After a bit of experimenting players would start to bring spells and unit load outs to the game that simply unbalanced it. Instead of a rock paper, scissors system players would just try to bring 3 mage characters and as many spells as they can to try and gain an edge over the other player. This led to not very exciting gameplay and certainly not very balanced either. Unlike the results where the users were playing games against the developers where we had knowledge of which unit counters which the best.

This led us to the point to decide that we will give each player an identical load out in the pursuit of balance. This was accomplished by giving each of the units spells instead of just the mage. The warrior got mostly defensive spells while the archer received spells that acted as force multipliers and allowed your other units to be more mobile on the battlefield. The mage was scaled back quite a bit as it seem a bit over powered in our initial testing. We ended up giving him two damage dealing spells. The fireball does the most damage but the iceball is able to reduce movement range of the target. This is quite useful when dealing with the close combat warrior at long range.

Lessons learned
I think the number one lesson we learned from this project was managing the scope of a project like this. We definitely bit off a bit more than we could chew at the start of this project. We went into the project being very ambitious with what we hoped to accomplish. We wanted to have a deep and customizable combat system that looking back on simply was not something we could accomplish in the time period we had with all of our other commitments for other classes as well. We tried to rationalize our deep combat system with a very basic UI and graphics. Looking back on it, it would have probably been better and more rewarding to keep the core concept much simpler and focus on making the game look a lot better. We had originally thought we would be able to not only program this complex yet balanced combat system but also program an AI to go along with it to provide a challenging game play experience to a single player playing our game. Quite simply we put the bar quite high and had our priorities in the wrong place a few too many times through the life span of the project. I think if we could do it all again we would have designed our game around a simpler (but still unique and interesting) game mechanic and focused on the execution of that mechanic and build a fun and beautiful game around it. By focusing on the idea of user customization, not only did it make the scope of the project very large so as to give the user as many options and choices as possible. It also interfered with the balance of the game and really made us rethink how we were going to execute it after we had tested it with some users that were playing the game for the first time.