Thursday, October 16, 2008

Dead Space is live!

As of yesterday, Dead Space, the last product I worked on, has gone out on the shelves. It's getting great reviews!
As of right now on Metacritic, it's getting a 90 on PS3, and 89 on Xbox 360. The PC version should be out on the 21st I believe. It's currently the 8th highest ranked PS3 game of all time on Metacritic, not bad!
There's a new trailer on the main site link above. Gives is a "movie trailer" feel.

If you're wondering, my roll on the game was "Technical Character Director". I created and\or supervised the creation of the overall technical character pipeline from art to engine: Character\creature\weapon\prop rigging, skinning, building, export, and a lot of animation tools. Basically, if you see it move in-game, I had some part in it.

Saturday, October 11, 2008

Edge detection in Processing, take 2.

A few new things: There is a base set of circles called "planets" that bounce around, getting smaller towards the top of the screen, and larger towards the bottom. They emit gravity on the "orbits", which are fixed sized circles bouncing around the screen. The planets try to pull the orbits to them if within range: the smaller the planets get, the less gravity they have. The orbits are also rendered to an off-screen buffer where a glow is created, then the buffer is reapplied back to the final image.

Originally uploaded by warpcat

Tuesday, October 7, 2008

Edge detection in Processing.


Originally uploaded by warpcat
After a few month hiatus (darn that Python), I thought I'd get back into Processing. Taking an old sketch, I wanted to try a few things: Simple motion in a confined space, and edge detection of colliding volumes. I solved the issue of edge detection by code found in "Processing - A Programming Handbook for Visual Designers and Artists" (by Casey Reas and Ben Fry, good book) dealing with 'convolution'. If you're interested in that convolution code, you can find it here (Unit 40 (Image 5), example 12) . My first crack at it, but it pulled off the effect I wanted perfectly. However, this only gave a very thin edge as a result. I wanted the edge larger. To pull this off, I ran a blur filter, then a threshold filter to blast out the blur to pure white and black, then another blur on top of that. The sketch got pretty slow, about 1 fps on my older laptop. For the motion, the circles get smaller as they move to the left of the image, and larger as they move to the right. Some circles are solid, while others have the opposite fill, givng them a donut effect, and I think providing a more interesting look overall as opposing values collide.

I was going to post the source for this, but my Processing Wiki currently isn't letting me update it... frustrating.

Monday, October 6, 2008

Dots in procs?

I've pretty-much made the switch from mel (Maya's scripting language) to Python. And what I describe below is standard in Python (implemented differently, but similar visually). But I just recently learned that you can include dots (periods) '.' in mel procedure names. While this doesn't in any way change their behavior, it does let you organize your procs in a more intelligent way based on their names.

Background: In Maya, if you have a global procedure in a mel script, and the global proc and the script share the same name, when you call to the name (via some other proc\script), Maya will search in its 'script path' for the script with the name, then search in that script for the global proc with that name, and (if it finds it) execute the proc. Furthermore, any other global procs in that script are now sourced and can be executed outside of the script by other procedures. Nothing new here. The 'dot in name' convention though lets you associate the script name with the other global procs in the script. When calling them in other procedures/scripts, you'll have a visual reminder of where they came from via their name. To explain this a bit better, an example:
// foo.mel

global proc
print "doing .boo() work\n";

global proc foo.shoe()
print "doing .shoe() work\n";

global proc foo()
print "foo.mel -- I do nothing.\n";
print "My global procedures:\n";
print "\\n";
print "\t.shoe()\n";
The above code resides in 'foo.mel'. Inside, there is a global proc called 'foo()', that doesn't really do anything other than print some info. But its there so when the user calls to 'foo()', the other global proces will become sourced. There are other global procs in the script that do the actual work. When you execute 'foo()', the other global procs '' and 'foo.shoe()' are sourced, and can be called to inside of that script, or other scripts\procs. If you're calling to them inside that script, it's fairly obvious where they're coming from. But say you have some other script called 'goo.mel':
// goo.mel

// Execute foo(), making its other global
// procs available in this script.
// Could have optionally executed 'source foo;'

// Execute foo's global procs:;
'goo.mel' executes (or optionally sources) 'foo.mel', thus giving 'goo.mel' access to 'foo.mel's' global procs, and then can call to each of them. By having 'foo.' in front of each proc, it's plainly clear to the user where they originally came from, which is a great aid in troubleshooting. This is a simple example, but imagine if you have goo executing procs from foo, moo, hoo, doo, etc, and you can see where this can come in handy.

So again, the 'dot in proc' is by no means required, but it's another tool in your organizational toolkit.

Friday, October 3, 2008

Dead Space on Metacritic

The last game I worked on, Dead Space, isn't out until Oct 14th, but it already has its first review up on Metacritic. 91! Very Nice. I've played through the game, and it's one of the first games in a long time that I worked on that I actually enjoyed playing though.