It is a special kind of person that will actively choose to go to a Game Jam. These jams are usually a 48-hour crucible that pushes mental endurance to the limits and to willingly give up two days in order to co-create a video game with a collection of strangers and friends speaks volumes. At the end, one comes away with an unparalleled felling of accomplishment and an electric pulse that will leave one hungering for more. In addition, the camaraderie of fellow game jammers will flourish into close friendships lasting years to come.

Global Game Jam of 2013 in San Francisco was no different, which took place in a co-working space in the heart of downtown. Upon arriving at the jam, I knew I was amongst my own people.  The folks that had gathered were all craftsman in their own right, be that in code, art or design. After the usual pleasantries of meet and greets, we broke off into smaller groups, all ranging from the single lone ranger to the massive tribes of ten. Personally, I had found fellowship with a motley crew of three other characters. Maybe it was written in the stars, maybe it was just luck of the draw, but over the next three days we would come together as a tight-knit team.  In the end, we had created a game that received a number of accolades from our fellow jammers.

At the core of any game jam is a theme, which is meant to serve as the seed for a game’s creative start. This year’s GGJ the theme was an audio clip of a beating heart. The key with any theme is not to take it literally, but to explore the fringes of what it could represent. After an hour or two of scheming, we had settled on a collection of ideas for the start of our entry. Taking the concept that a heart beat was a continuous signal; we chose to create a space horror survival game where the player is stranded in a pitch-black maze. The only guide for further progression is a constant “ping” or signal beckoning the player to proceed forward. It was decided upon early that there should be a feeling of helplessness as your move through the experience.  To make our lives easier and for effect, the player would never be able to fight back but only run as the main mechanic. We then came up with a quick concept art sketch to get the team’s mind on a single track; this also provided further inspiration as the jam progressed.

What Went Right

From early on, what drew our team together was that we were going to use Unity3D as the basic building block for the game jam entry. Unlike most of our fellow game jammers, the team had their heart set on creating a fully interactive 3D game with characters and environments.  This is also what set our entry apart from the rest. A fully walking, running and jumping 3D character is no small achievement, but, thanks to a fellow game jammer, we were turned on to a character animation middleware by the name of Mixamo. After reviewing the basic setup required by the animation software, we had a fully rigged and working character in less than four hours. Once the basic setup was completed, the team was able to choose from a huge library of motion capture data. Using the pre-made scripts provided by Mixamo made the integration of the animation as simple as dragging and dropping. It was also a godsend that one of the key developers of Mixamo was on hand to answer any of our questions and help work through any issues that had cropped up.  This in turn left our team to focus on the task of creating an experience instead of worrying about the minutiae of technical details.

The second major contributing factor of the overall success of the game was the visual and audio ambiance that was achieved.  It has been said horror is more about what is what your eyes cannot see than what it can. By creating a contrast of light and darkness, the player was left with a sense of helplessness and fear. This was the basic core of emotion that the team wanted to convey in the overall experience. In addition, the team was able to provide a music and effects soundtrack that perfectly complemented the bleak settings portrayed in the game.

What Went Wrong

Like any game jam, time is both the principal strength and weakness. Although we were able to achieve a lot of the basic gameplay that was initially conceived, a majority was left out due to a sheer lack of time.  Areas that we wished we could have explored more were a more substantial use of the light in the game as well as a better AI and Enemies. Maybe someday, we as a team will get together and try to flush out a more comprehensive experience. This could be very much be a Kickstarter in the making–a boy can dream…

In the end, we were proud of what we accomplished in such a short amount of time. It was due in part to the technology we used while the sheer skill of our fellow team members made up for the rest. What made everything truly worthwhile was seeing complete strangers become so engrossed in something you had put your heart and soul into. With that, I can only say for anyone that has ever thought about attending a hackathon or game jam, go do it. Go do it now! Once you have threaded that needle, you will come out a changed person and all for the better.

This article is featured on the official Mixamo blog, also the game can be played via the link.

After a few nights of work (much thanks to Dr.Woohoo for guidance and his extendscript tutorials), it was complete. So without further banter, here is the zip with a script, Illustrator and FontLab Studio template files to help vastly speed up the hours of tedium that comes with creating a font.

fontGenerator.zip

Also a link to the git repo of the project if you choose to extend the script.

We are calling it the “Circle Slider Button“. Yes, the name could use some work; suggestions are welcome. But as defined in the video above, it is a button that slides out to reveal other buttons that can be set and unset accordingly.  The CircleSliderButton object is initialized with a set number of CCMenuItems. With a little magic from a double angle formula and some objective-c, it will then create an equally spaced radial menu. The reveal can also be altered at any point by redefining the object’s actions.

The full source as well as the PSD files for all the buttons used in the demo can be found at its home at github. Feel free to alter or use the code to your heart’s content.

# Detect for heterogeneous array
array = [1, 4, "hello", [2, 4], 3.5]
if array.map {|e| e.class}.uniq.size > 1
  puts "Heterogeneous Collection"
end

Using the map iterator, the code will generate a new array of object class definitions for every object in the collection. Now, it is a matter of checking for the number of uniques in the resulting array. If it is more than one, you will have yourself a mixed collection.

When a game requires real world simulations of objects interacting with one another, programmers turn to a physics engine. These engines are just large calculators that help determine the position, rotation, velocity and acceleration of game entities. But, when it comes to the internal structure of how these engines work, most game developers are at a loss. We tend to think of physics engines as black boxes that perform some magic and rarely care about the deeper implementation. Although the output of these engines are amazing to behold, it can be quite advantageous to understand its underlying mechanics. So, when one comes across anomalies caused by physics, we can dissect the causality of what is going wrong.

The underlying characteristics that determine how to deal with objects in an engine are either Mass-aggregate or Rigid-body. Some other types of physics engines that are outside the scope of this article are soft body dynamics and fluid dynamics.

Mass-Aggregate Engines: These types of engines treat entities as a collection of smaller masses. These masses are connected with a network of rigid poles. A box can be constructed with eight separate masses that link in a web to form a solid. Mass-Aggregate engines are generally easier to program, due to each mass being expressed in only linear motion. But there is a drawback to these engines: truly solid objects become hard to simulate. There is always going to be some amount of spring in your mass, so extra code is required to correct these imperfections.

Rigid-Body Engines: With rigid body dynamics, objects are based on movement in three degrees of freedom. These objects occupy space and have properties such as a center of mass, moments of inertia, and are characterized as being non-deformable. Central characteristics of these properties are motion that is defined in six degrees of freedom, which are defined by translation in three directions plus rotation in three directions. What sets this type of engine apart is their level of realism, but this comes at the cost of being harder to program.

When boiled down, a physics engine processes how and when two objects are to touch which is denoted as contact resolution. This is delegated to objects that are sitting on the floor, objects connected together and collision of objects. There are three major avenues to go about handling these contacts.

Iterative Approach: Usually the easiest approach to implement, each contact is processed one by one. This works well with a limited number of contacts and can be resolved quickly. But it can run into problems with multiple objects colliding creating a large chain of collisions.

Jacobian Approach: In this method, each contact between objects is calculated as an overall set of effects and are applied to all objects at the same time. The down side is the calculations involved are processer intensive, but this can result in a more physically accurate simulation. Another pitfall to this approach is some collisions are just not accounted for and extra code must be written to deal with these conditions.

Reduced Coordinate Approach: These engines throw the laws of Newton out the window. Instead, sets of calculations are created to deal with every type of contact and constraints between objects. Most engineering software take this approach due to it’s high level of accuracy but it is an unrealistic solution for real time simulations where speed is key.

The last part of the puzzle is how these engines resolve contacts, or what happens after objects collide. This is when force comes into play. In physics, force is what changes a state of rest or motion in an object. Forces cause objects to accelerate, change direction or change shape. A crate sitting on the ground receives the force pushing up from the ground while at the same rate of gravity pushing down. In turn, no change of motion is experienced. In the case of a bouncing angry bird, the force acting on the bird is greater than gravity in turn causing a change in velocity. But this force is acting in such a small interval of time it can be considered just an impulse.

Force Based: Some engines use force to rest objects and impulses for colliding objects. A more frequent approach is to just treat everything as a force. This approach proves to be quite tricky to implement being that the equations behind forces are complex and are harder to implement.

Impulse Based: An alternative is to treat every collision as impulses, which are just, forces acting over a short period of time. A stationary object is kept still by calculating multiple collisions. The draw back is at lower frame rates; stationary objects can appear to jitter. But, being that the implementation is simpler, it is a good route to take.

When creating a physics engine from scratch, it is advisable to create it in stages. First, taking simple steps to create projectiles and eventually working your way up to cars and ragdolls. A wonderful book on the subject on physics engines is Game Physics Engine Development by Ian Millington. Also, currently we are developing an open-source JavaScript physics engine Bounce.js.

For all the video game loving peeps out there, that got them selves a sweet new HD ipad today! The full size image can be downloaded here.

As stated before in my previous tutorial, we are going to be building a 3D shooter that is an homage to some of the classic games of yesteryears. The goal of this installment of the series is to get an understanding of how to create a graphics pipeline. But before we get to into the nitty-gritty, we need an update on some of the tools and frameworks we are going to use.

Selected Frameworks and Tools

This is in addition to the list from the last tutorial in the series.

• MAMP: Quick set up of a local server for web development on OSX.
• Sparks.js: Particle engine built on top of three.js.
• Ammo.js: Physics engine for collision detection.
• ThreeConvert: Utility for batch converting .obj files to .js format.
• ThreeFab: JSON .js asset viewer
• irc.freenode.net #three.js: chat room for three.js help

Graphics Pipeline

According to Wikipedia, “the graphics pipeline typically accepts some representation of three-dimensional primitives as an input and results in a 2D rasterized image as output.” In our case, the 3D models we are going to create for the project are going to be rasterized by our draw engine–which is WebGL. This is done with the help of the abstracted layer that is three.js. Boiled down, the graphics pipeline is detailing how we are going to get our art into our code.

Before we even get into exporting our models, we need to talk about 3D packages. The current application for creating 3D assets for this project is going to be Cinema 4D. There are much better alternative 3D packages for setting up a pipeline to three.js. Currently, Blender comes out on top as the best software for integrating models into three.js. This is mainly due to the add-ons that let you export and import the native JSON three.js format. The second in line is 3ds Max, a popular 3D package that is exclusive to Windows. It is also the application of choice for most of the AAA game industry at large. Max via a plugin lets you export to the native JSON format while importing is not supported as of yet.

The rest of us who are not on Windows and those of us who detest Blender (any real 3D artist) are left with the very few alternatives. The first method is to output as an .obj or .fbx file and then convert to the native JSON format by using the python scripts that comes with three.js. To compile problems, the script for converting .fbx files is extremely outdated, in turn leaving us with the only choice of our export format as .obj. It must also be stated .obj files have no support for bones or animations, but for the current project, static meshes will work fine. Also, for those of you who can’t be bothered with command line utilities, there is ThreeConvert–an OSX utility app that lets you batch convert .obj files. The second method is to export as a COLLADA file format.

Note: All the plugins and exporters can be found inside of the three.js package in the folder utils/exporters.

JSON vs XML Fight!

Although the COLLADA files seem to work fine, the optimal method for importing 3D objects into three.js is to use the native .js format. The reason for this is due to the speed of JSON vs XML on the web. COLLADA documents are descriptions of digital objects using an XML schema to exchange digital assets in various graphics applications.

With traditional game development, the issue of loading large files is trivial being that the files live on the hard drive. The low latency between the data storage of the hard drive and the CPU lets native applications deal with large formats with minimal effort. This is the opposite case with the Internet. Your browser is only fast as your Internet connection and the choice of file formats plays a crucial role in the speed of your application.

This is where the native JSON loader of three.js comes into play. JSON or JavaScript Object Notation is a lightweight text-based open standard that is derived from the JavaScript associative arrays and is used for data interchange. Three.js itself has defined a model format using JSON to represent 3D objects and currently it is in version 3.0. After some extensive testing, the results of the two files were astonishing. Not only was the JSON format faster on load time, the output was also visually much cleaner. This was very much the case for very low poly objects as you can see with the side-by-side comparisons. Another caveat of using COLLADA was more lights were required in the scene to properly display the assets.

It has to be stated that the development of the COLLADA loader has currently ceased. There has been interest shown from The Khronos Group to pick up work for the loader, but at the current time, nothing has come of it.

Getting Baked with Tricks of the Trade

At the end of the day, all we want are clean assets in our game and we have to choose the best set of methods to accomplish this task. Being that we are dealing with the limited nature of webGL, we are going to have to employ a few tricks to get our assets to look nice and pretty inside of our game. The avenue we plan to take is a trick used in such games as Mirrors Edge and Proun. The style of our game is very simplistic but the visual fidelity of the objects can be improved upon by using Global Illumination(GI) and Ambient Occlusion(AO). These graphics rendering techniques are very processor intensive and virtually impossible to accomplish in a real time web based game. But, what we can do is bake the lights and AO into our game before exporting our models.

The game Proun used these techniques with some beautiful results, as you can see with the sample image below. If you have yet to play the game, go download it now! It is ok, this webpage will still be here when you get back.

The baking of GI and AO are a little bit out of the scope of this article. But, thanks to the awesome people of the Internet, detailed explanations have already been made on these subjects. Below is a list of the tutorials.

• Bake Object in Cinema 4d – YouTube
• Baking GI Basics – C4D Café
• Cinema 4d GI Baking with Importing into Unity Pro – YouTube

Conclusions

So what have we learned? Exporting from C4D into three.js is no easy task. But, the pipeline has been forged and it is too late to switch 3D packages. Down the line, I “might” consider using Blender, but a better option would be to create an exporter for C4D that creates JSON objects. Scale is another issue that was tackled while exporting. Generally the smaller the better; it is best to work at a millimeter scale when creating 3D models or just resize objects accordingly during exporting or loading. Another gotcha that one might run into deals with the local center axes of assets. If the object you are exporting is going to animate and move, it is important to set the local center point at the origin of the 3D package. With assets such as backgrounds or scenery, it can be advantageous to set its position inside of the 3D package as opposed to hand setting it in your coding environment.

At this point in the article, you must be asking yourselves where is the big payoff? So without further adieu here it is: Shooter01

Now, if you are not all that impressed, it is ok. Mind you, this is what is referred to as the Black Triangle. It is the journey that the object had to take to get on to the screen. It had to pass through a modeling tool, then to a converter program, then had to be loaded into the three.js code fully textured, and then finally rendered. The black triangle is a statement of a complex system being completed and now we can put work into doing more cool stuff.

When dealing with bleeding edge technologies, it is guaranteed you are going to run into unforeseen roadblocks a lot of the time. It is going to be up to you to forge ahead and set a path that has never been taken before. You will have to learn to roll with the punches. Just because there is a lack of documentation of what you want to accomplish, it should never hold you back. One great thing about three.js is the helpfulness of the community. With a little bit of digging around, you can easily find someone that will help answer your questions. Any framework is only as good as the people that are supporting it. So with that stated, if you have any questions please feel free to contact me or leave a comment.

Next

Coming up, we plan to get the ship moving around and firing some bullets.

• Quick overview of three.js.
• Moving the ship via input commands from the user by JS event methods
• Shooting lasers and bullets

This amazing piece was done by a close friend of mine, Gabo. Who has reminded me of what it means to be an artist once again. With any skill that is learned, it can also be unlearned. The only way to become a great artist is to draw and draw every day, draw every hour, draw every minute, draw every second! If you want to check out more of Gabo’s badass work that ranges from art to game design, it can be found at his blog gabotron2000.tumblr.com.

The OSX app ThreeConvert can be downloaded here. Also the source can be found on github.

Great video essay by Chris Franklin aka Errant Signal on what makes Doom, Doom. A breakdown of one of the greatest FPS games ever made. Must watch!