Thursday, May 9, 2013

Lessons Learned from Serious Games

Makahiki-KTUH's GitHub page is online now, and the documentation has gone up on Google Sites. You can visit the project page on Heroku, too, although a complete implementation remains far from ready.  Work on the project to develop it to where it is now has been a semester-long learning experience, with a great deal to teach. Over the last four months, the ICS 691 class covered a dazzling array of software tools, to boggle the creative mind and present a classic dilemma: Where even to begin? 

One of the crucial lessons about serious games and implementation that I learned along the way was well summarized by Brian Eno, in a lecture on a seemingly different topic:  
"Why is it that people can still make interesting music, and not only interesting, but innovative stuff, using those tools that, in digital terms, are hopelessly limited? Well, the reason is, you very quickly understand what you can do with... a set of drums, or an electric guitar, or a violin, and you stop looking for more options, and you start grappling with it. You say this is what this does, so what do I do? The problem with software-based work is that you can never exhaust what it does, so you can always cover the fact that you haven't got another idea by trying another option in the tools. So if you have a lot of options, you don't usually have a lot of rapport with the instrument, and if you have few options, you usually have good rapport with the instruments. And this is why people make good music with simple instruments. They understand them better than us software people understand our instruments."
With a huge set of possibilities, paring them down to a manageable set is imperative. "One of the things I spend a lot of time doing is banning options," said Eno, who could just as well have been speaking to this class. With the "instruments" in 691 chosen (or at least strongly recommended) for us—Python, Django, Makahiki, and a variety of web UI technologies—we spent the first three months of class simply to gain a basic grasp of them and begin writing simple programs.

At some point along the way, I had the frustrating realization that most of program I wanted to make could not be implemented in time for the final. I was still grappling with intermediate and advanced aspects of the system, and a mastery of these was required for the work to go smoothly. As these complexities emerged, however, I felt better about not being able to finish because I realized that an important task remained: My project partner and I needed to reassess the project in connection with the people we wanted to help—our players and my colleagues—and figure out how it would affect the software we were proposing to develop. It turned out that there was plenty more work to be done beyond writing the code.

We got encouragement from the KTUH and UH media teams, and through this we grew to feel that writing our own widgets for a first run of the game for the station wouldn't be necessary. While some of our feedback was much in favor of Projects and SRS apps custom built in to the Makahiki framework, we also realized that the Smart Grid Game could approximate these apps.

Doubt about the whole project also arose. Ultimately, and frustratingly, it became (and remains) uncertain whether or not KTUH really wants to play, or is able to manage a serious game. Our answer was to abandon the software development and refine the plan yet again, and document it all for the people who will later be deciding what to do.

From all this, the main general lesson is that software design is not only about implementing a program in code, but also about drafting a careful plan that takes into account the practical concerns of the people who would be using it.

To others beginning on this path, I would quote Nietzche, who said: “Many are stubborn in pursuit of the path they have chosen. Few in pursuit of the goal." We've seen how a precise vision and the reduction of possibilities into a small, practical set, can bring about a worthy set of goals. If serious game development is the path you're walking, then you will also need to set reachable, measurable goals for yourself, and pursue those goals tenaciously if you want to get anywhere.

Personally, I am going to continue working with the KTUH management and licensees, along with other UH media organizations, to help them guide their technological efforts in the near future. Their priorities have been on mobile applications for the whole student body, but I don't intend to give up on the Pledge-a-Thon. I think serious games are here to stay, and it'll be fun for everyone involved. I'm looking forward to a meeting with the higher-ups at the end of the week.

No comments:

Post a Comment