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-poor direct message)
- Other helpful channels
- All due in check-ins
- Week 1: Rust, Text-Based Games, and Course Logistics
- Week 2: Framebuffer Graphics and Input Handling
- Week 3: Collision (Unit 1 deadline!)
- Week 4: Movement
- Week 5: Tilemaps and Scrolling
- Week 6: Complete Games
- Week 7: Understanding Data and Performance
- Week 8: Workflow and Tooling
- Week 9: 3D Rendering
- Week 10: Collision in 3D (Unit 2 deadline!)
- Week 11: 3D Cameras
- Week 12: Game Entities and AI
- Week 13: 3D Animation and How do I…?
- Week 14: Shadows and Lighting
- Week 15 (Exam Timeslot): Demo Day (Unit 3 deadline!)
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:
- You can use
engine3dcode if you want (be sure to download the latest version)
- Feature count grade thresholds all decreased by 1
- 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 (
parry), audio (
cpal), input handling (even
events.rs 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):
- 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?).
[ ]Individual Deliverable (Due one day after deadline day)
- Of the games that you played from other teams, what feature seemed most interesting technically?
- Of the games that you played from other teams, what was the most inventive use of features that were not as technically interesting?
- In terms of your own team's games, what are you most proud of?
- In terms of working on your team's games, what was an aspect of the team work that was particularly effective?
- In terms of working on your team's games, what was an aspect of the team work that was particularly challenging?
- What would you personally do differently next time around?
- What would you like Prof. Osborn to know or do differently next time around?
Thanks for your notes on the mid-semester check-in! Here are what I've identified as some major themes:
- Students appreciate the open-ended nature of the course, and the labs can sometimes feed directly into project work (which was my goal!)
- 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!)
- Class is long, and the second half is maybe too unstructured; labs need more context
- 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:
- 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.
- 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.
- 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.
- 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!
- 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.
- 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.
- 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 flamegraph for CPU time profiling (if it supports your operating system)
- cargo profiler also supports valgrind and cachegrind (but is Linux-only)
- On Linux we'll dig into perf
- On Mac OS, you'll want to use Instruments
- On Windows, use the Windows Performance Toolkit
- For GPU profiling we'll use RenderDoc on Linux and Windows and hopefully figure out something on Mac using Apple's Metal Debugger.
- Fix Your Timestep
- Let's remove Quaternions from every 3D Engine
- Data-Oriented Design (Or Why You Might Be Shooting Yourself in the Foot With OOP)
- Physics in 3D
- Memory bandwidth napkin math, nice for a recent reproduction of the "latency numbers every programmer should know" table
- The Latency Elephant
- Performance and Good Data Design
- Data Oriented Programming Resources
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