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.