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.