



Game Mod was a six hour long workshop with the objective of showing the participants that it is not required to understand code to experiment and play with it. Although they had no experience in coding, the task of each participant was to make a mod (modified version) of a game built in Processing.

The code to be modded.

A version of the atari game 'Breakout' was built in Processing for the workshop. Unlike common breakout games, in this version the ball bounces on all four sides of the screen, so the game goes on forever, without pauses. This way the game can be modified to the point where its original gaming references are lost, and still maintain a continuous and endless motion. (A cool side-effect is that the player can dribble with the ball).

Although the code of the version had advanced programming features, like Java classes, it was optimized for easy reading and tweaking. Which wasn't so hard to do: the use of classes allows a clear view, by breaking the code into various sheets, each one controlling a specific aspect of the game. Also the variables of classes are usually declared at the beginning: the easy-tweaking bit is the first visible thing on the code. One specific thing I did was to write descriptive names of variables and methods (in a human readable way), and in Spanish, the main language of the workshop.

The modding.

The task of each participant was to create a mod of the game: dig into the code, change its looks and behaviours, search for unexpected results.

The workshop was given in the context of a graphic design graduate. Very few participants had had any experience in coding. No one had ever heard of the Processing language.

After a short presentation were they were shown several videogames and some of their mods, like Quake and the multifaceted Untitled Game, participants were guided to open the game source code in the Processing IDE. That's it, that's all I showed. They found out how to run and stop it, and after five minutes most were already modding its graphics and dynamics.

The main aim was not to teach them how to code, it was to push them to play around a be creative with a tool that is unfamiliar to them. Someone said that you don't have to learn how to play an instrument to make music with it. They saw first-hand that the same applies with coding, and that there's no point in being shy about touching the inside parts of an interactive medium.

I answered very few specific programming questions throughout the workshop, and my usual answer was to point them to the Processing reference, so they would either creatively look for an alternative solution, or find out they could easily get the answers by themselves - the great work put into the Processing reference and examples was a big helper. As a matter of fact, all the pedagogical approach of Processing was a big helper in many aspects.

The mods.

I was impressed by the results since the first moments after they opened Processing. These students have definitely proven you don't need to read a manual to be creative with a tool. Contrary to what many may think, understanding of technology is not a definite requisite for artistic expression on digital media.

Graphic design students, with almost no previous experience in coding, were pushed head first into object oriented programming. They discovered that in the complex system of a game program, change can lead to unexpected and beautiful results, and their lack of knowledge of the tool was more a creativity boost than it was a limitation.

Try it.

If you're curious about programming, or about Processing, or just want to play around, then you should try this. It's easy, and it won't take you much time. In 20 minutes you'll have your first mod done. You don't need to know anything about programming, just change stuff and see what happens. All you need is Processing and the game source code.

The installation of Processing is quick, and clean. If you're on Windows, get the version with java. After you open Processing, uncompress the whole folder and drag the 'gamemod_breakout.pde' file into the Processing application icon, or open it from within Processing. (Actually, the best way is to place the folder in the Sketchbook folder and restart Processing, but I'll let you discover that feature by yourself). Then start messing around.

A few tips: if something breaks, "undo" (CTRL+Z). If you like what you see, "Save as..." a different name, just in case it breaks really bad. By breaking I mean that the game window won't pop-up when you press play, and that means there's some kind of error in the code and it won't run. That's usual stuff, it happens all the time when programming.