- Characterizing a genre deals with a theoretical grounding for the semester's activity.
- Goals and Early Design relates how we came up with our overarching goals.
- What's on the Wall? looks at how the team customized their environment.
- What else is on the Wall? is a follow-up to the previous post
- Story Maps vs. Scrum Boards looks at how I was experimenting with story mapping as an alternative to Scrum-style task boards.
- Leaving Story Maps Behind, as the name implies, explains why I went back to Scrum-style task boards.
- The Launch of Traveler's Notebook: Monster Tales is a simple launch announcement.
- A Project Retrospective and Final Exam describes the format of, and findings from, our final project retrospective, and I shared what I still think to be a rather clever final exam format.
There are a few topics that I have not written about, so I will take the opportunity here to share them.
 |
| The sign on our door |
Multidisciplinarity
This semester had the best mix of majors I have ever had in a studio course, better even than the mix at the VBC. The team included: four Computer Science majors; one Telecommunications major with an emphasis in audio production, who also had a CS minor; one Philosophy major with a CS minor; one Art major specializing in animation; and three English majors specializing in Creative Writing. There were some tasks that people fell into pretty naturally: the CS majors got right into the programming, the artist into illustration and visual design, the English majors into writing. Our audio was all designed and integrated by our Telecommunications major, and one of the English majors also contributed significantly to the visual design, drawing upon her minor in Professional Writing (which includes a significant media design element).
Those are some of the common discipline-oriented production tasks involved in game design and development, but there are also important interdisciplinary aspects. Here, the team really came together and took initiative. Some of the students joined me in writing a scholarly article about our work, which is currently under review. Several contributed to the visual design of the game over multiple iterations. When it came time to conduct playtesting sessions, our Philosophy major showed her humanistic and analytical prowess in designing, executing, digesting, and disseminating our evaluation protocol. About halfway through the semester, we became aware of fundamental design problems, and this resulted in a beautiful, rapidly-developed paper prototype for a new design that was assembled by a CS major and our Philosophy major. This particular artifact served as an important intermediary work product, serving to align the team's disparate visions about where the project was heading.
 |
| Working on the paper prototype |
Technology
While I have been using GitHub and Travis for projects since last summer, this was the first time I worked with more than one or two other people using this technology. It was a little spotty at first, in part because so many of us were a little green, but once we agreed on how to coordinate feature branching, we hit stride. I think we still could have been a little more formal about how to handle pull requests and who is responsible for doing them. I wonder if this is a place where I should be more central in the process, teaching by example how to conduct a review of a pull request, and slowly doling out the responsibility to others on the team as they learn. I am uncertain, however, as to whether this would slow the team beneficially or artificially--if they need to make those mistakes with git in order to understand how to proceed.
A particularly tech-savvy team member knew a lot more about GitHub than I did, and he pointed out that we could set up an organization page as well as a project page. Given that our project is open source, this gives us free hosting for a web presence and the game itself, which is pretty slick. Our custom domain name simply redirects to our github.io page, with Google Domains' subdomain forwarding taking you to the info page or directly to the game. Thanks, GitHub!
We adopted Slack at the recommendation of one of our technically-minded team members, and this proved to be a great boon to the team. Over the past several years, I have struggled to find a team communication mechanism that fits the right balance of convenience for a maximal number of users. Usually, I have fallen back on Google Groups, which is essentially a mailing list; the problem is that kids these days, they don't conscientiously check their email. Slack hit us right where we needed it, with multiple entrypoints and notification settings for different users. If I were to use it again--which I expect I will--I will do a little more research on best practices for the use of channels. We used one #development channel, where programmers talked to each other and we had Travis sending continuous integration messages. This was much too noisy. The team had a lot of fun with Slack, which also meant that sometimes it was hard to separate the signal from the noise, so something like a new pull request might get lost. This is probably something that regular users have bot-based solutions for, and one of the team members even started writing such a bot during finals week; next time, I need to come in a little better prepared.
All together, we built prototypes in three different programming platforms. In our first push for a playable prototype, the team decided to use Java with JavaFX because it was familiar to them, even knowing that it would not likely be our target platform. While they worked on this, I worked on proof-of-concept systems in both PlayN and Polymer. After that first iteration was passed, we looked at all three platforms and centralized on PlayN due to the ability to write in Java and use familiar tooling while also being able to publish to HTML5 via the GWT compiler.
 |
| Team T-Shirts were an important part of our technology stack |
Integration
We never quite hit a good cross-functional integration rhythm this semester as has happened in past semesters. Art integration was an awkward manual process, with files being uploaded to Google Drive, downloaded by a programmer, probably renamed to match conventions, and then added to the project. By contrast, in Bone Wars, we had the artists integrated directly into our repository, so they could freely update files themselves. It's worth noting, though, that we had two artists that semester and for twice the credit hours, so we had more breathing room: our one art major this semester really went beyond the call of duty in producing the amount of original work that he did.
We once again used a design log, and this came up frequently in students' reflections about what facilitated team work. I think we could have been even more deliberate in using it to explore design decisions: a few times, some ad hoc contribution would end up in the code and then become seen as normal, even though it broke the game's theme. It is also possible that some team members never did reference the design log, as very late in the game, there were still some team members using the game's nomenclature incorrectly, which invariably leads to confusion. Of course, this was a highly-experimental course, and we came in with inspiration but almost no design at all. It is really amazing that this team was able to accomplish what they did in just one semester and three credit hours. It helped that I had an extra course release for research this semester, as it meant I also had one less thing to worry about and could focus on helping Studio 368 succeed.
Story integration was also awkward. I initiated the design of a JSON-based story specification format, so that a single JSON file could describe the world. (This actually came out of my Polymer-based prototype.) One of the team members undertook the challenge of creating a graphical level editor in JavaFX that could read and write this format, which--in theory--would make it easy for those focused on writing to integrate with the game. Unfortunately, that never really happened: the writers never adopted the editor as a primary tool, instead collaborating on Google Docs. This led to some conflicts, where their creative writing was not always aligned with the formal needs of the project. It was the first time since my 2012 VBC seminar that we had to write our own editor, but this one was not integrated well enough into the rest of the stack to maximize its utility. In all of our iterations, I don't think the story team ever saw and debugged their work in the game until after the iteration was formally over. Looking forward, if I were to continue this project or undertake something similar, I would want to more formally include the editor in sprint planning and ensure that it supports both rapid integration to the game.
 |
| Inspirational messages from Debbie |
Acknowledgments
This project was supported by an Immersive Learning Micro-Grant from the College of Sciences and Humanities, to whom I am extremely grateful. We would not be able to make it a real studio without the generous support of my home department, Computer Science. One of the reasons I had such a great team was because of trusted friends on campus who sent me their best and brightest, and I owe them gratitude as well. Special thanks to Jennifer Grouling and Joyce Huff from the English department at Ball State, both of whom volunteered their time to share their scholarship with my team; Cathy Hamaker at The Children's Museum, for sharing her stories and time with the team; and to Rebecca Parker and Stuart Cotton at Muncie Public Library's Connection Corner, for being willing to work with us on this venture.
And of course, thanks to those students who took a risk in signing up for the game production studio. You did great work, and I am proud of you.
 |
| It's a long story. |
