Using Google Reader has been an interesting, productive exercise for me over the last couple months. One of my professors mentioned it and I thought I would give it a whirl. It's an interesting tool, as it's relatively worthless out of the box. Start following a few people and subscribe to a few websites, however, and it transforms. Every day I wake up and several new items are in my new item list. Personally, I try to keep my feeds clear by at least reading a little bit of each post (so they read 0 and not 1,251). If I don't find them interesting, I skip the post and mark it as read. There is always something that I can be reading to entertain and/or better my self, so to have that convenience in my pocket is an awesome thing...
I subscribed to an already existing set of feeds called Agile. There are several which Google have set up already, but this one deals with, well, Agile topics within software development. Some of it is a bit too self-serving for my tastes(people blogging about certifications and workshops, things that may matter to people other than myself). However, a few blogs that I've added to my subscription have been diamonds in the rough.
One post by Jeff Atwood really hit home with me. In his discussion on How to Write Without Writing, he gave me another reason to do what I'm doing in this blog. To summarize part of his post, he says that blogging is a great way to better one's communication skills. Atwood says that bettering these skills will make you a more proficient programmer. The more I work in groups and on teams, the more I realize that he's absolutely right. I've seen firsthand how difficult it is to come in months after someone wrote some code and try to piece their ill-formed thoughts together. Sometimes there just aren't enough clear comments. These are the kinds of things employers will be expecting, and it'll be one of the ways they'll love you if you're good at it...at least that's what I'm hoping.
This space has been all about that, taking ideas and putting them in their clearest form(at least to me). I'm definitely not the best writer or communicator, but this is my attempt to hone these skills. It's nice to know that someone like Atwood, with all of his experience behind him, is encouraging me to blog and collect my thoughts.
Atwood's blog can be found here, http://www.codinghorror.com/blog/.
Another interesting blog I found is, http://bjk5.com/ by Ben Kamens. He's the lead dev at Khan Academy, which is deserving of its own post, but I'll save that for another time.
Using Google Reader has been a great experience. I don't have many followers, but I try to share with them only the things which I find truly interesting. There's almost a hierarchy of things which are worthy of being shared: a Google Chat status is the lowest, a Tweet would be next (if I had a Twitter account), a Facebook status after that, and finally a shared item on Reader.
Saturday, June 25, 2011
Searching for Other Options
A few quick emails yesterday afternoon all but nixed using JavaFX. Apparently it doesn't work at all with Mac, and our project is attempting to be cross-platform friendly from the beginning .
For our Digital Archaeology Project, we had a few ideas as to what software to use to design it:
For our Digital Archaeology Project, we had a few ideas as to what software to use to design it:
- Swing
- GWT
- JavaFX
- Unity3D
- Slick
Swing was quickly eliminated, as there are more powerful options in the list. Slick is what was used for the Morgan's Raid project, so we all are very familiar with it. However, it doesn't have a good solution for creating buttons and a custom interface. Those things would need to be done by hand,which is possible but difficult. So that left us with GWT, JavaFX, and Unity3D. The latter option is a 3D game engine that has some really approachable tools. The downfall is that these tools cost money and aren't very recreate-able without going in and typing things in by hand. In other words, it can't be used in other instances programmaticly, other archaeology sites would need to be redone by hand.
So with Swing and JavaFX out, the team is focusing on GWT and Unity3D this weekend. We know what Slick can do, but the other two options are relative unknowns. I have GWT all set up on my machine here at home and a free afternoon ahead of me!
So with Swing and JavaFX out, the team is focusing on GWT and Unity3D this weekend. We know what Slick can do, but the other two options are relative unknowns. I have GWT all set up on my machine here at home and a free afternoon ahead of me!
Friday, June 24, 2011
Digital Archaeology Project & JavaFX: First Impressions
For the Digital Archaeology Project I am working on, the Computer Science students in the group were given the weekend task of tinkering with JavaFX. So far, things are going well!
JavaFX was described to me as a language that allows us to do some interesting animation and visual effects, all while allowing us to build off of our knowledge with Java. It seems pretty robust, but I've only looked at a few code examples. Getting it going with Eclipse was fairly simple. I followed this tutorial Oracle JavaFX Tutorial and was able to work along side it very easily.
I have some plans outside of staring at a computer monitor tonight, or else I would continue on with these tutorials, but that is where I plan to get back into it tomorrow.
I haven't mentioned it in this space, but I am working with a few other students and professors on developing a digital archaeology simulation (a game) for 4th graders. I wrote a quick summary of our work so far, which can be found here. I'm not sure how to use this space in conjunction with a class-wide, shared blog. I'd like to keep working in this realm, as it's easier to wrap all of my thoughts up onto one page. I could also post to both spaces simultaneously.
I like the progress that was made today. I feel for the non-Computer Science students with the prototyping that we've done this week. They've done a great job so far, but the process can be frustrating initially. Those of us who were around for Morgan's Raid last fall were subjected to our fair share of prototyping, and, as Dr. Gestwicki would and does say, you do it so you can throw ideas out. It really saves you time later. Looking back, I wish we had done a bit more prototyping in Morgan's Raid at times, but with this project I think the Anthropology students are getting a good experience. One of them mentioned in a reflective post that they didn't think they would be doing so much design - that they enjoyed getting to take part in it. I'm glad they will have the opportunity to give a lot of feedback. CS people tend to be min/maxers, power users, so we might be more interested in the numbers side of things. A fresh perspective could really be huge for keeping the game fun on a surface level (I made an archaeology joke!).
JavaFX was described to me as a language that allows us to do some interesting animation and visual effects, all while allowing us to build off of our knowledge with Java. It seems pretty robust, but I've only looked at a few code examples. Getting it going with Eclipse was fairly simple. I followed this tutorial Oracle JavaFX Tutorial and was able to work along side it very easily.
I have some plans outside of staring at a computer monitor tonight, or else I would continue on with these tutorials, but that is where I plan to get back into it tomorrow.
I haven't mentioned it in this space, but I am working with a few other students and professors on developing a digital archaeology simulation (a game) for 4th graders. I wrote a quick summary of our work so far, which can be found here. I'm not sure how to use this space in conjunction with a class-wide, shared blog. I'd like to keep working in this realm, as it's easier to wrap all of my thoughts up onto one page. I could also post to both spaces simultaneously.
I like the progress that was made today. I feel for the non-Computer Science students with the prototyping that we've done this week. They've done a great job so far, but the process can be frustrating initially. Those of us who were around for Morgan's Raid last fall were subjected to our fair share of prototyping, and, as Dr. Gestwicki would and does say, you do it so you can throw ideas out. It really saves you time later. Looking back, I wish we had done a bit more prototyping in Morgan's Raid at times, but with this project I think the Anthropology students are getting a good experience. One of them mentioned in a reflective post that they didn't think they would be doing so much design - that they enjoyed getting to take part in it. I'm glad they will have the opportunity to give a lot of feedback. CS people tend to be min/maxers, power users, so we might be more interested in the numbers side of things. A fresh perspective could really be huge for keeping the game fun on a surface level (I made an archaeology joke!).
Thursday, June 23, 2011
Ubuntu
Tonight I finally bit the bullet and tried to get a version of Linux working on my home desktop. I wasn't sure what to try, but after a bit of research I decided on Ubuntu. I don't know where my Win7 disk is (I'll get reorganized after the upcoming move), so I didn't want to do something that would upset my productivity and home internet browsing back. So with that in mind, I chose the "install it on top of Windows" option, called Wubi.
It downloaded fairly quickly and asked for a reboot. I really look forward to the day when bootups take a handful of seconds. I walked away and missed the "choose which OS to boot into" choice, so it chose Win7. I came back to my machine and instinctively logged into my Windows account.
"Wait a second..."
*sigh*
Once I rebooted again and got into Ubuntu, I had to get some drivers - one of which was for my video card. After I got that going, and rebooted, I was mildly blown away at the beauty of the interface. The menus were crisp, the buttons were well bright and cheery. I halfway imagined the Matrix; my mind had anticipated something much more unapproachable than what was actually before me.
It wasn't long before I was trying to get it to do something that I couldn't figure out - get two monitors to register (I've got them, I might as well use them!). I'm sure it's something simple, as it's probably a fairly common problem. I'll leave it for another day. I'll keep my Windows 7 install around. If I want to play a great game chances are I'll have to use that to play it, but Linux has come a long way from when I last saw it. Maybe I didn't give it a fair shake, but this time around I aim to do so.
It downloaded fairly quickly and asked for a reboot. I really look forward to the day when bootups take a handful of seconds. I walked away and missed the "choose which OS to boot into" choice, so it chose Win7. I came back to my machine and instinctively logged into my Windows account.
"Wait a second..."
*sigh*
Once I rebooted again and got into Ubuntu, I had to get some drivers - one of which was for my video card. After I got that going, and rebooted, I was mildly blown away at the beauty of the interface. The menus were crisp, the buttons were well bright and cheery. I halfway imagined the Matrix; my mind had anticipated something much more unapproachable than what was actually before me.
It wasn't long before I was trying to get it to do something that I couldn't figure out - get two monitors to register (I've got them, I might as well use them!). I'm sure it's something simple, as it's probably a fairly common problem. I'll leave it for another day. I'll keep my Windows 7 install around. If I want to play a great game chances are I'll have to use that to play it, but Linux has come a long way from when I last saw it. Maybe I didn't give it a fair shake, but this time around I aim to do so.
Tuesday, June 21, 2011
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 |
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
Thursday, June 9, 2011
Morgan's Raid: Fall Semester
 | |
| 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.
Subscribe to:
Posts (Atom)