The trailer for our game!

Agile Methods used in Project Hestia

The way we've employed agile methods in the production of our game is mostly in the way we re-iterate some of the product phases. After we came up with a game pitch and requirements we started working on the design. While designing the game we kept revisiting and editing the requirements so it would match the design. We did the same thing again in the implement phase where we adjusted the design towards what we deemed to be possible and better in the game itself. In that way we keep the work we have done in previous phases up to date with the product we have each time and avoid contradictions and mismatches.

We also do this within the implementation phase. Before entering that phase we made an implementation plan which we try to follow the best we can but obviously it is impossible to do it exactly like it says. In our case, fortunately, we have managed to be ahead of schedule which gives us space to implement more things and/or have more time for things we are supposed to do later. So the implementation plan also has to be up to date with the current product.

Our use of Agile Methods

The development of Project Hestia has been very much an Agile process. Although we do have a thorough design doc to guide us, nothing is set in stone. If after implementing a mechanic or adding an object into a level we do not like the new development or think it doesn't fit in with the overall feel of the game we have no hesitation in changing it or removing it.

For instance the decision on upon wether coming in to contact with an enemy in the game makes you restart a level, or blows out the players current match has changed numerous times and I suspect will do so until we have played the game enough to work out which idea works best. Also, if we previously planned to implement something much later on in the project's lifespan but for some reason we feel that implementing it early will help the development process and likewise there is something due to be completed that isn't necessary at the given time we simply change the plan.

Most of our communication is done during group meetings. We normally have two a week that range from around 3-6 hours each. We find it is much more effective to discuss and compare opinions in a group face to face setting. During these meetings we decide what we want to do over the next few days and how we feel about where the game is going. We also get a fair amount of our implementation done in the meetings often using pair programming.

This readiness and ability to adapt to change, a strong emphasis on working software and strong interaction certainly embody the main aspects of the agile manifesto.

The Team in Relation to the Agile Manifesto

Individuals and interactions over processes and tools

We prefer having meetings to discuss plans as well as to do actual development work. Electronic methods of communication are rarely used in our team and even when we do use them, it is for collaborative purposes (e.g. working on the same document through Google Docs during our meetings).

Working software over comprehensive documentation

We always aim to create something that works, with the intention of revisiting it later to improve it if necessary. Likewise, we don't have our plans set in stone nor did we keep extremely detailed documentation of what has or will be done.

Customer collaboration over contract negotiation

We meet with our TA regularly to keep our "customer" in the loop.

Responding to change over following a plan

The plan we developed initially was not followed exactly, only approximately. We did this as a response to change. Change for us came in the form of discovering what actually needed to be done and what Unity was capable of doing, which altered our perspective and correspondingly our development approach.

Agile Methods for Project Hestia

One of the agile methods that we have made use of during the development is the Scrum meeting. We meet every week on Tuesday and Thursday to discuss what we have gotten done, what we plan to do and how we plan on doing it. These meetings also involve a lot of coding in a group, to make sure that we are all working together and communicating well. Almost every major design decision is decided in these meetings. We make sure that everyone is included in deciding how we want the game to iterate for the next week. Secondarily, we have a google document of our backlog. From this list, we all chose what we want to work on next and any time a task is complete, we have it crossed out on the doc, so that we can all see what is and isn't done. Finally, we build tasks in small steps and iterate on them later. Each task, such as getting light working, starts as the basic idea and then evolves slowly as we improve the game. For example when I first built our Light Controller class, it only had one very basic light that was created. After that we build the other forms of light. Then we worked on the different colours of light. This process was very scrum-like and meant that we had a working, albiet flawed, product at all times.

Late Homework 3 Entry: How our team is using Agile methods this term

Although our team does have an overall schedule to abide too, the overall development process thus far has actually been very Agile like in its methodology. For example, even after creating new pieces of code or assets, we often seemed to have found ourselves, going back to the code or art, and refactoring it for efficiency, or in the case of art, perhaps even willing to create newer better models for use in game.

We also have broken down our schedule into small manageable steps, where we allot different amounts of days to different tasks based on perceived difficulty in order to finish them in a more timely manner. However, much like Agile developmental methods, if the task requires more time than usual, we may put it off to work on another task and return to it later. In our case for the Alpha build, we actually managed to finish some tasks early such as the lighting mechanic that changes the game environment's wall layout, giving us precious time to work on other new features.

In essence, since we are using a very flexible developmental schedule, with smaller tasks to complete in set amounts of time, our team is using Agile processes. The additional use of frequent weekly meetings, email correspondence, occasional pair programming, client (TA) meetings and other Agile techniques has thus far been very useful in our game's development.

Hw #3 : Agile Methods

In our team we are using agile methods by making sure that we always have a product that builds and plays properly and it is always being incrementally being built. One of the things we started out with was that we properly built a character and a small level 1st that is playable and every week with the evaluator we would show how the product evolves and what kinds of iterations we will be building for the next week.

In other aspects of agile methodology we are going through the phases of talking to each other and making new changes on the spot. So for example when we found out that scripts for disappearing walls can work on other objects and character, we started to apply to different things in the game to make it more interesting.

Some of the risks we associated with agile methods is that it is very hard to kind of estimate the time when the the project will be done. Sometimes we are done early and we don't know if we should expand it to more quality or complete the functionality in the next iteration of our build.

The trade offs of using agile is that we can adapt easily to changes and at the same time always see how our game progresses. With other methodologies like waterfall we would not have a working build till the end as everybody would be working on different stuff and just integrating a finished product at the end. Thinking about using waterfall method for this type of project would actually be difficult to see...