iPad game LineBloom created at DinoJAM

This past Saturday and Sunday I had the fortune of attending the second ever DinoJAM. This event was co-hosted by Emily Daniels and Darren Torpey at the DINO/Sprout space in Davis Square. Right after wrapping up at 3d Stimulus Day, made my way up to Somerville to make some games.

This is what I came up with (made in Unity):

It definitely translates well to the iPad touch screen. Just draw lines and they appear. It feels pretty fluid, but the low framerate video capture doesn’t convey that very well.

Thanks to Lawrence Lee for the epic music – Berkeley musicians make some good stuff quick! Props to the game jam musicians out there.

Congrats to the other attendees for making some seriously cool stuff. Great games/projects all around , and thanks for live-tweeting (@demiurgestudios @acosmos @jdemond @emdaniels @darrentorpey @davidludwig @boodooperson)


3d Stimulus Day

I recently presented a talk at the second annual 3D Stimulus Day entitled “Problem Solving: A day in the life of a Technical Artist”. The session went very well and I received some great Q&A at the end. Thanks to Heidi and Brad for setting up the event, Eric Chadwick for editing and suggestions, and to the other presenters for making it a great day. Also thanks to Eric for working with me to rig the First Act guitar give-away. Kidding!


Unity experimentation – gravity, perspective, and teh Youtubez

Last night I began logging my development adventures by resurrecting my dusty unused Youtube channel. I uploaded around 7 videos, some of which were previously un-seen prototypes I’ve been messing around with recently.

Here are the new videos:

Please feel free to subscribe to my Youtube channel.

Comments Off on Unity experimentation – gravity, perspective, and teh Youtubez Comments

Max vs Maya – The war rages on

I want to mind dump my thoughts on the ever present war of Max vs Maya for general modeling, animation, and game development. Each has their plusses and minuses, and I’m going to quickly explore different key areas of each program in search for a clear winner in the fields of clarity, usability, and features.

Max represents history in their Modifier Stack paradigm. Deformers, unwraps, and other modifiers can be stacked on top of each other and are easily viewable in a simple table. Maya on the other hand uses the node structure to represent dependencies and related modifiers for a certain object. The clear cut winner in my mind, as far as simplicity and user interface is Max. Just look at the screenshot. Maya’s highlighted arrow doesn’t even tell you where you’re going to to end up when you click it. It’s like a mystery wheel! Or you can brave the depths of the hypergraph to see your node graph. Eww.
Winner: Max

Material Editor:
Maya has a well laid out material editor called the Hypershade. Create a new blinn, assign some properties. It’s very simple to use and you can see all of your materials at a glance. One downfall is that the default way to assign a material to an object is to middle click drag the material into the scene. This is far from the best approach. I am aware of the right click -> Assign material to selection but it should be much simpler. Another problem with Maya’s material editor stems back to the original node based decision for the whole basis of the program. In order to, for example, delete a file node that is linked in your bump channel, you cannot just hit delete or unassign a texture. It seems that the quickest way is to go into the hypergraph view and delete the actual file node that was created when you assigned a texture to that slot. Messy. On the other hand, Max’s material editor uses a confusing slot system that to me seems counterintuitive. When I look at a material editor, I feel like I should be able to see all of the materials in a list. Max instead chooses to represent materials on arbitrary material slot nodes, so if you see 4 textured preview spheres, it does not mean that there are 4 materials in the scene, but that you have created pointers to four existing materials and there may be more or less. You can even clear out all of the material slots and then are forced to use the eyedropper tool to load a material into the slot. Horrible.
Winner: Maya

Both Max and Maya have highly customizable interfaces with great context sensitive radial right click menus (or quad menus as Max calls them and marking menus as Maya calls them), customizable top menus, toolbars, custom actions or script buttons, etc etc. Both have more than adequate modeling tools, especially with Max2010’s graphite modeling suite, there’s a plethora of modeling tools available to use for any task. Max still hasn’t moved from the separate Editable Mesh / Editable Poly paradigm, which i feel is a weakness from a scripting and usability standpoint. At some point you need to ditch the backwards compatibility and put the best tools into one combined mesh interface. Max fails miserably at alphabetizing their modifier list, and that list has gotten WAY too long to keep in a linear pulldown menu. Shame on you Max. Then again, Maya’s interface looks like a bad Java app or a linux GUI… so there’s not much beauty to go around in this fight.

Winner: Tie

Despite what pretty much everyone else says, Maxscript seems equally as powerful as Mel so far, as I haven’t come across many things you can’t do in Maxscript, yet. That yet is a pretty big yet, and as time goes on and I develop more and more Maxscripts, I might need to revisit this section, possibly with a deep hatred for Maxscript. One thing to point out is that all of Maya’s commands are completely written in MEL and are available to browse, so ANYTHING can be scripted in Maya. Plus the addition of Python seems pretty huge for both Max and Maya, so there’s also no clear winner in this category.
Winner: Tie

Maya is cross platform. This is a huge plus for Maya that pretty much pushes it into the ‘extreme win’ category for me and thousands of other Linux and Mac users. Even though Autodesk owns both, I can say with reasonable confidence that Max will NEVER be ported to any other platforms. Also, the community is huge for both Max and Maya, and fanboys will continue to strangle each other over their favorite DCC app. One thing I would love to see to unify Max and Maya (come on Autodesk!) would be to help ease the pain of switching between Maya and Max. This could be helped by combining the documentation in a way that search terms for one app’s features will show up in the equivalent function of the other app. For example, a search for merge vertices will bring you to the editable poly/mesh docs for Max and show you the Max equivalent weld verts command. This type of guide already exists for Maxscript/MEL, located here.

Final Verdict:

Use whichever one you are more comfortable. Hey, they both import silently into Unity, so what’s not to love? It’s not worth the pain of switching just because your friend thinks the other app is better. If you join a company that is strictly Max and you’re a Maya person, take the time to learn the other app. It’s not that bad, really. Or if you want to avoid the Autodesk monolith, just use Softimage’s XSI… oh wait. *Sad*

So I’m not exactly the authority on either Maya or Max, so feel free to share your opinions in the comments section. Also, you may have noticed that I didn’t weigh in on UV tools, the quality of the individual modeling tools, and many other aspects of each program, either due to laziness or a lack of in-depth familiarity with that aspect. Weigh in!


SpringFling – Main Menu UI Mockup

A quick mockup of the UI. Grass and sky were painted in Photoshop. I plan on having the sun come up over the gray UI element as a subtle tip of the hat to the geniuses at Popcap.

I’ve been using the name ‘SpringFling’ as one word throughout development but people frequently put the space after spring so I don’t feel too bad wrapping the name on two lines in the main menu.

Comments Off on SpringFling – Main Menu UI Mockup Comments

Thoughts on the Unity engine

A few weeks ago, some friends of mine were starting a project and were deciding on a 3D engine to develop a desktop PC game in. I tried to list out the pros and cons of the Unity engine, which would in my opinion have been a great choice for the project they were kicking off. Here is what I wrote:

I have played a part in creating three Unity games, ported one other Unity game to Unity iPhone, and am currently creating an iPhone game with it. I know that isn’t ‘loads’ of experience and the games were medium to low scope, but here’s my thoughts on it:


  • Ease of Use: Unity provides easily the most seamless and anger-free development environment I’ve ever laid my hands on. From day one, everything made sense, and whoever designed the top down workflow must have been an engineer at Apple or something because they really nailed the interface, flow, and logic for creating games. Getting a prototype up and running is quicker in Unity than any other engine I’ve seen so far and that’s counting GameMaker and Flash.
  • Physics Integration: PhysX is built in and ported for both Mac and PC so it just works. You can add rigidbodies, forces, joints, etc to objects with one or two clicks or a call from the rigidbody class though code.
  • Art Pipeline: Unity provides an amazing art pipeline out of the box. Drag and drop integration with maya (.mb) files (and .max files in Windows) and native FBX support give Unity a one step pipeline: If the file is in your asset folder, it is automagically imported. You can also update a 3d scene while Unity is open, tab back to Unity and it will change in real time, even while the game is playing. That’s another thing; live changes. You can tweak values while the game is running by exposing variables to the editor and then changing them on the fly for very quick iteration and value shifting. It’s like Firebug for game development. Web developers know the glory that is Firebug.
  • Networking: Unity provides built-in networking classes that ease the pain of writing your own networking code. Then again, if you’re writing an MMO, you’re probably going to completely tear apart their built in functions and roll your own.
  • Deployment: You can build to Mac (PPC, Intel, or Universal Binary), Windows, or browser-based format (or the almost never used OSX Dashboard export). This makes porting a non-issue, as everything is handled for you. There are separate builds for Wii and iPhone development but your code will largely remain the same. iPhone will cost you extra and Wii will cost you a LOT extra (they won’t publically list the price).
  • Price: 200 bucks for an Indie license and 1500 for the Pro license. With Pro you get the ability to do post-effects, render textures, simple video playback, realtime soft and hard shadows, as well as terrain/asset streaming. You can still use projector blob shadows in Indie and code a loop to play back short videos in an image sequence, so Pro is definitely not always necessary. Indie will also throw up a little logo on the bottom for the first few seconds, so keep that in mind.


  • Source code: No, you do not get full source when you purchase a Unity license. The cost of the license is pretty indicative of that fact. The thing is, you won’t actually miss it. All of the coding on the developer’s end is done in C# or Javascript (well, a Javascript based language called UnityScript) or even Boo script (which almost no one uses). There is a massive list of API calls and built in functions and Unity really allows you to get at every level of the engine, from simple lerps and physics functions to low level engine calls (garbage/mem management and lots more) You can write your own C++ plugins and shaderlab/CG shaders can be written for custom graphics needs (toon shading, outlines, different post processor effects, etc etc). It does come with loads of pre-made graphical effects and shaders such as line render, toon, post blur, refraction, reflection, water shaders, glass, and an assortment of combinations of parallax, bump, spec, alpha, and diffuse shaders). Most if not all of the Unity forum members will agree that you can get down and dirty without having to touch the source of the engine. It’s been my experience that the cheaper engines that provide source in the regular engine price use that fact as an excuse to omit certain API calls and a sense that “Well, if the user really wants to , they can dig through this obscure section to modify it on their own”. This is what I often hear about Torque, the messy unkempt source with a serious documentation lack is not really helpful to most, and having to dig through someone else’s extremely low level complicated code is not always the best way to go about customizing something that should really have an easier outlet for change. Same goes for the C4 engine, in my experiences, but I don’t have the C++ knowledge to be able to really get in deep in the source and truly understand the inner workings of a full fledged game engine.
  • Version control: Versioning is wonky unless you buy their asset server: Because of the way Unity stores its project files, there are parts that do not play well with SVN/CVS. Therefore the Unity team sells an addon called the Unity Asset Server ($500) which is a fully featured asset server that will allow better collaboration among teammates (from what I hear, I haven’t had personal experience with it but I havent heard any negative comments about it, other than the fact that larger teams are pretty much forced to use it).

*Note that there would be a completely different list of pros and cons for Unity iPhone vs straight Objective-C or 2D sprite engine, but I’ll save that for another day :)