Syllabus

After taking this course, students should be able to:

1. Evaluate game engines based on criteria like performance, ease of use, and flexibility;
2. Create their own game engines from scratch;
3. Build games using game engines;
4. Analyze existing games to make educated guesses at how they were made; and
5. Make targeted measurements of software performance issues, grounded in an understanding of computer hardware.

You must have taken the introductory and intermediate CS curriculum at either Pomona or HMC. Being handy with Rust is a plus but not required; confidence implementing algorithms from specifications and some comfort at the command line are more important.

All required course materials are available on the course webpage.

Course discussions will take place on Zulip.

Lecture attendance is strongly encouraged but not required. This is important time for teams to share notes with each other and playtest each others' games, as well as to work together on labs.

Each week of the first half of the semester comes with a brief practice lab assignment, credit for which is granted through my office hours.

The second half becomes more of a workshop, where we'll have group meetings and discussions of progress and challenges in game development.

Peer instruction is shown to be effective both for the teachers and the learners. Accordingly, most weeks will feature a 15-minute "tech talk" and guided exercise by a triple of students on one of the following topics (or another topic if students are interested). I am happy to work with students to come up with good guided exercises!

Here are some examples of tech talks, but feel free to propose your own:

1. How to make games in some game engine we haven't seen yet
2. Cool tricks for using Rust effectively
3. Comparing how different UI libraries work
4. Cool rendering and drawing tricks
5. Accessibility in games
6. Sound design in games

Student groups must meet with me one week before their tech talk for comments.

During the second half of the semester, your team will build three games on the same game engine. This is a project-based course emphasizing teamwork.

Grading will be based on completeness and features. As a team, each project group and I will come to an agreement on what constitutes an adequate feature set, and revisit that agreement halfway through the unit.

Completion means having a playable demonstration of three games, and sending me the following during the course of the project:

• In the first week of the project:
  • A feature plan and description of your games
• At the time of the playtest:
  • The code of the engine and games, ready for me to cargo run --release on my linux machine. If it doesn't run, I can't grade it!
  • A brief summary of how the games changed (or didn't) since the original plan, and the main things you learned so far
• At the end of the semester:
  • The code of the engine and games
  • A trailer for your games: a 1-2 minute edited video showing off the features you hit.
  • A postmortem for your games: What features you hit, a brief description of the game, what went well, what went poorly, what you learned from playtesting, what you learned from coding it up (e.g. for your second game, how easily could you reuse code meant for the first game?).

Playtesting is a vital part of game development. We'll have two playtest days throughout the semester, and you are responsible for turning in a short questionnaire at the end of the playtest:

1. What games did you play?
2. What's something you found surprising or cool in each game?
3. What's something you would want to improve in each game, if it were your own?
4. What, if anything, are you thinking of changing in your own game having seen it played by others?

If you can't attend playtest days in person, let me know ASAP and we can find an accommodation.

Tech Talk (and responses)

10%

Labs

40%

Projects

50%

These are all basically effort grades! If you can communicate to me what you tried and show that you've worked through some hard problems, you will be fine. We will talk more about these categories and expectations as we get closer to deadlines.

So, like, don't freak out if it's hard. It's good if it's hard and I am totally, 100% supportive of you struggling and improving. This class is a safe place to get wrong answers.

Pomona students seeking academic accommodations should contact the Dean of Students Office at mailto:disability@pomona.edu. You'll need to meet with them to discuss appropriate accommodations and provide them documentation as necessary; they'll contact me, and then you and I will find an appropriate accommodation. You will never need to reveal the reason for your accommodation to me.

Students from other colleges should contact their home college's disability coordinator for accommodations. The coordinators are:

CMC

Julia Easley

Pitzer

Jill Hawthorne

Scripps

Sonia de la Torre Iniguez

Harvey Mudd

Heidi Bird

It is my responsibility to ensure all students have equitable access to the course material, and it is your responsibility to ensure I know what accommodations are needed. I will never need to know the why of an accommodation, only what I can do to ensure your access to the material. Going through the coordinators is the optimal way to achieve this separation but I can also work with you directly if you come by office hours or email me to make an appointment.

Learning any new programming language is challenging. I encourage you to help each other learn the language (in person and on Zulip) and I also encourage you to discuss the lectures, readings, and other assignments.

However: all work in the course must be your own. As explained in the student handbook, this means that the work you turn in must represent only your own work (or your work with your direct teammates). It must not be based on help from others or information obtained from sources other than those approved by the instructor. Examples of acceptable sources of information include:

• Lectures and discussions in class
• Our readings
• Meetings with me
• Discussions on Canvas
• The Rust reference manual or other sources of documentation.

Examples of unacceptable sources of information include:

• Stack Overflow (except with respect to Rust language features)
• Quora
• Your classmates' code (except as outlined above).

One borderline case is stuff like copilot or ChatGPT. I recommend against using them, because they'll slow down your rate of learning Rust (I have a whole rant if you're curious). Instead, use compiler errors and cargo clippy to help you, alongside https://docs.rs.

You should never read or copy another student's solutions (code or otherwise), exchange files, or share your solutions with anyone else in the class until after everyone involved has turned in their work. If a discussion with another student or StackOverflow answer helped you find your answer, mention that in a comment. It's hard to tell the difference between uncredited help and plagiarism (because they're the same thing).

If any of this is unclear, please just ask me.

Failure to abide by these rules is considered plagiarism, and will result in severe penalties. The first offense typically results in failing the assignment and referral to the appropriate college office or committee—which may mean further consequences. See the CS Academic Honesty Policy and Pomona Academic Standards for further information. Please don't put anyone—me, you, or anyone else—in this unpleasant situation.

Projects in this class have due dates because we need to share our work for effective feedback from our peers. If a due date for deliverables are difficult to reach for any reason, reach out to me as soon as possible and we can find an accommodation.

Typically, labs are due on Sunday nights.

Grades for the project are assigned based on the turn-ins at the end of the project. Every week during the project section, we'll have a check-in with a private Canvas assignment for each student to post their experiences over the last week and plans for the next week, so we can try to catch teamwork issues quickly.

I am happy to help teams work through issues like these throughout the semester. Team based project work is new for many of you!