This is the website for CSCI 181G PO: Game Engine Programming. Course information is available in the syllabus.

Zoom meetings
here (you should have received the password in an email; if you don't have it, please ask me!)
Office hours
Wednesday 9–11 PST, Thursday 14:30–16:30 PST in the class Zoom
Contact me
On Slack (#csci-181g-po or direct message)
Other helpful channels
#rust, #text-editors
All due in check-ins


Announcements/Special Topics

Emergency Unit 3 Adjustments

Three adjustments since I miscounted the number of weeks in the semester and we didn't resolve the "how to get started" issues in week 9 when we started on Unit 3:

  1. You can use engine3d code if you want (be sure to download the latest version)
  2. Feature count grade thresholds all decreased by 1
  3. Tentative plan to move demo day to our finals slot, Monday May 10 7-10 PM Pacific; I'll commit on this one way or another within two days.

Remaining Labs Optional

The remaining labs are optional. You can do them if you want (and make up for previously missed labs) but you don’t have to. So if they’re relevant to your game project then do them or at least look at the setup, otherwise don’t sweat it.

Engines for Unit 3 Games

Your games this time around cannot use engine3d as their engine, and you must make your own engine from scratch. Consider doing something like an ECS (feature point!), or making the engine own the game object data (transform, which model, etc) and finding a different way to support arbitrary game rules. Looking at the engines we surveyed on 4/12 could be inspiring or you could go off in your own direction—an engine that only supports untextured 3D objects to simplify asset pipelines and glue code could be worth exploring, or that draws everything wireframed or something. You can do what you want! If you aren't sure, get in touch with me! It's okay to use external crates for collision math (ncollide, parry), audio (kira, rodio, cpal), input handling (even from engine3d is fine), UI, asset loading and pipelines (distill), etc; but not physics or rendering. If in doubt, ask!

Turning in Unit 2/3

Here's a checklist for turning in unit 2/3 games. All deliverables should be sent to me via Slack DM. Extensions are okay as long as you turn in something by the stated deadline.

  • [ ] Group Deliverables
    • [ ] Game code, minus the target/ directory (Due on deadline day)
    • [ ] Game trailer videos (1-2 minute edited videos showing off your features; due on deadline day)
    • [ ] A postmortem for your game (Due one day after deadline day):
      1. What features you hit
      2. A brief description of the game
      3. What went well, what went poorly
      4. What you learned from playtesting
      5. What you learned from coding it up (e.g. for your second game, how easily could you reuse code meant for the first game?).
  • [ ] Individual Deliverable (Due one day after deadline day)
    • [ ] Questionnaire:
      1. Of the games that you played from other teams, what feature seemed most interesting technically?
      2. Of the games that you played from other teams, what was the most inventive use of features that were not as technically interesting?
      3. In terms of your own team's games, what are you most proud of?
      4. In terms of working on your team's games, what was an aspect of the team work that was particularly effective?
      5. In terms of working on your team's games, what was an aspect of the team work that was particularly challenging?
      6. What would you personally do differently next time around?
      7. What would you like Prof. Osborn to know or do differently next time around?

Mid-Semester Check-In

Thanks for your notes on the mid-semester check-in! Here are what I've identified as some major themes:

  1. Students appreciate the open-ended nature of the course, and the labs can sometimes feed directly into project work (which was my goal!)
  2. The order of class topics makes some features easier to implement than others; combined with tough labs, this means there's not much time for working on the unit games many weeks (which was not my goal!)
  3. Class is long, and the second half is maybe too unstructured; labs need more context
  4. Slack is helpful but not sufficient, class website/lec notes aren't updated with that info so it's hard to track

So here are some things I'd like to try (and ask of you) starting in week 7:

  1. Please read the notes before class so I don't have to read through them as much and can spend more time giving directed guidance on the lab. This is especially important for week 7, since there's a lot of information on CPU architecture that I want everyone to familiarize themselves with before we start.
  2. Between the before-class time and the initial breakout session, please prepare at least two questions each about the current week and/or previous week's topics.
  3. I'll try to drive the class from your questions as much as possible for the first hour or so, then we'll have a break.
  4. The second hour will be a fuller exploration of the lab setup, and I'll also provide a "checklist" of things to understand before starting on the lab; if you have unchecked boxes as of lab start time, ask me!
  5. The final hour will be group or individual lab work. I'll make voluntary breakout rooms and remain in the main channel and monitor the spreadsheet and slack channel.
  6. I'll make sure to update lecture notes/syllabus/etc as I fix issues asked about in Slack, and major announcements will be posted to the course website as well.
  7. If you have additional thoughts/questions/concerns, please DM me or post in a blank area on the mid-semester check-in spreadsheet! Also, if you want to use the slack for discussion/lab Q&A/etc, please please please do that!

Readings and Useful Libraries


  • My general rust advice
  • A half-hour to learn Rust, a quick tour through Rust's syntax and special rules
  • Learn Rust—the Rust Programming Language, Rust By Example, and links to documentation
  • RustConf 2018 keynote on data-oriented programming
  • Ultraviolet, a linear algebra crate with good support for SIMD and geometric algebra
  • Set up Visual Studio Code or Emacs or Vi to use Rust with rust-analyzer and LSP
  • Learn to love rustfmt (cargo fmt) and clippy (cargo clippy)

Performance Profiling



Books (all optional)

  • Artificial Intelligence and Games, Yannakakis and Togelius
  • Procedural Content Generation in Games, Shaker, Togelius, and Nelson
  • Game Engine Architecture, Gregory
  • Data Oriented Design, Fabian
  • Essential Mathematics for Games & Interactive Applications, Bishop
  • Game Physics, Eberly
  • Real-Time Collision Detection, Ericson
  • Artificial Intelligence for Games, Millington & Funge