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