CRCP 3315: Creative Coding III

Southern Methodist University · Creative Computation
Undergraduate · 3 Credit Hours · Online Section

Live class session: one 90-minute weekly studio via Zoom (day/time TBD; set against the registrar's section listing once the course is scheduled)

Course-approval draft — term and calendar dates are intentionally TBD. When the course is scheduled, university dates and the then-current SMU required syllabus statements will be inserted verbatim. The course description below is the proposed language-neutral catalog description submitted with the accompanying course-modification request; the catalog number, title, credit hours, prerequisites, and role in the degree are unchanged.

Instructor

Instructor: T.B.D.
Name, title, email, and phone will be inserted once the section's instructor of record is assigned.

Office Hours — T.B.D.; set by the instructor of record and posted on Canvas before the first live session.

Response Time — My goal is to respond to student communications within 24 hours. If for some reason I am unable to do so, I will follow up as soon as possible. I will always try to let you know ahead of time if I will be unreachable.

Assignment Feedback — My goal is to grade assignments within 48 hours. Instructor and peer feedback are also provided during each weekly live class session.

Course Description

Advanced object-oriented programming and software engineering from a "creative coding" perspective, including popular design patterns, abstraction and interface design, testing and evaluation, performance and resource reasoning, and collaborative development in existing codebases. Students engineer, evaluate, and maintain software systems built with and alongside AI development tools. Course examples, programming exercises, assignments, and projects incorporate creative computing concepts and best practices.

Creative Coding I taught students to think computationally and read what they did not write. Creative Coding II taught them to structure a system before building it. This course asks the question that follows: how does software survive contact with other people, with time, and with scale? A program that works today, on one machine, for one author, is a sketch. Software is a program with tests, documentation, a build, a version history, an interface others depend on, and a plan for what happens when it breaks. Engineering is the practice of turning the first thing into the second, and it is the practice AI development tools have changed most.

That change is the course's premise. When an agent can produce a thousand lines of plausible code in a minute, the scarce skills are the ones that decide whether those lines should exist: recognizing the pattern the problem calls for; designing the interface the code will have to honor; writing the test that proves it; reading the diff and refusing what is wrong; keeping a large codebase coherent as many hands — human and machine — change it. Students spend the semester inside real codebases, including ones they did not write, directing AI agents on bounded engineering tasks and taking full responsibility for the result. Design patterns, abstraction, memory and resource reasoning, testing, and tooling are taught as the means of that responsibility, not as a catalogue.

Computation remains a creative medium. A successful capstone might be a released creative-coding library, a generative design tool with a plugin architecture, a performance framework, an installation control system, an accessible drawing application, or a contribution to an existing open-source creative project. The technical sequence is shared; the creative destination is not. Students share technical competencies, not creative outcomes.

Prerequisite: CRCP 3305 or CS 1342. Students should arrive able to architect a multi-file program, apply object-oriented design, and choose basic data structures in any language.

Course Format — Flipped Studio

This course runs as a flipped classroom:

Class time is work time. Come with the tutorials completed, your questions ready, and your repository open. The live meeting is studio, not a second version of the asynchronous material.

Learning Outcomes

Upon completion of the course a successful student will be able to do the following:

Module-level outcomes (MLOs) are listed within each Canvas module; the number in parentheses next to each MLO corresponds to the course-level outcomes above.

One Course, Many Directions

Students are not graded on whether they use every pattern discussed in the course. They are graded on whether they understand the patterns well enough to make intelligent decisions about using — or not using — them in service of an individual creative or functional intention.

One student might release a small generative-typography library with a documented API and a test suite. Another might build a plugin architecture for a drawing tool, a control system for a physical installation, a performance framework other artists can extend, or a substantial contribution to an existing open-source creative-coding project. All are legitimate destinations for the same technical sequence.

An observer is never added because the course covers observers; a factory is never built because factories were in a tutorial. The best engineering is often the pattern not applied. Complexity must be earned by the problem.

Designed for many students and many instructors. Because briefs name competencies rather than media, the same sequence supports a student who thinks in images, one who thinks in sound, and one who thinks in play — and an instructor whose own practice is any of those. The tutorial sequence establishes a reference path; the demonstrations, examples, and critique vocabulary of a given section may be drawn from whatever medium its instructor works in, without changing outcomes, briefs, or rubrics. Creativity is not a bonus layered on the technical sequence; it is what the technical sequence is for.

Reference Environment

The catalog description of this course names no programming language, and neither do its learning outcomes. That is deliberate. Patterns, abstraction, testing, resource reasoning, and collaborative engineering are the same in every language, and the language an offering uses is an offering-level choice — like the day it meets — rather than part of what the course is.

Each offering does use a common reference environment so demonstrations, tutorials, and troubleshooting remain manageable. The reference environment for a given term is announced before registration and selected against four criteria: it must make memory, resource, and performance decisions visible — typically a compiled, systems-capable language with a real build system, so that engineering choices have observable consequences; it must have a mature testing and tooling ecosystem; it must have a living open-source creative-coding community whose codebases students can enter; and it must be one that current AI coding agents handle fluently. It is a reference environment, not an ideological commitment, and is revisited before each offering. Students may work in an alternative environment with instructor approval if they can demonstrate the same competencies.

Projects

The semester is organized around five projects plus studio participation: two four-week projects that establish the practices of entering a codebase and designing one, two two-week projects that harden a system, and a capstone. The count is deliberately smaller than in the earlier courses — engineering is the practice of sustaining one thing over time, and the projects are long enough to make that real. Project briefs are deliberately outcome-focused rather than prescriptive — each names the competency it assesses, not the medium it must take.

Every project may be realized visually, sonically, interactively, or in combination. A generative-typography library, an audio-sequencing framework, a plugin architecture for a drawing tool, a control system for an installation, and a contribution to an existing open-source creative project are all valid answers to the same brief. Students are evaluated on whether their engineering decisions serve an individual creative or functional intention.

Every project is accompanied by an Engineering Record — architecture decision records for the significant choices; the interface contract; the test and evaluation strategy; the AI Collaboration Note, including agent-produced changes that were refused; and the verification account — and is submitted as a Git repository whose history of branches, reviews, and merges shows the work developing.

Project 1 — Codebase Entry · Weeks 1–4 · 14%

The work: enter an existing, substantial creative-coding codebase — an open-source framework, library, or tool, or one supplied by the instructor — and make a bounded, reviewable contribution. Includes a map of the codebase's architecture, build, and conventions; identification of at least three design patterns already present, with an assessment of whether each is earning its place; a repository context document written for an AI agent; a contribution implemented on a branch, with at least one agent-produced change reviewed and either revised or refused; a pull request with a description a maintainer could act on; and the first Engineering Record. The contribution need not be large; it must be correct, tested, and explicable.

Evaluation emphasis: accuracy of the codebase map; pattern recognition; quality of the context document; rigor of the review; the pull request as a piece of professional communication.

Project 2 — Pattern Study: A Small Framework · Weeks 5–8 · 18%

The work: design and build a small reusable library or framework for a creative purpose — a particle toolkit, a scene-graph layer, a generative-grammar engine, an animation timeline, a sequencer, a synthesis graph — in which interface design and patterns are the point. Required concepts: a public interface designed and documented before implementation, with the alternatives considered; at least three patterns applied deliberately, each with an architecture decision record; a unit-test suite with meaningful coverage of the public interface; a property-based or generative test for at least one behavior; an example program that uses the library as a stranger would; and a review of an agent-produced implementation of one component, identifying what was accepted, revised, or refused and why.

Evaluation emphasis: interface design; appropriateness of the patterns; test quality; usability of the library from the outside; critical review of generated engineering.

Project 3 — Measure and Prove · Weeks 9–10 · 14%

The work: take a substantial system — the Project 2 framework, a prior project, or an existing codebase — and establish the evidence that it works and how it behaves under load. Required: a measured performance and resource baseline; explicit reasoning about memory, ownership, and lifetime for the system's principal objects; at least one optimization with before-and-after measurement and a record of what was not optimized and why; and a test suite covering the public interface, including a property-based test.

Evaluation emphasis: measurement-driven engineering; resource reasoning; test quality; judgment about what not to do.

Project 4 — Agent-Directed Refactor · Weeks 11–12 · 16%

The work: a significant refactor of the Project 3 system executed by an AI agent under the student's direction, plus the hardening a real system needs. Required: the specification the student wrote before the agent ran; tests written before the agent ran that define behavior to be preserved; the agent's changes as reviewable diffs; the student's review, with changes accepted, revised, and refused; the passing suite as proof behavior was preserved; a continuous-integration pipeline that runs the suite on every change; error handling, logging, and diagnostics appropriate to the system; and a security review of the system's inputs and dependencies.

Evaluation emphasis: quality of the specification and tests as constraints on the agent; rigor of the review; robustness; security reasoning.

Project 5 — Individual Capstone: Released Software · Weeks 13–Finals · 28%

The work: a released, tested, documented piece of creative software — a library, a tool, an application, a framework, or a substantial open-source contribution — demonstrating the student's individual perspective and the course's accumulated competencies. Students may substantially develop an earlier project or propose a new direction with approval. The completed capstone addresses five dimensions:

Final presentation: a live demonstration, an engineering walk (the student explains any part of the system, its tests, or its history the instructor or a peer selects), and critique during the officially scheduled SMU final-examination period. The precise slot remains TBD until the Registrar's examination schedule is published; no new major assignment is introduced or due during the final week of classes.

Grades

Your work and overall performance will be recorded on Canvas. Students can access their current weighted average at any time via Grades.

ActivityPercentage
Project 1 — Codebase Entry (Weeks 1–4)14%
Project 2 — Pattern Study (Weeks 5–8)18%
Project 3 — Measure and Prove (Weeks 9–10)14%
Project 4 — Agent-Directed Refactor (Weeks 11–12)16%
Project 5 — Individual Capstone (Weeks 13–Finals)28%
Studio participation / process10%
TOTAL100%

Weekly checkpoints are required milestones of the five projects and are assessed within the project each feeds. Late or missing milestones reduce that project's grade.

Common Project Evaluation Framework

Although each project is different, a shared rubric keeps expectations equitable. Technical sophistication alone cannot compensate for an undifferentiated idea, and creatively ambitious students cannot ignore whether their software actually works, is tested, and can be explained.

AreaApprox. Weight
Individual concept / creative or functional intention15%
Architecture, patterns, and interface design25%
Testing, evaluation, and verification20%
Resource reasoning, robustness, and delivery20%
Process, AI collaboration, documentation, and critique20%

Grading Scale

RangeLetter Grade
92–100A
90–91A−
88–89B+
82–87B
80–81B−
78–79C+
72–77C
70–71C−
60–69D
Below 60F

Materials

Required (all free or already provided):

Recommended readings (linked per-module on Canvas; drawn from the tutorial reference lists): Gamma, Helm, Johnson, and Vlissides, Design Patterns (the original, read critically); Robert Nystrom, Game Programming Patterns (free online); Martin Fowler, Refactoring; the reference language's official style and testing guides; Google's Software Engineering at Google (free online, selected chapters); current guidance on agentic software development and code review from the major AI providers; essays on open-source sustainability and the ethics of engineering, refreshed each term. No conventional textbook is required; the tutorial sequence is the primary text.

Course Schedule

Weekly rhythm: two tutorials before class → studio work in breakout rooms during class → checkpoint due before the next session. The sequence follows all thirty Creative Coding III tutorials in order at tutorials.ij8.ai. Calendar dates will be added from the Registrar's Official Dates for Terms once the course is scheduled.

Arc I — Entering a Codebase

Week 1 — What Software Engineering Is Now

Week 2 — Builds and Branches

Week 3 — Directing an Agent in a Real Codebase

Week 4 — Reviewing and Refactoring

Arc II — Patterns and Abstraction

Week 5 — Why Patterns

Week 6 — Structure and Behavior

Week 7 — Interfaces and Dependencies

Week 8 — Generality and Its Abuses

Arc III — Engineering for Reality

Week 9 — Memory and Measurement

Week 10 — Many Things at Once, and Proving It Works

Week 11 — Testing the Machine's Work

Week 12 — Failure and Hostility

Arc IV — Shipping and Sustaining

Week 13 — Releases and Documentation

Week 14 — Community and Time

Week 15 — Ethics, Roles, and Presentation

Finals — Capstone Presentations, during the official examination period

Course Guidelines

As this course is taught completely online, there are certain expectations that should be adhered to. The following guidelines detail the most important aspects of the online format:

Expectations

Students are expected to resolve ordinary technical issues, be active problem solvers, and embrace challenges as positive learning opportunities. This course explicitly normalizes documentation → inspection → experimentation → debugging → asking for help as the expected development process. A failing build or a broken system is not automatically evidence of failure; being unable to explain what has been tried, what has been observed, and where the system fails is the more significant problem.

Absent questions or requests for assistance, the instructor must assume that students understand the material being covered and are able to complete the assignments. It is primarily through your questions that the instructor learns where students are struggling and which topics deserve more time.

Workload

Consistent with SMU's Credit Hour Policy, students in this three-credit course should expect approximately nine or more hours of total course engagement per week averaged across the semester, including the live session. A typical week: 1.5 hours of synchronous studio; 1–1.5 hours of tutorials and explainer videos; 1–2 hours of focused engineering exercises and code review; and 4–5 hours of project development, testing, documentation, and revision. Capstone weeks may redistribute this time toward project development.

Attendance & Breakout Participation

Because class time is studio work time, attendance at live sessions matters more here than in a lecture course. Participation (10% of your grade) means more than being logged into Zoom: it is earned through preparedness (tutorials completed, repository in hand), active building, reviewing, and debugging in breakout studios, the quality of code review and critique you give peers, helping peers reason about problems without simply producing their work for them, receiving criticism constructively, and participating in engineering walks when asked. More than two unexcused absences from live sessions will reduce the participation grade; see the University Policies section for excused-absence categories.

Assessment

This course consists of a number of assignments and projects to be completed throughout the term. It is expected that all students will put forth the effort required to earn an 'A' letter grade for this course. Assignment grades will be determined using evaluation rubrics. You are responsible for reviewing the rubrics and raising questions or concerns related to the assignments, their rubrics, and their grading prior to the submission of each assignment. Questions regarding the grading of any assignment should be directed to the course instructor as soon as possible.

The course evaluates engineering judgment rather than volume of code. Because AI agents are used throughout, every project includes an engineering walk: during studio or the final presentation, the student explains any part of the submitted system, its tests, or its history on request. A system the student cannot explain is not yet the student's work, whatever tool produced it. Experimentation carries legitimate risk: students will not be penalized merely because an ambitious experiment reveals that an approach does not work. What matters is the ability to observe → diagnose → understand → revise, turning failures into a better design, a test, or a regression case.

The final grade for the course will be calculated on the basis of the earned cumulative percentage and the grade received for each of the components of the cumulative percentage. If you earn less than 60% (grade of D) in any one of these components, you will receive a final grade of F for this course. A course grade of Incomplete (I) will be given only in the case of extraordinary circumstances that prevent the student from finishing the semester; students must have completed at least 50% of the course with a passing grade to be eligible.

Collaboration

Major projects are normally individual, so that each student develops an identifiable creative and technical position — but code review is inherently collaborative, and reviewing one another's pull requests is a required studio activity. Students are strongly encouraged to critique one another's work, review one another's designs, discuss debugging strategies, share public documentation and references, pair temporarily during technical exercises, and explain concepts to peers. Students may not submit another student's project, or significant uncredited portions of another student's implementation, as their own. Shared code, open-source components, and AI-generated material must be documented in the Engineering Record when materially significant, and open-source contributions must respect the license and contribution guidelines of the receiving project.

Communication Patterns

Direct communications with the instructor should be made in the manner indicated by the instructor. General questions relevant to multiple students — that is, questions that are not specific to an individual and do not involve private information — should be posted on the course discussion board. It is the student's responsibility to ensure that all communications are received or acted upon. All students should be familiar with the Netiquette guidelines observed in this course.

Generative AI Policy (Course-Specific)

This is a course about engineering software in an era when AI agents write most of it; the use of generative AI tools is therefore expected and required for implementation, refactoring, testing, documentation, and review. Seven rules bound that use:

  1. AI collaboration is expected. Students may use generative AI throughout all legitimate course activities, and are taught to direct, review, and evaluate it as a professional would.
  2. Architecture and interfaces are yours. The system's structure, its public contracts, and its test strategy are decided and documented by the student. Agents implement against those decisions; they do not make them.
  3. You are the author of record. You must be able to explain any part of any system you submit, including code an agent wrote; every project includes an engineering walk. "The model produced it" is not an explanation of how the system works.
  4. Generated code must be tested, not trusted. Every agent-produced change is reviewed as a diff and verified by test before it is merged; an AI system's description of what it implemented is a claim, not evidence.
  5. Disclose. Each project's Engineering Record includes an AI Collaboration Note identifying the tools and models used, what they contributed, what you changed or refused, and how significant outputs were verified. Fluency in describing your process is itself a learning outcome.
  6. Evidence must be real. Performance measurements, test results, user feedback, and other empirical claims must correspond to real activity. Fabricating evidence and presenting it as real is an Honor Code violation.
  7. Protect sensitive information and respect licenses. Do not submit confidential university information, private personal information, credentials, or other restricted data to external AI systems, and do not contribute generated code to an open-source project whose policy forbids it.

Accessibility and Audience

Software is made for people, and released software is made for people the author will never meet. Tools and applications are expected to be operable by keyboard, to consider color contrast and not rely on color alone, to give clear feedback and readable errors, and to document their accessibility limits honestly. Libraries and frameworks are expected to make accessible use the easy default for the programs built on them. This is treated as part of interface design, not as a compliance step.

Technology

To be successful in this course, students should be comfortable with object-oriented programming and multi-file projects (per the prerequisite) and current AI assistant tools. This fully online course occurs primarily via SMU Canvas. Zoom web conferencing is used for the weekly live class session and breakout studios, and Panopto is used for recording audio/video assignments (including recorded project walkthroughs).

Important: A webcam is required for live sessions and recorded presentations. Please be sure your devices meet the technical requirements for Canvas and Zoom. If you run into technical problems, you can always check with me first; you can also contact the SMU IT Help Desk for assistance with Canvas, Zoom, and Panopto.

Privacy and accessibility policies: Canvas · Panopto · Zoom · SMU OIT Policies · Accessibility: Canvas · Zoom

University Policies (Required Syllabus Statements)

This course follows all current SMU required syllabus statements. The statements below reflect the official language as of August 2026; the published semester syllabus will incorporate the then-current official SMU language verbatim, with term-specific dates from the Registrar's calendar.

Academic Dishonesty / Honor Code

Students are expected to embrace and uphold the SMU Honor Code. Violations of the Honor Code — including plagiarism, fabrication of evidence, and misrepresentation of AI-generated work as required by this course's Generative AI Policy — will be handled in accordance with the policies and procedures in the Mustang Student Handbook.

Disability Accommodations

Students who need academic accommodations for a disability must first register with Disability Accommodations & Success Strategies (DASS). Students can call 214-768-1470 or visit smu.edu/DASS to begin the process. Once they are registered and approved, students submit a DASS Accommodation Letter through the electronic portal, DASS Link, and then communicate directly with each of their instructors to make appropriate arrangements. Please note that accommodations are not retroactive and require advance notice to implement.

Religious Observance

Religiously observant students wishing to be absent on holidays that require missing class should notify their professors in writing at the beginning of the semester, and should discuss with them, in advance, acceptable ways of making up any work missed because of the absence. The University Calendar's religious-holidays addendum lists the request deadline for each term; for holidays not listed, contact the Office of the Chaplain.

Excused Absences for University Extracurricular Activities

Students participating in an officially sanctioned, scheduled university extracurricular activity should be given the opportunity to make up class assignments or other graded assignments missed as a result of their participation. It is the responsibility of the student to make arrangements with the instructor prior to any missed scheduled examination or other missed assignment.

Medical-Related Absences

To ensure academic continuity and avoid any course penalties, students with a medical-related absence should follow the procedures described in this syllabus in order to be provided with appropriate modifications to assignments, deadlines, and exams: notify me as soon as reasonably possible (email is fine), and we will arrange make-up work and adjusted deadlines to maintain your academic continuity in the course.

Final Exams

Final course assessments must be administered as specified in the official examination schedule and shall not be administered or due during the last week of classes or during the Reading Period. Final capstone presentations for this course occur in the officially scheduled examination slot for the term in which the course is offered.

Title IX / Sexual Harassment

All forms of sexual harassment, including sexual assault, dating violence, domestic violence, and stalking, are violations of SMU's Title IX Sexual Harassment Policy and may also violate Texas law. Students who wish to file a complaint or to receive more information about the grievance process may contact the Title IX Coordinator at equalopportunity@smu.edu or 214-768-3601. Please note: faculty and certain staff are mandatory reporters, and all reports of sexual harassment made to them must be forwarded to the Title IX Coordinator. Anyone wishing to speak confidentially may contact SMU Counseling Services (214-768-2277) or the Chaplain's Office (214-768-4502).

Pregnant and Parenting Students

Students who are pregnant or parenting may request academic adjustments by contacting the Office of Student Advocacy and Support by calling 214-768-4564. Adjustments are not retroactive and require advance notice to implement.

Credit Hour Policy

In accordance with federal policy and SACSCOC standards, SMU defines a credit hour as the amount of work represented in the achievement of student learning outcomes that reasonably approximates one hour (50 minutes) of instruction and a minimum of two hours of out-of-class student work per week for each credit hour. See the Workload section above for how this course meets that expectation.

Inclement Weather and Emergency Operations

In the event that SMU cancels classes due to inclement weather or emergency operations, students should reference SMU's inclement weather guidelines for further information. As a fully online course, instruction will generally continue as scheduled unless university operations are suspended; any changes will be announced via Canvas.

Zoom Use Guidelines

SACSCOC and university policy require that all in-person classes be taught in person and not moved to Zoom or other technology-mediated modalities, except for extenuating circumstances. This course is approved as a fully online course; the weekly live Zoom studio is its designed instructional modality.

Recording of Classes

Unauthorized student recording of class sessions is prohibited. Recordings are permitted only with advance instructor permission or as an approved DASS accommodation. Institutional recordings of live sessions (made available for review through Canvas) are for personal educational use by students enrolled in this course and may not be shared outside the class without written consent.

Student Advising and Academic Success

Students needing assistance with writing assignments may schedule an appointment with the Writing Center through Canvas. Students who would like support for subject-specific tutoring or developing other academic success strategies should contact Student Academic Success Programs (SASP), Loyd All Sports Center, Suite 202, 214-768-3648, smu.edu/sasp.

Caring Community Connections (CCC)

CCC is a resource for anyone in the SMU community to refer students of concern to the Office of the Dean of Students. The online referral form can be found at smu.edu/deanofstudentsccc. After a referral form is submitted, students will be contacted to discuss the concern, strategize options, and be connected to appropriate resources. Anyone unclear about what steps to take should consult the CCC Reference Guide or contact the Office of the Dean of Students at 214-768-4564.

Mental Health: On-Call and Ongoing Support

Students who are in distress or have concerns about their mental health can seek support from Counseling Services by calling the Dr. Bob Smith Health Center at 214-768-2277 to schedule a same-day or next-day appointment. A counselor is also available for crisis support 24 hours a day, seven days a week at the same number. SMU Teletherapy provides additional free, on-demand counseling options.

Campus Carry

In accordance with Texas Senate Bill 11, also known as the "campus carry" law, and following consultation with the entire University community, SMU chooses to remain a weapons-free campus. Please see the SMU policy for more details.

Student Services

The following services and resources are available to SMU students:

Syllabus Revision

Because generative AI tooling and standards are changing unusually quickly, the instructor may revise individual technologies, model providers, technical examples, tutorials, or project milestones in response to significant changes in the field. Changes will preserve the approved course learning outcomes and will be communicated through Canvas; students will not be disadvantaged by a technology change introduced during the semester. Any other changes to this syllabus will be announced in class and posted to Canvas.