 | |
| General Morgan |
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.
No comments:
Post a Comment