• Due: Friday 25 November 10pm
  • Mark weighting: 50%
  • Template: coming soon
  • Submission: submit your assignment according to the instructions below
  • Policies: for late policies, academic integrity policies, etc. see the policies page

The submission deadline has now passed, but class isn’t quite finished—come along this coming Tuesday Nov 23 5pm–7pm in HN 1.24 for the final project exhibition (and I’ll order pizzas for dinner). So come along, wear a mask, and show off what you’ve made and see what your classmates have done :)


The end of the school year is approaching, and so is the EXTN1019 final project. As we’ve foreshadowed all along in this course, your final project deliverable is an interactive creative code artefact for an end-of-year creative code exhibition. Like any good art/music festival, there are multiple different stages and areas, so you get to choose whether your creative code artefact goes on the

  • main stage: for creative code performances—the sort of thing where you build an interface for yourself and then “perform” it for a crowd (who are watching your screen and listening to your sound/music over the PA)

  • reflection room: for interactive creative code artworks which are designed to be continuously running in a browser (on a standalone computer with keyboard, mouse & speakers) while festival attendees can pause your work and interact with it

Your goal is to provide an engaging performance/user experience of roughly three minutes, but the exact nature of that creative code experience is up to you.


Your final project submission has three parts:

  • an interactive creative code artefact
  • a README.md file explaining how to interact with your work (including a note about whether it’s for the main stage or for the reflection room)
  • a 2–3 page design document discussing your design process

Creative code artefact

Your creative code artefact needs to:

  • run smoothly in a web browser
  • be interactive (either by you, if you’re making something for the main stage, or by others, if you’re making something for the reflection room)
  • produce some sort of creative output (visuals, sound, etc.)

Other than that, we’re not going to put too many strict rules around things, because coming up with creative new ways to build things with code is the whole point of this class. Having said that, if you’re unsure about your ideas for whatever reason, then feel free to ask a question either in class or on Teams.

Design document

The creative code artefact you submit for your final project is a function of the decisions you make as you design and develop the artefact. Your design document should give us a window into your design process. We are not imposing a strict structure for the design document, but we will give you a few guidelines to follow.

  • Early on the document, perhaps the first paragraph, you should introduce us to the theme you explore in your artefact. Describe some early ideas you had for exploring this theme through your artefact.

  • Finish the document by discussing how the final version of the artefact i.e. the one you will submit for marking, explores your chosen theme.

  • In between the starting and finishing point of your document (mentioned above), you should discuss the key decisions you made while refining your artefact from the early ideas towards the final version.

Submission process

You must submit all the necessary files (code, image/audio/video files, design document) by committing and pushing them to GitLab by 8pm Thursday 18 November. The design document should be added to your git repo (the root folder, not any of the sub folders) as a PDF. You must push it to your fork of the project prototype template (this means you can just keep working on the code you used to build your prototype, and pushing it up to GitLab as usual).

Marking criteria

The marking criteria are connected to the course learning outcomes (LOs), and you will be assessed on your project’s

  • interaction design (LO #1)
  • artistic output (LO #2)
  • technical quality (LO #3)


Will things on the main stage get better marks than things in the reflection room?

No, it’s just a way of separating out the different types of creative code work—you get to choose.

What’s with the interactive part?

You’ve been making interactive creative code artefacts pretty much the whole time in this course. Any p5 sketch which uses a mouseX or a mouseY or has a keyPressed() or mousePressed() callback (or anything along those lines) is interactive, because the behaviour changes in response to the input of the viewer. Same with the Tone.js stuff—all the “hit space to play” stuff makes it an interactive work.

Now, since interaction is one of the marking criteria, you probably want to put a bit more thought into it than just e.g. “hit space to play”, but

One other thing: making your final project interactive doesn’t necessarily mean it has to be able to be used by just anyone with no training—it’s ok if you make an interactive performance interface just for you.

Do I get a mark for the design document?

Not directly—although the design document will help us better understand your process and final product when we mark it.

What type of file should the design document be?

The design document should be either

  • a new markdown file in your project called design-document.md (you can create a new file in VSCode by right-clicking in the left-hand file pane, choosing New file and typing in the filename)

  • a PDF with the filename design-document.pdf (you could write it in e.g. Word or a Google doc, then export it to a pdf and drag-and-drop it into the top-level folder of your project)

However you create the file, make sure you add, commit & push it to GitLab—because otherwise it’s not part of your submission.

What sort of “design decisions” should I discuss in my design document?

Here are some ideas.

  • Did you have an ideas which you found challenging to implement in code? How did you overcome this and what compromises did you make? What did you prioritise?

  • The implementation of an idea. The “breathing circle” exercise from Week 3 and Week 22 taught us that there is more than one way to implement an idea. Why did you decide to implement an idea a certain way.

  • Where there any “happy accidents” which you decided to keep or explore further?Not sure how to discuss each decision? With each decision you introduce us to in your design document, there are a few things you should keep in mind to ensure the discussion around that decision is informative.

  • Keep the description of the decision as brief as possible; you don’t need to go into unnecessary detail. We are more interested in why you made the decisions. Feel free to capture the details of your ideas by including hand drawn sketches or screenshots of your browser window in the document.

  • When you discuss why you made the decision, use the following probing questions as guidelines for what to discuss.

  • How did your decision help you explore your theme more effectively through visuals or audio?

  • How did you consider the “audience’s” experience of your artefact when making the decision? This includes interaction, the response to the interaction through visuals and sound, the way visuals and sound change over time.

  • How did your decision affect the technical implementation of an idea?

Can I use some of the information I used in my prototype when explaining my project in the design document?

You can, for some of the “project description” stuff (your final project is based on the prototype, after all). However, the design document is not meant to be a description of the project, it’s a discussion of your design process (see the previous FAQ entry). So you’ll need to think hard about that, and that will involve writing significant new material which wasn’t part of your prototype documentation.

What will we be doing in class for the final weeks leading up to the final project submission deadline?

Class is still on as normal (well, it’s online on Teams, but it’s still on 5pm–7pm on Tuesday arvo) right up to the Tuesday before the submission deadline (Tuesday Nov 16). There will be some “content” to work through in the class, but it’ll mostly be about supporting you to develop, test and iteratively refine your final project as the deadline approaches.

You need to make the most of these remaining class sessions! That means:

  • working hard outside of class until you get stuck, and then bringing your problem to class (although you can also post questions in the main Teams channel) at any time, as per the class communication policy

  • taking the time after a class to finish off any work you didn’t get done, and to ask any followup questions if you get stuck

  • talking to your classmates (either on the main chat, or you can even DM them) to see how they’re going, ask for advice, get feedback on your work in progress, etc.

Will the final exhibition be in-person, or online?

Yes, it will be in person—we’ll be having the low-key final project exhibition in class on Tues November 23 (5pm–7pm as usual). So come along, show off what you’ve made and see what your classmates have done :)

Do we have to submit a video this time?

No, this time you’re primarily submitting the code artefact itself (plus the reflective design document). That means your code really needs to work—and not only on your laptop.

Don’t fret, though, because we’ll be exploring ways to make sure that it works reliably in the last few weeks of class, but the key is going to be checking things at the “test URL” (like you did right back in lab 1 when you put a circle on the internet).

What’s the relationship between the prototype and this final project?

This is the big one—it’s meant to be a standalone work of interactive creative code, with a degree of depth and polish that’s beyond what you did for your prototype or in the weekly lab sessions.

If you’re still a bit unsure, there are a few FAQ entries in the prototype FAQ which might be helpful.

Why does this final project “reuse” the prototype GitHub project template?

Because you already did a bunch of work on your prototype, so if we made a new “final project” template repo you’d have to fork it all over again and copy your code over manually. That’s just an unnecessary hassle, so instead you can keep using the same GitLab project as you’ve been using in building the prototype so far.

Can I use code that I’ve already committed & pushed to GitLab as part of one of my labs?

Yep, that’s fine—if it’s your code, you don’t even have to reference it. If it’s code from the template itself, then make sure you make a note of it. As an example, if you copy the drawPokemon() and updatePokemon() functions from the lab 8 (Pokegardens) template last year you should say something like this in your references.md file:

The `drawPokemon()` and `updatePokemon()` functions (starting at line 67 of my
`sketch.js` file) are taken from the [lab 8 template repo](https://gitlab.cecs.anu.edu.au/extn1019/2021-2022/year-11/extn1019-2021-lab-8).

Can I use code from elsewhere on the internet (e.g. p5js.org, coding train, GitHub)?

Yep—using/remixing other people’s creative code is a crucial part of learning (and of being a creative practitioner in general). However, there are two things to be a bit careful about when doing so:

  • you need to reference everything in your references.md file (seriously, do it as-you-go rather than waiting till the end, because “whoops, I forgot to add the reference” isn’t an acceptable excuse)

  • it’s ok to use these external sources, but your final project must contain significant new work by you—you can’t just cobble together stuff from these other places and pass it off as your own

If I find a bug between the submission date and the exhibition, can I fix it?

Yep—the “push to GitLab -> show up on the test URL a couple of minutes later” thing will work all the way up to the exhibition time. As described above, though, your last push before the deadline is still counted (and marked) as your submission.

bars search caret-down plus minus arrow-right times arrow-up creative-commons creative-commons-by creative-commons-nc creative-commons-sa