BOSTON UNIVERSITY

CS391 - GAME DEVELOPMENT

SPRING SEMESTER 2027
🎨 COLLEGE OF ARTS AND SCIENCES 💻 DEPT OF COMPUTER SCIENCE

COURSE INFORMATION & DESCRIPTION

LECTURES

Mondays / Wednesdays, 75 minutes
(9:30 AM – 10:45 AM)

DISCUSSION LAB

1 weekly 50-minute lab section
(Check myBUstudent)

INSTRUCTOR

Tiago Januario
Office: CDS 911

TEACHING ASSISTANT

Vivian Tvedt
Office Hours: 🔗 Blackboard

COURSE DESCRIPTION

This course is an introduction to software engineering through game development with the Godot Engine. Students study and apply core software patterns used in games: component-based composition, finite state machines, the Command pattern, data-driven design with custom resources, and the Model-View-ViewModel (MVVM) pattern for user interfaces, with an introduction to performance profiling and data-oriented design.

The class follows a workshop format: each meeting has a short technical lesson followed by in-class development and code review. Across the semester, students build a series of small two-dimensional (2D) games, then a multi-week team project that ends in a final showcase.

PREREQUISITES

Foundational programming knowledge in Python (e.g., CS 111 with a grade of B or better). Familiarity with basic object-oriented programming concepts (classes, methods, instances) is expected.

LEARNING OBJECTIVES

By the end of this course, students will be able to:
  1. Build and Export: Build complete 2D games in Godot and export them as standalone desktop builds.
  2. Composition and Inheritance: Choose between inheritance and component-based composition, and explain the choice.
  3. Behavior and Actions: Organize character behavior with finite state machines, and player actions with the Command pattern (including undo).
  4. Data-Driven Design: Write custom Resource classes so that game content lives in data files, and new content (a new enemy, tower, or item) can be added without changing code.
  5. User Interfaces: Keep user-interface code separate from game rules using signals and the MVVM pattern, and use small test scenes to try one feature at a time.
  6. Performance: Use the Godot profiler to find what makes a game slow, and apply object pooling or data-oriented design (packed arrays) when a specific problem calls for it.
  7. Teamwork: Work on one project as a team with Git branches, pull requests, code review, a task board, and an agreement about which teammate edits which scene (two people editing the same scene file at once causes merge conflicts that are hard to fix).
  8. Playtesting: Run playtests, record what players do, and turn the observations into a prioritized list of fixes and a written post-mortem.

REQUIRED RESOURCES AND EQUIPMENT

TEXTBOOK (FREE, ONLINE)

Robert Nystrom, Game Programming Patterns (Genever Bench, 2014).
🔗 gameprogrammingpatterns.com

ENGINE DOCUMENTATION

Godot Engine Documentation (Version 4.x).
🔗 docs.godotengine.org

COURSE HANDOUTS

GDScript Quick Start (Week 1) and Playtest Guide (Week 12), posted on Blackboard.

PRIMARY TOOLSTACK

Godot Engine 4.x (pinned stable release), Git, and GitHub Classroom.

HARDWARE REQUIREMENT

Students must bring a personal 64-bit laptop (Windows, macOS, or Linux) capable of running Godot 4 under the Compatibility renderer (OpenGL 3.3 support; 8 GB of memory recommended).
Boston University does not maintain loaner computers for this course.

EVALUATION AND GRADING

COMPONENT WEIGHT ASSESSMENT TYPE
Attendance and Participation (Lectures & Sections) 10% Individual
Quizzes (4 scheduled; lowest score dropped) 15% Individual
Programming Assignments (A0 is 3%; A1 through A8 are 4% each) 35% Individual (A8 completed in pairs)
Final Project: Team Score (Milestones M0–M4 and the post-mortem) 25% Team
Final Project: Individual Contribution (your pull requests, code reviews, and a short oral check) 10% Individual
Final Showcase Participation (hosting your game and giving feedback on other teams' games) 5% Individual

PASSING MINIMUM REQUIREMENT

To pass the course, you need at least 60% in each of these three areas, in addition to a weighted total of at least 60%:

  1. Quizzes;
  2. Programming assignments (A0–A8);
  3. The final project (team and individual scores combined).

A strong score in one area cannot make up for a score below 60% in another. If any area is below 60%, the course grade is F.

LETTER GRADES

AA-B+BB-C+CC-DF
93–10090–92.987–89.983–86.980–82.977–79.973–76.970–72.960–69.9below 60

GRADE SIMULATOR

Move the sliders to your expected score in each component. The simulator applies the weights, the letter scale, and the passing minimums above.

Weighted total: 0.0% Projected grade: A

WEEKLY COURSE SCHEDULE

Released items are handed out in Lecture 1 (Monday) of that week. Due items are due before Lecture 1 (Monday, 9:30 AM) of that week, unless marked (Wed) for before Lecture 2, or (Fri) for Friday at 11:59 PM. If a deadline falls on a university holiday, it moves to the next class meeting. Quizzes take the first 25 minutes of Lecture 2.

WEEK LECTURE TOPICS REQUIRED READING RELEASED DUE
1 Getting Started with Godot: the editor, scenes and nodes, GDScript basics (variables, functions, type annotations, class_name and inheritance, @export and @onready), the game loop and delta time, and how to organize a project (assets/, scenes/, and scripts/ folders) and credit the art you use. HandoutGDScript Quick StartTextbookGame LoopFor detailsGDScript reference (Variables, Functions, Classes, Annotations) A0: Setup & Hardware Test
A1: Coin Dash		 A0 (Fri)
2 2D Movement & Game Feel: CharacterBody2D, collision layers and masks, painting levels with a TileMapLayer, tweens, and forgiving controls (coyote time and input buffering). DocsUsing CharacterBody2D/3DOptionalUsing TileMaps (to build your own tileset) A2: Movement Lab A1
3 Composition vs. Inheritance: building objects from small reusable components, scene inheritance, and decoupling with signals. TextbookComponentDocsUsing signals A3: Arena Survivor A2
Quiz 1 (Wed)
4 Finite State Machines: enemies (and players) that switch between named states such as Patrol, Chase, and Attack, and warning the player before an attack. State machines are one simple tool for enemy behavior, not a full survey of game AI. TextbookState A4: Patrol & Pursue A3
5 Custom Resources & Data-Driven Design: writing your own Resource classes, making content variants as .tres files in the Inspector, the shared-resource bug and duplicate(), and designing so that new content needs a new data file instead of new code. DocsResources ("Creating your own resources")TextbookType Object A5: Tower Defense Lite A4
Quiz 2 (Wed)
6 The Command Pattern & Event Queues: turning player actions into objects so they can be undone, redone, replayed, or queued for turn-based play. TextbookCommand A6: Block Pusher A5
7 User Interfaces with MVVM: Control nodes and containers; keeping the screen separate from the game rules (the Model holds rules and data, the ViewModel prepares them for display, the View only shows them); updating the screen with signals; and small test scenes that open one screen with made-up data. DocsUsing Containers A7: Bakery Rush
Team survey		 A6
Quiz 3 (Wed)
8 Saving, Loading & Random Levels: saving game data to a file, autoloads for game-wide state, changing scenes, and a short introduction to building levels from hand-made rooms with a seeded random number generator. Pair programming. DocsSaving gamesOptionalRandom number generation A8: Dungeon Roguelike (pairs)
Teams announced		 A7
M0: Team Charter (Fri)
9 Planning a Team Game: choosing a scope you can finish (must-have list, nice-to-have list, cut list), splitting the work, using a task board, and team Git practice: branches, pull requests, code review, and agreeing who edits which scene. TextbookArchitecture, Performance, and Games — A8
M1: Proposal (Wed)
Quiz 4 (Wed)
10 Optimization When You Need It: finding slow code with the profiler, object pooling, and a data-oriented design case study: moving hundreds of units in a strategy game with packed arrays instead of one node per unit. Studio time. TextbookData LocalityDocsThe Profiler Proposal feedback: approved or revise —
11 Polish: particles, sound effects and audio buses, menus, and a settings screen (volume and control remapping). Studio time. DocsAudio buses — M2: Greybox PrototypeGreybox Gallery (Wed, mandatory)
12 Playtesting: watching someone play without helping, what to write down, turning notes into a prioritized fix list, and basic accessibility checks (readable text, no rapid flashing, remappable controls). HandoutPlaytest Guide — M3: Minimum Viable Product (Wed)Playtest Day (Wed, mandatory)
13 Shipping: exporting a desktop build, a final credits and license check, and writing a post-mortem. Studio time. DocsExporting projects — M4: Final Build (Fri)
Finals Final Showcase & Mini-Game Jam: teams host their games, everyone plays and gives written feedback on other teams' games, and each team gives a 2-minute talk on what they learned. None — Showcase (mandatory)Post-Mortem (48 hours after the showcase)

PROGRAMMING ASSIGNMENTS

Each assignment is a small, complete game built around one week's topic. Release and due dates are in the schedule above. Later assignments reuse earlier ideas, so components from A3 return in A4 and A8.

ASSIGNMENT WHAT YOU BUILD WHAT IT PRACTICES
A0: Setup & Hardware Test Install the course's Godot version, set up Git and GitHub Classroom, and run a hardware test scene on your laptop. The tools you will use all semester
A1: Coin Dash Collect coins before a 30-second timer runs out, then restart. Scenes, nodes, scripts, the game loop, first signals
A2: Movement Lab A three-room platformer painted with a provided tileset. Tune the jump until it feels good. CharacterBody2D, collisions, tweens, coyote time, input buffering
A3: Arena Survivor Survive waves of enemies. Health, hitboxes, and movement are separate components shared by the player and the enemies. Composition vs. inheritance, signals
A4: Patrol & Pursue Sneak through a room of guards that patrol, chase you when they see you, and warn before they attack. Finite state machines
A5: Tower Defense Lite Towers, enemies, and waves are custom Resource files. Adding a new tower must take only a new data file, with no code changes. Custom Resources, data-driven design
A6: Block Pusher Push blocks onto targets on a grid. Every move is a command object, so the player can undo and redo any number of moves. Command pattern, event queues
A7: Bakery Rush Serve customers before they run out of patience, then spend the day's earnings in an upgrade shop. The on-screen display and the shop follow MVVM, and a test scene opens the shop with made-up data. MVVM, UI containers, signals, test scenes
A8: Dungeon Roguelike (pairs) Each run joins hand-made room scenes in a random order picked from a seed. When you die, a new run starts. Settings and your best run are saved to disk. Saving and loading, autoloads, seeded randomness, team Git workflow

FINAL PROJECT

Teams of about four build one original 2D game in Weeks 8–13 and present it at the final showcase.

MILESTONE DUE WHAT YOU SUBMIT
M0: Team Charter Week 8 (Fri) Roles, weekly meeting times, how the team makes decisions and resolves conflicts, and who edits which scene.
M1: Proposal Week 9 (Wed) A one-page plan: the core loop, the must-have and nice-to-have features, and a cut list. Course staff reply approved or revise by Week 10, Lecture 1.
M2: Greybox Prototype Week 11 (Mon) The core loop, playable from start to end with placeholder shapes. Shown at the Greybox Gallery in Lecture 2.
M3: Minimum Viable Product Week 12 (Wed) The game is playable from start to finish and has most of its core content, without polish. This is the build other teams play on Playtest Day.
M4: Final Build Week 13 (Fri) The finished game as a desktop build, with a README.md and a complete CREDITS.md. This is the build that is graded and shown at the showcase.
Post-Mortem 48 hours after the showcase A short team write-up: what went right, what went wrong, and what you would change, using feedback from Playtest Day and the showcase.

COURSE POLICIES

ATTENDANCE AND PARTICIPATION

Attendance is tracked at the start of every lecture and discussion section via an in-class digital check-in code. Students who attend at least 90% of all scheduled class meetings will receive full credit for attendance; attendance below 90% is pro-rated accordingly. There are no retroactive excused absences except in cases of documented religious observance, university athletic travel, or serious medical emergencies communicated in advance.

Attendance at the following three events is mandatory and directly contributes to your individual project grade:

  1. Week 11 (Wed): Greybox Gallery;
  2. Week 12 (Wed): Playtest Day;
  3. Finals Week: Final Showcase.

LATE ASSIGNMENT POLICY

  • Individual Assignments (A0–A8): Submissions uploaded within 48 hours following the posted deadline incur a flat 10% penalty. Assignments submitted more than 48 hours after the deadline receive an automatic grade of zero.
  • Team Milestones (M0–M4): A milestone submitted up to 48 hours late earns half of that milestone's points; later than that, it earns zero. A late milestone does not pause the schedule: the team keeps working toward the next one.
  • Showcase Date: The finals-week showcase schedule is non-negotiable.

QUIZZES AND MAKE-UP EXAMS

Four paper-based quizzes are given during the first 25 minutes of Lecture 2 in Weeks 3, 5, 7, and 9. Quizzes are strictly closed-book and closed-device. The lowest quiz score is automatically dropped from your final grade calculation.

  • Students who miss one quiz forfeit that quiz as their dropped score.
  • Students who miss two or more quizzes, or who miss Quiz 4, must take a paper-based Make-Up Exam during finals week, covering the quizzes they missed.

COLLABORATION TIERS AND ACADEMIC INTEGRITY

Learning to design software requires honest, individual engagement. Work is partitioned into three explicit collaboration tiers:

  1. Individual Tier (A0–A7 and Quizzes): All code, scene files, and written responses must be composed entirely by the individual student. Discussing high-level concepts and debugging techniques is encouraged; viewing, copying, or sharing another student’s code or assets is strictly prohibited.
  2. Pair Tier (A8): Students work in pairs and share a single repository. Both partners must contribute demonstrable Git commits and pull request code reviews.
  3. Team Tier (Final Project): Code and scene files are shared freely within the assigned project team. Sharing source code across different teams remains strictly prohibited.

Modifying, circumventing, or tampering with the automated checks in your GitHub Classroom repository constitutes an immediate violation of academic integrity.

ARTIFICIAL INTELLIGENCE (AI) POLICY

Generative AI tools (such as large language models) may be consulted as interactive tutors to explain programming syntax or engine concepts. However, students are strictly prohibited from using generative AI to write, generate, or refactor code submitted for grading.

Furthermore, AI-generated visual art and audio assets are strictly banned in all submissions. All art, audio, and font files must either be created originally by the student or sourced from public-domain and Creative Commons Zero (CC0) collections with complete attribution recorded in CREDITS.md.

Right to Oral Defense: The course staff retains the right to conduct an oral defense on any submitted code or milestone. If a student cannot explain the logic, architecture, or operation of code submitted under their name, the instructor will assign:
  • A grade of 0 on the assignment (first offense);
  • A grade of F in the course and immediate referral to the Academic Conduct Committee (second offense).

UNIVERSITY ACADEMIC CONDUCT CODE

Academic misconduct will not be tolerated. All students are expected to maintain familiarity with and adhere to the Boston University College of Arts and Sciences Academic Conduct Code:
🔗 bu.edu/academics/cas/policies/academic-conduct/

ACCOMMODATIONS (DAS)

Any student requiring accommodations must contact Disability & Access Services (DAS) at (617) 353-3658. Official accommodation letters must be delivered via email to the instructor at least two weeks prior to the assessment or milestone for which accommodation is requested.