“Comfortably lying on a couch in any position you want, stripping a Cardboard VR on your face, bearing your arms behind your head, and let your tongue take over all the snapping, just like a hungry frog boss.”
Here comes my next experiment. The tongue controller is already working, the player has to reach his/her tongue out and touch the controller, and it will register a hit in the game. The feedback, SFX and Visual, has to be satisfying to make it a worthwhile experience.
Makey Makey Go is able to simulate a touch easily with just 1 contact (capacitive touch), in this case, it is the player’s tongue. This setup will require a USB adaptor from Makey Makey Go to the android phone.
The “Dogs of War” heading includes the Regiments of Renown. The name “Regiments of Renown” was used prior to the introduction of the Dogs of War concept for certain units led by a particular hero and they were given rules in White Dwarf and sold as boxed sets. Again there are limitations on use, for instance regiments such as Bugman’s Dwarf Rangers or “Prince Ulther’s Dragon Company” can only fight with groups from their own race. “Ancient Astronauts” can join any race in the world of Warhammer because they are the creators of all.
Ancient Astronauts
The ancient astronaut is a scientific hypothesis that posits that intelligent extraterrestrial beings have visited Earth and made contact with humans in antiquity and prehistory. Proponents suggest that this contact influenced the development of human cultures, technologies, and religions. A common claim is that deities from most, if not all, religions are actually extraterrestrial in nature, and that such visitors’ advanced technologies were interpreted by early humans as evidence of divine status. Once a while a scout unit is deployed to Earth for routine survey. The members of the unit will participate various human activities in disguise and report back to their superiors.
Acron Riders coin dispenser and capsules digitizer
Acron Riders – Rise of Evil Chestnauts is designed to be a half physical and half digital gaming experience. During the gameplay, the player will be rewarded in real coins. The player purchases power-up capsules from a gashapon machine (coin vending machine) with the coins. These capsules can be used strategically in the digital game through a custom digitizer.
Acron Riders coin dispenser
priority 1: Get a coin hopper to work with Arduino Having a machine that can spit coins when there is an upgrade is the most crucial element to the success of this game. I am going to test this first. I call it an “up-coin dispenser”, a part of my Acronrider Physical Power-up System (APPS) that I am building for my 1/2 digital shooting game called Acronrider – Rise of Evil Chestnuts. The most difficult part is to get the coin hopper to work. I had seen a few youtube videos of people controlling a coin hopper with Arduino, so I was confident. However, I wasn’t able to find any detailed documentation of how it actually work together. At one point, my research had led me to coin hoppers with built-in CCTalk or serial communication. However, I realized that they are not necessarily friendly for Arduino both voltage (12-24v to 5v) and data parsing wise. I decided to do some virtual autopsy on coin hoppers online. Most of the coin hoppers, without the fancy CCTalk and serial interface, are made of four basic parts: a coin dial, a geared motor, a light sensor, and a small circuit board that manages power and standard I/Os to other vending modules. I began to search for a coin hopper that outputs their light sensor value through their standard I/Os because if I could read the pulse from the light sensor, I would know exactly when to stop the motor.
priority 2: Get my capsule vending machine to use game tokens instead of .25 cents. The current system (up-coin dispenser + capsule vending machine) works well with .25 cent coins, but that is not ideal for me. I prefer the game tokens. Normal game tokens are slightly bigger than .25 cent coins and about the same thickness. The up-coin dispenser works for both, but the vending machine doesn’t. I have to either modify or 3D print a coin dial that works with my game tokens. After close evaluation, I decided to sand it down with my Dremel tool. It worked like magic.
The token I have is a 0.984 token according to this chart:
priority 3: read 3 serial ports at the same time on Arduino Had a brief glance on software serial on Arduino Uno, didn’t think it was a roadblock. It turned out to be problematic with a regular Arduino. I use 3 Sparkfun RFID USB boards to read 3 acorn capsules at once but separately, so basically, I needed 3 serial ports. That is all I needed on the board so it was a waste to switch to the bulkier Arduino Mega with 3 extra built-in hardware serial ports. What I realized with the software serial library is that it allows multiple ports but only 1 port can be accessed at 1 time, and the data arrived at the deactivated ports are discarded. That was disappointing. It worked well with 1 serial, but when I added 2, it failed to work correctly.
After some trial and error, I eventually got it figured out. I combined 1 hardware serial port, 1 software serial, and 1 altsoftware serial port to get the job down.
I also decided to make the acorn digitizer a separate piece than a part of the controller. I had originally thought this to be a lightgun game, an upgrade from the lightgun I built at MFDT.
Priority 4:Laser Pistol
02/18/2015 Sketched out all the possible acorn power-ups, planning to 3D print the parts. 03/02/2015 Currently working on the casing of real-time physical power-up system. 03/09/2015 Dissamble vending machine coin mech and took out the coin wheel out.
Quest-to-Learn teachers, Limor Levy and Andrea Henkel were leading the “tinkering” part of the boss level (12/06/13) and interested in having a digital simulation of the tinkering experience in SMALLab. She showed me a web game called Tinker Ball as a reference to what they had in mind. The game was made by Lemelson Center for the study of invention and innovation. In Tinker Ball, the player has to build a contraption to guide a little ball into a randomly placed bucket at the bottom of the screen. This is a potentially effective learning mechanism – theory building and iterative process – if bundled with properly design supporting lesson plans.
My biggest dissatisfaction from a game developer’s point of view is the poorly integrated physic simulation. The physic interactions between the ball and all the tools are far off from the reality that they stop learning moments from stimulating. I immediately accepted the proposal and took on the challenge to develop this new SMALLab game in two weeks. I’ve recently tested out a new development pipeline to build games and it involves a physic engine, so this project came at the perfect timing! SMALLab hasn’t had any game using a physic engine before because the concept of gravity might be confusing on a floor projection. Now is the time to find out.
The new SMALLab game is designed to have two phases. They are the tinkering phase and simulation phase. Players will be going back and forth between the two phases to improve their contraption until the ball successfully falls into the goal bucket in the simulation phase. In terms of game control, some of the objects in this game require angle adjustment and it’s challenging to have two separate control states – position and rotation, on a buttonless SMALLab controller. After a few testings, I decided to have those objects start rotating on itself once the player picks it up and stops rotating after the player drops it off. This way, the player only has to worry about one thing at a time. During the testing, I thought of making use of the rotation data from Optitrack. However, because I am developing this game remotely, I decided to save this task for later.
After sent in the first prototype and discussed with Limor over the e-mail, I realized what she envisioned was more complicated than Tinker Ball or maybe her imagination had grown since last time we talked. It has become more like a Rube Goldberg machine builder. The first time I saw a Rube Goldberg machine was in an old Jackie Chan movie called “Drunken Fist”. My most recent trendsetting experience with Rube Goldberg machine was by Shogakukan’s Pitagora switch (ピタゴラ装置) on YouTube. At first, I was worried the current prototype is lacking the defining element of a Rube Goldberg machine – the chain reaction. Tinker Ball type of game reminds me more of LEGO’s Great Ball Contraptions (GBC) or games like “Screwball Scramble” than Rube Goldberg machines. I thought that a Rube Goldberg machine focuses on triggering different contraptions with various types of energies like the game “Mouse Trap”. However, after researched further, I was convinced that creating a modular contraption to guide the same ball to a goal bucket is a type of Rube Goldberg machine.
The origin: Rube Goldberg’s “Professor Butts and the Self-Operating Napkin”
I finished coding the game early and decided to work on the visual of the game before the SMALLab testing and rehearsal which is the week before the boss level. The visual presentation of the game is one of the many elements I utilize to build engaging play experiences and it is often inspired by the overarching theme of the semester. However, the upcoming boss level doesn’t have a theme to follow so I came up with my own look & feel – creamy pastel colors and wallpaper patterns. Because of Pitagora switch videos, I was determined that this game needs a Xylophone background music. Iva made me the perfect one in minutes with her music composing magic.
Limor and Andrea designed an amazing excise for students prior to the SMALLab experience. They made a paper version of the game and have the 6th graders cut and paste the paper tool pieces into a design that they imagine would take the ball to the goal bucket. This is done a day before SMALLab. Till this point, they have not seen how each tool actually behaves in matchbox tinker so they have to come up with their own theories around each tool. The result of this exercise is an amazing collection of creative solutions to one single problem – ball in the bucket. This preparation built up such a fun and engaging need-to-know for students to want to find out if their own crafty design actually works out in the digital simulation.
The day has come, anticipating students surround the white mat with their own design in hand and eyes on the glowing projection in the dark SMALLab room. We ran the usual schedule, 8 home bases in one day, and that is about 120 students in 4 consecutive 45-minute sessions with breaks in between. After Andrea explained the game to students, we ran the first simulation. I heard a student yelled out and I continued to hear it many times throughout the day in different sessions, “This ball is so bouncy!” They noticed the differences in behaviors between their imaginary ball and the ball in the game. Many of them also realized the dryers are stronger blowers than what they had originally imagined in their paper prototypes. By the way, gravity on the floor wasn’t a problem at all!
I noticed an interesting embodiment piece that some students had difficulties getting the angle they want when placing the tool down in the workspace. This is their 2nd time in SMALLab and not very good at working with their body in the space yet. In order to get the right angle, the player has to predict the rotation and side out the controller early to cover up the delay caused by the hand motion. This requires good eye-hand coordination and it was definitely a challenge for some students.
“Let’s just build a tunnel for a ball to go down!” and this happened…
The ultimate next step is to have the working contraptions printed out from a 3D printer so the students can see their own creations in action in the real physic space. This will bring the learning home and to the next level. It rounds up the play experience in full cycle with paper prototypes, digital simulations, iterative designs, and real working products.
12/03/13 Basic build is finished, sent an e-mail to Limor for more ideas for artifacts that are relevant to the boss level players. If spacebar is pressed (drop a ball) while dragging, makebody() of the dragging artifact will not run therefore ball goes right through. 12/12/13 Update to Ver.2 for the desktop application, change the control to mouse-friendly. 12/16/13 Major slowdown on gameplay when first tested on the SMALLab computer because all the PNGs used in the game. Switched to OPENGL in 1.5.1 solved the problem. 12/17/13 When the controller lost tracking while carrying a tool, it takes the tool to (0,0). When this happens to a cog, it simply disappears and left with a small pink circle at (0,0). Solved by repositioning all the tools that land on (0,y). “Where is the ball?” heard that a lot during their first building phase. When two objects collide, they also make the ball impact sound.
Deign & Technology mailing list is a treasure trove for game ideas. Yesterday we have a new thread on whether or not we should purchase a refrigerator. Sven replied with this awesome idea of a walk-in refrigerator. People start to contribute to this fun idea, here are some of the highlights.
“This will be a walk-in refrigerator, and will replace the Director’s office over in the corner. We will each have a large locker in the refrigerator. There will be a side for ice-cream making, and another area housing the frozen vegetable section. The whole room will be videotaped 24 hours, and will become part of an international new media experiment on refrigerative theory. And there will be robots strewn about, some with identifiable duties, others more mysterious.” -Sven
“And if the fridge incites bugs to visit D12, Mr Ayo can use them for his garments for the future. Everybody wins. A Soda Machine would be nice too.” – Daniel
“And a city bike station instead so people can bike around for food.” – Aero
…
and I added the wardrobe to Narnia at the end.
“…And if you pass the ice-cream and vegetable section, you will run into a closet that takes you to Narnia.”
This is very inspiring on a Sunday night so I decided to make it into a RPG game.
There is a set of armor and weapon to collect. Power up yourself with popsicles and vegetables and see if you can beat the optional boss!
PC Only: Quest Of Procrastination
PUSH is a Flash application designed to explore concepts surrounding Simple Machines, which is integrated into the Q2L 6th grade math and science domain “The Way Things Work”. PUSH was built specifically to create game-like learning experience through collaboration and embodied play. In PUSH, students work collaboratively to help a group of digital creatures to push an object (in this case a hat) up on a hill by physically exerting ‘force’ through a set ‘distance’, at the same time tackling a common misconception in mechanical work with inclined planes. The support provided by teachers to the students in the space in terms of discussions and walk through, accompanied by worksheets, creates a different level of learning experience for the students.
PUSH is divided into four parts – title screen, level selection, gameplay, and result/formula screen. With the teacher’s guidance, students will learn to play the game utilizing their body in the SMALLab space. The students will have to make a decision on which inclined plane will require more work than another. They will then physically pushing a digital hat up on different inclined planes. By going through PUSH, the students will soon be confronted with the misconception about an inclined plane lessening the amount of work done. An experienced teacher will find moments during PUSH to take advantage of opportunities for learning. An example is when students are pushing the hat up on the hill with the digital creatures, only the force that goes along the inclined plane will be counted. In order to do better in the game, students have to “push” (actual physical movement) along the path of the inclined plane. This is a great opportunity for the teacher to step in and reinforce the fundamental concept of mechanical work.
The embodied play component in PUSH is made possible by using the Gaming SMALLab platform. It is a mixed-reality learning environment that empowers the physical body to function as an expressive interface experiencing custom-built scenarios and media-rich content through full-body movement and gestures. PUSH reads optitrack data through a custom middleware because Flash don’t have access to UDP ports. The middleware parses the data from Tracking Tool and send them to Flash using a socket server.
12/05/13 Ran PUSH for Leah, there were difficulty translating position data precisely into PUSH. In PUSH it was mapped to 1280 pixel wide but the screen resolution of the new projector is set to 1024 pixel wide. After configuring the resolution back to 1280 pixel wide, it fixed the position problem.
Old versions: [ver.17]Mac desktop version: Proteincraft [ver. 1][old]Win32 desktop version: Proteincraft_win32bit (see update details at the bottom of the page)
How to play: Mouse: Drag’n Drop tRNA Up key: Switch between Shape mode and Text mode Right arrow key: skip to the next codon set on mRNA ESC key: exit the game
In Spring 2012, SMALLab team at Quest 2 Learn New York worked with our Living Environment teacher, Dan Bloom, to create a game scenario about protein synthesis. After the kick-off meeting with Dan and a few rounds of quick prototyping on the subject, I decided to narrow down the multi-level gameplay idea and focus solely on the translation portion of the synthesis. According to Dan’s experience, students have more difficulties with translation than transcription because it is harder to visualize the relationship between codons and anti-codons in the classroom. Through the use of scale, sound, visual cue, collaboration, this new SMALLab scenario creates an immersive playground for students to practice their knowledge on translation.
Proteincraft puts students in the moment when DNA translation happens. In order to succeed in the scenario, students must help Messenger RNA(mRNA) find the right Transfer RNA(tRNA) by matching codons with their correspondent anti-codons. Every successful match consists of three steps. The first step is to read the next codon on mRNA and to find the matching tRNA. Secondly, brag the tRNA to ribosomes. Thirdly, crank the white circle on ribosomes to the left side to advance to the next codon. Repeat these steps until all the codons are matched. The teacher moderates the entire experience and interrupts at moments for learning opportunities. In the picture above, Dan is pointing out to players that in order to start the translation, the initial tRNA (met) has to be found first.
In addition, this game can be viewed in the text mode. All the color and shapes are replaced by the black-and-white letters that represent each of the four bases in the textbook. Teachers can switch between modes by pressing the UP arrow key. Here are notes from Dan that becomes the guidelines of the visual system of both modes in Proteincraft:
1) The bases in DNA should be shaped so that they can fit in to each other. ====T (thymine) – blue, be shaped with a pointy triangle on the end ====A (adenine) – red, be shaped with an inverted space for a triangle ====C (cytosine) – yellow, be shaped with a semicircle on the end ====G (guanine) – green, be shaped with an inverted space for a semicircle 2) The bases in mRNA and tRNA should be the same except instead of T, there is… ====U (uricil) – purple, should be shaped to fit into A
The scenario was a success with Dan’s class. Students had no problem warming up to the game because all the colors, shapes, and letters are inspired by diagrams Dan showed in the classroom. During the gameplay, teams of students have to find an efficient way to work together in SMALLab. Some teams assigned their teammates different roles – capturers, crankera, and translators while other teams spread out in the space like football players all waiting for the right tRNA to swim by. Spectators definitely play an important role in the overall play experience, they give verbal suggestions to the player team – “AUU not UUA”, “Green-Yellow-Red”, “tRNA has no T in it”, “tRNA let’s go!”.
Visual and sound design:
At the beginning of the research, I watched many scientific renderings on protein synthesis. Surprisingly, none of them look the same graphically even though they all look “realistic”. All of them are subjective and technology-dependent. It is more like a strategy to attract longer attention span with realistic-looking visuals than anything else which is understandable. I made an animated gif of my favorite rendering so far:
Dan showed me diagrams and illustrations that he used in the classroom. They are mostly represented in geometric shapes and are carefully color-coded. That set me free, I am going for color-coded geometric shapes! – to connect the scientific facts to design elements. Even though they are geometric shapes, they still follow the principles of translation dearly. Instead of coming up with a fictional realistic form, I draw a connection between Dan’s diagrams and the design elements of Proteincraft’s visual system, e.g., each of the four bases is represented visually by a unique shape and a unique color. The shape of an amino acid is dynamically determined by the shape combination of its three bases.
The tRNA and mRNA in this game synthesize sounds too. Usually, SMALLab game scenarios are designed and produced in less than five weeks, so we usually don’t have time to do serious sound design. However, during a check-in meeting, we decided to bring the connection to sound elements too. Claudio’s sound design took the relation between codons and amino acids to the next level! When the player successfully brings back a correct tRNA, the game will play three tones that match the codon combination. Claudio designed the tones and a matching ambient music that really gives the play experience an awesome upgrade.
SMALLab Version:
Desktop Version:
10/18/12 proteincraft playtest with 9th graders, suggested moving mRNA to the top of the screen to avoid shadow cast by the projector in SMALLab 11/20/12 project release postponed due to a scheduling conflict 01/18/13 SMALLab Proteincraft released 06/11/13 plan to convert proteincraft to desktop and android. 06/18/13 [android] curveVertex() slow app overtime. Image memory leak on android still a problem. 09/27/13 desktop demo completed. 09/28/13 Desktop ver.1 released (Mac and Windows) 09/29/13 Desktop ver.15 released (Mac): implemented amino acid names(desktop ver. only feature), text mode visual tweaked 09/31/13 Desktop ver.17 released (Mac): fixed a major data parsing error that caused amino acid name mismatched 11/14/13 Ran SMALLab version for 9th graders made the following changes: ===1. fly speed of tRNAs now starts slow and gradually speeds up ===2. the visual of crank mechanism now flashes when ready to use ===3. games now automatically change to text mode after the 8th tRNA is found ===4. minor visual tweakings
11/19/13 Desktop ver.20 released (Mac): minor visual feedback improvement, added replay function
11/05/13 Built a prototype with Processing 2.0. Openprocessing downloads have weird compiler problem solved by duplicating the project and removing the code folder inside the project folder.
11/07/13 Playtest: arms are too powerful – death on touch! and not much to do for the Kinect player.
Old Notes: 10/30/2011 Been thinking about a 2 player co-op game in which player 1 uses a Kinect sensor and player 2 uses something else e.g. a regular game controller. The cover art of the Monster Rods model kits is a great example of this idea. In the picture below, player 1 controls the monster on top and player 2 drives the car.
With AR markers, we can easily put the Kinect player’s skeleton/avatar on the tabletop. Player 2 can take control of the AR Marker and player 1 can be the summoned hero on the card.
10/18/13 Been looking for ways to create a Monster Rods demo. However, a 3D driving game is out of my lead. Instead, I decided to create a top-down space shooting game for proof of concept, and that reminds me of NES Twinbee.
10/23/13 Space muscle car with animal influence in style. 2 player co-op Asteroid-like game.
Chickensaur – a new Jurassic creature created from a conversation in Major Studio 1. I drew the first version on the wall, but didn’t like the way it was mutant together. I did a few more sketches after the class. A mini-game of this creature ran for its life in doomsday is inevitable.
How to play:
Right gear shift or key 0-9: change to control different parts/function on Chickensaur =====0: Energy: Waggle the steering wheel (or alternating ‘z’ and ‘x’ key on keyboard) to generate energy. =====1: Sonic bolt: Use the steering wheel to tilt the head and honk (‘h’ key) to shoot a sonic bolt. Be mindful that each shot costs certain amount of energy. =====2: Plasma shield: Press star button (‘s’ key) to shield Chickensaur with plasma, great protection against flaming meteor. =====3: Show up after evolving to stage 2, Chickensaur gains the ability to fly. Steering wheel controls the heading; honk button flaps the wings; and star button spits fire
I used this slice-game as a demo to introduce the week long design-under-limitation excerise with the Adventure Explorer game controller a couple weeks later. Students used the game controller as an Universe creator, a virtual reality navigator, a sound only storytelling machine, and a shot gun – yes, a shot gun!
I had a meeting with Hyunjee Koo, a student in Anezka’s Major Studio II, about a game she is making for her final. It is about raising awareness of crimes specifically targeting women who are commuting late at night.
Her second iteration has great potential to be a fun serious game. Her research brought a few interesting elements into the mix. She found a color-coded alarm system used by the military to acknowledge different states of awareness for the soldiers in combat. She put together amazing assets of different sites to stage the potential crime scenes. She has information about the crime and how to prevent them. Her attempt was simple and straight forward. When the game starts, a potential crime scene is shown. The player has to pick what state of awareness does the potential crime scene implies. However, the moment of meaningful choice is broken here because what the scene implies is really up to the player’s interpretation but there is only 1 correct answer for each scene.
The quickest fix is to define the meaningful choice better by switching a few elements around and maybe bring in a timer. She has information about the possible threats and how to eliminate them in potential crime scenes – underground parking garage, household, shopping mall, and late-night park. We can design each scene with these threats embedded in the graphics. The player has to circle these possible threats out under a timer, the original mechanic but with a kick, to prevent the crime from happening. Here is the next iteration.
05/20/2013 stop the time when player find all threats before time is up.
