KARATE – Experiment 5 – Book++

bannerkarate

Team members: Dimitra Grovestine (3165616), Salisa Jatuweerapong (3161327), Siyue Liang (3165618)

January 17, 2019

 

INTRODUCTION

Our group picked the book Karate: Questions And Answers.  It introduces the history, development, impacts and the essential practices of karate.

DESCRIPTION

KARATE is a virtual karate simulator, inspired by Donald S. Bitanga’s non-fiction book, Karate: Questions and Answers. This hybrid game, installation, and performance piece prompts a meditative approach to the typically fast-paced sport.

The physical set-up consists of a modified bo staff (attached phone holder) and a single projection on the wall depicting a traditional Japanese dojo. Inside this virtual space lives our Karate Sensei, who bows before demonstrating a standard set of practice moves (katas). In front of the sensei is a floating virtual bo staff, which is mapped to the real-world bo staff. The player, standing in front of the wall projection, uses the physical bo staff to follow along and mimic Sensei’s movements in order to “learn their inner self and find peace within.”

The simulator is powered by Unity, and takes input from a smartphone gyroscope. 

*some Karate facts presented as truths should be taken with a grain of salt

Continue reading “KARATE – Experiment 5 – Book++”

How do astronauts go to the bathroom in space?

Brian Nguyen – 3160984

Nik Szafranek – 3173634

 

Team Roles

Brian – Creative and Development

Nik – Creative, Design and Asset Creation

Concept

Our project is a three player space survival co-op game. Players each have a role they must play on the space station in order survive until help arrives. Player 1 is the engineer of the ship, and must repair problems inside the ship. Player 2 is the pilot of the ship, they must steer the ship out of the way of asteroids and other space junk. While they are dodging the asteroids, items inside the ship will be affected by the thrust. This makes player 1’s job of acquiring items directly linked to player 2’s performance. Player 3 takes on the role of being the antagonist of the players. They control the path the asteroids will spawn on and their goal is to destroy the ship before help comes.

Inspiration

 

Our book inspiration is from How Do You Go To The Bathroom In Space. The book answers questions regarding daily functioning while in space written by a former astronaut. We brainstormed many different ideas based off this topic such as a toilet building game, reverse magic 8-ball style game, and even an AR experience. But settled on a Kings Quest inspired point and click game, which is where player 1 is heavily influenced. From then on we bounced ideas on how this make this an interactive, multi-user experience. Where eventually we ideated to create a space survival game, stemming from works such as Spaceteam, Keep Talking and Nobody Explodes, and Don’t Starve. Our original concept is different from our final due to time constraints. In the original concept, player 3 would be someone at Mission Control providing troubleshooting info from a manual. Similar to how the book itself is structured.

 

The order of events originally planned was as follows:

  1.    Start
  2.    Asteroid
  3.    Air filtration breaks
  4.    Waste full
  5.    Solar Panel hit by small meteorite;
  6. a)    X amount of time before power level too low.
  7. b)   Low power lights
  8.    Sensors scrambled; Pilot can’t see Engineer
  9.    Magnetic storm/Solar Flare; no contact with mission control for 1 hr
  10.    Pipe leak
  11. A)   Hole starts to grow because items are pulled into it.
  12. B)   Pipe breaks
  13. C)   Hull integrity damage
  14.    Toilet clogged
  15.   1 thruster is broken
  16. A)   restart
  17.   Film
  18.   Film on camera runs out
  19. A)   Replace film
  20. B)   Swap out film
  21.   Thermostat breaks
  22.    X amount of time before it is too hot
  23.    Certain equipment won’t work if too hot
  24.    Easier to miss keys; image distortion
  25.    Die of heat stroke

Pliers

PDA/Walkie Talkie

Gag items

Duct Tape

Water

Air Tank

Space suit

Electrical Gloves

 

Planning

We chose p5.js for the project because we were both comfortable using it and could develop the project quickly enough for the timeline. In hindsight, it might of been easier to learn and use Unity to build the point and click adventure game as there are no available libraries to aid in the creation. Clicking on objects in p5 takes a little extra time to setup the collision detection and classes, essentially we had to create a 2D game engine from scratch.

Implementation & Issues

The final implementation consists of three p5 sketches connected through PubNub. Assets were made with Affinity Designer. Player 1 uses p5.scenemanager.js to handle switching between rooms. Every room is split up into their individual js file for organizability.  

Networking Diagram

Data

  • Game over state – Boolean
    • Used for all players to determine when the game is over
  • Thrust direction – “up” or “down”
    • Used by player 1 to shift around items on the screen when player 2 moves the ship
  • Ship position
    • Displayed on player 3’s screen of where the ship is
    • Updates only when player 2 stops moving as a balancing decision, during movement it will not update.
  • Asteroid X Position
    • The x position of where to spawn the next asteroid, set by player 3 and then used by player 2.

Demo & Code

Github Repo w/ Commented Code

https://github.com/notbrian/Atelier2-Book

 

Link to live links

https://notbriann.com/Atelier2-Book/player1/player1.html

https://notbriann.com/Atelier2-Book/player2/player2.html

https://notbriann.com/Atelier2-Book/player3/player3.html

Starfish Generator

 

20190124_111837-1

Samantha Sylvester, 3165592

Michael Shefer, 3155884

Rosh Leynes, 3163231

Assignment 1

Nick Puckett

Atelier II

Thursday, January 24th, 2019

Github: https://github.com/MiShefer/Starfish

Google Drive: https://drive.google.com/open?id=1_zDgL0qcprlQB0LUa1fZlISaExyAZ8yk

About:

Our goal was to create a UI based starfish creator. Starfish come in many different shapes and sizes as we learned from our book. There are tons of different species, each with their own unique traits such as colour, shape, and texture. Starfish are found in mainly tropical places but are not limited to them, they can be found as deep as 6’000ft. To simulate the variety of starfish and what makes them unique we developed an interactive system that constructs a starfish based on the choices made by different users. Additionally, a scientific name would accompany each attribute such as texture, colour, and shape and would result in a name for the starfish upon creation.

Sam:

I had a lot of fun doing this project, I learned so many new things. Working with a variety of software and different logics that I’ve never used before to form a final product was really challenging yet rewarding. Illustrator was interesting to use, it’s amazing how quickly you can learn something when under pressure and a time limit. I find myself thinking in illustrator now when I need to design something quickly. Making the starfish bodies and shapes was really cool! I was a little confused about how svg filetypes work but we made it work in the end. I also originally wanted to have ocean pictures in the end but the layering of the code and issues with masks and colours prevented us from figuring that out in time. It would also have been nice to incorporate sound into it too. 

Another idea I had for this project was based on something I learned from our starfish book. When a starfish loses a limb, it has a regenerative ability that allows it to grow back. So I thought what better animal to play tug of war with, then a starfish? Five screens, one for each arm with one person per a screen pulling the starfish in five different directions. (Poor starfish)

Something to improve on:

  • Design aesthetic, Adobe Illustrator has never been my strong suit

Something to add:

    • The scenery, or ocean backgrounds

Thoughts:

    • Trying to figure out masking and the layering of images within the code.
    • Browser windows seem to be getting confused and aren’t updating

Michael:

As we were working with ideas, our original set environment to work in was Unity. Although it was new to us, we were interested to explore its potential to create an interactive system based off choices and reactions. As we further developed our concept we settled on working in P5 as it was more familiar to us and basic inputs from a variety of choices were more simple to translate to a final screen with cell arrays.

To construct the actual generated starfish, we had to create the assets such as the shape and textures ourselves. Implementing all the assets together as an image with a mask proved difficult especially in a system that was based off a variety of choices. Since image masking only works by calling which particular image it is supposed to overlay, we struggled with working around it before settling on the solution of creating many if statements that contained more than one condition. Although the final result of the code proved to be convoluted and made debugging complicated, the front-end displayed well and even updated in real-time without the need to constantly refresh.

Rosh:

When we started this project I was completely open-minded to whichever approach we took. Preferably, a challenge always. Once we settled on p5js, I was really into the idea of doing the back end logic/programming. It was a bit selfish of me to take on a lot of this responsibility but it was a great learning opportunity.

My portion of the project began with drawing out the workflow of the program. By using barebones sketches and annotations, I devised a way for three interfaces to send messages to a listener, and have a choice selected from a database. To be honest we limited the number of options to save programming on us. After a very poorly done version was made to work on one device, we imported PubNub and brought our project online. The program made to operate on one device was then turned into four separate scripts, and with some refining, this became our final piece.

Sketches and Brainstorming:

plan-1 plan-2

 

The Outrageous L.A. Quiz Game!- Book++ Project

TEAM MEMBERS

Ermar Tanglao

Joseph Eiles

Kiana Romeo

CODE

https://github.com/ErmarTanglao/quiz_game

DESCRIPTION

Our project “The Outrageous LA Quiz Game” is a quiz game based upon the book we chose titled Outrageous LA in which three players compete against each other in order to gain the most points through answering eight different questions. Each outlandish question presents the player with four different answers. Once the player selects an answer, they are locked into it and cannot change their answer; if the player answers correctly then they are immediately rewarded with a point that is tracked through a number on the player controller. Once every player has answered, the game host then proceeds to the next slide or question through their host controller.

On a technical level the quiz is comprised of sixteen different slides, eight for each question and another eight for the answer to the corresponding question. The quiz show is comprised of five different controllers with each controller having its own independent code. Three controllers are designated for each player, one controller is designated to the host so that he/she can select the next slide or reset the game, while the last part of the code controls the question and answer slides.

screen-shot-2019-01-28-at-3-45-55-pm question2

RATIONALE OF CODING LANGUAGE (P5.js)

The programming language we used for the project was P5.js. We used this language because we were the most comfortable writing code with it and learning another programming language or using another software could possibly be difficult to learn. For the way we presented our work we decided to have it be projected from a projector because it would act like a screen for the players to look at in a manner akin to Jeopardy and Who Wants to be a Millionaire.

Image result for who wants to be a millionaire

Image result for jeopardy

CONTEXT

img_6917    img_6918

The book our group chose was Outrageous LA, a book highlighting all the weird and quirky aspects of Los Angeles in the 1980’s. It was full of fun facts and interesting images that one would not only not normally associate with LA culture, but also facts that are definitely not widely known. The ridiculousness and randomness of the book really gave us a lot of wiggle room in terms of coming up with a concept. This made us want to create a way to test people on these random facts, but to make it interesting instead of just making a simple test or an informational program.
answer8

We aimed to make our project as fun as possible and so we came up with the idea of a game show. We examined many older game show themes to come up with a way to format our quiz game and decided on a Who Wants to be a Millionaire type concept in which all the questions appeared on the screen and the player would have to choose the right one. We also paid great attention to the aesthetics of the project and tried to make them as 80’s themed as possible. The only issue with that was it turned out quite unattractive and so we decided to use a more late 80s/ 90s theme for the question slides and buttons. In all, we aimed to make a colourful, nostalgic and fun experience for our players.

answer3 answer1

ISSUES

Within our project we had a few problems. The first had been getting the slides to communicate with both the game host’s controls as well as the players’. For a while, when the host’s controls were clicked it either affected the player or the question slides when it was meant to change both. This was easily fixed by changing the channel name to the same thing on each page of code.

As well as that, we had issues with getting the buttons to revert back to their original colour when the question was reset and getting the points to change only when the correct answer was selected.

NEXT STEPS

An issue that was never solved was that the buttons did not work on iOS devices. This would ultimately cause issues if a large group were to try to open the controllers on their iOS devices and would therefore be our next steps in making the project more cohesive. Furthermore,  we would add more to the game like music, make the question slides themselves interactive and also make it so that points accumulated based on speed of choice and not only if anyone got it right. A stretch goal would be to make it on Unity so that the game show would be immersive as if you were actually on set of a game show!

Experiment 5 – A Little Birdie

Team Members

Melissa Roberts

Donato Liontino

Description

We chose to use the book “The Doubleday First Guide to Birds” for our project. We decided we wanted to code a simple video game. Since our book had no narrative to follow, we had a lot of room to interpret it as we like.

We centered our game about bird watching. The game is to be played by four people, each player controls their own character on the screen, which is represented by a pair of binoculars, and their objective is to collect birds from the “play area” and to trade them with each other.

screenshot-23

The game is played with each character looking at the same computer monitor. Upon startup of the page, they can see a stylized game board that is divided into four quadrants which represent the domain for each player’s icon to move in. Four species of bird can be seen flying around the laptop screen:

the scarlet tanager (red)                            the bluejay (blue)

screenshot-16 scarlet_tanager screenshot-18 bluejay

the tree swallow (green)                            and the meadowlark (yellow)

screenshot-15 tree_swallow screenshot-17 meadowlark

Each player uses their own smartphone as a controller, connecting to the webpage for their user by scanning the associated QR code. The object of the game is to collect all 4 of your bird species, at which point you receive a “winning” message, and the rest of the players receive a “losing” message.

img_2920  img_2919

Continue reading “Experiment 5 – A Little Birdie”

ATLR II Experiment 1: The Suede Game

Mahnoor Shahid – 3162358

Andrew Ng-Lun – 3164714

Denzel Arthur – 3157183

PROJECT DESCRIPTION

The SuedeGame is a 3 player puzzle game. The players are storekeepers who have to find separated parts of their leather items. The separated items are a watch, a duffle bag, and a journal. They have to assemble the found objects corrected according to the item they belong to before the store opens.

When they come close to a  part, a video starts on the monitor showing information related to leather products or sewing.

screen-shot-2019-01-27-at-10-01-21-pmscreen-shot-2019-01-27-at-9-59-27-pmscreen-shot-2019-01-27-at-9-59-41-pm

 

PROJECT CONTEXT

We based our game concept on Leather in Three Dimensions by Rex Lingwood. It is a craft book that demonstrates interesting leather crafting techniques for the beginner and the expert. The book includes instructions and diagrams of how to shape, fold and cut the leather. Based on this, we thought of a basic matching game where the player would have to collect and assemble the corrects parts of a leather object and assemble them correctly. The three products are a leather watch, leather duffle bag, and a leather journal book. In our initial concept, the players would have had to select the correct parts from a table. Later we changed the environment to a leather store where the players have to find hidden parts of the products and assemble all three of them before the store opens.

Data synchronization in unity and pubnub:

https://www.pubnub.com/blog/realtime-data-synchronization-image-switcher-with-unity-pubnub/

We used the Pubnub Unity SDK to synchronized our game across three laptops in real time. This tutorial shows a Unity Build in WebGL hence we chose to use laptops instead of other devices for a better game view.

RATIONAL FOR SELECTED ENVIRONMENT

To develop our suede game, we used Unity to build the leather store game system. Unity excels at creating 3D environments and has easy compatibility with other 3D models. This gives us the opportunity to create our own content from other applications and merge them together in Unity such as using Blender to create 3D models and input them into the game environment. Unity is not only compatible with model applications but can also talk to online networking platforms like pubnub. By using pubnub, we can connect several users together to play the game on several screens with live updates. Furthermore, the beauty of unity, it allows us to fully customize the game components, whether they are the UI menu, interactive buttons, lightings/camera direction, and other features, but also when developing the game, it gives us an interface to work with which makes editing much easier.

3D MODELS

screen-shot-2019-01-27-at-10-15-09-pmscreen-shot-2019-01-27-at-10-15-18-pm screen-shot-2019-01-27-at-8-43-10-pm screen-shot-2019-01-27-at-8-15-10-pm screen-shot-2019-01-27-at-8-14-18-pm

PROCESS

Although the initial real-time synchronization involving Unity SDK and pubnub on WebGL was a success, we had difficulty connecting the finished game to Pubnub. Eventually, the game was connected to pubnub but we were unable to test it with multiple players.

Process Video links:

https://drive.google.com/drive/folders/11_SH5KMMDsDYE7ZhNzaCtiurWqvKd4gX?usp=sharing

BACK UP SKETCH

We created a back-up sketch in p5.js related to modifying shapes. The idea of the sketch was to drag small circles on the outline of the circular shape and match it to the static shape. It was meant to be a multiplayer, interactive game. So far, the players can drag their mouse along the x-axis to change the radius of the circle. Their interactions can be seen on other devices in real time through the help of Pubnub. We are still working on the dragging to manually modifying the shape.

download-1 screen-shot-2019-01-24-at-4-29-58-pm

CODE LINKS

P5 sketch:

https://github.com/mahnoorshahid/gameTestLeather

Unity scripts:

https://github.com/WUNISTUDIOS/Suedegame

Unity build:

https://drive.google.com/drive/folders/1GI70aqiFZAJCGr0wbisNIMfpn5M_34X1?usp=sharing

 

Train Simulator Book++ Project

Train Simulator Book++ Project

Madelaine Fischer-Bernhut, Ola Soszynski, Vijaei Posarajah

Book: Trains: Classics of Transportation

20190117_100348

Group Work Breakdown:

Ola – PubNub and p5.js sketches and implementation (coal shovel and whistle for mobile)

Madelaine – research into and final path creation (with BG Curves and dynamic speed implementation), final game build and scripting in unity with PubNub, basic 3D models of train, terrain (map), station, and collision detection of train and station

Vijaei – research into path creation, Project context research, documentation compiling, shovel acquisition, unique asset design (trees, diverse coloured train stations – unfortunately, were not able to be implemented in the presented build)

 

Project Description:

Our project aimed to enhance the reading experience about classical 19th century trains by providing the participants a simulated experience of operating a steam engine train through teamwork. The train simulator game works with a laptop displaying a train on a route with train stations to stop at. The participants  are tasked with operating the train by using a phone mounted on a toy shovel to shovel coal using a shaking or shoveling motion allowing the train in the game to move forward. Another participant will have a whistle used as a button to supply the the coal shovelers with more coal. The main goal within the game is to move the train along the track and complete it’s route consisting of train stations. The participants have to work together as a team to operate the train. Our original inspiration was to replicate a train simulator type game with cooperative play in mind with multiple devices used to operate the train but instead of a modern train players would operate a steam engine train along with the devices associated with its operation. Our final project was a scaled down yet functioning version of our original concept.

The original concept involved tasks such as:

-Checking statistics (speed, supplies, engine)

-Shoveling coal into the steam engine, depleting supply, increasing speed

-Communicating with a station for supplies, increasing supplies

-Releasing steam, needs to be done or engine overheats

-Conducting the train, depleting speed

-Slowing down is required to receive supplies

-Going too fast will cause a collision, ending the simulation

-Running out of supplies results in the train stopping, ending the simulation

-Forgetting to release steam results in the engine overheating, ending the simulation

 

Code:

P5 Buttons and Controllers: https://github.com/olasosz/olasosz.github.io

Train Simulator Unity game:  

https://github.com/Vijaei/Train-Simulator-unity-files-updated

 

 

 

Displays:

Computer display – output of players actions (world and train representation in Unity. In the presented build we used one display, but in the future we can imagine having multiple displays to represent different views from the train. In unity, multiple cameras pointing in different directions were added  to support a multi display experience. Displays would be placed in a formation similar to an actual train.

Mobile display – input player actions, two were used for the presentation, although this can be increased so multiple players could be in charge of shoveling and “blowing” the whistle to restock coal. At least one coal shoveler and whistleblower are need to play the game.

 

Programs Used:

Our project used Unity to create the main train simulator game which involved assets such as the train referenced from our book, train stations, railway signs, trees and terrain. WIthin the Unity we used a pathway system for the railway track as well as systems for acceleration and collision. We used P5.JS for the steam whistle button interface as well as the coal shovel controller used to accelerate the in game train. To have our mobile devices communicate between each other as well as the gem we used Pubnub to establish a network. The steam whistle button communicates with the coal shovel by sending coal to the shovel to be used, and in turn the shovel communicates with the game to accelerate the train forward or stopping the trains movement by not shoveling. Ideally our system would allow one steam whistle user, one train simulator game display and multiple users for shoveling coal.

 

Project Context:

For real world references we looked at simple versions of existing train simulator games found online such as Train simulator 3d ( http://www.crazygames.com/game/train-simulator-3d) which uses the acceleration and braking mechanic as simple sliders to operate the train. We also took note of the optional fixed camera views provided by the game as a feature to implement in our own game. For the Cooperative multiplayer aspect of our game we looked at available and relevant games in the current market such as Space team (https://itunes.apple.com/us/app/spaceteam/id570510529?mt=8)  by Henry Smith, which allows multiple players to simulate a spaceship bridge by commanding players to press buttons and switches according to a sequence provided in the game. Here players are reliant on other players to follow through on their sequence so they can contribute as team and progress in the game as a whole (https://www.youtube.com/watch?v=ymwSbxUDtTw) . Where Space team is reliant on multiple individual devices, we used Artemis Spaceship Bridge Simulator (https://itunes.apple.com/us/app/artemis-spaceship-bridge-simulator/id578372500?mt=8)  by Incandescent Workshop LLC as a reference to how our game would work reliant on a single game world with multiple devices used as controllers to play a single sequence game. Here each participating player is in charge of a single aspect of operating the spaceship and rather than being told by the game what to do, they have to react to the game world as a team to survive encounters (https://www.youtube.com/watch?v=V9Q2X32hZNk) . We also used “Game Mechanics for Cooperative Games (https://fenix.tecnico.ulisboa.pt/downloadFile/395138343981/artigo.pdf ),” by Jose Bernardo Rocha, Samuel Mascarenhas, and Rui Prada to understand the variety of cooperative game mechanics that can be implemented into our cooperative simulator game.

 

Sketches:

Group meeting sketches used to flush out our concepts for a simulator type game

 

Process:

2019-01-17-1 2019-01-23-6

Trying the pathing asset by Surge. Madelaine was unable to implement dynamic speed values using this component.

spline-editor

The final asset used for pathing was the spline creator BG Curves.

bezier-curve-tests

Madelaine’s attempt at creating a bezier curve system from scratch.

20190122_131405 tree-assets

Unity game development process including modeling game assets, train paths, and terrain

20190122_131520 screenshot_20190117-125603_chrome screenshot_3

Development process for steam whistle button, coal shovel controller, and Pubnub network

 

Issues:

The biggest issue that we had to overcome was getting the different devices to communicate with each other. All the devices were able to publish information, but the mobile devices were unable to communicate with unity. After a lot of troubleshooting and help (thank you Nick) we realized that PubNub was getting confused with all the different data being published to one channel. The creation of subchannels for each data type, solved the issue (ie. A separate channel for the coal values from the speed channel).

 

Demonstration:

img_20190124_114208678 img_20190124_112603794

https://www.youtube.com/watch?v=s_VhflOroYA&feature=youtu.be