Today in analysis, we learned more about the agile scrum method (basically a philosophy of work for programmers) and how to apply it on a daily basis, so that oughta increase my efficiency some more. We then started the first major team project of the program: simulating the conception phase of a game. Basically, we made teams of four and we'll think about how we'd go about developing a game, while applying the agile scrum method on a daily basis and switching roles each sprint (two weeks). Seems simple enough but it's actually an extremely important exercise since it teaches us to work with people we're used to work with and that, with perfect teamwork. I'd describe the agile scrum method since it's so essential, but I'm really tired so I'll just skip it and pass to the next class.

Audio! I knew I'd love that class and I was right, we started learning FMOD and I'm already having a blast experimenting. Sadly, headphones are required and I experimented quite a bit so now I've a pretty intense headache, amongst other pains. We were supposed to use OpenAL but it actually died because it's completely incompatible with 64bits OS, but I'm glad because FMOD is much easier to use, has no compatibility issues whatsoever and works perfectly on the go. It's also super popular and many companies (such as Blizzard) use it, so you can't really go wrong with it.

...Alright, I'll describe the agile scrum method, be ready for a wall of text.

---

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.

Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

Business people and developers must work
together daily throughout the project.

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

Continuous attention to technical excellence
and good design enhances agility.

Simplicity--the art of maximizing the amount
of work not done--is essential.

The best architectures, requirements, and designs
emerge from self-organizing teams.

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.

---

Those are the 12 commandments of video game programmers, the Holy Bible, and it can be resumed by:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Sounds simple enough, right? Well, it is, and that's exactly why 99% of video game companies use it nowadays. Back before it existed (in the 70s), the most popular development method used in games was the waterfall method, and it was really straightforward and methodical. Describe the game entirely, THEN do the game concepts (arts, audio, voices, etc), THEN code it, THEN test it. Meaning if the game designer changed his mind about something or wanted to add something, you'd have to redo the game concepts entirely, then redo the programming entirely, then retest the whole thing. Or if you found bugs in the code, you'd have... to redo the game concepts entirely, then redo the programming entirely, then retest the whole thing. Thankfully in the 70s they were making Pong consoles... it'd take DECADES to develop a game with that method nowadays.