Greg Lieberman's Weblog

Rapid Physics Beta Release

2011-12-04T00:21:00.001-08:00

Rapid Physics is a custom Physics Engine that I decided to build in Flash.

Why would I torture myself like that?

There are plenty of industrial-strength physics engines out there, such as Havok and Box2D. They offer complete and robust physics simulations, but they also hide a lot of information from the programmers that use them. This leads to two problems:

Hard limits on authorship control over the physics simulation (lots of code you didn't write)
A sense of helplessness when debugging engine-level problems (lots of code you didn't test)

Effectively, game programmers lose the granularity to control subtle features of the physics simulation, and the ability to do custom collision resolution for gameplay purposes. For games whose physics are integral to gameplay, there is still a place for custom physics implementations.

I designed Rapid Physics to tackle one specific problem that most general-purpose physics engines never attempt to address: Tunneling

Tunneling

In a physics simulation, physics objects actually teleport small distances each frame. The faster they move, the farther they teleport. Eventually, there comes a point where objects end up teleporting through other objects they should actually collide with. We call this problem Tunneling.

What Rapid Physics Does

Rapid Physics solves the tunneling problem for a fast-moving points that collide with Lines and Circles.

That's all?

For now, yes. The mathematical and algorithmic needs behind advanced collision detection are damned complicated. It turned out that perfecting such a simple task still takes hundreds of lines of code. Throw in some useful engine features, test code, and demos, and the codebase explodes to several thousand lines of code. That's a lot to do in a single semester!

Check out the Beta Release here:
http://kwarp.com/portfolio/rapidphysics.html

How Rapid Physics Works

Rapid Physics is heavily inspired by the Flixel 2.5 framework. If you know how to use Flixel, you will know how to write in RapidPhysics. Here is a handy guide of some Flixel equivilents:

FlxGame - RapidSim
FlxG - RapidG
FlxU - RapidU
FlxState - RapidWorld
FlxBasic - RapidBasic
FlxObject - RapidObject
FlxGroup - RapidGroup
FlxText - RapidText
Input - (literally the same code, use RapidG.keys)

Flixel's Design overview applies equally well to RapidPhysics. The class where your game starts will extend RapidSim. The class where you write most of your physics code will be a class that extends RapidWorld. Exactly one RapidWorld exists at a time, and it's easy to switch between worlds with a call to host.switchWorld() (every RapidWorld has a host property).

Next, let's discuss some of the core components of Rapid Physics:

Islands

In Rapid Physics, Islands do all of the heavy lifting of the physics simulation. The idea is as follows:

Add all of your RapidObjects to an Island
Add your Island to the RapidWorld's IslandManager
Enjoy sexy physics

The base class Island contains that core algorithm that solves collisions in Rapid Physics. Subclasses of island simply define what kinds of objects are collected together for collision solving. Currently, there are exactly 2 Islands in Rapid Physics:

PointLineIsland
PointCircleIsland

Let's take a look at PointLineIsland, for example:

package org.rapidphysics.islands
{
 import flash.geom.Point;
 import flash.utils.Dictionary;
 
 import org.rapidphysics.Collision;
 import org.rapidphysics.RapidU;
 import org.rapidphysics.Rlap;
 import org.rapidphysics.shapes.RapidLine;
 import org.rapidphysics.shapes.RapidPoint;

 /**
  * An Island that solves collisions between moving points and fixed lines. 
  * @author greglieberman
  * 
  */
 public class PointLineIsland extends Island
 {
  
  public var points:Vector.;
  public var lines:Vector.;
  
  public function PointLineIsland()
  {
   super();
   points = new Vector.();
   lines = new Vector.();

  }
  
  /**
   * This is an implementation of collectCollisions for points and lines
   * NOTE WELL: This implementation collides every point with every line, but it does NOT collide points with each other, or lines with each other 
   * @param frameTime
   * 
   */  
  protected override function collectCollisions(frameTime:Number):void
  {
   var temp:Point = new Point();

   // test for collision between every point and every line
   for each(var rPoint:RapidPoint in points)
   {
    for each(var line:RapidLine in lines)
    {
     var result:Point = (Rlap.lineSegments(rPoint.position, rPoint.nextPosition, line.position, line.end, temp));
     if(result)
     { 
      // grab a collision object, and fill it with data from the intersection
      var c:Collision = recycleCollision();
      c.init(rPoint, line, Rlap.resolveMovingPointAndFixedLine); // obj1, obj2, how to resolve the collision
      c.pointOfCollision.x = result.x;
      c.pointOfCollision.y = result.y;
      c.time = frameTime + RapidU.timeOfCollision(rPoint.position, rPoint.nextPosition, result); // define time for priority in solving collisions
      
      addCollision(c); 
     }
    }
   }
  }
  

 }
}

At it's core, it's just two Vectors, and 2 nested for loops. Not too bad right?

It should be extremely easy to write new Island subclasses with the existing intersection tests, should you have more custom collision needs. The tough part is writing brand new intersection tests. I could spend another semester just working on those...

The Core Collision Algorithm
The core collision-solving algorithm is perfect, but extremely expensive. Here's what it does:

Every Island, every frame:

Test for collisions
Sort collisions by time
Resolve collisions in time order

Every time Step 3 occurs, throw out all collision information, and return to Step 1.

This is insane, but necessary. When a collision is solved, it changes the state of the system, so every object that is being tested for collision needs to be evaluated again. In the worst case (which never happens), you are looking at a runtime of O(n!). The only way to avoid this is to cheat the physics in some way. Thankfully, in general, you are looking at an average runtime of O(n^3). This can be even faster if the collision test code runs better than O(n^2).

Intersection Tests
I designed Rapid Physics in parallel with a game that I am building. I wanted to utilize parts of Rapid Physics immediately during development, so there are 2 components to the engine that are extremely easy to integrate into to other games: Rlap and RapidU.

Rlap contains the hardcore Intersection Tests, and also Collision Resolution functions
RapidU contains low-level utility functions, like clamp, vector reflection, dot product, etc.

Intersection tests are some of the hardest parts of physics programming. I hope they serve you well.

Setup
For project setup, I strongly recommend importing RapidPhysics into a Flash Builder project. For this, Flixel has a nice setup guide.

Download the source files on GitHub:
https://github.com/KWarp/Rapid-Physics

Unlike Flixel, RapidPhysics is not a complete game engine. You will probably be better off exploring and modifying the five project demos instead of building something from scratch.

You can find the code documentation in the GitHub repository, but for convenience, you can also find it here:
http://kwarp.com/docs/rapidphysics/

Conclusion
That's a wrap for this Beta Release. Maybe I'll add more to this project in the future.

PEACE

Rapid Physics

2011-09-20T02:10:00.000-07:00

I am building a physics engine called Rapid Physics. It is designed to correctly simulate objects that move really fast. This is difficult problem that is commonly known as the tunneling problem.

Check out a quick demo here:
Rapid Physics 0.25 Alpha

Developer Blog

2011-09-16T10:52:00.000-07:00

I'm running a developer blog on Bullet Time Ninja. Check it out!

E3 2011

2011-06-14T13:26:00.000-07:00

A few weeks ago, I received an amazing phone call that would change my life (for a week).

I became an IGDA E3 Scholar!

What's that you ask?

Let's break it down. First, the IGDA is an official support group for game developers. Here is their official About statement from IGDA.org:

The International Game Developers Association is the largest non-profit membership organization serving individuals who create video games. We bring together developers at conferences, in local chapters and in special interest groups to improve their lives and craft.

The Electronic Entertainment Expo, or E3, is the largest media gathering in the Videogame Industry. Every major game studio and platform holder uses E3 as a venue to announce their next big thing.

As an IGDA E3 Scholar, I got a pretty sweet deal:

Pre-paid E3 ticket ($500 value)
Access to the press events from Sony, Microsoft, Nintendo, EA, and Ubisoft.
Tours of several game studio booths on the show floor
A couple lunches with various game developers
Some 2nd floor access
A field trip to the CAA, and EALA
Doing all of the above in the company of 14 other IGDA E3 Scholars.

It was the most epic E3 a person could ever hope for. I am extremely grateful to the IGDA for this incredible opportunity to network and learn from my peers. Below, in no particular order, are some of my most vivid memories from the event:

During a developers lunch, I spoke with an EA programmer about game engine architectures. My specific interest was what comes first in a professional GameObject class hierarchy: rendering or physics? To illustrate my question more clearly, would the class inheritance hierarchy look like this:

GameObject
RenderingObject
PhysicsObject

Or this?

GameObject
PhysicsObject
RenderingObject

The professional convention seems to be one of two things: they either both occur at the same level, or an object-compositional model is used, where a RenderingObject owns a PhysicsObject. The latter model is especially useful in games where a 3rd-party physics engine like Havok is employed.

Microsoft made a bunch of Kinect-related announcements during their E3 press conference, one of which was the use of Voice Commands in Mass Effect 3. I was giggling to myself as this was presented, as I had already beaten Bioware to the punch with my Voice Command game, The Bridge. We wrapped up that project last month. :D

For the record, the experience of physically speaking Voice Commands to a game character, and then having that character respond appropriately, feels really amazing. It will be a killer addition to the Mass Effect 3 experience that everyone should try at least once.

Tim Schaffer is hilarious.

Sony had a good press conference. The Playstation-branded 3DTV for $500 looked really damn nice.

I managed to show my Bullet Time Ninja game in video form to quite a few game developers on the show floor. Reactions ranged from "pretty neat" to "omg that's really awesome!!", so I'm pleased as punch. :)

A few quick blurbs on games that I played:

Fruit Ninja for Kinect is everything that I have ever wanted from a Kinect game.
Skulls of the Shogan looks like a good Indie game. There are a few game design kinks, but I am optimistic that they will be addressed before release.
SkullGirls has the greatest art and animation that I have ever seen in a fighting game. Must buy!
Monaco is really fun, but I feel like the current pixel art is holding the game back. I had a difficult time initially learning what was important on screen. Some focused art direction will turn that game from Great to Incredible.
I was outright impressed by the new XCOM game. The art style is right on the mark.
Kirby Wii is the most fun Kirby game I that have ever played.
The Wii U demos were pretty neat. I have high hopes.

Videogames Live had a great show this year. The Chrono Trigger performance was beautifully done. Have a listen: http://www.youtube.com/watch?v=UV2RKqmCs4w

Overall, this was the greatest E3 experience I have ever had. The IGDA is doing a great service for up and coming students. I hope future generations of amazing game designers get the same opportunities.

Thanks for reading,

Greg

Empires & Allies

2011-06-01T12:25:00.000-07:00

I started my internship at Zynga Los Angeles last week. We are working on a cool game called Empires & Allies. I think it's the best Zynga game yet.

While most Zynga games have you building some kind of farm or city, in Empires & Allies you are building an army. Make buildings, produce units, and take them battle. There's a pretty lengthy single-player campaign, and you can also invade your neighbors and take their resources.

The most interesting part of this game is the incredible sophistication of it's economy. I have never seen a game with a remotely comparable amount of interlocked systems. Let's list out every resource there is:

Coins
Empire Points
XP
Energy
Wood
Oil
Liberty Bonds
Ore Types

Aluminum
Uranium
Iron
Gold
Copper

Population
Neighbors
Units
Time - (a component to everything)

We've seen a lot of these resources in previous Zynga games. Let's talk about the new ones.

Wood: A resource limiter on how quickly you can make buildings. Simple enough, and quite clever.
Oil: A resource limiter on how quickly you can make military Units.
Ore types: The player is randomly given one kind of Ore type that can be produced within his or her empire. Players must trade with their neighbors to get other types of Ore. Ore is mostly required to produce certain kinds of units and buildings.
Units: The most significant new resource. Units you make can be taken to battle. When units die, they are permanently gone, and new ones must be produced.

The problem I have with many Zynga games is that after playing them for a few days, I amass so many buildings and resources, that I stop caring about my resources altogether. This is why I find Units in Empires & Allies so fascinating. A Unit is a resource that I can lose. The more I play the game, the more I burn Units in combat. In response, I deposit my hard-earned Coins, Oil, and Ore to replace them. It's a great cycle that will keep me running a tight economy for the lifetime of my gameplay sessions. Plus, units exist in several tiers. As I unlock new ones, I always have something to build.

Empires & Allies looks to be a fantastic addition to the Zynga portfolio. I am thrilled to be working on it.

The Bridge Wrap-Up

2011-05-09T23:28:00.000-07:00

Work has wrapped up on The Bridge. Big thanks to the team and everyone who supported us.

Here's our awesome website:
http://commandthebridge.com/

Here's a live demonstration of the final game:
http://www.youtube.com/watch?v=uW5x6AyL7Cw

We were featured on ABC 7 News:
http://abclocal.go.com/kabc/video?id=8113138

We were also featured at TEDxUSC:
http://www.facebook.com/media/set/?set=a.10150217517612037.355868.509387036&l=9a2c67f60c

What an awesomely fun project.

Global Game Jam 2011

2011-01-31T23:31:00.000-08:00

I made an awesome Tron-style game for Global Game Jam 2011

Play the game here:
http://kwarp.com/portfolio/fightfortheusers.html

Team page here:

http://www.globalgamejam.org/2011/fight-user

Demo Day

2011-01-26T15:48:00.000-08:00

Each semester, USC hosts a Demo Day where Computer Science Games students present their game projects to professionals in the industry. In December 2010, I presented The Bridge on behalf of my team. The media coverage has just been released, which you can check out here:

http://viterbi.usc.edu/news/news/2010/gamepipe-lab-hosts.htm

The picture of me in the article is nothing short of ridiculous. :P

Microsoft Word Makes Me Sad

2011-01-24T02:22:00.000-08:00

I have a love/hate relationship with Microsoft Word. I trust it to get my work done securely and professionally, but my day-to-day experience with the product is often plain frustrating.

Take for example, this outline I began putting together in Microsoft Word 2008 for Mac

I have pasted a URL, and want to make it a hyperlink. How can I do that?

Ah yes, there it is, in this huge menu. Let's select the Hyperlink option.

Whoa, a huge popup with tons of information I don't want to read. Let's press ok and see if it works...

It looks like the URL became a hyperlink, but it also screwed up my bullet point formatting.

:(

Vector Math

2010-12-13T01:50:00.000-08:00

I ran into a fun problem while working on The Bridge today:

In my process of refactoring the ship engine, I added a rotational thruster to turn the ship. When the player issues a Turn Clockwise command, the Navigator AI will apply the rotational thruster to the ship until it reaches the desired velocity.

Here are the properties I worked with:

A target yaw, pitch, and roll to rotate to, in terms of angular velocity
Current angular velocity of the ship
Angular acceleration of the ship's engines

Each of these I represented as a Vector3 in XNA

Vector3 targetAngularVelocity;
Vector3 currentAngularVelocity;
ship.engines.angularThrust

I figured that the most logical way to approach this was to adjust angularThrust every frame in an Update loop. The challenge was figuring out what acceleration was appropriate, when only given currentAngularVelocity and targetAngularVelocity.

My first attempt involved finding a midpoint vector with a simple LERP:

ship.engines.angularThrust = Vector3.Lerp(currentAngularVelocity, targetAngularVelocity, strength) * time;

This works when going from not rotating at all, to rotating in some direction. However, it fails miserably if the ship is already moving in some capacity. I ended up spinning the player's ship phenomenally fast.

Clearly, a midpoint isn't good enough, I need something a bit more relative.

Thankfully, a simple Vector Math trick works nicely:

ship.engines.angularThrust = (targetAngularVelocity - currentAngularVelocity) * strength * time;

Subtracting targetAngularVelocity from currentAngularVelocity will give me a new Vector that points from currentAngularVelocity to targetAngularVelocity . Then all I need to do is shrink the strength of the vector down to a reasonable acceleration, and I'm done.

And thanks to the miracles of Vector Math, this will work in any direction, under any circumstance.

Typical Day

2010-11-07T01:23:00.000-07:00

I have a daily habit of scanning through kotaku.com and gizmodo.com. As I read through article headlines, I open the articles in new tabs for later reading. Here's a sample of what that looks like:

I find it a good way to keep up to speed with current trends in the game and gadget industries, and also find lots of cool pictures.

Sometimes I will watch a video as I read through web articles. Generally I'll watch at a TED conference or two since I find them pretty enriching. The window resizing features in Windows 7 are particularly useful here:

Have a favorite news website to procrastinate on? Leave a comment below.

The Bridge

2010-10-27T21:53:00.000-07:00

This semester, I am the Technical Lead of a super-cool Science Fiction game called The Bridge.

In the game, you command starship entirely with voice control.

Here are some of the innovate things the game has going for it:

Speech Recognition as a seamless part of gameplay

The player can say things like:

"Weapons, fire missiles at enemy ship alpha"
"Navigator, engage defense orbit"

Dynamic Story Engine

Every actor in the game is an Entity
Entities have Relationships with other Entities
Relationships evolve throughout gameplay
Result: fully procedural storytelling

Emotional Voice Recognition

The player's tone is interpreted by the game
This affects crew loyalty towards the player

Of course, that's only the beginning.

For more information, check out the game's website:
commandthebridge.com

- Greg

Flash Sound Tutorial

2010-09-17T21:22:00.000-07:00

I made a tutorial for using Sound Objects in Flash.

The tutorial covers a few tricks I use, including:

Object Dictionaries
Creating Asset Instances in the Flash IDE
Importing Sound Assets
Creating Sound Objects in ActionScript
Using Sound Objects

Play, Stop, and Change Volume

You can download the tutorial here:

Flash Sound Object Tutorial

The tutorial includes a Complete copy of the code, and a Skeleton copy for you to practice writing yourself. You will need Flash CS4 or later.

Surprisingly, creating a robust Sound Engine only requires about 60 lines of code.

Hope it's useful,

- Greg

AStar Game

2010-07-08T03:33:00.000-07:00

Recently, I learned how to implement the super-awesome pathfinding algorithm called A*. Given a start point and a goal, A* will find the shortest possible path to the goal while evaluating as few paths as necessary.

Not satisfied with leaving such a juicy algorithm to rot in a classroom, I set out to build a game.

I chose to create a Cat and Mouse game where the player tries to reach a goal while running away from evil baddies. Sound familiar? Well I've made it before:

Warp Chase was the first videogame I ever made. And by "made", I mean copy-pasted from a game programming book and added some levels. Oh shame. At the time, I did my best to add some personal spirit to the title, but didn't know enough concepts to program any of the gameplay that I had imagined.

Lucky for me, this kind of game lends itself perfectly to A*, since baddies need to be pretty movement-efficient to chase the player effectively. I set forth to fully realize the gameplay I couldn't quite grasp before.

Implementing A* was an interesting exercise in itself. I spent a few days experimenting and optimizing my implementation. Ultimately, I cut my processing time for a long A* search from 117 milliseconds to under 4. The biggest gains came from two places: First, I evaluated visited nodes by looking up values in a 2D array, rather than wastefully looking through each nodes list of visited previous nodes. Second, I implemented my own priority queue using a heap, which saved a lot of time on sorting.

From a gameplay standpoint, the escape mechanic was fun for a while, but I quickly grew bored of it. A* was just too intelligent to waste on such shallow gameplay.

I wanted strategy.

While finishing the implementation for the Escape part of the game, I stumbled upon a very interesting bug. Effectively, the bug allowed the player to create walls that could trap unsuspecting baddies. Very interesting indeed.

A few experiments and 9 levels later, I found that the trap mechanic allowed me to make some modestly interesting puzzles. I won't spoil the levels here though. Go play the game!

http://kwarp.com/portfolio/astargame.html

Computer Graphics

2010-03-21T00:45:00.000-07:00

Here's some cool Computer Graphics projects I've worked on this semester:

(Download Here)

In this assignment I wrote a variant of the Midpoint Algorithm to draw lines. You can also toggle attributes such as color, anti-aliasing, and line weight.

(Download Here)

Here's a cool Wireframe renderer. I wrote Matricies that handle all the transforms from Object Space to Screen Space, and everything in between. I threw in my animated robot dude for good fun, and a slider that moves between a pure perspective and orthographic projection. With a perspective projection, objects farther away seem smaller and converge at a vanishing point. On the other hand, orthographic projection has no vanishing point at all.

I wrote the programs using a Java-based work environment called Processing. It's very easy to get started making cool stuff. Check it out.

The Factory Project

2010-01-18T14:40:00.000-08:00

Last semester, I took a Computer Science course about concurrent programming using the Agents. For my final project, I was put into an eleven-person programming team and tasked to design a way for robots to assemble kits in a Factory in 6 weeks. I have put together a walkthrough video of our results:

The five of us in my CSCI 201 class worked on the system design and backend. The other six people were in CSCI 200 class and coded the GUI components.

Our team was very strong, and chose to go well beyond the requirements for the assignment. We chose to make both the machines and the intelligence (making decisions for the machines) operate on separate threads, accurately simulating how a real factory would behave. There are approximately 43 threads in this program.

I decided to try pair-programming with one of my team mates on this project, which turned out to be the best idea ever. We designed pseudo-code for key parts of the system in a single night, and comprehensively worked through the code on paper (and an excel spreadsheet) to insure that the logic worked out. From there, coding was trivial.

The most difficult part of the project for me was designing the behavior for the Factory's FeederController. During runtime, the FeederController cycles through four major part-feeding states. At any time during any of those states, the Feeder could be interrupted with a command to feed a new type of part (or parts). The challenge was designing a system intelligent enough to appropriately respond to new commands under any circumstance.

Unit Testing was an unexpectedly lengthy ordeal, eating up a couple days of my life and 1700 lines of virtual paper. In hindsight, such a comprehensive Unit Test was absolutely necessary. I discovered several behavior-breaking bugs that would have been impossible to detect after integration with the rest of the team. In fact, after integration, my tested components of the system worked almost exactly as expected, and suffered significantly fewer problems than the horror stories I heard from other teams in the class.

While the resulting Factory simulation doesn't look as cool or flashy as the games on my website, it was a worthwhile team experience that dealt with some very difficult programming designs. Additionally, the tools I gained experience with, Subversion, Team Wikis, and Unit Testing, will be indispensable on future programming projects.

3D Animation Reel

2010-01-10T00:58:00.000-08:00

During the Fall 2009 semester, I took a 3D animation course that let me dabble in modeling, texturing, animating, and lighting 3D objects. I've put together a quick reel of some of the more interesting stuff I worked on.

The two big subjects the course introduced me to were animation and lighting. I really enjoyed animating in Maya; it breathed some much-needed life into my (otherwise static) creations. The lighting process is sort of a mixed bag. My 3D objects looked absolutely stunning when lit correctly, but the actual process of lighting an object well took a lot of practice and patience.

Overall, I learned some powerful techniques in this animation course that will serve me well in future 3D game projects.

Instead of Writing a Research Paper, I Made A Game

2009-12-11T01:19:00.000-08:00

This semester, I took a General Education class on Modern Japanese Literature. One of the cornerstones of the course was writing a lengthy research paper about one of the topics discussed in class. Happy to push my luck, I proposed to the professor that I build a game instead of writing a paper. I figured that creating a simple game to satisfy the assignment would only take a few days to make, and it would give me an excuse to work with Antonio Cade, a fellow classmate taking the course, and an excellent artist.

Our professor was intrigued with the idea, but only let us go ahead with it the project if we still wrote a 5-page paper to turn in with the game. Not too bad. That makes about 2.5 pages for each of us, and I could easily fill that space with discourse about the game design process. In fact, that's exactly what I did.

Play the game here: http://kwarp.com/projects/youaregodzilla.html

The game is pretty open-ended. You play as Godzilla, and can walk anywhere on the map. Beware that everything you walk into crumbles beneath your mighty feet. There are two ways to "win" the game. Either violently destroy all the buildings, or disappear into the ocean, never to be seen again. The point of the game is to reveal what the players think Godzilla should think and do. In actuality, understanding what Godzilla is about is a pretty sophisticated topic. The paper portion of the assignment discusses those issues in depth.

Antonio ended up writing the more "researchy" portion of the paper, while I wrote about the game design and vision. Frankly, writing about the game design process was one of the most fun things I have ever done in a writing course. The paper occupies the rest of this blog post. See if you can find where I stopped writing and Antonio began. ;)

===========================================

Greg Lieberman

Antonio Cade

ARLT 100g

Designing the Game “You Are Godzilla”

We (Antonio and Greg) initially had drastically different ideas for how to approach designing a game that answers the question “What is Godzilla Really About?”.

Greg initially wanted to design a narrative-driven game whose theme was to destroy Godzilla before he destroys you. The player would take the role of a person living in a city that Godzilla had begun to destroy, and encounter several moral choices in the game that ultimately lead to either destroying Godzilla or being destroyed by Godzilla. For example, in one scene Greg imagined the player jumping across building rooftops to run away from Godzilla as the creature mindlessly raged forward. If the player kept running away, Godzilla would eventually destroy the whole city. If the player failed to run away, Godzilla would kill the player and then destroy the city. However, if the player strategically attacked Godzilla, the player would defeat Godzilla and the city would be saved.

Greg’s game design was an interesting approach to exploring the way that humans react to Godzilla’s presence, but the design itself did not attempt any deep introspection into understanding Godzilla. In fact, it did the opposite. Greg defined Godzilla as an aggressive villain in the game that must be destroyed for the common good of mankind. Thus, all of the player’s moral choices in the game were framed within the boundaries of Godzilla as a devastating enemy. Ultimately, this one-sided view of Godzilla led to the rejection of Greg’s game design.

Antonio proposed an open-ended exploration game where the player controlled Godzilla directly, allowing the player to explore several of Godzilla’s actions and consequences. The player begins the game as Godzilla near the coast of a city. From there, the player could choose to violently attack the city, attack nearby battleships, harmlessly sulk in the ocean, or leave the map entirely. The genius of this game design is that it empowers the player to be the agent of moral choice, and to project the player’s ideas of what Godzilla does into actions in the game. In tackling the question of “What is Godzilla Really About?”, the game reveals the intentions and biases of the player.

Wherever Godzilla walks on the game map, the creature leaves a path of destruction in its wake. In our Godzilla game, Godzilla will destroy buildings as it walks past them, even if it is not shooting fireballs. This was a crucial design choice. As Honda Ishiro once observed, “Monsters are tragic beings. They are not evil by choice; they are born too tall, too strong, too heavy… They do not attack humanity intentionally, but because of their size they cause damage and suffering” (Ryfle, 161). Ishiro’s comments highlight an interesting ambiguity. Godzilla is not intrinsically a menacing, destructive force bent on destroying human civilization. Rather, it is completely possible that the only reason Godzilla would approach a metropolis is to explore and satisfy its primitive curiosity. The intention itself seems innocent to Godzilla, but a grave problem to the humans it encounters. We saw this curiosity manifest itself in many of the students who play-tested the game. Upon first playing the game and viewing the city, many students curiously walked into the city and began destroying buildings, even if violent destruction was not their intention.

The fact that no part of the game map actively tries to stop Godzilla is meant to follow a common theme present throughout all of the movies, “the profound vulnerability of Japan” (Tsutsui, 91). When a player controls Godzilla, buildings crumble, trees snap, and battleships helplessly sink. The message here echoes that of the movies, “we certainly can’t count on the Japanese government, the United Nations, the scientific community, big business, the professional class, or even the world’s armies to do a very good job of protecting life, limb, and property” (Tsutsui, 91). The world’s utter failure to stop Godzilla further accentuates how out-of-control this “child of the atomic bomb” has become. Here is this huge creature, a product of the reckless hubris of civilization, able to easily stomp all over civilization without resistance. The clear lack of ability to stop Godzilla also expresses the loss of faith in science and government held by Japanese society since American occupation.

The production of Godzilla was taken very seriously, as the film was cultural reminder of Japan’s suffering during the Atomic Age and the dangers of technology. Barely a decade after the atomic bombings of Hiroshima and Nagasaki, the effect of nuclear warfare was still fresh in the memory of Japan’s population. The culture as a whole came to recognize the deadly potential that belies nuclear technology, a strong theme of the Godzilla series. In March 1954, a Japanese fishing vessel, Lucky Dragon No. 5, strayed into a U.S. testing area for hydrogen bombs near Bikini Atoll. One crew member died, another 23 were contaminated from the massive amounts of radiation, and some of the irradiated fish even made its way into the Japanese market. This event serves to show the unexpected and dangerous repercussions of nuclear testing, and its indiscriminance towards the lives of innocents. Godzilla brings these tragic events into public awareness through clear thematic reference, as shown in the opening scene of the 1954 Godzilla film: a fishing vessel is suddenly obliterated by a mysterious energy blast from under the sea. The conscious decision to feature national disasters as plot points shows the director’s intention to openly discuss the impact of these events, and to force the audience to critically analyze their significance in Japanese culture. Japan already suffers from natural disasters such as earthquakes, tsunamis, and typhoons, and by this time the appearance of nuclear testing has instilled another fear of massive destruction in the heart of its culture.

Godzilla truly is a monstrous creature of destructive nature, but his true intentions and feelings remain a mystery to this day, making his identity as a character quite ambiguous. Godzilla’s potential for destruction is constantly made evident, whether he is trampling through skyscrapers and terrorizing the populace, or battling fierce monsters of equal or greater size. However, his use of his sheer size and power has shifted throughout the life of the series. Sometimes he is a traditional giant monster, mindlessly bent on decimating anything and everything in his path, as illustrated in our game by the option to destroy a large number of buildings, battleships and trees. At other times he is the defender of Japan, protecting it from hostile creatures like Rodan or Mothra in gigantic battles. He is a symbol of both the potential hope and the destruction brought by technological advancement, although nearly every instance of hostility in the series—the monsters themselves—is created by the side-effects of nuclear testing, most often radiation. His entire series plays on faults of mankind that could possible lead to its destruction: the greed for power, the desire for dominion over nature instead of living in harmony with it, the will to destroy anything we cannot understand or control.

The article "Japan & Godzilla: Reflecting a Nation's Fears, Concerns and Culture” quotes an excellent summary of Godzilla’s identity as the “reverse of every Japanese stereotype. He is huge, in a country where, until recently, people were relatively small. He is clumsy and rude in a country where people tend to be graceful and polite. He is spontaneous in a place that values the impassive, studied response. He is confrontational where conciliation is considered proper behavior. He is, in essence, a nuclear bomb in a country that is emphatically opposed to nuclear weapons" (Easton, 2). Godzilla is Japanese cultural icon representing the many issues of nuclear warfare and its negative, unpredictable effects on humankind, but as a character he forms a duality with the values and characteristics that make Japanese culture unique. In this respect he is almost an anti-hero to the Japanese people and their values; he is not a character one can remotely relate to, and he often acts in opposition to scientific progress and political authority. He lays waste to industrialized areas with tall buildings and communication towers like a child trampling through a sand castle, and even demolishes the Japanese parliament building. His actions stress the vulnerability of civilization’s building blocks in situations of crisis, yet at the same time he defends it from other his hostile entities. Considering these characteristics as a benefactor and as a destroyer, Godzilla stands as a symbol of restraint against dangerous scientific progress. Technology, while yielding the tools such as medicine and transportation which make human life safer and more convenient, gives birth to indiscriminant, destructive tools such as the atomic bomb. Godzilla is a testament against the creation and use of such technology, as his own destructive nature parallels the destructive potential of man’s own tools.

Work Cited

Ryfle, Japan’s Favorite Mon-Star. Chicago: LPC, 1998.

Tsutsui, William. Godzilla on My Mind. Palgrave McMillan, 2004.

Gunde, Richard. "Godzilla and Postwar Japan." (2005): n. pag. Web. 8 Dec 2009. .

Bunchwacky, . "Japan & Godzilla: Reflecting a Nation's Fears, Concerns and Culture." (2008): n. pag. Web. 10 Dec 2009. .

Semester in Review: FA 102

2009-12-10T18:20:00.000-08:00

I took a Fine Arts Design course this semester to contribute to my minor in 2D Art For Games. The course had me do a lot of sketching and painting with a solid watercolor paint called Gouache. The stuff was slick, better than printer ink.

These pieces are created by painting two sheets of bristol paper with black and white paint. The shapes are then cut out of one sheet and glued onto the other. The result is crisp, clean, and delicious.

The course put a huge emphasis on the process of drafting art. All of our assignments began with several pencil thumbnails, the best of which became ink drawings, then full size drawings, and ultimately a final painted product.

We also had our fair share of technical painting exercises. I will never look at gray the same way again.

My only frustration with the course was that I could not submit any of my final drafts as a computer image (not even printed). The final piece needed to be assembled by hand.

Of course, that didn't stop me from coloring my sketches in Photoshop to determine color schemes. :)

The final product, a 14 by 17 inch poster.

The last class assignment was to redesign a CD album cover. I chose one of my favorite indie composers.

I liked the pattern in the original cover, and decided to expand upon it with imagery that the music triggered in my mind. To keep in line with the technically raw nature of the music, I repeated the simple primary colors and strong angular lines found in the pattern. Materials used were colored pencil, and drops of paint for the stars.

Overall, this art class gave me great practice in design and composition. I learned some useful skills for designing color schemes that will be essential for my digital art projects.

Designing Levels for Kory The Thief

2009-10-21T18:04:00.000-07:00

Kory The Thief was an interesting exercise in level design. Thanks to the Edward Flash Platformer Engine, I was able to build sophisticated levels with relative ease the Flash IDE. In this post I will describe the my intentions when designing the levels, and why every piece has its place.

Tutorial Level

The purpose of the tutorial level is to introduce the player to the key elements of the game. One at a time the player learns to move, jump over obstacles, the nature of sloped surfaces, the consequences of touching lasers, and the behavior of fans and trampolines. Upon completing the tutorial level, the player is familiar with every element that commonly appears throughout the game's levels.

Dino Level 1

To complete a level in Kory The Thief, the player must first grab the level's jewel, then proceed to the door. Level 1 presents the jewel in plain sight, making the goal clear. However, the player needs to circle around the entire level to grab it. In this process the player will likely see the door and find it inactive. After grabbing the jewel, the player has no hint of where to go except to the door. Thus the requirements for level progression are learned.

Dino Level 2

This level lets the player get some air time with fans and trampolines. It adds a welcome change of pace compared to the previous two levels. Like the previous level, the jewel is in an easy-to-see but hard-to-reach location. Moving laser beams are also introduced, increasing the play difficulty a bit.

Dino Level 3

Naturally, a dinosaur themed set of levels should have a giant dinosaur skeleton. The player is pretty smart at this point, so I set a few simple laser traps. They can be easily avoided through caution or trial and error.

Aqua Level 1

A new environment theme. By this point, the player knows to get the jewel then proceed to the door, so the jewel is not in plain sight like previous levels.

Aqua Level 2

The difficulty ramps up a bit here, requiring synchronized jumping with the motion of the lasers. I am particularly happy with how the 3 lasers at the end of the level almost squeeze the player into getting caught. Once the player gets to the door, well, mind the gap.

Aqua Level 3

This stage breaks from the theme of dodging lasers to solving a simple, but tricky puzzle. When the player jumps from a high enough height into the fan updraft, the player will fall past the updraft, hit the trampoline, and shoot up to the ceiling where the jewel is.

Egypt Level 1

This stage introduces conveyor belts and some tough lasers to dodge. The player is smart enough at this point to navigate stages without guidance, so I placed an impassable laser path between the jewel and the door to throw the player off.

Egypt Level 2

This stage introduces lasers that pulse on and off. I torment the player in this level by making the room with the jewel difficult to find. I expect many players to at first skip past the room and catch a glimpse of the jewel while falling down the corridor on the right. Of course, by then it's too late. :P

Egypt Level 3

The final stage looks more difficult than it actually is. There are many lasers in the level, but most are easy to dodge, except the lasers on the conveyor belts. Once the player has spent a few lives figuring out how to grab the jewel, the rest of the level only requires some simple, cautious jumping before the player is out of the museum and scot-free.

In Summary

-Thanks to the linear nature of the game, I was able to design the difficulty curve to tightly coordinate with the player's ever-increasing skill set.

-In designing levels, I gave each stage its own unique shape and progression. Unique levels are memorable.

If you are interested in designing your own levels, download Edward and give it a go.

Have fun,

-Greg

3D Models

2009-07-07T16:28:00.000-07:00

Last semester, I took an introductory course in 3D modeling for video game engines. All the students in the class made assets to help senior game design students with their final game projects. I had a blast working with Maya and made some pretty sweet objects.

After running through a couple weeks of tutorials, our professor let the class loose to create 3D model from scratch. He sent us to a website full of blueprints from World War 1 vehicles and told us to build anything that was not already in USC's Online Asset Database. I picked the Sopwith Triplane and got to work.

Modeling the object was pretty straight-forward. Since this 3D model is meant to be run by a videogame rendering engine, I needed to keep the shape geometry as simple a possible so that the engine could render it quickly.

Texturing the model was a completely different process from building it. The procedure for texturing a 3D object involves mapping its surface in 2D space on a square image. The process, called UV mapping, is much like peeling an orange, ripping the peel into cleverly shaped chunks, and then pounding all the peel chunks together to form a perfect square. Oh, and the computer usually treats automatic UV mapping with the same finesse as a paper shredder, so I needed to do this process manually.

Cool! So where's the texture? Well, I had to make that from scratch too. Making good textures required a comprehensive search of images on Google and liberal use of Photoshop's clone stamp tool.

Eventually everything fits together like a tight game of Tetris and you've got yourself a complete 3D model. I think this plane took around 16 hours to build from start to finish.

My second model was a grocery store for a Dubai-style strategy game. It's meant to be seen from a Gods-eye view, so again I kept the geometry agonizingly simple (perhaps too simple). The class learned a lot about the particulars of Arabic architecture, particularly the flat roofs and bleached building colors.

I loved working on this one. The building is a simplified version of the US Bank Tower, the tallest building in downtown Los Angeles. I managed to work a massive amount of texture detail into the model by patterning the window texture vertically along all sides of the building.

I wasn't even required to make this airport tower. I happened to need one for a Java 3D project and figured it would be good exercise. There are control panels inside the top part of the building, but you can't see them from here.

Score one for effective asset reuse!

Our final project was a bit more involved than the previous models. We were expected to make our model twice as complicated and our textures four times as detailed. Our source material were some science-fiction robot figurines that are popular among hobbyists. Many of the models are carved with insane detail, including realistic rust marks, oil stains, and warped metal all where one would expect. I found some fantastic photos of my model, the SAFS Raptor, for my texture work.

My resource luck aside, the Raptor was extremely difficult to model. The main body was a complex collection of bulging, rounded plates of metal that did not lend itself easily to a mashing of cubes and spheres. I needed three days to get the modeling done properly, and another two to apply the textures. It was incredible that I survived all my finals that week.

Building 3D models was a blast. Next semester, I will be animating them.

Brief Thoughts on Violent Videogames

2008-11-08T02:31:00.000-08:00

I support strict content regulation of violent videogames, but I highly doubt videogames universally make people violent.

Who spends the most time immersed in a given violent videogame? The game developers of course. If videogames universally train people to become violent, then the behavior of all videogame developers would have to most clearly support this claim. Not every violent game developer can aim a real gun properly, or feel indifferent to injuries on real people. Other factors influence the suspectability of a person to commit a violent act, and violent videogames are just one of a vast ocean of potential influencing factors.

The Sliding Button Class

2008-08-18T03:48:00.000-07:00

I recently finished a new Flash game called Trig Spinner. A couple ActionScript 3.0 classes developed over the course of the project, so I've decided to share them with the curious.

Today's class is the oh-so-neat sliding button:

The sliding piece on the button gets dragged by the mouse and when let go, locks to either the left or right side. In Trig Spinner's case, it sets the game mode into either degrees or radians. I made a sample file to demonstrate how the button works:

The class's code goes as follows:

package {

 import flash.display.MovieClip;
 import flash.events.MouseEvent;
 import flash.events.Event;
 import flash.geom.Point;

 //Algorithm
 //on mouse down
 //if mouse is touching slider
 //start dragging it
 //on mouse up over the button or stage
 //if I am dragging the slider, stop dragging it
 //release and autolock the slider to closest edge
 //left = true
 //right = false

 public class SlideButton extends MovieClip {
  //For a cool sliding button that gets dragged by the mouse and locks into place when let go
  //if the piece isn't dragged, the it will also autolock on the closest side the mouse releases inside the button boundaries
  //NOTE: slidePiece1 is an instance variable name inside my library movieclip

  //generic variable describing the boolean state of the button, 
  //access it through myBoolState and interperet it 
  private var myBool:Boolean;
  //assists dragging accuracy, difference between mouseX and slidePiece1's x
  private var xDiff:Number;
  private var initWidth:Number;
  private var rightEdge:Number;
  //constructor
  public function SlideButton() {
   addEventListener(MouseEvent.MOUSE_DOWN, mouseDownState);
   slidePiece1.mouseEnabled = false;
   //true by default, be careful!
   myBool = true;
   xDiff = 0;
   //width changes during runtime when the slide piece is dragged too far, need it constant
   //scaling the SlideButton instance is also a factor
   initWidth = width/scaleX;
   //the farthest x-coordinate the slide piece can go, 
   //do not confuse with the edge of the button graphic
   rightEdge = initWidth-slidePiece1.width;
  }
  public function get myBoolState():Boolean {
   return myBool;
  }

  public function mouseDownState(event:MouseEvent) {
   //convert local points to global so hitTest will work
   var clickPoint:Point = new Point(mouseX, mouseY);
   clickPoint = localToGlobal(clickPoint);
   if (slidePiece1.hitTestPoint(clickPoint.x, clickPoint.y, true)) {
    xDiff = slidePiece1.x - mouseX;
    addEventListener(Event.ENTER_FRAME, dragHandler);
   } else {
    xDiff = -slidePiece1.width/2;
   }
   //let the stage listen for the mouseUp since the mouse can be dragged anywhere
   this.stage.addEventListener(MouseEvent.MOUSE_UP, mouseUpState);
  }
  public function dragHandler(event:Event) {
   //don't drag beyond the button boundaries
   if (mouseX + xDiff < 0) {
    slidePiece1.x = 0;
   } else if (mouseX + xDiff > rightEdge) {
    slidePiece1.x = rightEdge;
   } else {
    slidePiece1.x = mouseX + xDiff;
   }
  }
  public function mouseUpState(event:MouseEvent) {
   removeEventListener(Event.ENTER_FRAME, dragHandler);
   if (mouseX + xDiff <= rightEdge/2) {
    slidePiece1.x = 0;
    myBool = true;
   } else if (mouseX + xDiff > rightEdge/2) {
    slidePiece1.x = rightEdge;
    myBool = false;
   }
   event.target.stage.removeEventListener(MouseEvent.MOUSE_UP, mouseUpState);

  }
 }
}

Download the sample .fla file here.

You are free to use this code however you please (without any warranty whatsoever, not even an implied one), but crediting me would be a nice gesture. ;)

(Learn about ActionScript 3.0 classes here.)

Some of My Favorite Videogames

2008-08-18T00:21:00.000-07:00

These are some of my favorite videogames in no particular order:

Advance Wars is a turn based strategy game for the Game Boy Advance. The game was my first real dive into the strategy genre. I fell in love with the beginning tutorial missions, whose clear instructions eased me into the deep and varied play mechanics as if I had known them all along.

The rest of the game proved equally fantastic. The unique and varied units, commanding officer abilities, balanced gameplay, clever map designs, strategy possibilities, funny dialog, solid music, and stage editor made for a phenomenal package I sunk hundreds of hours into (and hundreds more in the sequels). My only complaint with the first game was being stuck with the same 3 commanding officers for most of the Campaign mode. Thankfully, Advance Wars 2 changed officers every couple missions and made some other welcome improvements. Of the four Advance Wars games (as of 2008), Advance Wars 2 is my personal favorite.

I first attempted to play this gem around 1999 at the age of 10. It freaked me out! Playing as child Link was fine, but after turning to adult Link and encountering the sea of redead in the castle town, those club-wielding boars in the Lost Woods, and even creepier creatures Forest Temple, I was just too frightened to proceed any further. *shiver* Come 2003, I'm completely addicted to this game, replaying it more than 4 times (and one go for the Master Quest version). Of all Zelda titles, this one houses my favorite 3D dungeons, music, and emotionally engaging plot. I still discover quirky details here and there when replaying the game.

Hell yes! Kirby Super Star is my favorite videogame ever. I will happily play and replay this entire game any day of the week. Kirby is an adorable pink blob with the ability to eat his enemies and copy their abilities. The copy mechanic allows players to experience the game's platforming environments in dozens of different ways. The game's rich color palette and happy music create a wonderful aesthetic I dearly miss in more modern "polygon-pushing" titles. The game consists of 5 chapters that take Kirby on different platforming adventures, and also a few mingames for good measure.

One chapter, "Revenge of Metaknight", incorporates narrative in a very interesting way. The chapter reveals plot progression from the radio communications between Metaknight and his underlings. As the player progresses through the platforming stages, the villians comment on Kirby's position in real time as he foils Metaknight's plan to conquer Dreamland one stage at a time. I haven't seen narrative incorporated as tightly into a sidescrolling game ever since. Like the rest of the game, "Revenge of Metaknight" consists of exciting stages, boss battles and sweet theme music.

Another chapter, "The Great Cave Offensive" places Kirby on a fantastical treasure hunt as he searches for a way out of the underground cave he has fallen into. Kirby travels through underground gardens, mine-shafts, and water-filled crystaline caverns (among many more) in his search for wealth and freedom. The sheer amount of imagination poured into each of these environments astounds me; how did these designers squeeze such rich colors and beautiful levels into a 2 megabyte cartridge? The level design proves just as interesting. Collecting all 50 hidden treasures is quite a tough feat, even with the help of a strategy guide. I could gush about this game forever, so to conclude: artistry, music, level design, and play mechanics, Kirby Super Star has got it all. (Also, the 2-player rocks!)