Posts

Week 4 Blog

Chapter 7 is about planning for a video game project. One of the core ideas I took away from this one was the description near the start of the chapter about how a PS2 launch title project was estimated to be bigger than it actually could be. It was difficult to predict how many cities would be playable in the game from the start of the project, with an initially planned 6 being reduced to 3 and then 2. Agile could have simplified this process to make the scope easier to understand. Chapter 8 is about teams. Particularly, I found the talk about leadership to be interesting. Having massive teams of 100 or more people lead to the creation of hierarchies in order to keep these teams from becoming a chaotic mess. Hierarchies work on a purely surface level, but they make communication much more difficult as a result as leaders in the hierarchies are the only ones who can communicate with each other effective. Agile would do away with structures like these. Chapter 9 is about iterations.

Week 7 Blog

There's not much to say about this one since I was mainly working on the pitch video. I encountered an error when uploading videos to Adobe Sparks consistently and I don't know what went wrong, so I'm not as satisfied with it as I feel like I could be. I tried researching what the problem is for a good amount of time and came up with no results. I really don't know what the issue is. I did record the line multiple times until I was satisfied with them. I found Adobe Sparks's slide system was very helpful in this regard. It allowed me to easily break up my script into individual parts in which I could clearly record my voice in 10-12 second bursts, meaning I could easily re-record individual lines rather than having to re-record the entire script at once. The lack of video upload, however, meant that I tried looking into other programs to use, and for those I tried recording the entire script at once which took a lot longer. I inevitably went back to Adobe Sparks a

Week 6 Blog

Chapter 14 is about the myths associated with agile project management. One that stood out to me in particular is that "Change is Bad", which is often taken on by studios that already have processes that work. This reminds me some of how the studio Rare once mentioned that they hired new employees who had no experience so that fresh ideas could always be brought to the plate to avoid stagnation. Another point that stood out is that not every person believes that Scrum works for them, and may leave due to this style being forced upon them, although some studios may choose to give them specific roles that do not involve Scrum. Chatper 15 is about working with a publisher. The chapter starts off with an example of how Nintendo handled new game ideas in the 90's, in which they'd search for fun first and would tell their outside company to scrap a project if the game they were currently making wasn't fun. This is definitely an agile form of development, focusing only

Week 5 Blog

Chapter 10 is about agile technology, as its title implies. One of the first points the chapter covers is that the author was given an 80 page document detailing all the features the tool he was developing, which came as a surprise to him. It allowed the artists to detail what they needed, rather than leaving it up to him to figure out what the artists needed. However, the artists ended up not finding much use in the tool, as they didn't have the foresight to know what they wanted. Agile programming aims to fix this problem. Later in the chapter, it goes into detail on Extreme Programming, or XP, and its advantages and disadvantages. Chapter 11 involves the use of agile methodologies for art and audio. Audio in particular I find to be an interesting subject in this regard, as the book mentions that the audio team is often delegated to doing work at the end. In my opinion, it would make more sense to develop the audio at the same time as everything else (which would be more natur

Life or Death and Reading Post 1

Reading: Chapter 3 of the book covers how Scrum came to be in the modern era, what team roles are and how they should be allocated, and the core principles of what Scrum is.. The history in particular is fairly interesting. In the early 1900's, factories were synonymous with dehumanization. They required humans to become robots, working on a factory line with no input of their own. Following World War II, however, this began to slowly change, and finally in the past few decades, the concepts of Scrum started to arise. Scrum's principles include details such as Empiricism, Emergence, Time Boxing, Prioritization, and Self Organization. These are accomplished through Sprints, which are explained in more detail in Chapter 4. The team role that stuck out to me most was the Scrum Master. The Scrum Master is the one that encourages the team and does everything he or she can to make sure they succeed. This includes being stubborn enough to make sure the Scrum processes always go t