Morgan's Raid: Spring Semester

The Spring of 2011 saw a new semester of courses for me at Ball State University. Work still needed to be done to finish up the Morgan's Raid project, and I was asked late in the Fall to continue working on it with a few other students. At the end of the Fall Semester we had a working product. It did what it was supposed to do, but it really wasn't fun. Fun is, well, kind of important. There needed to be a fun injection, and the nine students working on it in the Spring would be there to administer it.

The player chooses their raid target priorities

This post will focus on my work on finishing up the Morgan's Raid project. It was a blast to take part in and I've missed working on it this Summer. Here is my synopsis of the events that took place this Spring.

Key Differences

Several students were carried over from the Fall to continue developing Morgan's Raid. Many, many things operated differently in the Spring versus the Fall semester. The main two were: the size of the team shrunk and the introduction of a dedicated workspace. 

Nine students were kept on the project from the Fall, which is a huge drop from twenty-five. Managing twenty-five people, all working on the same source code, would be a nightmare for me, so hats off to Dr. Gestwicki for doing as good of a job as he did. The Spring experience would be much more intimate but also much more intense. With only nine of us, the pressure would definitely ramp up if we were to be successful in our goals. There were a few of us who knew each other very well, but to be successful we would need to find a group identity, a personality that we all could take part in, day-to-day. By having a dedicated space (which I will talk about in a moment) and through several group activities, we were able to really get to know one another and develop some seriously deep friendships. I wish I had had this experience at the beginning of my college career, but that is another topic. Some of the group activities we took part in were: playing Team Fortress 2 after workday ended, meeting for lunch and eating together, as well as the almost weekly boardgame night. We worked together and we played together. By the end of things, we all knew what made the other people tick. It helped that we had similar personalities and life experiences, too.

For a great article on the importance of eating together, check out this Joel Spolsky blogpost: Lunch.

Overall, the team atmosphere was there much more noticeably in the Spring than in the Fall, despite having small teams within the bigger team in the Fall. Some of this can be attributed to the dedicated workspace in the Spring, versus the twenty-five of us spreading out as needed in the Fall. It's easy to see why working in one room for nine hours a week promotes unity. In the Fall, my group would meet for "daily" standup meetings, but after that we generally went our separate ways. Very little interaction took place outside of these meetings, other than pair programming.

In addition to having a much smaller team in the Spring, our group was privileged to have a dedicated workspace. We commissioned a rarely used room that was housing some servers. We maintained a good relationship with the System Administrators, and they returned the favor by helping us arrange the room as was needed. This arrangement of the room helped greatly. The desks were set up in a way so we could see each other easily, but we weren't all facing one another. Also, the ample supply of whiteboard let us have some very productive sessions of brainstorming and design.

We were also able to have a physical SCRUM Board, which was interesting. It was interesting to have the tactile version that we could look to daily for guidance. In the Fall, we had a digital version, which I preferred. I liked being able to access the digital version from any internet access point, but the physical version had a few pluses. It was motivating and encouraging to see the tasks move, physically, throughout the week, and since we did all of our work in one room, we didn't need to access the SCRUM Board from home.

Other Differences
In the Fall, the validation process was...chaotic. People would assume they were done, when, in fact, their approach was problematic and flatout wrong. This was a huge, huge problem later on. We would eventually uncover a rat's nest of issues, with the rat king being the overhaul of the classes pertaining to time and the retrofitting of the massive InGameState. This was avoided in the Spring, almost entirely, by having the final step in task completion requiring the person to validate that item with whoever we deemed should do it (we decided this when we created the tasks from the Product Backlog). Having this validation step (and more access to our gatekeeper, of sorts) kept us from straying off the path of righteousness.

In the Spring, we also had daily access to our artist. He wasn't on-site in the Fall, so our game looked pretty mediocre at the end of the first semester. Having him there, in person, sped up the pipeline quite a bit. We could get instant feedback on whether an idea was doable, as well as give feedback to him if we needed to tweak something. I cannot think of how we could have used him on-site in the Fall, as we were kind of meandering along through development. We had direction but we lacked the perspective necessary to create something that was focused enough to warrant a ton of artwork. In the Spring, we used our little artist (who we decided was a robot, as he was quite productive) to the fullest, and having him there with us was a great experience.

One other difference between the two semesters was the set worktime in the Spring. As I mentioned, we had our "daily" standup meetings in the Fall semester, but we didn't have a set work time. In the Spring, we established a schedule where we could all meet and work for several hours. The benefits of the latter approach are obvious, so I won't spell them all out, but to summarize: having a dedicated work time three days a week was a great improvement over the Fall and enabled a lot of our successes.

Playtesting
In the Spring, we had a solid enough game to run a playtesting session with real, live(important, they must be fresh!) Indiana 4th Graders. This was a great experience for me, personally, but also for the whole team. We did two playtests at a pair of elementary schools.

The first was a school in the Indianapolis area. They were a gifted and talented class. We had a very positive experience, as the students gave us great feedback. Looking back, our game lacked focus, but the kids loved it. They went so far as to say, "It felt like we were testing Halo or something."- high praise from the students. Their feedback was especially helpful because they were used to articulating their thoughts and they had some very valid concerns.

Our experience at the second playtest was quite different than the first. We playtested at a local school here in Muncie. We benefited just as much (maybe even more) over the first playtest. Economically the two areas are very different, and this wasn't a gifted and talented class, so we knew not to expect the same reactions from the kids, which was fine. We didn't make the game with any one level of student in mind, all Indiana 4th graders should get something out of playing it.

At the first playtest, we had a very rough game, so their enthusiasm for what we were doing helped motivate us early on (this playtest took place one month into Spring development). By the second playtest, our game had came a long way, but we were drunk with power. The game was trying to do too much and this became very apparent. Following the second playtest, we really scaled back what we were doing and focused our energy into making our game do something great instead of doing several things well.

The summary screen of Morgan's Raid

Summary of the Summary
The main things I took away from the Morgan's Raid project were:

• Game design can be fun, but challenging
• Software development is what I want to do for a living
• Working in an Agile environment is very productive
• Version Control Software is absolutely necessary
• I realize I haven't mentioned this at all, but it's such a big thing that it really warrants its own post
• I love history
• Working on something one is passionate about makes the whole process much more enjoyable

This class was my introduction to Game Design, and I am by no means great at it. I struggled at times but those were the moments I learned the most. This course was also my introduction to a long-term software development project, one where I had to reread a lot of code. This really cemented the concept of writing worthwhile, optimal code. Failing to do so causes more headaches later.

Agile and SCRUM were also fun to work with. It was a little difficult to wrap my head around the concept of there being no "manager" on the project, but eventually it all clicked. I feel I have a solid understanding of SCRUM, but I still need to work on making accurate time estimates. 

Screenshot of:
Civil War Generals 2: Grant, Lee, and Sherman

Working on a history project like this reminded me of my love for American History. I loved learning about the American Civil War and the Revolutionary War in school. I remember getting excited about Civil War History through the game Civil War Generals and Civil War Generals 2: Grant, Lee, and Sherman. Looking back, it wasn't a great game, but it did something that we were trying to do with the Morgan's Raid project: entice people (in our case, Indiana 4th graders) to learn about the era by participating in a simulation. 

I've had an absolute blast working on this project. I am truly sad that development is complete, as I had a lot of fun working with a lot of inspiring people. Moreover, I am proud to have helped create something, that, with a little luck, might be another kids inspiring moment.

I am working on another educational video game this summer. Several students in the course will be blogging about the experience, which can be found here:
Digital Archaeology Project

If you would like to check out Morgan's Raid, it can be found here:
Morgan's Raid Site

My professor, Dr. Gestwicki, did a write-up about the Morgan's Raid experience,
which you can find here:
Morgan's Raid Postmortem

Screenshot of Civil War Generals taken from: www.mobygames.com.
Screenshots of Morgan's Raid taken from: https://sites.google.com/site/morgansraidgame/screenshots

Morgan's Raid: Fall Semester

General Morgan

This will be a longer post, so I will break things down a bit as I go.

Background
John Hunt Morgan was a Confederate General in the American Civil War. Against direct orders, Morgan and over 2,000 cavalry units rode through Southern Indiana and raided several towns. They carried their raid on into Ohio, where they were ultimately caught. Morgan escaped from jail, but was later killed, ironically, in a Union raid.

The goal of my Game Programming class, which took place Fall of 2010, was to capture the events that happened during Morgan's Raid, create an accurate simulation, and turn it all into a tool that 4th grade teachers could use to engage students. Historical accuracy was pivotal -as was keeping in mind what worked when 4th grade students used computers. So to keep these two things in focus, we leaned heavily on a History professor who focuses on Elementary Education, as well as a History Graduate Student, who did the majority of the legwork when research was necessary.

This post focuses on the Fall Semester of Morgan's Raid development. Having worked on the project in the Spring of 2011 as well, I had very different experiences. Both had their positives and negatives, and while I filled out a course evaluation for the university, I feel that it is important to try to summarize what I took away from both semesters of the project.


SCRUM
As mentioned in my previous post, we used SCRUM and Agile methodologies to keep our project organized. In the Fall, we utilized a shared Google Document Spreadsheet as our Product Backlog, which saved our time estimates and automated our burndown chart.

Using a publicly shared document worked well enough, but there were hiccups associated with having such a large group. We often had to spread out to different rooms/labs to have enough space to talk as a group without disrupting other groups. It would have been nice to be in one place for planning meetings, but it just wasn't possible. Needless to say, our class regularly was pretty loud during these meetings, which isn't a bad thing. In the chaos, however, sometimes a group or two would nab the more desirable tasks. One group might have been working on a certain problem and the next week another group would take a task that would be best given to the first group. The first group had a better understanding of the architecture or the package that was being used, but the latter group might quickly take it. People didn't want to create drama, so in the first few Sprints people took what they could get, as far as tasks go. It paid to quickly take a task, and in retrospect I can say that we weren't following SCRUM practices to the letter during our planning meetings.

Later in the year we moved to a larger area and developed a way of pulling the SCRUM Masters together to discuss any of these issues. However, by this time it was nearing the end of the semester and people were either pulling more than their weight or easing up. If we had had a dedicated, larger space from the get-go, some awkward situations could have been avoided.


Entity System Architecture

Our professor had a vision of using an Entity System architecture (ES). He had us read several articles as initial assignments, one being here: Evolve Your Hierarchy. I have a good understanding of ES, but if I get a part of it wrong, feel free to correct me in the comments.

To summarize it, ES is a way of creating attributes (called Components), while using Systems to modify the Components. In our application, a Component we had was "Speed", which we applied to the Entity John Hunt Morgan. Entities are made up of Components, and generally you find the Entities based on the Components they have, not by a name. Morgan had a Speed value, and the Speed System would modify that value.

Components could be applied to multiple Entities as well. This allowed us to modify many Entities at once, without making systems for each individual Entity. In our case, every road was an Entity. We had a System that would render the roads (before we baked the image into the background). Another System also made sure our GPS coordinates lined up with the coordinates for the correct town.

Using ES required us to maintain the right scope when we developed our systems. If the systems are nested too "deep" then if that logic is needed elsewhere, a messy refactoring is necessary. This way, all that is required of the dev team is to apply the component to another Entity, and voila! Fun stuff!

In order to do ES well (and this applies to Software Development in general), logic should be pulled apart when possible. There might be a good way to determine when this is necessary, but from my perspective it's more of a gut-feeling one develops. For example, if our previously mentioned Speed System class is doing much more than modifying the Speed Component, it probably needs this functionality pulled out into its own space somewhere. If changes need to be made to Speed to use it in another instance, you know exactly where to look to carry changes through to other classes. This is kind of a "duh!" idea, but it wasn't touched very well in my experiences. It's pretty easy when asked to make a project for a class to do things the quick and easy way. The only expectations are that things are commented and the requested task is fulfilled. This is by far the largest project I have worked on, so seeing why it's so important to do things this way has been game-changing for me.

Colocation and Summary
For the Morgan's Raid project, I was on the "Map" Team. At the onset, our initial tasks dealt with the Map, but after the first Sprint we weren't assigned to "Map" tasks. The three other teams had similar names, but one team decided to rename themselves.

Week in and week out, the four teams took tasks and performed them to the best of their abilities. By far, the use of the Slick 2D Game API and Entity System Architecture gave students the most trouble. Slick was difficult for the team to get used to, but once we understood it we were rolling. ES was more troublesome (even into the Spring semester for those who hadn't worked with it yet). It was easier to make bloated, redundant classes. I found it easy to wander off the path and instinctively push my code away from ES. Having someone there (our professor) to keep us on-track was very helpful. In the Fall, one-on-one time with our him was harder to come by (25 to 1, vs 8 to 1 in the Spring ). Sometimes it was frustrating, but everyone tried to be patient. Generally, we all worked following our daily Standup meetings in a lab that is dedicated to CS students. This colocation of groups was great, as any questions that might pop up could be answered by someone in the room.

Fast forwarding to the end of the semester, we had a decent, shippable product. Some core game mechanics were present, but the lack of high quality art made it difficult to envision the game being played. Several people went above and beyond the requirements (as far as invested time goes). My programming partner and I showed an interest in fixing a few errors, and Dr. Gestwicki met us a couple weekends to try to come up with a solution. Many others, not just us, pitched in (or came in on weekends) to help. This goes outside of the SCRUM scope of things, as you're supposed to allocate the necessary time, but in crunch situations sometimes drastic measures must be taken. Our efforts were successful and in order to move forward at times we had to take a step or two backward. Much less of this was needed in the Spring semester, which I attribute to having a smaller team, having more clear goals, and everyone having a much better understanding of what we were trying to accomplish. Time estimates are difficult when the project is so far from being complete.

I was very excited and nervous when I was asked to continue working on the project in the Spring. In the Fall, I really grew as a programmer. I developed some confidence and a great understanding of what it takes to work on a larger team, as well as working with a partner. I learned a few lessons in the importance of not outsmarting yourself (developing such complex systems that you end up wasting more time than you're going to save). I also experienced the pains of watching bits of code that I (and my programming partner) worked so hard on disappear. These moments were small, but valuable failures - the kinds of failures you learn from and build off of.

And I would need it in the Spring, as we more than doubled the total lines of code, while removing maaaany bloated spots of the code (hellooooo InGameState!). In one of my next posts I will sum up my experiences in the Spring on the Morgan's Raid project! I've had a blast working on this project, and coming up with a summary of lessons learned proved difficult but very beneficial.

My Introduction to SCRUM

Sometimes something comes along that you're excited about but wholly unprepared for how it will change the way you think. Last Summer, I was coming off of an unfulfilling Spring semester, but I was looking forward to the Fall session. I was scheduled to take a few classes with the bright spot on the horizon being a course on Game Programming. I think the gut reaction when people my age see a course on Game Programming is "oh man, I love video games. That sounds fun!" My reaction was probably pretty similar, but I was especially interested in the logic that drove some of my favorite titles. The class would be taught by one of the younger professors, Paul Gestwicki, who I had not had up to this point in my college career. I had heard a lot about how his courses were demanding but very rewarding.

The first day, I knew the class would be different than anything I was used to. Once we had created four socially-constructed teams(we built them based on pre-existing friendships and proximity, not on areas of expertise or ability), we went over the organizational system that we would follow. With around 25 students, all working together, we would definitely need some guidelines to adhere to.

We followed SCRUM, which, by the Wikipedia definition, is:

an iterative, incremental framework for project management often seen in agile software development. 

In plain words, SCRUM incorporates several small teams (four to six people each), with one person designated as the SCRUM Master. Their job is solely to remove impediments, obstacles that are preventing the team from achieving their goals.

The teams work in sections of time called Sprints. Ours typically lasted two weeks, with some modification when holidays would cause the Sprint to end awkwardly.

We had Product Owners, who would create goals called User Stories. These User Stories would be arranged by importance in a Product Backlog. At our Sprint Planning Meeting, which took place at the beginning of each Sprint, we took these User Stories and broke them down into manageable, achievable portions, called Tasks. For example, if the User Story was to create a dialog box for something, a few tasks might be "Create the text for the dialog", "Sketch out some placeholder art for the box", "OK the dialog with a Product Owner".

Pairs of people would volunteer for the task that they were comfortable taking. They would then give their estimate as to how long it would take to accomplish. Every pair was asked to determine their availability in the next two weeks, and volunteer a maximum amount of hours. (This is important because as a legitimate college course, we wouldn't have lectures or labs to attend, so we would need to fulfill the credit hour requirements by working)

This process may appear complicated, but the following flowchart depicts the process from beginning to end, with the goal being to deliver a shippable, high-quality product at the end of every Sprint. If a feature couldn't be finished on-time, it was renegotiated (more on this process later) and left out.

(Image courtesy of Mountain Goat Software)


Typically, time estimates were tallied up and a burndown chart was created. This chart was useful for the teams to see their task progress visually. Also, the chart was useful in retrospectively spotting hiccups in progress. For example, a snow storm might cause the team to lose a bit of production for one day, which could be seen clearly on the chart.

Here is one of our actual digital burndown charts, taken from an old spreadsheet:

The red line indicates steady progress, and the blue line represents our actual day to day progress.


SCRUM Day to Day
Throughout the sprint, "daily" stand-up meetings were held. I say "daily" because many schedules did not sync up perfectly, at least in the Fall Semester, and meetings were held every Monday, Wednesday, Friday instead. These meetings were timeboxed (at fifteen minutes), much like our Sprints, and literally everyone had to stand up. This kept meetings short and focused, with the purpose of the meeting being to inform members of the team as to your progress since your last meeting. Scrum Masters were to pay attention to mentioned impediments during this meeting.

At the conclusion of the meeting, pairs would get to work on their tasks. When the work time ended, each pair was responsible for updating their estimate on the burndown chart. Keeping the estimates up-to-date was imperative for ensuring the burndown was accurate.

If team was going to fail at meeting a deadline for a specific task, it would be renegotiated several days before the end of the Sprint. Renegotiations would take place between the task-assigned team and the Product Owner(s). Sometimes specific requirements might be lessened, but in more extreme cases the task could be dropped entirely. Obviously this is a last resort measure.


This concludes my summary of how I understand SCRUM. While there is a lot to digest here if you're unfamiliar with SCRUM, it all is important. From what I've read, our implementation of SCRUM was pretty true to the standards established by industry professionals. Overall, this development strategy and organizational process suited the project well. Both semesters of development benefited greatly by using SCRUM, but each one did so in very different ways. I'll shed some light on that when I get to the respective semesters.

In my next post, I'll talk about the game, how software development with 25 other people (college students, no less) can be difficult but rewarding, and how SCRUM and Agile methodologies made it all work.