Final Project: 42

The Concept: Why and How

For my final project, I wanted to create a game that would combine Processing’s visual capabilities with Arduino’s hardware ones. As an enthusiast of RPGs (role-playing games), I decided that I would attempt to make one. In doing so, I would have to make sure that it includes some of the defining features of choose-your-own-adventure/RP games: an open world where you have the ability to make choices for your character, a sense of randomness, multiple possible outcomes (a few of which are positive), non-linear storylines, etc.

At first, I wanted to incorporate these features into my game by making it a text adventure combined with photos, videos, and a storyline, however that proved to be taxing because I would have had to include at least 27 different scenarios in my code which I wouldn’t even be able to randomize because of how I had specific media in mind for each chapter of the game.

I decided that I would make a 2D RPG modelled on games like Pokemon, which shaped my childhood. I would incorporate Arduino into the project by means of a controller modelled on the DualShock, though a simpler version with Up-Down-Left-Right buttons and vibration-feedback (by attaching two off-balance motors to the inside and using the Servo sweep code to get them to vibrate). 

The Code 

Coming from a background that involved little coding, the hardest part of the project was writing the code for the game, especially while trying to make the map infinite. However, I was eventually able to code something that resembled the games I intended to model mine on. 

What I Changed and What I Would Change

Whilst working on the Arduino controller and testing it out, it dawned upon me that the use of the buttons as controls was inefficient as it meant that, for example, whilst trying to “attack an enemy”, one button would have to serve multiple purposes which just isn’t possible. The vibrating-feedback aspect of it worked out perfectly but since the buttons didn’t and they were a key feature of the controller, I was forced to scrap it at the last moment. If I had the chance to redo the project or improve upon it, I would aim to create a wearable with vibrating-feedback instead of an entire controller so that the same experience can be obtained in a much more effective setting. 

After testing my game out with my friends, I was told that while it retained many of the elements of games like Pokemon, the fact that it lacked a proper storyline or an end-goal made it tiresome to play, which I agreed with. In order to remedy this, I inserted a funny video that would play only if the player reached a certain level, however, I seemed to have made the game to difficult because neither I nor anybody else was able to get there. An improvement would be to add a text-based storyline to each part of the game as well as “rewards” at each level so that it becomes more interactive, less tiresome, and the surprise element is retained.

Final Thoughts

I called the game “42” because in my favourite book The Hitchhiker’s Guide to the Galaxy, the number is the “ultimate answer to life, the universe, and everything” and a mystery at the same time. One of the main elements I knew I wanted my game to have is that of surprise, whether in the form of an unusual storyline in a text adventure game or a lack of an objective in the RPG I ended up making. However, it now dawns upon me that not everyone appreciates not knowing what is to come or when it’s coming while playing a game that, from all of its other aspects, seems like a typical 2D RPG. During future game-making, I will be sure to think about how a game can be surprising but not frustrating, which I felt was a big drawback to mine. 

Final Project Proposal: Interactive Choose Your Own Adventure Game

Concept: 

I would like to create an interactive 5-7 minute Choose Your Own Adventure game that incorporates both Arduino and Processing. The player’s choices will decide the course/outcome of the game, in terms of the scenes they will encounter or further choices they will have to make. I hope to film the scenes myself and use Processing to add on-screen transitions, buttons/a menu, text, images, sound, etc. Arduino, on the other hand, will be used by means of sensors, to relay the player’s choices to the game. I may incorporate the motion/colour tracking feature on Processing for the same purpose.

Technical Requirements/Equipment Needs:

  • A projector
  • A white wall/screen for the projector
  • Ultrasonic sensors/infrared sharp distance-measuring sensors
  • Around a meter of space for the player to walk around in
  • Pushbuttons (if they are used as controls)/joy sticks/potentiometer

5 Challenges:

  • The code: arranging the scenes in such a way that they play in the right order/when the right options are chosen and adding on-screen transitions/menus/options that do the same.
  • Making sure the sensor used to measure the distance of the player from it works instantly by registering range limits and relaying the information to Processing so that the transitions work.
  • How accurately and consistently colour/motion tracking can be used to relay the player’s choices to the game.
  • Limitations of the physical space and the arrangement of the sensors, screen, and other equipment in relation to the player.
  • The coherence of and communication between all the elements involved.

Specifications:

(Rough) Block diagram for the software:

 

 

 

Recreating from Computer Graphics and Art: DNA!

Click!

 

Orchestra in a Box

Concept

The MusicBox is a project using metal circles along with analog & digital inputs and outputs to produce unexpected “Tinkle” sounds, which are played in relation to a standard tone originating from a piezo buzzer. It shows how ‘real-world’ sound is different from the “digital” aspect of an electronic device as the buzzer.

 

A servo attached to pin 3 moves to certain angles so that it will touch the metal circles hanged in the box, producing a tempo. I defined two positions of the servo and two waiting times (one longer and one shorter) which I use to create the tempos.

We used the following materials:

  • 1x potentiometer
  • LEDs
  • push buttons
  • 10KΩ resistors
  • jump wires
  • 1x Piezo buzzer
  • Arduino UNO board
  • USB cable
  • A cardboard box
  • A wood board

Code for the Servo

 

Code for the Buttons

In Action

Issues

  • The music from the Servo mechanism and the speaker didn’t synchronize like we wanted them to. This can be resolved by writing the code for the Servo, in terms of its delays (AKA the rhythm), in accordance with the tempo of the music.
  • I originally wanted to use 3 buttons that would play 3 different songs when pressed (as with the 2 in the code), but what actually occurred was that when one of the buttons was pressed, both songs would combine and the play and nothing would play when the other was pressed.

On (Good) Documentation

Documentation is more common than one would think, present in the forms of recipes, furniture assembly instructions, and DIY tutorials on YouTube. It’s an important part of the creative process, not least because it serves as a reminder of its (the project’s) specifics. It allows just about anyone to do what the original creator did, by means of a set of instructions, representations, photographic evidence, etc., which is a significant part of the maker culture that IM was born out of. Moreover, documentation helps the creator(s) figure out where they went wrong if they do not achieve the desired result, or how to get to a certain result (again) if they got there “by accident”, or what method produces the best results(s).

The question, then, arises: what comprises good documentation? There is a general answer as well as a specific one.

The general one comprises the following points, regardless of the audience and the topic/content. Be:

  • Systematic and organized.
  • As specific as possible.
  • Representative.

Specifically, however, the list of things to keep in mind when documenting differs depending on the audience, mine being the Intro to IM class and anyone who finds their way on to this blog by Googling related terms.

Firstly, in addition to posting code, photos/videos, a list of required materials, and the instructions to a project, a schematic diagram, as Professor Shiloh says, adds much to the quality of documentation, simply because it depicts the components and connections in a circuit clearly and straightforwardly. Secondly, using terminology known to my audience goes a long way towards making instructions clear-cut. Thirdly, since we, as a class, (generally) work with the same materials, it helps to refer to other/special components as specifically as possible. 

On a final note, I agree with what Joel Spolsky says because writing blog posts for this class has led to me, among other things, better remembering what I learn in class and becoming a better/more concise writer.

 

 

Silence of the Lamps (Switch = Hannibal?)

  For this project, I used (momentary) pushbutton switches and LEDs arranged in a pattern to make something artsy. 

Materials Required:

  • 7 LEDs: 2 blue, 2 green, 1 red, and 2 yellow
  • 11 wires: 1 red (for the positive terminal), 1 black (for the  negative terminal), 2 white (for the pushbutton switch), 7 miscellaneous (preferably of the same colours as the LEDs)
  • 2-3 pushbuttons
  • Breadboard
  • 7x 330 Ohm resistors, 1x 10,000 Ohm resistor
  • USB cable
  • SparkFun RedBoard
  • A laptop (or another power source)

Procedure:

Step 1: Connect the RedBoard to the laptop using the USB cable.

Step 2: Connect one of the ends of the red wire to the 5V pin on the RedBoard and the other to one of the pins in the “positive” column of the breadboard.

Step 3: Connect one of the ends of the black wire to a GND (ground) pin on the RedBoard and the other to a pin in the “negative” column of the breadboard.

Step 4: Stretch a blue LED’s leads apart, connecting the longer one to a pin in the right middle column and the shorter to one in the left middle column of the breadboard. Do the same with a 330 Ohm resistor except with a pin in the “negative” column and one in the same row as that of the shorter lead of the LED.

Step 5: Taking a wire of the same colour as the LED, connect one end to a pin in the same row as that of the longer lead of the LED. Connect the other end to one of the numbered, digital pins on the RedBoard.

Step 6: Repeat Step 4 and Step 5 with the other LEDs, arranging them in the shape of a smiley.

Step 7: Fit the pushbutton onto the breadboard, one leg to a pin on the right middle side and the other to one on the left middle side.

Step 8: Connect a wire to a pin on either side (=2 wires) of the pushbutton (in line with its legs), with the other ends connected to a pin in the “positive” column of the breadboard and a numbered, digital pin on the RedBoard respectively.

Step 9: Connect one lead of the 10,000 Ohm resistor to a pin in the same row as that of the “positive” column wire in Step 8 and the other to a pin in the “negative” column of the breadboard.

Step 10: Type the following code into Arduino:

And voilà, you’re done!

The Smiley in Action:

 

A Final Note: 

The lowercase letters represent the numbered, digital pins on the RedBoard.

As you may have noticed, I used just one pushbutton switch as an input when I was supposed to use multiple. My solution to this (as in the photo) was to add another pushbutton to the circuit and code it so that it would either turn the LEDs off or take over control of the smiley’s eyes.

Source: Warner Bros. Entertainment Inc.

Critique, Don’t Attack! \ (•◡•) /

Before I learnt of TAG, whenever I wanted to critique a person’s work, I would use the ‘T’ and ‘G’ parts. I would first tell the creator something I like about their work, followed by a suggestion.

The ‘A’ part of TAG, however, is new to me and I found it a bit unclear, but here is how I interpreted it (and the way that makes the most sense to me): if you feel like an addition or a subtraction to/from the work would enhance it, ask the person whether they considered it or what they think could improve their work. If they respond saying what you wanted to suggest, then you can just agree with them without having to suddenly switch from a compliment to a critique. Alternately, I also interpreted it as politely asking them if you may offer a suggestion, and if they say yes, proceeding to ‘G’.

I suppose using ‘A’ would make my critique politer, so I’m going to try it out sometime (probably in class) and note the result(s) if any!

A few things I like to keep in mind while critiquing work are to:

  • Critique the creation, not the creator!
  • Be diplomatic—use positive language and suggest instead of stating—and listen.
  • Be objective!
  • Be specific!
  • Use opinion words and phrases.

And finally, it is important to make sure that feedback has been asked for (or is expected) and to remember that while praise makes you feel good, (constructive) criticism makes you better (at doing what you do)!

The Cell Phone Anti-Detonator Switch ᕕ(ᐛ)ᕗ

The inspiration behind this project is the fact that I am a phone-dropper. This project serves as a means both of reminding me not to drop my phone as well as preventing any possible drops.

Materials Required:

  • Aluminium foil
  • Copper tape
  • 4 wires (2 black, 1 red, and 1 blue)
  • Breadboard
  • LED (preferably red since the colour is usually associated with “danger”)
  • Sellotape
  • 330 Ohm resistor
  • USB cable
  • SparkFun RedBoard
  • A laptop (or another power source)
  • And, of course, a phone you don’t want to drop (with earphones connected to it)

Procedure:

Step 1: Connect the RedBoard to the laptop using the USB cable.

Step 2: Cut an approximate rectangle out of the aluminium foil, its measurements matching those of your phone*, and tape it to the back of the phone with sellotape (only on the edges).

*Note: I taped foil onto just half of my phone due to the PopSocket on it, but covering as much surface area as possible would ensure that the switch works to its fullest potential (pun unintended).

Step 3: Connect one of the ends of the red wire to the 5V pin on the RedBoard and the other to one of the pins in the “positive” column of the breadboard.

Step 4: Connect one of the ends of the black wire to a pin in the “negative” column of the breadboard. Use copper tape to connect the other to another black wire in order to make sure it is long enough to coil around a pair of earphones connected to the phone, and further, to make contact with the foil.

Step 5: Connect one of the ends of the blue wire* to the GND (ground) pin on the RedBoard and the other to the centre of the foil (sideways) using a strip of copper tape.

*Note: I used a black wire for this step as well but found it hard to differentiate between this wire and the other one without following them all the way through to the other ends, so using a wire of another colour would be more efficient.

Step 6: Stretch the LED’s leads apart, connecting the longer one to a pin in the “positive” column and the shorter to one in the middle of the breadboard. Do the same with the resistor except with a pin in the “negative” column and one in the same row as that of the shorter lead of the LED. 

And voilà, you’re done!

The Anti-Detonator in Action:

To test out the switch, position your phone at an angle between 0° to 180° (as shown in the picture), simulating how one would normally hold a phone while using it.

Then, tilt it at an angle >180°* and watch the LED glow as the black wire touches the foil, closing the switch!

The tilt is supposed to mimic a phone falling backwards*. In such a case, the LED would light up just in time to warn the user not to let go or in case they do, to be prepared to catch the phone!

*Note: The phone isn’t tilted at an angle >180° in the photo because I didn’t take the possibility of a false alarm (as pictured) into account until I started writing this post. For the switch to work as intended, however, the black wire must be coiled around the earphones so that it touches the foil only when the phone is tilted at an angle >180°

A Shortcoming:

The wire coiled around the earphones doesn’t always touch the foil enough or at the right angle when the phone is tilted, resulting in the switch not closing and thus not working as intended. Moreover, the need for it to be wrapped around earphones is inefficient as it may unwrap or one may not always have earphones with them.

And How to Overcome It:

Instead of coiling the wire around earphones, tape the insulated part 1/4th before its end to the foil with copper tape, facing towards the top of the phone. This will ensure that, for the most part, the wire will make contact with the foil when the phone falls (is tilted).

Final Thoughts:

The most challenging part of this project was coming up with an original idea, but I resolved this by thinking about a problem I face on a daily basis, which I can, at the very least, attempt to fix by building a switch. Plato was right: necessity IS the mother of invention!

Source: Warner Bros. Entertainment Inc.