Minutes: March 8, 2012 Meeting

-new policy: just 1 person to approve code
-better communication on the last Friday

-having coins appear at random to get more chronite

-coins increase in value the longer they are on the screen
-creeps drop bomb sometimes, tap bomb to diffuse it otherwise it blows up towers around it
-chance a creep will drop something: chronite or <insert crazy name> bomb here
-bomb destroys one surrounding tower
   ->makes space unbuildable?
   ->set amount of time before you can build on it again
-map design
   ->blocked tiles
-tower types
-upgrades
-sell towers
   

-bridge from one tile to another
-ART WORK

-Global Spells
   -slow
   -nuke
   -rapid fire clicking
   -speed up tower fire rate
   
-Tower power-ups:

                   Damage
               /
           AOE1 - Effect (slow)
       /
Starter -    SF1 - Fire Rate
       \        \ Range
           AA1 - Damage

Minutes: March 6, 2012 Meeting

Shailin:
-level design -> can't place towers EVERYWHERE on screen
   -maybe change the portal after a certain amount of time
   -something where the user will have to do something more creative
   -this will bring the game up farther than others
-art needed
-additional game mechanic in terms of tower creation*** <- super important
   -maybe a creep that makes certain spots unbuildable and destroys towers as it walks
   -time to build a tower?
   -makes towers that are stronger take more resources and take more time to upgrade
   -different tower types
   -describe tower types
   -put some tiles where creeps can more faster/slower in
   -need to be able to keep user attracted to game for a while, not just a short period
   -balance the game to make things challenging
   -slow creeps down, make them harder to kill
   -instead of killing creeps to get chronite, have some other way of getting resources
       ->force them to do something else to get resources
       ->resource collection should be part of the user's jobs
       ->maybe creeps drop chronite and you need to click on it
           ->if you don't touch the chronite in time, another creep can pick it up and get stronger. And after that if you kill that one you get even more chronite (it's a risk!)

-don't shoot down ideas when brainstorming
-after the brain storm is over, discuss the usefulness of ideas

-need to balance out the game flow

-after Beta release, you can't change things unless they are in the design doc

-river!
-waterfall!
-currents!
-canoe! (portage)

Minutes: February 28, 2012 Meeting

For alpha demo:
-make alpha fun somehow
-just mechanics is not quite enough
-mechanics should work together to be fun
    -example: you run out of resources, so you can't keep building towers
-challenge is needed
-1 creep type and 1 tower type is okay
-should be able to play the game for 5 minutes and have fun
-game shouldn't be totally difficult from the get-go
-if the game is easy, it doesn't mean it's fun
-user should get rewarded after achieving something
-not just an interactive demo; this is an actual game
-put text at the beginning just to establish the story a little
-put instructions in there on how to play as well (before the game starts)

To deliver:
-executable file
-have demo ready for Tuesday

In-Class Presentation:
-spend maybe 1 minute talking about hardships you faced and what the game is
-spend the next 3 minutes playing it and showing the game being played

IDEA TO ADD CHALLENGE:
-"research" for better technology (like WarCraft, StarCraft)
    -then you can build newer and better towers

FUN:
Shailen:
-play Plants vs Zombies and look why that's fun
-make tower building and resources scarce

-tower building and resource limits
ROB*-multiple creeps on screen
BRANDON*-flying creeps
ROB*-balance for wave spawning (more challenge as game goes on)
-tower destruction? (temporary)
    -high risk
KEVIN*-tower upgrades
    CARMINE*-click tower and press upgrade (sideHUD)
    CARMINE*-make sprites for tower buttons
AARON*-creeps walk around towers (creep pathing on tower creation)
KEVIN*-global spells
    -time slow
    -select quantum nebulator
*-Quantum Nebulator charge is decremented when creep collides
    -start at 100, decrement by 5 for each creep
    CARMINE*-test
SAM*-high scores
    -number of waves survived
CARMINE*-better sprites
-special tiles
-acheivements
SAM*-game intro

NOT FUN:
BRANDON*-design document
AARON*-cable to show game (or some other method)
AARON-reduce zoom

Agile development risks

There is no doubt that short iterations are great for preventing feature creep and for pushing the team to meet their commitments, but at what cost? In my experience, the biggest risk of agile development is the tendency to become too focused on the short term goals of the project, ignoring the longer term vision and key non-functional requirements.

When an iteration deadline is approaching, the team is focused on the immediate tasks (and rightfully so!). Unfortunately this means that non-functional requirements such as "the system should be scalable" or "the system should be maintainable" tend to take a backseat to the more concrete "implement feature XYZ" style of functional requirements. If the non-functional requirements are ignored for too many iterations, the cost of recovering can become incredibly high. Agilistas tend to overplay the "we can refactor this later" line when trying to dodge non-functional requirements. Refactoring is a key tool in the developers toolkit, but it should never be used as an excuse for ignoring non-functional requirements.

In order to mitigate this risk, it's important to regularly review the bigger picture with the entire team. Determine if the team is spending enough of their energy on the project's non-functional requirements, and identify and refine the non-functional requirements as a group.

Other semi-related software development resources

http://www.joelonsoftware.com/articles/AardvarkSpec.html

http://agilemanifesto.org/

http://www.infoq.com/news/2008/11/nonfunctional-requirements

Agile Development: Towers, creeps, and many beeps

One could take a quick glance on GitHub issues and pull requests and immediately rule out the possibility of our group using a non-agile development process. Why? Well first of all, let me make it clear that it is almost impossible for a decent game to be developed with the traditional waterfall cycle.

Video game design requires originality, innovation, and adaptation. Change is good, and in fact the design phase of a good video game demands change. Change leads to diversity and diversity is the true seed of originality.

Agile methods in the video game industry allows developers and designers to be on pace with each other, allowing room for tweaking for the better or for the worse. Having experience scripting quests for MMORPG servers, the designers, storyboard writers, artists and testers have a whole arsenal of ideas and improvements every step of the way. Some ideas are great, some are on the other hand, downright terrible from a developer's perspective, but the key concept is that change can happen and it will happen.

In a traditional sturdy method of software development such as the waterfall lifecycle, developers and designers would be forced to agree upon one and only one implementation strategy by the end of the design phase. Risks which are unforeseen during this phase will result in massive setbacks and redesign phases which cost a lot of time (or money). In addition, many designers are not developers, and vice versa. The game mechanics and concept envisioned by the designer may be completely different from the resulting outcome of implementation by the developers. Of course, such problems can be avoided by clear software documentation which is why other software projects may yield great success with traditional waterfall methods.Video games, however, are a different story. They are designed for fun, and as I have discussed in previous blog posts, fun can neither be quantified nor predicted. Fun is hit and miss. Or in nerd terms, the realm of fun is to be explored in a stochastic domain and thus determining whether a video game is fun via the design step alone is like attempting to solve an NP-hard problem. This, in my opinion is the main reason why video games (fun ones) simply cannot be created through sturdy methods.

Change is constantly required as the developers need to communicate with designers, receive feedback constantly and determining the next direction the game should gear towards (nothing insane like changing game genres but mechanics and concept). This is why lean development is so important in video game development, it allows designers and developers to have an idea of what the product looks like and what needs to be improved. If a design flaw occurs, problems can be corrected quickly within a few iterations of the development cycle. This constant communication between the two core teams is vital to the success of the game itself. The idea of fun can be evaluated often and adjustments can be changed accordingly (it's like greedy exploit with random sampling in the search space of fun).

Agile vs. Sturdy Development

What is Agile Development?

Agile refers to a strategy of using short development cycles and continuous feedback from stakeholders to improve upon future iterations. Developers will design, write, and test code in a small amount of time (compared to Sturdy development) and then identify any issues before repeating the process and improving on the previous cycle.

What is Sturdy Development?

Sturdy refers to the practice of identifying project requirements and creating an elaborate design plan prior to any development. A significant amount of effort is put into this plan to define clear requirements and avoid future changes which can be costly. Sturdy development projects usually have static requirements that do not change much. Developers follow the plan as best they can, and when changes to the requirements need to be made, the design plan needs to be reevaluated and updated with the developers new time and cost estimates.

How they differ

Agile is usually used when project requirements are dynamic and constantly changing. Sturdy favours static requirements.

Smaller teams tend to use Agile because it's easier to communicate with one another and get feedback. In larger teams, where communication can be infrequent, a shared and detailed design plan can set requirements in stone and preempt any changes that might need to be addressed.

Both methods use design plans, but Agile users spend less time trying to get it right the first time, and instead, update it over time. Sturdy users spend more initial effort on the plan to avoid future changes.

Minutes: February 16, 2012 Meeting

Terrain for level 1:
-sand
-lava
-grass?

Survival:
-wide open
-plain map
-should be a decent size
-monsters get more health
-quanity of creeps increases as game progresses
-edge of map is usable but has visual cue to indicate that it is the edge

Battle/Build:
-beginning build phase
-then battle happens when indicated
-waves keep coming
-can keep building while game is going on

Creeps:
-creeps that destroy towers on destruction? -nice to have
    -explosion could not destroy towers but instead down-grade tower
-creeps that can accelerate when there is a straight away? -nice to have

HUD:
-semi-translucent on top
-when laying tower, side HUD comes up (also semi-translucent)
-when selecting Quantum Nebulator, side HUD comes up (also semi-translucent)


Overall note:
-when adding features, ask yourself whether it’s making the game fun

Next meeting: Starbucks @ Cambie & Broadway
Tuesday, February 21


Core creep types:
- fast, low hp
- flying
- heavy armour and slow
- normal/basic
- boss editions of each

Minutes: February 14th 2012 Meeting

Hackathon for reading break:
-Saturday: 12pm to 10pm

Global spells:
-click on Quantum Nebulator to use spells?
-one menu comes up for global spells
-spell ideas?

Tasks:
-User preferences and settings (persisting/loading)
-Instructions written down
-Place holder art
   -make sure the images are sized using bases of 2 (e.g. 32 by 32)
-High scores (setting and saving)
-In game HUD (Heads Up Display): top
-In game HUD (Heads Up Display): side
-Tower AI
-sound effects (basic sounds)
   -assessment of what sound effects are required
-cut scenes in between levels (text and images)
   -assessment of what is needed (storyboard/script)
   -use design specification to write script
-on collision particle effects
-collision implemenation
   -radial attack (affects all creeps)
   -"bullet" and creep interaction
-SPRITES
-resource management (how to spend and get resources to spend on towers)
-build phase
-battle phase
-global spells
   -what are they?
-design doc maintenance
   -keeping N Sync with what's going on
-quantum nebulator
-level controller/creep controller

Beta:
-random portals on map

Feeback from Shailen:
-Google docs isn't very good looking -> next time use Word
-Design Spec: 15/15
   -can creeps move through diagonal spaces?
       -We say no. It's 4 directional movement
   -cut scenes are not important (only if you have time)
   -having levels is more important than having cut scenes
-Project Plan: 10/10
   -hours are unevenly distributed
   -more hours will happen towards the end of the semester
-Concept Demo: 8/10
   -nicely done, but should include all game mechanics of game
   -more explanation was necessary
   -lots of game mechanics were not present
-Implementation Plan: 15/15
   -nice job
   -everyone had tasks and was broken well done
-Formatting: 8/10
   -was good, but could have been better
   -some unecessary things
-Readability: 15/15
   -nice

Shailen:
-never write something unless you have to
-reuse code if you can
-never write collision detection

Risks Associated With Agile Development

Agile software development is a necessary process. Nobody can know exactly how to design and implement a software project from the beginning. There are too many modules to take into account and people can and will make mistakes. This is why agile development is necessary. But there are certain risks that are implicit in an agile approach.
One of the first risks one might think of is the risk of changing a project too much after the design phase. An agile approach allows programmers to go back to previous stages and rethink what they are programming. But taken to an extreme, a programmer might conceivably write a program and realize half way through that there is a better design. The risk here is if the programmer redesigns the software completely and then starts implementing it again. Furthermore, there is no guarantee that the second time through won't shed light on an even better design for the program. Thus the software developer could be stuck in a cycle of redesigning.
A second risk is the strategy of "ready, fire, aim" that becomes tempting when using an agile model. A software developer may just begin coding with no design and then make a design based on what they have coded later. While this certainly could work for some people and in some situations, generally it is a smart idea to make at least a bit of a plan before coding (especially in large software projects).
A third risk of agile development is the lack of a clear authority in decision making. If there is a dispute in the team about how something should be designed, tested, or implemented, a lot of time could be wasted talking about what should be done instead of just doing it. This is contrary to a sturdy method where developers simply need to follow instructions from a central authority that tells them what to do and when.

Agile versus Sturdy Methodology in Game Development

During the initial stage of game development, the team decides which development methodology to adopt. In this blog post I will be discussing trade-offs between agile and sturdy methodologies.

First off, the obvious advantage of the agile method is the ability to produce working products fast and being highly adaptable to unforeseen changes and obstacles during development. While those are extremely valuable attributes, sometimes diving in head first without an adequate amount of planning can be detrimental to a project. Sturdy methodologies are more strict and usually flow from design to implementation stage subsequently without being able to go back to the previous stage. This type of development style has a clear start and a clear ending, which is easy to learn and follow through with.

Which is the better approach for game design? I believe that while they both have their own advantages, the agile development style falls more within the scope of game development. The reason being that the landscape of the gaming world has continuously changing demands as well due to new technology and innovation. By going with the agile development style, you can come up with a working model of your game really fast and be able to obtain feedback before committing too many resources. With the sturdy method, typically we would be spending many many many weeks of resources planning the game and creating an incredibly elaborate design spec without knowing if the actual game will succeed (Of course everyone thinks theirs will!). By the time we enter the latter half of the development cycle, the game gets tested and thats whenwe will know if the game we intended to make ended up to be all that we want it to be. If there was a core flaw in the game (a game concept error rather than a technical error in programming), it would be already too late to go back and fix it! When we are being agile, we can consistently obtain feedback on each build of the game and modify it accordingly. Not only does it sound useful for the actual game developers, it provides external stakeholders more reassurance in the game that is being developed! Agile development allows you to always have a working model of your game that can concretely show what you have been working on.

While both agile and sturdy methods are both widely used development models in the world of software engineering, due to the unique characteristics involved in game design, I believe that following a more agile approach will provide many more advantages during its product development life cycle.

How our team is using Agile methods

Our team uses agile development to develop the game. The following properties in our project show some of the characteristics of agile development.

Feature Backlog:

In our phase 2, we planned and listed out all the features needed to be implemented. Also, the features are updated with it's dependencies and priority. The features are then sorted by descending priority and is shown on our feature backlog ( see progress page). The features are decoupled as much as possible so that team members can pick up on independent tasks.

Weekly milestone:

We estimated the hours needed to develop the features. Our team has weekly milestones and each team member picks features/tasks from the feature backlog that accumulates to a week worth's of work.

Scrum stand-up meeting:

We have retrospective meetings after our weekly milestones to describe about the tasks we have done for the milestone, what is not completed and any improvements to be made. We will also demonstrate the features we have implemented. We also have scrum planning meetings that allow us to update the feature backlog. Having done the tasks assigned on the milestones, we have a clearer grasp of the implementation needed and change the feature description correspondingly.

Communication:

We constantly communicate via emails to know each other's progress and help out if there are issues. THis can help out identify risk and adapt quickly to such changes.

Minutes: February 7, 2012 Meeting

From now on minutes will be available on the website in addition to google docs.

Git and GitHub: Introduction, setup, and our workflow

Git and GitHub are going to be two incredibly important systems that we will be working with at every stage of development, so we need to take some time to learn how to use them properly. This post will cover a brief introduction to each, a tutorial for setting up Git on your local machine, and a workflow that we can use during development.

Major Deliverable Level 2 Complete!

After a huge effort from everyone on the team, we have finished the written monstrosity that is Deliverable 2! Great work everyone!

The Design Specifications can be found here and the Project Plan is over here. Carmine's concept demo can be downloaded here (Change the file extension from .cpsc to .exe and run it).

Here are some teasers:

Storyboard 1 by Aaron



Concept Art by Kevin



Screenshot of the Concept Demo made by Carmine



Game Mockup made by Sam

Super Smash Bros. Melee - Mechanics, Dynamics, and the overall system

One of the games that I spent a considerable amount of time playing back in the day was Super Smash Bros. Melee. This was the sequel to the original Super Smash Bros. game for Nintendo 64 (made for the Nintendo Gamecube).

The game involved choosing a specific character to play as, where characters were various Nintendo gaming franchise characters such as Mario, Link, Fox, Donkey Kong and Kirby, and using them to knock other players out of the stage boundary using various moves. The game stages were 2D and characters were only allow to progress forward and backward.

Mechanics:

Each character had their own unique set of skills, as well as common moves between all of them. Every character had the same buttons for jump, block and basic attack (punch or kick). Contrary to traditional fighting games, the player inflicting the most damage does not guarantee victory. The objective of the game is to knock the opponents outside of the stage boundary. The most damage a character accumulates, the increase in likelihood that he/she will experience stronger knock back effects. Any type of attack in game causes a knock back effect where the magnitude of the effect is determined by the amount of damage the receiver has already accumulated.

Dynamics:

Throughout the course of a fight, there are many external factors which affect the tide of the battle. Two main factors, the stage where the battle is being fought and random appearances of items are dynamic events which randomly happen and can affect the result of the game. One obviously example, is when the characters fight in the Starfox stage where they are fighting on top of a gigantic battleship from the Starfox franchise. Starfox fighter ships will randomly spawn during the battle and start to shoot at the characters. If a character was caught of out position (shot by the fighter ships), he/she might end up accumulating a enormous amount of damage, allowing their opponents to have an easier time knocking them out of the stage.

The overall system:

There are many many different stages to choose from, and there are some stages where there are no dynamic affects which allow the battle to be less influenced by the stage. Each character in the game is somewhat balanced, characters that do lots of damage have a harder time landing their attacks, and ones that do less damage, are typically more swift. This allows the overall system of the game to appear fair which allows it to attract a wide audience of players. The move executions are standard across all characters, making the variety of characters that a novice player can choose to be numerous. Of course, this game also scales for hardcore players as well, since lots of moves can be strung together for combos, skills can be parried and dodged as well. The fighting is also very fast paced, which makes the gameplay more intensive and focused. I believe that the ability to create a game which is easy to pick up for new players and be able to retain them by having a high skill ceiling to reach is an ideal focus for a game, as shown by the incredible popularity of this game.

Bubble Tanks Tower Defence - Gameplay Mechanics

Bubble Tanks Tower Defence is a highly addictive web-based tower defence game. The object of the game is simple: prevent the enemies from reaching their desired destination by building towers that slow down or destroy them. The game is easy to pickup and play, but maddeningly difficult to master.

Defense of the Ancients Gameplay Analysis

As a relatively recent genre of video games, the MOBA (Multiplayer Online Battle Arena) has evolved from its RTS engine roots and emerged into a fully developed genre by itself. The most widely played MOBA game of all time, Defense of the Ancients or as many players called it - DotA - is a highly complex and competitive online multiplayer game.

A quick, top down, general description of the game would describe it as a tug-o-war style game between two sides with equal amount of players on each side. The goal is to conquer the other team by successfully destroying the main artifact (structure). Each player controls a hero selected at the start of the match. During the course of the match, the hero gains gold and experience to enhance their heroes with items and leveling up skills.

At every multiple of 30 seconds since the start of the match, monsters - known as "creep" - spawns from the base of each side. These "creep" cannot be controlled by the players directly, and will attack (rather unintelligently) in a direction in each of the three distinct paths (commonly referred to as "top lane", "middle lane", and "bottom lane").
Killing enemy creep will result in experience and gold for the hero. It is also worth noting that gold will only be awarded to the hero if and only if the hero is the true killer of the creep by executing what is known as the "last hit" on the creep.

The goal of the game is to earn gold to buy items which grants different attributes and abilities, and experience in order to defeat the enemy team. Killing enemy heroes will result in more gold bounty than killing creep, and also result in much more experience depending on level of the hero killed.

In the most general sense, the goal of the game is quite simple. However, the level of mechanics involved in this game is far too complex to comprehensively describe in this blog post.

Mechanics

To start off, I will be discussing some of the main mechanical details of the game.

Hero Attributes

Each hero has three different values for attributes: Strength, Agility, and Intelligence. A hero also has a primary attribute, allowing the hero to gain 1 point of damage per attribute value. Each attribute also corresponds to different statuses of the hero: Strength to Max HP and HP regeneration, Agility to Attack Speed and Armor, Intelligence to Max Mana and Mana regeneration. Other attributes include Movement Speed and Attack Range.

Controlling Your Hero

In order to control your hero in a DotA game, the interface, keys, and controls are similar, if not equal to a typical Real-Time Strategy game. You select your hero, move with right click and have commands such as Attack, Move, Stop, Hold Position, as well as other skills.

Hero control is crucial in playing the game well, and plays a large role in survival, acquiring "last hits" on creep, and timing.

Purchasing Items

Each hero is able to purchase items from the shop at their base. Each items have unique abilities and grant the hero different attribute bonuses, special effects, or even skills. Generally more powerful items require much more gold to purchase, which is why it is important to gain plenty of gold.

Using Skills

Skills are unique to each hero, and each skill can be either "Active" or "Passive", with the difference being Active skills require user input to function, while Passive skills are always in effect once leveled. Most Active skills require Mana to cast and have different cool downs (periods of which the skill cannot be recasted).

Dynamics and Metagame

DotA gameplay is complex due to the the level of metagame required to be understood before graduating from the "novice" level of play.

Multiplayer

DotA is a multiplayer 5v5 game, requiring 10 players to play. As a result, in order for a decent match to be played no player should leave the game. The skill level of each player should be equal to ensure a fair game. Due to the competitive nature of the game, flaming other players, insults, and rants are often rampant across the DotA community. Hence, DotA is dubbed as one of the most hostile environments for novice players, and a breeding ground for bad mannered players.

Popular Mechanics for Kids

Tactics Arena Online is an online, 2-player, turn-based strategy game that is like an animated version of chess. Each player controls up to 10 units and uses their abilities to try and kill the other player's units. There is a single game map which is tile-based and square-like in shape. Players can choose how to arrange their units on the map, and which units to use via their game settings before battling other players. These arrangements can easily determine the winner of a match, so players usually put some thought into the placement of their units. Defensive players often place their units close together and by a corner of the map in a tight group, whereas offensive players might place their units aggressively in the middle of the map closing the distance between themselves and the enemy player. Players can also choose a colour scheme for their units to distinguish between themselves and other players' units.

Choosing which units to use is also an important part of the game strategy. Even though there is a limit of 10 units per player in a game, each player is initially given 12 units of 9 distinct types to choose between. Additionally, paying game subscribers have access to 9 more unique units (Say that 5 times really fast). Each unit has different attributes, abilities, and frequency of use. For example, a Knight has high defence increasing its chance to block physical attacks, and it also has high power inflicting strong attacks upon enemies. A Knight also has a high frequency of use meaning that once you perform an action with it, you only have to wait 1 turn before using it again. Typically, strong units have a low frequency of use and you have to wait several turns before using them again making it important to use them wisely.

Players enter a battle by selecting an empty arena from the game lobby and waiting for another player to join them to start the match. A randomly selected player is chosen to move first and they select a unit to move or attack. A typical move involves moving a unit to a position of attack, attacking an enemy unit, positioning the unit defensively, and then ending that player's turn. This repeats back and forth until one player defeats all the units of an enemy or if a player surrenders and leaves. Each player is given a time limit of 1-2 minutes to perform their turn otherwise they are forced to pass.

The high structure and clearly defined rules of the game make it easy to play and learn after a few matches. The game itself is fairly static, but the gameplay is dynamic in the sense that no 2 matches are the same. You cannot predict how your opponent will move, so players learn to think critically and create strategies to outmaneuver their enemies. Also, each player has their own ranking. Win a match and your ranking increases; lose and it goes down. Leaderboards with the highest ranked players are displayed on the game's website encouraging players to keep playing for bragging rights. So what are you waiting for? Go and play TAO!

Castlevania: Dracula X Gameplay

In Castlevania: Dracula X (Super Nintendo), the mechanics are simple relative to many games made for modern consoles today. The player takes control of a vampire killer who must defeat Dracula by progressing through six levels that are set in Dracula's castle. The player may move from side to side, although progress through the game is largely left to right. The player may also jump. Jumping can be combined with lateral movement for three different types of jumps. One, a simple jump in the air (no lateral movement). Two, a jump followed by a direction (slight lateral movement). And three, lateral movement followed by a jump resulting in a considerably long jump. Once a player has jumped, just like in the real world, they cannot change the direction they are moving. This adds an extra challenge in the game since moving platforms and enemies force the player to think before commiting to a jump. The player can also attack with a whip. The player must be directly in front of the enemy to attack them with the whip. Jumping and whipping can be combined to hit enemies that are on different levels than the player. There are also a number of other weapons that allow the player to attack enemies above and below the player, but only one of these weapons are be carried at a time so the player must choose carefully which one they should take. Also, these weapons can only be used a limited amount which adds to the difficulty of the game. The player only has 3 lives to beat any given level. If they die at some point in the level, they restart in the room they died in. If they die and they don't have any extra lives, they restart the level from the beginning. A password system is used to recover the player's progress should they become frustrated with the game. Finally, a note on the enemies is necessary. The "bad guys" in the game all move in a predictable pattern, but they also adapt their pattern according to the player. For instance, one enemy might throw axes at the player while the player is far away, but as soon at the player comes close the enemy charges forward like a bulldozer on red bull.

EDIT: The preceding blog entry was necessarily brief and did not delve into detail that would do the game justice.

Assassin Creed BrotherHood Gameplay

Desmond Miles lies on Animus which allows him to explore and experience the memory about his ancestor Ezio/Altaïr kept in his DNA. The synchronization level of Animus and Desmond only allows him to explore small portions of his DNA. Through exploring these DNA, Desmond increases his synchronization level allows him to access more memory.

The gameplay switches between present and past but focuses mainly on the past. When the game enters a sequence of the past, the interface changes; there are weapons selection (on the bottom left of the screen), Enzo’s health and armor indicator, and your wanted level. The user controls Ezio who is an Assassin. The game uses a mission structure to follow the main story, where Enzio is assigned missions. The user can choose to accept or decline this mission. However, users can only accept missions that are critical to the story line. There is a large variety of missions, from assassinating public figures, stealth missions, recruiters people to join the Assassin organization, eliminating Borgia authority by killing the Borgia captains, to buying stores to improve the society/city.

The game uses active and passive modes. Actives modes allows the user to free-run, climb, and assassinate. However, these high-profile actions will increase your wanted levels and catch the guard’s attention. Passive modes allows users to blend into the crowd and pickpocket. If a guard sees you, there is a green indicator that display the guard’s level of suspicion of you. The guard notifies and attempts to murder you when the indicator turns red. The user can either eliminate all of the guards, or hide in spots like well and haystacks. However, there are guards that specifically check the haystacks. If the guards do spot Enzo hiding in the haystack, the guards will immediately attempts to convict you.

Performing actions that is against’s the Assassin’s policy will indicate a warning, a repetition of these actions will result in breaking the synchronization. There are also certain parts of the map that Ezio cant accessed. A brute force of accessing will also result in breaking the synchronization. When Ezio’s health indicator reaches zero, the synchronization also breaks. Breaking the synchronization will reset the uesr’s last checkpoint.

Major Deliverable Level 1 Complete!

The complete deliverable file can be downloaded here

Check out our game pitch video below (kudos to Carmine and his awesome video editing skills)



And we also have a shiny new logo!

Setting up Android Dev Environment in Eclipse

Here's how to setup the Android SDK with Eclipse Indigo to get started with Android development. Here's what I'll be using for the setup:

• Apple iMac OSX Leopard (10.5.8)
• The process should be similar for any OS
• Eclipse Indigo (3.7)
• The following instructions may work with older versions, but I'll be using Indigo
• http://eclipse.org/downloads/ (the 'Classic' version should be fine)

Carmine's Opinion on Video Game Worlds

I really think that the one thing that has really kept me captivated in my gaming experiences is the story and the world that is created by the game. I always wished there was some way to transport myself into the world of the video game I was playing when I was a kid. Video game worlds are rewarding and challenging at the same time. The world of Link in the Legend of Zelda is complex and vast. It is easy to get lost in the mythology that is created by the game developers. Indeed, watching the story unravel is a motivating factor for beating the game.

I bring up the example of The Legend of Zelda because it is one of my favourite games and I have played the series extensively. In addition to beautiful environments, the "world" of the game is constructed with its own mythology. There are different races of people, all with their own myths and legends. There are ancient artifacts that have origin stories. There are the main characters themselves who each have a story to tell in their own right. All of these details contribute to an intriguing world that enthralls the player. Another example I choose to present is the Castlevania series. This horror movie-inspired series presents a classic good versus evil conflict that pits a family of vampire killers against the Count Dracula. The environment is dark. The music is eerie. The monsters are frightening. The game is awesome. The overall mood is achieved much in the same way that moods are created in movies: set design, music, costumes, and props. The video game equivalents are: level design, music, characters (including enemies), and weapons.

I have expanded on why I think the world created in a video game is essential to its success in the preceding blog entry. At this point I would like to address the fact that casual gamers often do not require such an in depth story or detailed world to enjoy a game. Take Angry Birds as an example. I’m pretty sure the story is “the birds are angry, and they don’t like pigs”. It works. It’s weird, but it works.

A Nostalgic Game

Throughout the course of my time here on earth, there has been a number of games which have helped develop my exquisite taste in gaming. If I were to sit here and write about each and every one of them, it would surely exceed the 100-300 word limit of this assignment. Therefore I'll only talk about one title which have really established a comfortable niche in the back of my mind, here it goes...

Pokemon Red - Pokemon is arguably the most virulent franchise ever created, and has acted as a gateway drug by further leading me into their game sequels (many and many of them), trading card games, competitive tournaments, books, TV Shows, and even fancy apparel. The game had an addictive element, I remember fighting my brothers for playtime on the Game Boy and freaking out when we lost a save. What parts of it did I enjoy the most? Collecting all the different types of Pokemon? Breeding them? Pokemon Battles? Beating the Elite 4? or successfully capturing rare Pokemon (Mewtwo without using a Masterball)? None of these aspects alone can really define the addictive nature of the game, but collectively, they are able to strongly captivate and bind the player. You can find many aspects of the Pokemon game in many other games, but what Pokemon excels in is its ability to mesh everything together, the "unique" battle system, the story, side stories, an expansive/explorable world, and of course, incredible art work.

Due to the limitations of handheld gaming technology at the time (we had to buy link cables to physically link up Game Boys to play with other people), the multiplayer component of the game was deeply crippled and not a core aspect of the game. There has been great changes to the landscape of the gaming industry since Pokemon, and modern games now put great focus on adding social and multiplayer features. It is incredible to think that if the Pokemon franchise had been launched around this day and age, will it still be able to achieve the same insurmountable success that it had 10 or so years ago? The answer is probably no!

Rob's Fave Games

I have never been a big gamer, but there have been a few games that have really connected with me at some point in my life. Here's a quick look at three of them.

NHL - EA Sports

EA's NHL series was the first video game I really became obsessed with. It started with NHL '95 on the Sega Genesis. Looking back, the graphics were atrocious, but at the time it was hard to imagine wanting anything more. I think that the entertainment value of this game comes from the competitiveness it brings out in people. It's about getting together with your friends, picking your favorite teams, and trying to beat the crap out of each other. The internet makes it even easier to connect and challenge others now. I regularly play (and beat) my brother who lives in Winnipeg, and it's simple to connect with strangers at your skill level who live across the world.

Civilization - MicroProse:

Civilization is the most addicting game I have ever played. It has amazing ability to suck me in and not let me out, no matter how much I want to quit. For me, the game is about validating my thoughts, ideas, and strategies. I want to see how my decisions play out, to simulate a world where I am the king. The most enjoyable part about the game is that there does not seem to be one 'best way' to play it; any strategy has a chance each game.


Madden - EA Sports:

The Madden series has similar qualities to the NHL series. The competitive aspect is still a major part of the game, but for me, Madden is more strategic. Like a real NFL game, it's about keeping your opponent off-balance with your team's play calls. The time to make decisions is very limited, and like the games above, there is more than one path to victory each game.

Video game vs regular software development!

Video-game development are not that much different from regular software development. Both the terms video game and regular software are vague can vary from various factors such as regular software development that varies from the target audience, the intended amount of users, the software’s purpose and the characteristics of this software itself but the fundamentals are the similar; both development are planned (product development life-cycles, iterations), execution and maintenance.

Most game development probably undergo agile lifecycle; the iterations are short and there are many features to demo at the end of each iteration. On the other hand, some regular software development are developed from waterfall lifecycle.

Video games can be played in consoles and portable gaming devices so technically video games developers have more variety of platforms to develop from. If developers were to develop on those gaming devices or mobile devices, the games will be restrained to limited resources, which means that the code has to be very efficient. In order to achieve that, the development process might increase coding reviews and measuring efficiency.

Modern games now have very cool graphics( except for some games like minecraft) so developing graphics are emphasized more in video games development. There are many new technologies that produces good graphics. Sports games (well,at least EA does) develop players movement through motion capture. Besides motion caption, there are many game engines that develops good graphics too. A good example is Unity. Aside from graphics, good games often require no lag and quick response time so again resource allocation efficiency can also be a major component in video game development.

Lastly, due to nature of the video game market, video game strict release deadlines, which differs slightly with regular softwares, so video games development tend to be more stressful when near to the release date.

Fun

Of course, it's not that simple when you try to define "fun" in the video game industry. Everybody is different, there are casual gamers, hardcore gamers, wannabe hardcore gamers, or most commonly just plain noobs. I'm sure all our mothers have told us at one point or another in our lives that we are all special in a certain way. Well she's right. Fun is different for everybody, a game that is considered fun to most people may be the most boring crap in the world to another person. To each their own.

I play a lot of games ranging from genre to genre, and for each genre there are specific elements that I find enjoyable. A simple example would be the competitiveness of an MMORPG game. I used to be "that guy" on Ragnarok Online who would analyze each and every aspect of the PvP metagame to become the ultimate PvPer. I was famous, and I loved it. To others it would be nowhere close to "fun", I would even go as far as using calculus to figure out the best builds and damage combinations. At one point I even developed a small piece of software to simulate and tune builds for optimality. This sense of extreme competitiveness was enough for me, it was exhilarating to be respected and feared at the same time. Would this be fun for everyone? I strongly doubt it. Hell, you'd probably think I'm a total nerd by now. But this sort of perspective perfectly illustrates the grand differences and how difficult it is to quantify "fun" in its general sense.

The real question is, how do we quantify a certain level of "fun" for the people who do enjoy a certain game. All video games are different, even if their sequels seem exactly the same (I'm calling you out Call of Duty) but what makes things fun? Are the elements of a video game that make it fun transferrable? I like Portal. I think it's fun. I don't like Angry Birds, I think it's boring. What if Angry Birds had portals in it? Would that make it fun? To some maybe, but personally I think that would be absolutely stupid.

So how do we make things fun? Honestly, I don't believe there is an actual formula for fun. It's entirely subjective, and that's the beauty of video games. There is seriously something for everyone. You like driving? There's Gran Turismo 5. You like trains? There's Train Simulator 2012, I kid you not. You want a game that you can rage over the NPC blocking the doorway? Welcome to Skyrim. Of course, not everybody will enjoy a game for the same reason. Or perhaps, a person can enjoy a game because of a certain element, yet dislike another for the very same element.

The next time you ask a friend "Is ____ fun?" you'll realize your question can never have an accurate answer. Just play it and find out for yourself.

From Google:

fun/fən/

Noun:	Enjoyment, amusement, or lighthearted pleasure: "anyone who turns up can join in the fun".
Adjective:	Amusing, entertaining, or enjoyable: "it was a fun evening".
Verb:	Joke or tease: "no need to get sore—I was only funning"; "they are just funning you".
Synonyms:	noun. amusement - joke - sport - jest - lark - entertainment verb. joke - jest - banter - jape - lark