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 |
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.
Summary of the Summary
The main things I took away from the Morgan's Raid project were:
Screenshot of Civil War Generals taken from: www.mobygames.com.
Screenshots of Morgan's Raid taken from: https://sites.google.com/site/morgansraidgame/screenshots
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.
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
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
No comments:
Post a Comment