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