The Hyperion mission! Having to manage one unit with a continuous stream of battling non playable characters takes away the added task of micro management and lets me enjoy a feeling of ‘distinctiveness’
How ‘cutscenes’ meld into gameplay e.g when saving Raynor, Kerrigan’s Leviathan arms smash into the prison ship which then transitions into the game level
Evolution missions really helps players understand how an evolution works and how to use it
After Kerrigan’s battle with Narud, I felt she recovered too quickly. It drew from the gravity of the fight. She should have been in an injured state for the Leviathan section where characters could comment on her fight. Then by the next mission having recovered, there would be a contextual piece of dialog about it
Introduction: Developed on the Oculus Rift with PS Move, DinoRancher had guests play atop a Triceratops armed with an electric lasso. The goal of the guest was to shepherd a herd of Stegosaurus to safety, protecting them from danger.
Story: You are a DinoRancher armed with your electro lasso and trusty trike. Travel across the desolate wasteland, and protect your herd from those nasty predators!
Integration of the PS move into Virtual Reality
Trike movement system
Design Goal: To create an experience that made the guest feel like a cowboy travelling through the desert protecting a herd of dinosaur from predators.
My Contributions: As producer I arranged meetings, delegated pending tasks, and contributed creatively. In addition as a programmer I was responsible for setting up the games environment which included, asset preparation, level design and developing agent behavior.
Introduction: Developed on the CAVE with Makey Makey, NoseDive had guests play in the CAVE environment using airplane controls we constructed using Makey Makey.
Platform:CAVE, and Makey Makey in Unity 3D | Time: 2 weeks | Roles: Programmer – Game Designer – Producer | Team Size: 5
Story: Our game had our guests take the role of make shift pilots thrust into having to fly a plane to safety through a terrible storm when the captain has become incapacitated.
Adapting to the CAVE environment.
Creating an authentic flight simulator experience with an easily understand story.
Design Goal: To create an authentic story of saving the day through the game we created.
My Contributions: For NoseDive I was producer, designer and programmer. Being producer involved scheduling and coordination of our teams artist, programmer and sound designer. In addition I assisted my fellow programmer with environment and Unity prop setup.
Introduction: A Playroom was a developed on the HTC Vive. A virtual reality device that allows a guest to walk around a calibrated virtual reality space with hand held controls.
Platform:HTC Vive in Unity 3D | Time: 2 weeks | Roles: Designer – Producer | Team Size: 5
Story: The setting of the game is in a play room where the guest encounters a ghost boy who needs help in-order to ‘move on’.
Design Challenge: To design a game for naive guests, conduct play tests, and make three predictions of what the guest will do all whilst having the guest ‘feel free’.
Design Goal: Round 2 of Building Virtual Worlds was indirect control round. This required we build an experience that felt free, and was intuitive enough for a guest to play from start to finish without any instruction or guidelines.
My Contributions: I analyzed, and designed the guests interactions as well as wrote our main non playable characters dialogue. In addition I conducted play tests which gave us invaluable feedback which we used to further develop the experience.
I focused on interaction development by first analyzing what we currently had. From that I wrote a draft story design which was a rough version of what we would aim for. Our current gameplay was clearly a linear story experience, and I believed we could achieve a greater sense of freedom by allowing a player a choice of what game to play.
From this notion I created two different interaction models.
I then met with the team, presented my two plans. We choose plan 2 which I further developed into a more detailed version.
Audio would play a vital aspect in driving this interaction model therefore I worked with our sound designer on a script for the game which we iterated over based on feedback (script documents).
Once the various audio cues, and interaction model was implemented we went about play testing the game. I conducted play tests with over fifteen naive guests which included an audience of fellow students, professors and non-students. This feedback was then used to polish elements of our experience.
In conclusion we correctly predicted each of the three interactions, and the guest understood our story, all with no guidelines or instruction from us.
We began our project with brain storming, and research into the platform on which we were developing. We came up with several ideas including:
Darkness– Use light to guide the guest through a street.
Space Exploration– Explore the universe, and pick a planet to colonize.
Dreaming – Flying a plane, flying elephants, flowers turn to buildings (freedom from constraints).
Empty Room – Furniture place (guide them to a correct place).
Having difficulty grappling with the concept of ‘freedom’ we spoke to a member of The Entertainment Technology Faculty Jesse Schell. After meeting with Jesse Schell we honed in on an idea of a ghost boy which we would help in some manner through objects around him.
Next we thought about location, which was first a storage room due to it making sense to have many object, we then changed to a play room as it offer the potential for a ‘warmer’ environment for guests to feel comfortable.
After creating a basic room with a simple number of interactions which included:
Place a train on the train track.
Hide & Seek.
Give a hug.
We had a prototype ready for interim.
After interim our two main points of feedback were
Make the boy and game generally less ‘creepy’.
To develop our interactions.
Point 1 was a significant design challenge which we tackled by investing time into solving by:
Making our main game character look more human like.
A warm game atmosphere.
A friendly, light and clear character voice.
I decided to tackle point 2 by first analyzing what we currently had, then writing a draft story design which was a rough version of what we would aim for. Our current game play was clearly a linear story experience, and I believed we could greater the sense of freedom by allowing a player a choice of what game to play.
From this notion I created two different interaction models.
After meeting with the team, presenting the two plans and convincing them of the need to carefully design the experience, we choose plan 2 which I then further developed into a more detailed version.
Audio played a vital aspect in our experience so I worked with our sound designer on a script for the game which we iterated over three times based on feedback (script documents). In addition to audio we used a number of other techniques including:
Lighting – To direct the players focus.
Color – Brightly contrasting objects such as with the yellow train on a blue chair, and a red book on a beige floor caught the players attention.
Uniformity – A suggestive picture fragment was placed in the frame, and other similar looking puzzle pieces were placed around the level.
After implementing these features with a new interaction model we went about play testing the game. We conducted play tests with over fifteen naive guests which included an audience of fellow students, professors and non-students.
Based on the feedback we received we continued to polish elements of the game. The end result of our work was that not only did we accurately predict each of the three interactions, but the guest completely understood the story behind our world all with no guidelines or instruction from us.
Story: Jam-O-Draw was inspired by the classic etch-a-sketch game.
Design Goal: We wanted to create a multiplayer artistic experience with a fascinating reveal.
Adapting to an unfamiliar platform.
Creating an aesthetically pleasing experience using visuals and audio
Having the user interface during the experience be responsive and informative.
My contributions: My primary role on this project was as producer which involved making creative contributions, arranging meetings, coordinating our artists, programmers and sound designer to create the game in a timely manner. My programming responsibilities included assisting my fellow programmer with development, and preparing the game environment and assets.
Introduction: Seize the Sky was built during Building Virtual Worlds at Carnegie Mellons Entertainment Technology Center. The world was constructed using Oculus Rift, and Leap Motion. Using these technologies we put our guest into a virtual reality space with an ability to use a natural interface in our world.
Story: A mighty giant heads towards a town with murderous intent. A country side boy notices, and cries to Zeus for help to defeat the giant to save the city. You are Zeus, save them all!
Design Goal: Our design goal with Seize The Sky was help character A (the boy) who is afraid of character B (the giant).
Incorporating a satisfactory use of Leap motion.
Achieving our a sense of character A is afraid of character B.
My Contributions: As the lead programmer on Seize The Sky I made large contributions to the code base for this project. I also took an active part in the design process with working with the team to develop various aspects including game play, and level design.
The development process started with being assigned teams. In our first team meeting we made clear our skills, started brainstorming ideas, and kept good development processes in mind.
During brainstorming we tried using several appropriate methods, such as gesture centered brainstorming (due to our use of Leap Motion). Finally we had five initial ideas:
Help mend relationship between characters.
Play piano to make baby sleep.
Use light to guide a character home.
Keep animal safe growing to adulthood.
Hold characters hand to guide them.
With our initial ideas we further boiled them down to three concepts with the following reasoning:
Concept one was hard to conceptualize compared to our other ideas which seemed simpler and more clear.
Concept five could be incorporated into concept three.
Creating sketches of each concept we then sought out the advice of our professor Jesse Schell.
With Jesse Schells feedback we went with concept C, because we wanted to explore squeezing in Leap Motion.
We then began further conceptualizing the idea with sketches, and research into the capabilities of Leap motion and Oculus.
With this in mind we began assigning tasks to complete, considering game play, and used a scrum board to assist us in tracking tasks.
On the technical side we used a NavMesh, and simple A.I. to run the behavior of the Hunter and Deer. The behaviors of the two agents were essentially:
The deer always moved to nearest tree that has an apple.
The Hunter patrolled around fixed points, and if it came close enough to the deer it began chasing it.
The result of our hard work was the following.
We then received feedback at interim, which sadly wasn’t good…
Building Virtual Worlds at Carnegie Mellon University starts with each student being assigned a role in Round 0. Since I have a Computer Science background, my role was that of programmer; this entailed I build a world that employed a number of basic features in Unity, such as:
Loads models and textures.
Use intervals, lighting, collisions, and multiple scenes.
When considering the world, what I noticed was the amazing talent of the artists and musicians around me. It occurred to me what a shame it would be for their work not to be seen. I decided then that my virtual world would be a gallery of other peoples work. My first task was then to coordinate of assets with artists, and sound designers.
Artists were initially required to create animated lunchboxes, then dragons, and sound designers were required to create music for a clip of game play from a previously made world. I decided to meld the two by attaching audio sources to several of the artists assets that would constantly play music made by our sound designers.
Browsing Reddit’s PlayMyGame subreddit I found a post by Jon Oldblood asking for QA testers for his upcoming game Masochisia. Wanting some experience having a look at game analytically I volunteered to help out, and ultimately performed two rounds of testing.
My first round of feedback was based on my first impressions of the game. While playing I took notes on noticeable details that jumped out at me in areas like:
Reddit is where this story begins. Trawling around I joined the /r/gameDevClassifieds sub-reddit. A place of gathering for game developers advertising paid, and un-paid game project work.
By chance I came across a post asking for a game designer, to which I replied. Unfortunately the position had already been filled though fortunately additional help was happily welcomed.
The project in question is Hero of Allacrost. Its an ‘open source single player 2D role-playing game inspired by classic console RPG’s, and I’m thoroughly impressed with the standard of this project. It’s use of BitBucket for source control, a Wiki containing lots of information/documentation, a forum, and welcoming project members! I’ve worked on this project for approximately a month, and my contributions to this project have been enhancements to the battle code.
Here’s the latest Hero of Allacrost gameplay footage. Check it out!
When searching for a teleport system in Game Maker, I often find the following suggestion. When object A collides with object B at position (x,y) change object A’s position to (x_new,y_new). This works perfectly if you require a fixed position teleport system.
Though, what if you wanted (given any character position) to be able to teleport to a location that is not pre-defined. A dynamic teleport. What do you do? I asked myself this, and here’s a simple solution that I used for my puzzle platformer Multi.
First lets define a few terms and variables:
Ideal Teleport – A teleport which results in the character being where you most want in a regular scenario.
Teleport – A boolean variable that determines whether the character can teleport or not. It is reset with the use of an alarm.
Teledist – A fixed integer that determines the position change of the ideal teleport. I used the value 96 pixels.
Par_solid – The fundamental solid object of my game (I did not use Game Makers solid variable, this article explain why.
It also helps to know the basics of Game Maker Language’s (GML), and how one of its functions place_meeting works. If not I suggest you check out this great post in the Game Maker forums by Torigara.
Thrillseeker is a game jam submission on the theme “You Are Your Own Worst Enemy” designed and created by my friend Sangseo Lee and I. The core mechanic of the game is that whilst flying close to passing asteroids gives you a higher score, doing so greatly increases your chance of crashing. It’s like Burnout in that the player is rewarded for high risk game play.
White blood cells play a vital role for our health, without them we’d be easy pickings to the likes of even the common cold. Play a moment in the life of a white blood cell and battle against an ever growing hordes of viruses and protect the red blood cells to keep your heart beating. Even better, do it with a friend! Happy hunting!
Immunity is a coop game that I worked on with Sangseo Lee, for the Global Game Jam 2013 at Edinburgh. It took second place in the local competition and was noted by the judges for best design. At the moment it’s written in Java using the Slick framework and can run on Windows, Linux, Mac and Solaris. Check it out at the Global Game Jam website here!
League of Legends is described by some as the equivalent of electronic basket ball, by others like AngryJoe as “crack”. I agree. This Multiplayer Online Battle Arena (MOBA), where team work is essential to success has players take control of a single unit in a multi-player match up, with the goal of destroying the opposing teams ‘Nexus’.
A Short History
League of Legends or LOL (though well executed) is not an original idea. In fact it was originally conceived as Defense of the Ancients (DOTA). Based on a mission from Starcraft, DOTA was a custom game created by Eul on the popular Real Time Strategy game Warcraft 3: Reign of Chaos. Unfortunately Eul did not update his map, and so others created spin-offs; it was Steve ‘Guinsoo’ Freak who got it right.
Guinsoo created a variant of DOTA calling it DOTA: Allstars. He then put in an enormous amount of work in to adding new champions, items and game features. He later handed it over to Abdul ‘Icefrog’ Ismail who continued his work. At present IceFrog has gone onto become a lead designer at Valve working on the sequel DOTA 2.
No One Has to Die’s comments on Newgrounds read “4 people are trapped in a building fire and need your help to escape”, now I’ve finished playing it, looking back it’s the tip of the iceberg… an awesome iceburg.
An hour or so in length, this indie game manages to pack quite the punch. It isn’t particularly difficult and it’s not designed to be. The simplicity of its gameplay and mechanics, peel back to reveal the complexity one feels in considering the consequences of those simple choices, which in turn furthers the narrative in a ‘player-driven’ manner.
It’s art style is simple, functional, colorful and doesn’t detract from the game. The music is top notch, working well to build up an atmosphere in tune with what’s happening in-game. The writing of characters is good and given the length of game it’s enough to start to get a ‘feel’ for them.
All in all No One Has to Die is a thought provoking puzzle over life and death. Its great moments and emotional highs and lows leaves one with a joyously sweet aftertaste. This is one indie gem, is well worth your time.