Lenses in game design and curriculum design

Yesterday, my game design students completed an assignment that had three optional paths. One path involved reading Richard Bartle's excellent summary of the Hero's Journey (1, 2), which includes not just an overview of the concept but also helpful pointers about what students often get wrong. During the class meeting yesterday, a student gave a masterful presentation showing how the The Last of Us maps to the Hero's Journey. Before his presentation, I gave a short lecture about what I've learned about lenses. My point here was to get out in front of issues around the masculine and feminine roles of the Hero's Journey, and I think students got my point.

One of the examples I like to give in this kind of discussion is the ludology vs. narratology wars in game design, which were dying down right around the time I joined the games scholarship community. As I understand it, scholars like Henry Jenkins applied a literary analysis lens to games and, from there, concluded that games are stories. My criticism is that if you hold up any lens, the thing you look at looks like the lens. Using the lens of literary analysis to look at games will always make them look like stories, in the same way that using a Marxist lens to analyze games makes them look like class struggle, or a systems analysis lens makes them look like systems. I made a little joke here and pointed out that we need lenses—if I take mine off, the students turn blurry—but we have to recognize their strengths and weaknesses.

Knowing that my class is mostly Computer Science students, I pointed out that Computer Science curricula still suffer from the fact that many of the discipline's founders were mathematicians. They looked at this new idea through the lens of mathematics and determined that, of course, Computer Science is basically mathematics, and that mathematics is the way to understand this thing that we called "Computer Science." Why, I asked, do we require calculus—which we almost never use in practice—and not philosophy or psychology, which we use multiple times a day?

In truth, I meant it as more of a good-natured jab, but that observation has been haunting me the last 24 hours. The lens of mathematics has undoubtedly done good things for the discipline, as lenses can often do, but it also makes the subject look like the lens. My own department is in the "natural sciences" division of the College of Sciences and Humanities, and that forces the administration to look at us from a particular lens as well.

The old joke goes like this: Ask five Computer Scientists to define "Computer Science" and you get seven different answers. I see the rise of interest in both computer science and in programming for K-12 education, but there's also infighting between the two camps. I heard at a conference the other day, "Logic is the science of Computer Science!" Meanwhile, adults who go to coding bootcamps are taking the jobs that my graduates would otherwise go for: why hire someone green and immature when you can get someone hungry for a challenge and capable of "adulting"? Why, when I try to push the old lenses out of the way, do my colleagues desperately reach out and pull it back like a comfortable blanket on a cold day?

Mapping Introductory Game Design to CS2013

Regular readers may be wondering why I was looking at the learning objectives of CS2013, the ACM/IEEE recommendations for Computer Science curricula. The answer is that I am in the process of putting together a proposal for a new Introduction to Game Design elective in my department.

For the past several years, I have been teaching an Honors Colloquium on Game Design in the Fall semester. This has been very rewarding, but it is only made possible by internal funding from the Immersive Learning program and the good will of both the Honors College and the Computer Science Department. I believe it is time to formalize this class and bring it into my home department. This has a few implications, one being that I have to explain to my colleagues the relationship between Game Design and Computer Science. I suspect that they, like many outside the discipline, have never carefully considered the distinction between Game Design and Game Programming—the latter of which is an elective that I teach here. If I can get their approval for the course, it will allow me to build a more reliable pipeline of prepared students, which means we can explore more ambitious game development projects.

One of the ways I am planning to make the course appropriate as a departmental elective is to give it a one-semester programming prerequisite. While it's true that this will allow us to do a little programming in the game design course (such as in Twine), primarily I want to be able to use programming as a lens for considering system analysis. One of the real values of learning to program is that it teaches you to think through complex problems and serialize the steps of a solution. This is, essentially, writing the rules of a game. It's something that I've seen some of my past non-CS Honors students struggle with, and it's a skill that I see good programmers take for granted.

That's sufficient background for me to get back to the CS2013 mapping. Below is a list of the knowledge areas and topics that I see as being covered in an Introductory Game Design course that would be housed in a Department of Computer Science. With each topic, I have indicated whether the ACM/IEEE recommendations include minimum contact hours and at which tier.

• Human-Computer Interaction:
• HCI/Foundations [4 Core-Tier1 hours]
• HCI/Designing Interactions [4 Core-Tier2 hours]
• HCI/User-Centered Design and Testing [Elective]
• HCI/Collaboration and Communication [Elective]
• HCI/Design-Oriented HCI [Elective]
• Platform-Based Development:
• PBD/Introduction [Elective]
• Software Engineering:
• SE/Software Project Management [2 Core-Tier2 hours]
• Systems Fundamentals
• SF/State and State Machines [6 Core-Tier1 hours]
• Social Issues and Professional Practice
• SP/Professional Ethics [2 Core-Tier1 hours, 2 Core-Tier2 hours]
• SP/Intellectual Property [2 Core-Tier1 hours]
• SP/Professional Communication [1 Core-Tier1 hour]

For most of these, the course could cover all the core hours. For SE/Software Project Management, which I wrote about last week, team-based projects in introductory game design could hit the objectives as well as anything else, despite the products being analog rather than digital. The only place where the proposed course would clearly not fully satisfy the recommendations is SF/State and State Machines. These provide useful tools for describing the behavior of games, but we would not use a rigorous form of them and probably not spend more than an hour on their explicit treatment. It may be worth noting that some past offerings of my game design class provided an optional exercise with the formal design tool Machinations, but no one ever took me up on that.

It may be worth noting that all the core hours of those objectives above are covered elsewhere in the curriculum, although not all in required courses. HCI/Designing Interactions topic is only met in the HCI elective course, and this deficiency was noted in my department's recently-written self-study. The SE topic is ostensibly covered in the senior capstone, and the SP in our required one credit-hour professionalism class. However, I think it's worth repeating aphorism that it doesn't matter what we cover in the curriculum: it matters what our students uncover.

Of course, introductory game design primarily is teaching game design. This mapping exercise is to help me frame this work for any potential skeptics in the department. The result of this exercise belongs in the Course Rationale portion of the master syllabus. My next step is to define the learning objectives and assessments for the course proposal, which defines more clearly what the course is about. Here, I can focus more on fundamental principles of design, which I was disappointed to see are not directly addressed in CS2013. 

Questioning the value of CS2013

I recently had cause to re-read the ACM/IEEE CS2013 curriculum recommendations. This document is created by a large committee of content experts to provide guidance to Computer Science undergraduate programs. On one hand, it's a useful articulation of the body of knowledge that constitutes "Computer Science". On the other hand, well, let's take a closer look.

The CS2013 document breaks down Computer Science into knowledge areas such as Discrete Structures, Human-Computer Interaction, Operating Systems, and Software Engineering. Within the Software Engineering (SE) topic is a section called SE/Software Project Management. The section contains "2 core Tier2 hours", which means there are two recommended minimum contact hours on the topic, and they should be in a non-introductory course. For those who don't know the higher education jargon, "contact hours" means "students and faculty together in a formal meeting" such as a lecture. According to US financial aid legislation, and therefore according to practically every domestic institution of higher education, a student is expected to engage in two additional effort hours for each contact hour. For example, a student is expected to read, study, or work on homework for two hours for each one-hour lecture.

The core topics contained within SE/Software Project Management are as follows:

• Team participation
• Team processes including responsibilities for tasks, meeting structure, and work schedule
• Roles and responsibilities in a software team
• Team conflict resolution
• Risks associated with virtual teams (communication, perception, structure)
• Effort Estimation (at the personal level)
• Risk (cross reference IAS/Secure Software Engineering)
• The role of risk in the lifecycle
• Risk categories including security, safety, market, financial, technology, people, quality, structure and process

That's a lot of topics to cover in two hours of lecture and four hours of studying, but I could see it being all combined into a breakneck chapter of a Software Engineering textbook. Note that there are additional elective topics within SE/Software Project Management, but we won't consider those for this discussion.

Part of the ostensible value of CS2013 is that it doesn't just provide a topic list for each section of a knowledge area: it also provides learning outcomes. These are classified in a system inspired by Bloom's Taxonomy of the Cognitive Domain, so each outcome can be at the level of Familiarity, Usage, or Assessment. These are defined on page 34 of CS2013, and we can summarize them as basic awareness, ability to deploy knowledge concretely, and being able to consider from multiple viewpoints—as one would infer from the nomenclature. These, then, are the learning outcomes for SE/Software Project Management, as listed on page 177 of CS2013:

1. Discuss common behaviors that contribute to the effective functioning of a team. [Familiarity] 
2. Create and follow an agenda for a team meeting. [Usage]
3. Identify and justify necessary roles in a software development team. [Usage]
4. Understand the sources, hazards, and potential benefits of team conflict. [Usage]
5. Apply a conflict resolution strategy in a team setting. [Usage]
6. Use an ad hoc method to estimate software development effort (e.g., time) and compare to actual effort required. [Usage]
7. List several examples of software risks. [Familiarity]
8. Describe the impact of risk in a software development lifecycle. [Familiarity]
9. Describe different categories of risk in software systems. [Familiarity]

It's pretty clear to me that it's impossible to meet those nine objectives in two contact hours and four out-of-class work hours. Even if we assume that each student is perfectly capable of independent learning and studying, the time required to make any meaningful knowledge about these items is certainly greater than the recommended hours. I recognize that I am making assertions here and not arguments. In an earlier draft of this post, I tried a more rigorous argument, but I realized that a true skeptic could always counterclaim that they could meet these goals within the timeline. The real difference would not be the time required but our mutually exclusive definition of what it means to meet a learning objective.

It seems to me, then, that there are only two ways this could be approved by a committee. The first is that the committee has no functional understanding of contemporary learning theory. If that were the case, then why should anyone take their recommendations for curricula seriously? The second option is negligence, that the committee as a whole knew better, but they did not verify whether their recommendations and the learning objectives actually align. If that's the case, then why should anyone take their recommendations seriously?

Two Paths to Systematizing Introductory Game Design Coursework

I have a decision to make, and there are two paths I can see before me. Seems like a good opportunity for a short blog post to lay out some arguments for each.

I have been teaching game design for several years thanks to the generosity of the university's Immersive Learning program. They have provided the funding that has allowed me to teach an honors colloquium on Game Design through Ball State's Honors College. This gets me a somewhat captive audience, since each student has to complete six credit-hours of colloquia to graduate, and the students tend to be high achievers. I wouldn't mind continuing this line of work indefinitely, but it relies upon both internal funding and political goodwill from many different areas. Briefly, it is a fragile plan, and I've been thinking especially the last two years about how to systematize this work.

The university recently announced its call for 2019-2020 Creative Teaching Proposals, and this got my wheels turning about whether this program would be appropriate to bootstrap my revisions. The proposals are not due until the end of February, but the break between semesters is the best time for me to get my thoughts and writings together.

The first path I am considering is to take my Honors Colloquium on Serious Game Design and make it into a low-level elective for the Computer Science department. Specifically, I am thinking of making CS120 (Computer Science 1) its only prerequisite, which would mean that each student would have some expected level of computing literacy. This would enable interesting perspectives on game design from a systems approach, including potentially formal modeling of game systems (e.g. state machines or Machinations), introductions to end-user games programming environments such as Construct, and important metaphorical understanding of rulebooks as programs for human execution. Also, I suspect such a course could drive increased enrollments in CS120, which I think is good for everyone: more people learning fundamentals of Computer Science can only be good, whether or not they choose to continue into a degree program in Computer Science. One of the changes that would be required in transitioning my existing course is that I would have to go from an Honors College-imposed cap of 15 students to a more likely cap of 30-ish. This is actually a significant change in the course, including a switch away from individual projects toward team projects.

The disadvantage of this approach is that, if the course is as popular as I imagine it would be, I would not be able to teach enough sections of it. I am the only member of my department who is engaged in games-related research, and I do not expect other tenure-track faculty to be interested in picking this up. We do have a vibrant collection of adjunct faculty who I think could do a good job with this course, or even local community members who might be interested in adjuncting such a course, but they would need significant support. This is where the Creative Teaching Grant proposal comes in: I could propose to create a teacher's guide to go with the course, a primer for interested but untrained people to be able to effectively teach introductory game design.

The alternative path is inspired by some research and conversations I've done around how other people in my shoes have solved this problem: Computer Science faculty with an interest in both game design and game programming, at a university without an existing program in game design. I've seen some people combine these two together into a sequence specifically for CS majors. That is, rather than have two separate courses on game design and game programming (which would be part of the path described above), they roll the two together into a two-course sequence on Game Design and Development. There's a real elegance to this, as concepts of design can be discussed alongside the technical skills required to build such systems. It also addresses a problem that I have had with the Game Programming class, which is that some of the student-designed projects are understandably terrible since we don't spend any class time on game design. The clear disadvantage of this approach is that it restricts participation to those students who have already completed five CS courses as prerequisites. I do believe that a Computer Scientist can design good games, but I also believe that a multidisciplinary approach will almost always yield better games.

Right now, I am leaning heavily toward the first path. Even if the course proves very popular but we only offer one section a year taught by me, that is still a systematization of what is now ad hoc. I suspect that CS majors and minors who plan to take Game Programming would take this hypothetical Introduction to Game Design course anyway, so that could still yield improvements in the Game Programming teams' projects.

Either of these paths I think could help lead toward another direction I have been considering taking my work. The past several years, again thanks to the Immersive Learning Program, I have been able to engage in some high-impact projects with undergraduate student teams. I've written extensively about these here on the blog, so I won't bother saying too much more about these now. However, I have been thinking about the value of having more, lower-stakes projects.

This was inspired in part by this year's recruiting of the 2019 Spring Studio team. This was the first time that I advertised more broadly across campus in addition to talking to my colleagues in complementary departments. This wasn't a very aggressive recruiting, just a few campus-wide emails sent by the Immersive Learning office. However, it resulted in many more applicants than I have had in the past—38 applicants for roughly 11 slots were submitted by the first deadline. From these applications, I had to craft what I hope to be the team with the best chance of success. This means that there were at least 27 other students who were excited and eager to join the group, but they won't have the opportunity. One way to provide opportunities for these students is to offer more low-stakes projects, where several multidisciplinary student teams can work together on passion projects rather than having a smaller team with close faculty mentoring working on a community-engaged project. In fact, we already have a curricular structure in place for this in CS490: Software Production Studio. This is the course that I created as a framework for the high-stakes projects, but I intentionally kept it broadly-defined to allow for other project structures as well. In a sense, all that would be needed is the right kind of recruiting and the department's blessing to offer a section of CS490 in the coming academic years that would allow for student teams to form and pursue their interests. This fits with one of my general philosophies, which is that we should incentivize, legitimize, and give credit for the immense amount of work that some students are willing to put into creating original games.

Thanks for reading. As always, let me know in the comments if you have feedback on any of these ideas.