Author: tli

tli-FinalProject

DDRaw is a drawing game based on Dance Dance Revolution.

Overview

DDRaw is a game that borrows the language of rhythm games to recontextualize drawing as an act of following instructions. Players must hit buttons as prompted at the right time in order to control a pen drawing on a canvas. The more accurately the player follows these instructions, the more closely they will reproduce the target image. In addition to the game mode, DDRaw includes a level creator that mimics the appearance of popular image editing software.

Narrative

The concept of DDRaw is drawing as instructions as opposed to drawing as an act of creativity. This dichotomy is embedded into my own identity as an artist, as I consider myself more of a “maker” than a “creator”. I combine an existing tradition of instructions-based drawing game-likes, such as Paint By Numbers and tracing games, with the strict timing demands of rhythm games, such as Dance Dance Revolution (DDR). The resulting juxtaposition of precise sketching creates opportunities for interesting mistakes and highlights the choice to avoid them. Missing one prompt can skew the entire drawing! Each gameplay level is created by an anonymous user using DDRaw’s drawing software-like level creation tool. By playing a level, a player is always indirectly imitating another player’s drawing process. Importantly, players are free to be both or to prefer one over the other, regardless of the distinction between the two roles. Key to the success of this interaction is that people of both roles mutually benefit from each other’s engagement.

The exhibition served as both a proof of concept and a playtest opportunity. On the conceptual end, the engagement of the exhibition visitors—particularly those already familiar with rhythm games—proved that the concept was viable on a broader scale. On the implementation end, observing what passersby noticed and struggled with provided helpful feedback on interaction improvements. I define a non-exhaustive list of improvements for each element of the game.

Player

  • Alternate control schemes. Arrow keys and one-handed setups were popularly demanded, especially among more experienced gamers.
  • Increasing the accuracy window by about 100ms. Currently, a hit is registered as on-time if it is within 200ms of the target timing.
  • Increasing the window for detecting simultaneous key presses and syncing this up with the accuracy detection. Currently, determining whether two key presses are simultaneous (and therefore whether to combine their directional vectors into diagonals) is independent of the accuracy detection on the UI.
  • A return to menu button to interrupt the level.
  • More feedback in general.

Level Creation

  • Provide an undo functionality with the arrow preview.
  • Remove the ghost line when draw is toggled off.
  • Make the title input box more obvious and prevent users from submitting works without a title.
  • Make the submit message more obvious.
  • Prevent multiple submissions of the same work. I am considering between detecting whether the canvas has changed or forcing the player back to the menu.
  • Either remove grid snapping or make it more obvious. Drawing-oriented players disliked not being able to line up points perfectly.

Menu

  • Make the scroll view more obvious.
  • Add functionality to delete specific drawings.
  • Add functionality to remix specific drawings. This would pair with forcing the players back to the menu upon submitting a new drawing.

In future expansions of this game, I hope to clean up the internals, improve usability, prototype new mechanics, and most importantly, publish DDRaw as a networked game with a database of drawings.

I’d like to acknowledge sheep for suggesting the name DDRaw.

Additional Images

Video

tli-FinalProposal

I plan to further develop my DDR-inspired drawing game for the final project. In particular, I hope to clean up the prototype’s mechanics and incorporate a Photoshop-like interface for creating playable custom “step-charts”. If I have time, I also hope to prototype additional ideas that I have planned, such as paint fill combos, curved lines, or a polar coordinate system. At the exhibition, I will display the game and allow visitors to create their own “step-charts” or play others’.

Part of my proposed final project involves cleaning up my prototype. This can be broken down into 1) exploring better line renderer options, 2) discretizing the drawing to a grid in to promote usability and playability, and 3) revamping the internal representations and structures to better promote custom levels. A stretch goal is improving the GUI visuals.

The core of my final project will be the level creation tool. This tool will directly reference popular image editors such as Photoshop. The minimal implementation for this would simply be drawing lines between points on the grid and transforming these lines to a “step-chart” for the game. However, I hope to include additional functionality such as a draw speed parameter that determines the minimum length of a line that can be drawn in the tool. Another nice feature would be viewing the game sequence on the side, either as a playback or as a snapshot if the user traces the line with their cursor. The inclusion of this level creator also necessitates creating a navigable menu, preserving created levels, and supplying an interface to select levels.

Lastly, as a far stretch goal, I hope to explore some mechanics I have in mind. The most developed of these would be a paint fill combo mechanic. If the player successfully follows a sequence of colored arrows, the enclosed shape formed by the line drawn by those arrows will be filled with the color of the arrows. Another possibility is creating a polar coordinate game mode.

Here are some sketches:

tli/jackalope-BarcodeProject

Jackalope and I played Pokemon Mystery Dungeon with a barcode controller we made from printed barcode text taped sloppily to a piece of paper and some human-unusable key bindings to a DS emulator.

This setup is with many, many disadvantages. Any game that requires sustained key holding to be playable is out. Any game with any timing requirement is out. Games with multiple simultaneous button presses are out, unless we create barcodes for every such button combination. Games that are just plain long and tedious by themselves are also out. And quite frankly, the barcode reader we use is terrible and has a success rate of about 50%.

On the other hand, this setup made diagonal movement much easier since we created distinct barcodes for diagonal input. This was particularly noteworthy in Mystery Dungeon, where diagonal movement is strategically noteworthy in contrast to the mediocre abilities of the DS to detect simultaneous button presses. Complicated button sequences could also be simplified by printing longer barcodes.

tli-telematic reflection

The first thing I learned is that many of my classmates have terrible handwriting.

Kidding. More seriously, the feedback framed my vandalism cairn in a way I hadn’t expected while I was implementing it at 3AM right before the deadline. For one, many people referred to it as a game even though I hadn’t fully intended for it to be a game. People also emphasized the collaborative aspect much more than I had actually thought about during implementation. I also received useful execution feedback, such as technical things to fix, usability improvements, and further exploration of this idea.

tli-telematic

My telematic project is a website where you can publish a text work and watch it get vandalized by visitors in real time. Once a work is published, each visitor is given a random word in the work that they can replace by submitting a text form. Every time a word is replaced, this is communicated to each client using sockets. The visitor also gets a new word to replace. This project is implemented in glitch.com using JQuery, Sequelize, and Socket.io.

This project’s concept has evolved far from its starting point. Originally, I was looking into text RPGs and sought to create a cairn where each visitor can add a new “page” to the text RPG. This text format naturally led me to look more into the implications of language rather than taking on a game-like structure. At that point, I fully intended to write some form of poem remixer in which visitors could do things like change the rhyme structure of a written poem or transform a word to a synonym, antonym, or other related word. This still felt lacking to me, because what was the point of this transformation? I realized that I could create a more interesting work (at least to me) by focusing on that transformative aspect. I have a long history with transformative works and the futile notion of authorship and content ownership on the internet. That, and it would be kind of funny to watch a troll vandalize your work before your very eyes.

So I opened up the format to freely change any single word in the published piece. A few limitations apply. Instead of choosing which words to change, the programming assigns you a random word. You can only replace words with single words–no spaces. In order to go to a different word, you must submit your change (or lack of change) for the current word. Additionally, the text supports HTML, which provides another avenue of mayhem in exposing the ugly syntax by getting rid of an end-bracket. Where I found the most interesting interactions to arise was in the networking. Once the work is published, the author is simply another visitor to the site. The author can see their work be vandalized in real time. Just as the vandalizers can bastardize words in the original text, the author can defend by restoring their original words or even communicate with the vandalizers by sacrificing a word with an angry, caps-locked “STOP”.

 

tli-telematic (check-in)

My telematic project is an online cairn where visitors collectively write a poem by adding or modifying lines of prose. Each line has a fixed last word that either rhymes with the previous line’s last word or does not. This app is implemented on glitch.com using JQuery, Socket.io, Sequelize, and possibly Rita.js.

So far I have set up the networking and database interactions as well as the webpage styling, but I am stuck on the details of how to design this idea. A couple variations I have in mind include:

      • A grid-based cairn. Internally, lines are stored in a 2D grid where one axis represents the depth of rhymes and the depth of non-rhymes. Each visitor would start at with the line at (0,0) and add to their poem by choosing whether the next line should rhyme or not rhyme. When the visitor stumbles across an empty cell in the matrix, the visitor can create a line at that location. The visitor may choose to print the poem generated by the traversal through the matrix.
      • A cairn with only 10 or so lines. Visitors can write (or rewrite) the text leading up to the last word of a line. Visitors can alternatively toggle the last word of a line. Each visitor may only do one of these two actions.

I think the latter idea is both more interesting and easier to implement, but the more I think about this the more alternatives pop up in my head. Regardless, I will probably advance this project in the second direction.

tli-LookingOutwards03

1. I’m Here and There [https://anthology.rhizome.org/i-m-here-and-there]

In I’m Here and There, Jonas Lund creates and uses a custom browser extension that reports every website he visits to http://imhereandthere.com/. I chose this as a Looking Outwards for my project because I’m interested in the idea of opting in to a cairn as a participant. There is nothing inherently tying the browser extension to Lund specifically in this project, so I imagined a version of this project where the browser extension was a public software that any user install and therefore opt in to. While this act of opting in is inherent in many of the telematic cairns we viewed in class, I’m interested in exploring this choice in particular.

2. Form Art [https://anthology.rhizome.org/form-art]

Form Art is Alexei Shulgin’s exploration of mundane HTML buttons and boxes as compositions. With this project also came a short-lived submission-driven competition wherein users were allowed to create their own form art. I chose this work as a Looking Outwards because I was immediately attracted to the abstract, reductive yet nostalgic visuals. I was also inspired by the concept of the button as an artistic element–as an abstract force that pushes you down a certain path. Viewing this work brought up strong memories of interactive texts, such as email, collaborative writing tools and text games. That Shulgin opens his idea and art form to user submissions is particularly important to my reception of Form Art as Internet art.

BONUS: Mezangelle [https://anthology.rhizome.org/mez-breeze]

I’m attracted to Mez Breeze’s Mezangelle for the same reasons as Form Art. I enjoy the poetry that arises from the reductiveness of the green terminal text, as well as the palpable undercurrent of programmatic rules that drives it. This work reminds me of the concept of readable code and code poetry. Much like using the HTML button as an artistic unit, I am fascinated by the idea of using functional blocks of text as modular visual elements.

tli-DrawingSoftware

My project for the drawing software assignment is a DDR-inspired drawing game. A cursor moves at a constant rate on a canvas. You must hit D (left), F (down), J (up), K (right) or SPACE (draw/stop) according to the arrow prompts in order to direct the cursor and draw an image. I prototyped this idea in Unity.

My conceptual starting point was agency in drawing. I thought about paint-by-numbers, trace-the-line games–activities that simulate drawing without any of the creativity and decision-making associated with drawing. I also thought about the distinction between art and craft, which is a tension I am very familiar with as someone who is more of a maker than a creator. I was reminded of instruction-based games like Dance Dance Revolution and typing games, which lead to a natural connection to chain codes in vector drawings. After switching back and forth between project ideas that only frustrated me, I settled on my final idea: a DDR-inspired drawing game.

As I developed the prototype, I became excited about unexpected conditions that the DDR system enforced. The importance of timing in rhythm games translated to the importance of proportions and length with contour drawing. The sequential nature of the instruction prompts forces mistakes to stack–one missed draw/stop prompt can invert the drawn lines and the travel lines for the rest of the level. Additionally, I chose to implement diagonal movement as hitting two arrows at the same time. If these two arrows are not hit simultaneously, the cursor will travel in the direction of the last arrow hit instead of the resulting diagonal.

These gameplay conditions that arise from just a rough reimplementation of DDR mechanics are already exciting, so I hope to expand this project either as a personal undertaking or as a capstone in the future. I hope to open this idea to sharing, collaboration and multiplayer play. My primary goal would be to create an interactive level-builder tool in order to allow people to create their own drawing sequences and share them. I also hope to explore paint-fill combo mechanics and utilizing non-Cartesian mappings.

tli-mask

Windows is a (mostly) cozy view of two windows whose blinds open and close based on your blinks. Outside, you can see the birds flying by.

A couple things prompted this idea: a desire explore Processing’s API in conjunction with FaceOSC, a play on the word “mask” as the object that covers a face and “mask” as the image processing tool, and a take on that cheesy saying “eyes are the windows to the soul”. I set out to create something minimalistic and cozy like all those pleasant app store games, but as I worked through implementation details I discovered an interesting tension between the demands that the software makes of the viewer and its desire to be cozy. I decided to emphasize this inconsistency by introducing sudden and uncomfortable changes when the viewer can no longer be detected by the camera. I didn’t plan for an involved concept behind this work, but perhaps there’s a reading in there about how we perceive our digital infrastructure and how we can become desensitized (or shall I say blinded ( ͡° ͜ʖ ͡°)) to the odd demands it may make of us.

Besides the conceptual reading, I’m pleased at how satisfying the interaction with the blinds is. You can see the gaps between the blinds as they fall down, and the cord to the side rises and falls opposite the movement of the blinds. For this reason, my performance is mostly just me having fun blinking at the program when it works and bobbing my head at the camera when it doesn’t.

tli-lookingoutwards02

Matthias Dörfelt’s Face Trade is a work that asks viewers to trade a mugshot for a computer-generated portrait, but the transaction is recorded a blockchain semi-permanently.

 

 

 

What interests me about this work is how much the artist gets away with asking from the audience. The trade-off is unnervingly real; not only does the work promise to record your mugshot permanently, you can also see the records for yourself at this website. The tension that the work induces is very real and, for me, very hard to separate from the artistic intention of the work. I can’t help but recoil instinctively and accuse the work of being malicious in itself. I think the audaciousness of this piece makes it successful, and I would like to take away some of Dörfelt’s nerve in my future work.

Looking into Dörfelt’s past work reveals a deep practice in generative art and a recent exploration of blockchain as an artistic tool. This helps me contextualize the choice of using computer-generated portraits as the commodity of the transaction. Face Trade‘s generated portraits seem like an arbitrary trinket that just fills the description of “commodity which the user trades for” (which may very well be the point), but I can see how these portraits build on top of Dörfelt’s previous generative sketches. It’s interesting that in some ways the viewer is paying their identity to view Dörfelt’s next iteration as a maker.