My first two robots in The Supers went from concept/design to hi-polygon modeling (waterfall method) which is a complete mistake because any future changes requires a massive re-working. I suspect AAA games have this problem. Once something has been decided and implemented, changes are hard + problematic + expensive.
So I’ve decided to use a more iterative approach since my deadlines are not as firm as others. I plan to rough model each robot, add a rig, insert it into the game and test out the gameplay before going into hi-polygon modeling. This is more of the “prototype first then implement” methodology and I suspect it will provide a better end result, but cause the project to take longer than expected.
An expensive game with a large team probably would bleed money and get canceled if it tried this method but that is the beauty of indie games - experiment, refine, experiment, refine!
100+ people showed up Friday night to attend the “screening” of the games made at TOJam 3 - all of thanks to the hard work of Jim, Em, and Rob.
It was a lot of fun to see games projected onto giant screens and have people play (or fail to play) them instead of hiding our works in some obscure directory on a hard drive never to be seen again.
Photos of the third jam can be found here/ Pictures of the Arcade night should be up very shortly.
It’s amazing, two years ago I looked for a public implementation of workflow management system for small media projects (like games) and now I still haven’t found an easy/cheap one.
I’m not talking about version control system like Perforce or Alienbrain. I’m talking about Flickr-like access to concept art, web-based access to changes + comments (think blog/Drupal), easy file upload and download (the version control part) and the ability to set and track the status of an asset (think approval levels). The justification behind all this overhead is the ability to share assets with offsite artists without resorting to FTP and E-mails. With FTP and e-mails there is version explosion and a lack of metadata (comments, history, requested changes, approval level, etc.) connected to it
The animation + visual effects business has Tactic but it’s not open and tailored towards those industries.
I’m looking at using motion capture-based animation for the supehero for the simple fact that I can stick (presumably) any animation cycle I find on the web onto it as necessary. Ideally all animation cycles will be tweaked to match the “animation style” of the superhero. The reality is that using mocap data is painful and I’ll explain why.
Here is my workflow:
Build Hero model with default mocap friendly rig (bone hierarchy - no constraints - no IK)
Import BVH into scene - creates bone hierarchy and applies animation
Import hero model in scene - character in T-pose with bone hierarchy
Transfer animation from mocap bone hierarchy to superhero bone hierarchy!
The last step has not worked at all even with two rigs (hero + mocap) having similar but different hierarchies and due to the suckiness of Maya Trax transferring animation has been a nightmare.
So I’m toying with the idea of using MotionBuilder. There is a FREE Learning Edition that works but does not export FBX files for you to use in your 3D app and is for non-commercial purposes (i.e learning!)
MotionBuilder has it’s own idea of what a rig should be. It wants a bones named in a certain way or you will have to manually map your bones to their bones.
This requires a few extra steps so the workflow to get mocap animation into a Maya-based character is as follows:
Export Maya character as FBX (bones + geometry)
Import FBX into MotionBuilder
Create character definition for Maya rig - maps maya bones to MotionBuilder bones
Import BVH/AMC (mocap data) into MotionBuilder
Create character definition for mocap rig - maps mocap bones to MotionBuilder bones
Transfer animation from mocap to Maya rig (pretty easy)
Export animation into FBX
Import FBX into Maya and onto the character
The hard part is still transferring the animation because of differences in the rig. Sometimes re-targeting is necessary, but if you have to do it… MotionBuilder seems to be one of the best tools for that task.
At the recent Toronto GameCamp, j2Play presented their SDK/service for self publishing your game on social networking sites using their “universal gamertag” (that’s what I call it)
j2play is the not the publisher - they only provide the framework for you to connect your games to Facebook and other social networking sites. What do they get? A piece(15%) of the advertising revenue in exchange for the infrastructure they provide like Leaderboards, Badges, and Challenges - a great deal if you ask me because they ask for no money upfront. Details here.
As an indie game developer, you can take two viable (let’s assume) directions:
Self-fund and beg artists to work for free. Stay small and the game stays indie.
Sell out and get external funding. Grow to a small crew and the game goes tries to become commercial.
Well I’ve taken the second route, but I must admit the past few months have been as Alexander would say “Terrible, Horrible, No Good, Very Bad” due to the stress and uncertainty When a game requires more than one person to build, it stops progressing when others are not available - which is usually due to lack of funding to pay them or if they are working for free, spare time, because they need normal jobs to pay rent + food. Thankfully, I’ve recently acquired some significant funding.
If I had gone route No.1 like Petri then life would carefree and simple, right? At some point I’d run out of resources(time + money), of course and I’d have to return to the workforce.
