Design Computation

Final Project Outline

The Proposal

Draft a proposal with images and sketches that portrays the topic you want to investigate over the rest of the semester. These can consist of images, drawings, diagrams, etc., but should all point to some sort of system you want to investigate and report on.

The System

The first task after the proposal is to investigate the system you have chosen to explore. The question to ask here are of the type:

  1. What are the acting elements of the system? Are they semi-autonomous agents acting relatively independently?
  2. Is there a top-down structure governing the organization and behavior of the system?
  3. Is it primarily user-interaction driven, like a drawing tool?
  4. Is it data-driven, accessing external data sources for visualization or other purposes?

The Data Model

Attempt to reduce the system into a computational model. This includes choosing a pre-existing data model type for the system, such as agents, components and topology, descriptive geometries, interactive datasets, etc.

Delineate the parameters of this data model and the data types you’ll need. If you’re working with an agent-based system, where semi-autonomous actors work independently, you will probably need an “Agent” class. Describe the “data” that the class objects must hold, such as “position” in a PVector, “direction” in a PVector, some other arbitrary quantity in a float, etc.

Behavioral Model

Write a pseudocode for how the model behaves. Include as much of the data and variables you have already delineated as possible, but focus on getting the underlying logic and process documented in English, not in code.

Use the following constructs to help your pseudocode:

  1. Conditional logic: if … then … else …
  2. Looping: “for every x in a collection of x’s”, or “for every Agent in my list of Agents: cause the Agent to move”
  3. Calculating something: “Get the number of Agents. Calculate the average direction of all Agents.”
  4. Executing some command: “For every Agent in my list of Agents, draw the Agent.”

Make the pseudocode as detailed as you can, but first start with high-level thinking about how the system behaves. Don’t get bogged down in the details of calculating individual properties just yet, such as how to calculate averages or slopes of lines. You can leave that for the Implementation phase later.

Sketch Research

Find a few Processing sketches that are related to the ones you are working on. Download the source code and try to get it running.

For the ones that you can get to work, perform the following analyses:

  1. Describe data types and possible values for variables.
  2. Which variables are temporary?
  3. Which variables qualify as “parameters,” and drive the behavior of the sketch?
  4. Start changing the parameters to ascertain what they do. Which ones affect the overall behavior of the sketch? Which ones just affect rendering or representation?
  5. What does each function do?
  6. Outline the structure of the sketch, setup() … draw().


Using the information you have gathered, start implementing the system in Processing. Just start with a simplistic 2-dimensional sketch that implements a portion of your pseudocode. You will have to structure the code first, writing empty functions with descriptive names that describe various processes in your code. The data model will give you cues as to what variables to declare, what classes to define, etc.

Search through the Processing reference to find libraries that may fit your goals. Download them and read their documentation to see how they work. Attempt to implement the library in a small, independent sketch to “get the hang of” how it works.

Exploration through Iteration and Evolution

Once you have your first sketch, you’re ready to explore its potential. This involves adjusting the parameters and structure of your sketch, saving new sketches that exhibit different behaviors, and iterating in a change-and-explore, or trial-and-error, fashion until you discover something interesting.

  1. Behavioral Explorations
    Change the parameters that govern the overall behavior of the sketch. Through observing the resulting behavior, you can determine what other behaviors will be more interesting or closer to what you want to explore. Try to find the appropriate values for parameters that will achieve these behaviors. Also try to find different ways of calculating derived quantities (parameters calculated from the values of other parameters) that will yield different results.
  2. Rendering and Representation Explorations
    Finding different ways to render the system may yield a different understanding of how the system behaviors. There are two things to change: the rendering methods for what your are already drawing, or what data you are actually rendering. Look at other example sketches for inspiration.

While you proceed, think about the theoretical framework your explorations embody. Are you developing a tool that helps you execute a series of repetitive actions in an easier way? What benefits do you get? Are you exploring the potential of some system object model that allows you to design within the pre-defined rules of the system? The key issue is to define what computation is doing that you couldn’t do otherwise, or why the computational explorations are valuable. Most likely it will take the form of a “better understanding” of how a particular system works, and thus giving insight into the potential of such systems.


Compile your efforts into a coherent, web-based presentation.

Load the presentation before you present to have them all available. All the work should be on the server with a CD or USB drive backup on hand.

Consider the speed of the machines attached to the plasma screens. According to DM, their resolution is 1072 × 600 pixels. So the ideal size for sketches is a little less, probably around 900×500 pixels. I will have at least one screen up early for all of you to test your presentations on.

If you use OpenGL, make sure to test your series of sketches before the presentation. Have non-OpenGL (P3D) versions ready if they fail.

The presentation should be as seamless as possible. No searching for files. You have two options to achieve this:

  1. All HTML pages: Use full-screen mode in a browser (F11) and have your own in-page navigation.
  2. PDF or Powerpoint, full-screen, for non-Processing images and text, and use Alt+TAB to switch to your full-screen browser with the Processing sketches embedded.


When: Thursday, December 16th, 9am to 1pm.

Where: 6th floor pit

Equipment: 4 plasma screens

Typical Outline

  1. Images and text describing the inspiration for your project. This primarily comes from the project proposal you did before.
  2. Diagrams and drawings describing how you model the data that describes the system. This always involves some loss of fidelity, but you gain the computational power that your project demonstrates.
  3. Process, process, process. Processing sketches that show your development step by step. Be sure to hold on to every sketch that you make as you add functionality. You should be able to tell the advantages of what you found, the problems and shortcomings you encountered, and how you solved them or moved past them.
  4. Final results of your Processing work. This can be a working sketch, renderings, physical output, etc.
  5. Present how you could take the work further with a statement, diagrams, or drawings. The jury will have suggestions.