Course Information

CSCI 181G PO is an upper-division elective in game engine development for real-time interactive graphical simulations. We will cover text-based, 2D, and 3D games as well as game engine architecture and tool development.

The grading scheme for this course is split between in-class labs and discussion and out-of-class group work.

Aim and Objectives

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.

Course Materials

All required course materials are available on the course webpage.

Course discussions will take place on Slack in the #csci-181g-po channel.

Lectures and Labs

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.

Each week of lectures is accompanied by a brief asynchronous lab assignment, credit for which is granted through a check-in with the professor by the beginning of the following week's class. I'll be available for checkins after each class period for about half an hour.

Every week will feature a lab assignment, and you must complete 8 for full credit in the course. Labs may be completed in your engine groups or not. It is my hope that lab assignments parlay neatly into feature points for your game engines.

Tech Talks

Peer instruction is shown to be effective both for the teachers and the learners. Accordingly, weeks without playtests will feature a 15-minute "tech talk" and guided exercise by a pair or 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!

  1. How to make games in the Godot game engine
  2. How to make games in the Unity game engine
  3. How to make games in the Unreal game engine
  4. Cool tricks for using Rust effectively
  5. How to make games in the rg3d engine
  6. How to make games in the bevy engine
  7. How to make games in the Amethyst engine
  8. Comparing how different UI libraries work
  9. How to make 3D models and animations
  10. Cool things we can do with graphics shaders

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

Course Units

This course is split into two units: 2D games and 3D games. During each unit, your team will build two games on the same engine. This is a project-based course emphasizing teamwork; you'll be on a different team in each unit.

Grading for a unit is based on the number of designated features implemented across its games, with penalties for incomplete turn-ins or due to problems in the one-on-one check-ins. Your team and I will decide together what constitute features and whether they have been achieved. I will meet every team within two weeks of the start of the class and then again in the week 10–week 12 period to discuss features.

Completing a Unit

Completing a unit means completing all of its games (the text-based unit just needs one game; the other units need two games each). Completing a game means sending me the following:

  • The code of the game, ready for me to cargo run --release on my linux machine. If it doesn't run I can't grade it!
  • A trailer for your game: a 1-2 minute edited video showing off the features you hit.
  • A postmortem for your game: 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?).

Each incomplete turn-in will cause a letter grade reduction for the unit.

Each team member will also need to schedule an independent meeting with me to talk about the engine and games and their own work.

Unit 1 Features

Your feature count is the union of your feature count across your two games. Both games must share at least three features (or face a penalty of 1 letter grade).

Grade assignment:

Three or fewer features
Four features
Five features
Six features

These are just suggestions for possible features, but you are encouraged to come up with your own ideas and ask me if they'd be suitable!

  • Four different graphical building blocks (e.g. texture-blitting, polygons, filled polygons, text)
  • Simulate some real-world system (e.g. erosion, fluid dynamics, population dynamics, …)
  • Multiple "windows" or views on the world (e.g. split screen play, mirrors, portals, …)
  • Fancy collision (e.g. slopes, character and terrain shapes that aren't AABB)
  • Rigidbody physics, joints, …
  • Combined sprite and paperdoll animation (animations must be defined in data, not hard coded)
  • In-engine cutscenes (scripted sequences)
  • Quad-per-sprite rendering instead of framebuffer graphics
  • Efficient use of image resources, e.g. tilesheets, sprite atlases
  • Rewinding/undo
  • Save/load progress
  • Loading game rules or world from data files
  • In-engine game editing tools (e.g. level editors)
  • Sub-games/turn taking/menus/modal UI
  • Infinite tile map or other procedural content generation
  • A million objects live at once
  • Destructible/modifiable terrain
  • Complex level layout/reactive spawning/time synchronized gameplay
  • Music/sfx, situational/responsive music; music should loop well. Consider the rodio or CPAL crates.
  • Networking
  • Streaming loading/unloading of assets
  • Spatial audio, footfalls, and 3D audio sources, tied into gameplay
  • AI characters that communicate and/or cooperate and/or have other complex behaviors
  • Gameplay-relevant shadows and lighting

If you'd like to propose an additional feature, let me know.

Your Unit 1 games are both due before the Tuesday of week 8. If you don't have a game mostly done by week 5, you'll need to meet with me so we can catch you up.

Unit 2 Features

Your feature count is the union of your feature count in the two games. Both games must share at least three features; there must be a clear game/engine split.

Grade assignment:

Three or fewer features
Four features
Five features
Six features


  • Collision beyond AABBs, for example GJK collision or sphere-swept-volume collisions
  • Particle system effects
  • Fancy math—use rotors + bivectors for angular orientation and velocity/momentum
  • Fancy physics—rigidbodies, cloth, joints, physical particles, …
  • Mixed 2D/3D with interesting camera effects
  • Multiple graphics pipelines, off-screen render targets, reflections, or related effects
  • Advanced animation systems, e.g.:
    • Blend trees, additive blending, etc
    • Inverse kinematics
    • Procedural animation
  • Shaders that relate to gameplay, e.g. to show characters obscured by walls
  • Using shaders written in rust-gpu
  • Decals or related effects
  • Voxels
  • Infinite Level of Detail
  • Supporting 2D games from the previous unit using this engine OR reuse substantial code from 2D engine
  • Potentially any 2D game feature listed above

If you'd like to propose an additional feature, let me know.

Your Unit 2 games are due before the scheduled final exam. If you don't have a game mostly done by week 13, you'll need to meet with me so we can catch you up.

Grade Breakdown

Tech Talk
Labs (8 out of 15)
Unit Projects (2)
Demo Day

Course Policies

Special Needs and Religious Observance

Pomona students seeking academic accommodations should contact the Dean of Students Office at 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:

Julia Easley
Jill Hawthorne
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.

Academic Honesty

Learning any new programming language is challenging. I encourage you to help each other learn the language (in person and on Slack) 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 Slack
  • 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).

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.


Because the pace of the course is rapid and work is done in groups, I don't recommend asking for deadline extensions—better to turn in what you have on time than stack up work and risk an untenable situation.

Missed deadlines will result in no credit for the assignment in question.

Accommodations for extenuating circumstances such as family emergencies or major illness are a separate issue and can be handled on a case-by-case basis.

Teamwork Issues

Grades for each unit are assigned based on the turn-in and on individual check-ins at the end of the unit. Hopefully, by the time the unit is concluded, every member of each team should be very familiar with the code on which they worked and be able to explain it to me in detail. This only serves as a last-resort check against imbalanced teamwork, unfortunately.

Far better would be for teams that notice an imbalance forming to try and resolve it, getting in touch with me if necessary to help figure out a way to mitigate the issue before it gets too severe. I am happy to help teams work through issues like these throughout the semester, and I promise to check in about this with each team before the halfway point of units 1 and 2.

Teamwork Tips:

  • Use version control. Git and either GitHub or gitlab are good options
  • Implementing unrelated features? Maybe implement a separate "game" which just has/uses the one feature, then push that up into the engine as you go!
  • Consider finding ways to move as much of the skeleton as makes sense into your engine so you don’t have to copy it out for each new game.
  • If you want your games to each be single file, then a unit1 crate with a src/bin folder is a good way to do it. If you want your games to have multiple modules, it’s tidier to have a cargo workspace with your library crate and then a separate binary crate for each game. See the cargo book for details.