Archive for May, 2010

Search for game design advice brings me back to Tim Ryan

May 26, 2010

In the Spring, I team-taught a colloquium on history education game design with my respected colleague Ronald Morris, a professor in the History Department at Ball State. Regular readers may have noticed that I have not written much about this experience. I’ll get to it. Or not.

This colloquium explored the design of a game for Indiana 4th grade students. The production of a high-quality educational game remains Ron’s main focus in the project, while I am also specifically interested in exploring how students can learn directly from the mechanics of the game as opposed to the layer of story atop the mechanics. My interest in this question goes back several years to when I first read Raph Koster‘s Theory of Fun for Game Design, which is the first book I recommend to anyone who expresses interest in Fun. (That’s “Fun” with a big “F”, by which I mean the serious study of fun.)

The students in the colloquium created some compelling physical prototypes in the first half of the semester, and the goal was to create a high-quality design document from these experiences. Unfortunately, the final document does not meet production standards. We are still planning to build a game, and specifically, my Game Programming students will be building it in the Fall. The task of finalizing the design document therefore falls in my lap, and it’s not unwelcome.

In the colloquium, we used Wave to start the document, but performance was not adequate for our purposes, and so the document moved to Google Docs. I do like docs for quick and dirty documents, but years of wysiwym editing in LaTeX have left me with very little patience for wysiayg editors. A lot of the advice I encountered online recommended the adoption of wikis for design documents, and so my first step was to import the existing Docs file into Google Sites, a general-purpose Web site creation utility that has convenient wiki-like features. The two main advantages of Sites are that (1) I already know it well and (2) I don’t have to configure a wiki server.

I quickly found, however, that the format of the original document was not empowering my creativity. I felt like I was mechanically creating pages but with no real end in sight. I decided to invest an afternoon to find the best practices for design document creation and management, beyond the technology and into the realm of content.

Suffice it to say that you can find a lot of advice about game design on the Internet. I bounced from site to site and eventually ended up on’s General Game Design page. There, I downloaded some templates and started tinkering. The one that stood out happened to be based on Tim Ryan’s series of articles at GamaSutra, the first on proposal and concept documents and the second on functional and technical specifications. If you’ve read this far in hopes of finding my links to the best advice I’ve found, and the title of this post didn’t give it away, there you go.

The funny thing about these articles is that these are the same ones I read four years ago in my first foray into serious game development (serious development, that is, not serious games at that point). The articles themselves are from 1999, and a lot has changed since then in both the games industry and the academic treatment of games. I’ve read many books on game design and design theory since then, and Ryan’s articles still stand out as having just the right balance of practical advice and theoretical soundness. They have also helped me identify my Summer path more clearly:

  1. Write a concept document and share it with my stakeholders, who are Ron and a few key undergraduates whom I will be trusting with high-responsibility tasks in Fall. The concept document is essentially complete and I am awaiting feedback.
  2. Write a functional specification.
  3. Write a technical specification, while concurrently developing the milestone schedule.
  4. If necessary, develop any core software architecture that will be required before the Fall semester begins. After all, I will be managing a team comprised entirely of novice developers.

That leads me to my next great quandary: how do I manage a team of 30 novices on a critical project? But that’s a topic for another day.


Writing, Scholarship, and Software

May 22, 2010

My Google I/O travelling companion was Brian McNely, professor of Rhetoric and Writing in the English Department at Ball State. He told me a bit about his personal daily scholarly regiment: he reads at least 50 pages a day and writes at least 750 words, the latter supported by I respect this endeavor, knowing how, as a professional academic in a university, there are other forces that can drain the time and focus that should be devoted to academic pursuits. Brian clearly enjoys his scholarship, even when he has to make sacrifices to meet his goals.

This made me think about my own scholarship and personal goals. There is a great contrast between my feelings between Fall and Spring of the last academic year. In Fall, I felt productive and I also felt that I was learning. In much of the Spring, I was frustrated. (Interestingly, as I look back at the past semester’s writing to pull out those links, there is more positive ideas there than I remembered there being. That’s encouraging. I suppose I need to spend more time reading my own blog.) One of the major differences between the two semesters was that in the Fall, I was inventing: working on Confluence was a great experience, as I’ve said before. I know that I love the process of inventing software systems, and so I have been actively seeking out opportunities to leverage this as both personal fulfillment and scholarship. This Summer, in fact, my time should be nicely split between some interesting Wave and game projects. I embrace Boyer’s model of scholarship, and pertinent here is the scholarship of application.

When I try to tie these ideas together with Brian’s 50/750 regiment, I hit a contradiction. Clearly, as a professional scholar, I could just adopt 50/750 myself, and this would undoubtedly improve my scholarship. However, I would also like to have time for invention, for creating software. Unfortunately, you cannot measure productivity in software, so how does one set personal goals for invention?

Last semester, I set aside time Friday afternoons for writing on this blog, and I am happy with the results. I feel like I have been able to crystallize several concepts by writing them, and it has given me an outlet to explore and ripen new ideas. There were only a few times in the semester that I was unable to set time aside. However, even in reflecting on this writing, it was done in relatively small spurts of about an hour. That is, it was done in what Paul Graham calls the manager’s schedule. I know, from years of development experience and many semesters of frustration, that if I want to successfully build a system, I need to do it on the maker’s schedule. (Incidentally, adopting inbox zero has significantly improved my ability to occasionally adopt the maker’s schedule during the academic year.)

I don’t have a plan, then, for how to deal with this contradiction of wanting measurable goals for something that brilliant designers call unmeasurable. I have developed some experience using Scrum and MSF in leading teams, and I could always adopt these for myself, except that I am not sure that “maintain development momentum” or “mitigate one high-impact risk” are goals that I can meet. One one hand, these managerial techniques were designed for teams, and on the other, neither really is a measurement of productivity. Of these two, the idea of measuring momentum via Scrum or similar techniques is somewhat appealing, partially because it could hone my capacity for estimating time requirements, and in the end, time may be the only invariant I can use to commit to invention.

No conclusions, but I’m open to ideas.

On People

May 19, 2010

I’m at Google I/O 2010 right now and having a good time. The best story so far, though, is from the flight out here.

A passenger comments to the flight attendant, “It must be hard to smile and be nice to people all the time.”

The flight attendant shrugs and responds, “People are good.”

An inspiring philosophical lesson at 30,000 feet.

The Story of Sasha

May 14, 2010

This past semester, I have served as an external evaluator for a high school student’s independent study project, the creation of a graphic novel called The Story of Sasha. I got into this role almost accidentally: I met a girl at a friend’s 40th birthday party, and somehow we got to talking about comics. Turns out “Anna” is a senior and needed an evaluator, so even though it’s a bit beyond my scholarly expertise, I agreed to it.

The student created a blog at, and I encourage you to check it out. I have shared it with some professional artists and designers, and they all agree that it’s phenomenal for a high school project.

Although comics are not my area of expertise, I am a longtime fan of the medium and I’ve done a bit of light reading on the form, the most relevant of which is Understanding Comics. (See also Scott McCloud’s excellent TED talk on the topic.) During the Q&A after the presentation, I got the feeling that most of the crowd was not actually interested in deep discussion, so I suppose I’ll have to schedule a coffee meeting with Anna to dive into such topics. (It is worth noting that her writing and art instructors, who were giving her the independent study credits, did not know anything about graphic novels, which I think left me as the “expert” in the room. Not the first time, but never in this subject!)

Two things struck me about the project that I want to write about here: the project-as-capstone and the presentation itself. I’ll start with the latter, since quite briefly, it was excellent. No bullet points, no gratuitous animations. Anna clearly has a good sense of style and design, even if she was not aware of their application to effective presentation delivery. She was well-prepared, speaking confidently from her knowledge of the topic, clearly showing adequate preparation in terms of both the content and the delivery. I found myself wishing that my Computer Science majors could have been there to see a truly excellent presentation. As I’ve written about before, I fear that many of our university students actually get worse at presentations during their time in higher education due to both exposure to and indoctrination in ineffective techniques.

It became evident during Anna’s presentation that the project itself was a capstone in the fullest sense. She  cited her art, writing, and biology classes as being explicitly influential on the project. When I asked for elaboration, she mention also math, history, and other science classes as being places where she was able to both explore and expand on her work. This is a phenomenal example of the power of intrinsic motivation and cross-cutting projects. It’s not that her school is any less bureaucratic than any other, but she made the opportunity to explore The Story of Sasha wherever she could. I get the feeling that within the University, there may be less opportunity for this: students get loaded with “other peoples’ work” rather than being able to bring their unique interests and background into cross-cutting experiences. (Originally wrote “learning experiences”, which is redundant, since all experiences are learning experiences.)

I look forward to tracking Anna’s progress as she moves on to art school and from there, to a successful career.

Reflection on 345/545

May 6, 2010

It’s the end of the semester, and today were the final presentations in the HCI class. I am taking this opportunity to reflect upon this teaching experience, an attempt to articulate some of the joys and frustrations of this semester.

  • I am disappointed that none of the projects have been released on the Market. I suppose it’s a good thing for the students that I didn’t make this a requirement to get an A. I do not think that any of the teams even seriously looked into the distribution requirements, which makes me sad, because there are many interesting elements here, including application permissions, application signing, certificate management, and dealing with feedback from unknown and unexpected users.
  • I knew going into the semester that the vast majority of the students would not be able to adequately scope their projects, and so agility was built into the expectations. However, I did not fully account for the negative relationship between estimation inexperience and team size.
  • I suspect the results would have been better overall with smaller team sizes: this would have increased both accountability as well as motivation, since individuals would be needed. I tried to keep the number of teams relatively small so that I could keep track of each team and provide directed feedback. In retrospect, seven teams were too many for me keep track of anyway, and so having more teams would not have been a significant drain on my time. It would have complicated in-class presentations, but I suspect this would not have brought as much difficulty as benefit. (Many wise students suggested smaller team sizes in their reflections.)
  • The risk matrices were generally useful, but the MSF Team Model was not. From personal experience and the stories told in students’ reflections, it is clear that most students did not understand the meaning of the roles, and I suspect the “role” system caused more difficulty than was necessary. Students with no prior experience in significant team development projects have no useful mental framework for roles, and so, in retrospect, I should have predicted that they wouldn’t appreciate what the roles meant. Point in case: “testing” doesn’t mean anything to a student who has never tested anything. (The fact that students can go through the foundations courses and never discuss testing is a problem, and it’s being addressed by the introduction of 222.)
  • The teams suffered from communication breakdowns and uncertainty about tasks at a fine grain. The risks of the risk matrices were slightly too abstract for the students with no prior team or large-scale development experience to handle. I suspect one of the following would be preferable: (1) more rigorous management of the risk matrices, including more directed feedback from me about the appropriateness of risk articulation; or (2) a more quantitative, task-oriented project management technique such as the product backlogs of Scrum or the use of issue tracking software.
  • Having community partners was important, especially to the best students. Many of the students clearly learned important lessons from these interactions. Some of them were lessons I was also trying to convey, but it was much more effective to work with the ignore-the-professor-in-favor-of-outsiders phenomenon than it was to fight against it!
  • The reflections were worthwhile except that I needed to set stricter deadlines. I am not a fan of deadlines for such work, but they are needed for my own sanity, not for the students. Because I did not set explicit deadlines, I have been inundated by “reflections” the last two days. The astute reader can guess the quality of reflections that are being sent in right before the end of the semester. Hint: they’re not the ones I really enjoy reading, and I think they primarily why I have been so blue today.
  • Expanding on the previous point, it was very rewarding to read the reflections of the responsible students. By responding to their metacognitive essays, I felt like I was having a direct and positive impact on their individual learning, a great win for a constructivist. I realize that there are two potential complications in this: (1) there is a chance that better rhetoric is being rewarded over authentic-but-inarticulate reflections, and (2) a student who is savvy with emotional intelligence could manipulate me through these essays. I think either are acceptable costs. Regarding the first, writing is an extremely important skill that students should have anyway, and regarding the second, I think the best of the students are more honest than that.
  • Expanding on this point again, it was frustrating that some students still did not get the point of the reflections, or perhaps what metacognition is about. I am concerned that perhaps I did not articulate the requirements clearly enough, but with targeted individual responses, I’m not sure what else I could do aside from assigning them to do exercises out of Pragmatic Thinking & Learning.

There are some things I would change if I could do this course again, but mostly, I wish I could take all of my “A” students and with me and do some really great things. Unfortunately, the curriculum doesn’t work this way: this is a terminal class, and I have to let go. (Another reason I’m a little blue today.)

For any of the negative aspects of the course, I do believe that the students really did meet the learning objectives of the course. By and large, I think they understand better the role of humans in software development, both as users and as collaborators. For those who are not graduating (who are most), I look forward to watching them move through the curriculum and seeing if the course really had a measurable effect, especially as they take the capstone course— projects of which are often characterized by team trouble and bad user-interfaces!

Also, the design of the course met the primary constraint: the students were able to hit the ground running with a mobile application development project of their own design, while I was free to enjoy the birth and first few months with my second son. I wouldn’t want to do this every semester, but this one worked out fine.

Advice to future students from current students

May 6, 2010

It’s the end of the Fall semester, and I am a little bummed. More on that later. For now, I will amuse myself by sharing with you, dear reader, the advice that my students are leaving to future students. Specifically, this came from an anonymous survey in my HCI class. The class was project oriented, 15 weeks on a mobile phone application. In the survey, I asked for “Advice to Future Students,” and the students were told that any responses would be shared.

I will be linking my 315 and 222 students here in the Fall.

The only advice that I can give. Any course taken by Dr Gestwicki is very immersive and practical. If you want to fully utilize his course, dont take any other course or atleast dont burden yourself with too many courses other than the required minimum. I personally felt that I had only used 10% of him this semester and still I found it very enjoyable and wonderful. So imagine how I would feel, if I had utilized him to the full. You can make a living out of any of his courses. Attend all of is meeting( I wouldnt say that as classes) and always dont hesitate to ask him any doubts, even if they are silly. Go and knock his office doors often :)

Tackle the bigger problems first, making about pages, and splash screens is trivial compared to the main functionality of your program.

Consider your scope very very carefully. Consider how you are going to meet that scope. Consider what you want to do and make sure you refine that as much as possible. If you have someone that’s taken software engineering before have them help you figure out a development process that will work for your team. Try and do everything you can to involve all the team members.

start your project eariler,
go to developer guide, if you have some problems with andorid coding
communicate your team more than once per week

My advice would be to always get your work done in a timely manner. This, of course, does not pertain to the specific class alone. Nobody likes the person that never does their work. Don’t be that person, is my advice.

Read your documents and any extra material that you think you may need or even peaks your interest. In this field its always good to stay up to date on the latest information as well as branching out and learning new languages, ideas, and methods for accomplishing a goal.

Also, get to know people a bit before you decide to work with them. Just because you are friends with someone doesn’t mean you know their work ethic or their abilities.

Read before start

A good group makes all the difference, and bigger isn’t always better. Having a good tight group of 4 or so people will keep you organized and agile.

Let me begin with an overarching caveat: when you take a class like this, the majority of your work – perhaps 90% or more – will be dealing with other people. You will pick your project, the difficulty level, and almost every aspect of how it should get done. Furthermore, everyone in a 300/500 level CS course should be able to write code and solve problems. Skill is not the problem. Getting people to do the work is.

Take the hiring phase of this course seriously, even though you may have little time/resources to do so. Once you’ve formed a team, get to know the PEOPLE on your team ASAP, not just WHAT they can supposedly do. Find out if they have a lot of other courses this semester. Find out if their other courses are difficult or easy. Find out whether they will consider this a blow-off class or not. If you find yourself among a team of slackers, leave the team or fire those people immediately. Otherwise, you will probably ruin what could have been a fantastic learning experience in this class.

Additionally, find out how your teammates think. This is especially important (in my experience) if your team includes students from other parts of the globe; not everyone thinks like you. The words ‘testing,’ ‘development,’ ‘design,’ etc. can mean slightly/very different things depending on your background. In fact, even if your team consists of just one nationality, your teammates’ past project experiences may foster inconsistent team-wide expectations. Create a terms list for your team ASAP defining project-related terminology. Make sure everyone is on the same page.

Lastly, make sure you adhere to the following three rules when it comes to working as part of a team:
1. Communicate early.
2. Communicate often.
3. See rules 1, 2, and 3.

The internet will lie to you, only incorporate those ideas and algorithms into your project that you understand.
It is best to address the problem of an unproductive team member early rather than late and to do this in as creative and friendly of a way as possible.
Satisfactory results are not always correct results. Test at the margins; the beginning and end of files, the extremes of input – large and small, and test your project with both an expert and a novice.