Lock, Load, Code.

Over the last few months, we've learned a lot about how to work together as a team, and the friction that clashing personalities can cause. Agile principles and practices have helped us from veering too far off course. Rather than using up-front design and guidelines, we were able to adjust when needed. In the end, this resulted in a better product that stuck to the original vision, while still making changes to cater to more valuable features. Featured Picture: Our game nearly complete

With everything closer to finalized, it was time for our ultimate challenge - playing our game with the teacher. It's one things to play on our own, since we put in all the work to create the game. Bringing in a somewhat outsider to go through the madness is something else. Even though our product was a bit weak, our team's glowing personalities made the experience pretty enjoyable. We had a lot of laughs, since our game encouraged dark humor. Feature Picture: The logo of the game

Getting closer to an actual release for our game, we had to start polishing things up. Our notes for the game could no longer exists in a Google Drive folder. If we expected someone to play our game, we couldn't just give them read-only access to the folder and wish them well, right? We began working on character sheets, instruction manual, and so on. Featured Picture: Our official character sheet

Over the course of our next week, we were pretty determined to pick up the pace on our project. All around, we felt that we were getting pretty stagnant - sitting around for weeks, getting little done. Working around peoples' schedules was proving difficult too. We decided that we were going to push forward, holding meetings as fast as possible, even though everyone might not be able to participate. This meant we would hold Sprint meetings at times where not everyone could attends, playtests as well. We had to strike a balance between getting work done, and following the manifesto. Featured Picture: Notes from playtesting

Even though developers are encouraged to stay on track and work only on what needs to be done, it's also beneficial to let developers have some fun time. Give them time to work on some ideas they've been tossing around, and you'd be surprised just how innovative they can be. When I had time to get loose and just work on whatever I wanted, I created a pretty elaborated spreadsheet for testing classes. In our textbook, Extreme Programming was given a couple of chapters, describing the principles and practices of XP. One of those practices was automated testing. I decided to implement automated testing for our classes, and use a spreadsheet to compare class stats to random GM rolls. For each class, 2500 tests could be run just by adjusting a class' stats. No more rolling a die and recording a number! Now that's efficient! Feature Picture: A peak into the spreadsheet

In the next week of our Agile adventure, I decided to take my turn as Scrum Master. That meant I wanted to do some research about what it takes to be a good Scrum Master. The role is something more than just a supervisor, manager, or babysitter. The Scrum Master is a servant leader, they are there to keep the wheels greased and keep the parts working together. I found some great resources online, including a really neat video from Spotify: https://vimeo.com/85490944 . The video covered more than just what a Scrum Master does, but how a team can take the Agile practice and bend it to what works for them. Not every team is the same, and teams can change over time. It's important that the Scrum Master doesn't restrict the team to certain methodologies simply because "This is the Agile way." Feature Picture: Part of the Spotify presentation  

After our Product-Owner-lead playtest, our team was bummed out once again. We felt that a lot of the work we had done before now was wasted. What made it worse is that we felt it wasn't our fault. Why exactly did we feel this way? We were told that we were off vision, that we were working in a different direction. Of course we all felt pretty justified about why we were off track. To be on track, you need... tracks. Developers are like a train that just keeps on going. It's up to the conductor to lead the train in the right direction, right? We were still suffering from the same problems that plagued us in the past. Ambiguity was striking once again, which lead to work being done on all the wrong things. It's pretty disappointing when you feel that you put in hard work, and it was all for nothing. We decided to improve upon our communication by leaning more on our team structure. Each mini-team has a lead - lead designer, lead-mechanics, lead-content. Our collective would...

Following the events of my last post, the original Product Owner of our team lead our next playtest as the Game Master. The Game Master is along the lines of a narrator - they lead the players along the story, triggering events and entities for the players to encounter. As our GM guided us through his vision of the game, it became obvious that it was not his first time at the rodeo! He was definitely an experienced GM, and provided a very entertaining experience. From this playtest, we gained a better understanding of the Product Owner's vision for the game. He made his points clearly as he narrated the game, and showed us what he was expecting. Sometimes language fails us, and you have to really get your hands on something to understand it. However, not all of us were happy with the experience. We had some grieviences, such as players not being in control of their character due to GM interference, and how complex the items in the games were. The Product Owner would have to give ...