Time’s starting to get tight around here due to a bunch of N+ related deadlines.. however we’re going to do our best to keep this delicious blog from getting too stale.
Let’s just backtrack a bit. This was almost exactly a year ago:
- we made all sorts of soft-collision/simple physics experiments (as mentioned previously)
- we banged out a geometry-based collision system which worked pretty well (mostly this was a proof-of-concept to convince us that such an approach would be much simpler in the long run than the tile-based system in N)
- we spent about a month getting rope collision working (an incredibly bitchy problem since finding the actual intersections involves swept-lines vs swept-points, and moreover required a pretty sophisticated event-based scheduler/simulation to properly handle all the wrapping/unwrapping that can occur between frames.. how the hell did they do it in Umihara?!)
- we came up with an initial concept for graphics/design, and did some mockups/prototypes of ideas
- we started learning C++/openGL, and got some of our graphics ideas working (as well as text rendering and some other misc junk)
..That may not seem too bad for 5 months or so, but at this point we were planning on having the game ready for September 2006 (aka “IGF entry deadline”). So, from that perspective we were a bit behind.
Then again, we couldn’t really be said to be working on the game, since what we were doing was more like R&D for when we eventually started work on the game proper. When we came to this shocking realization, we decided that — given the immense amount of work required to get this right (just getting up to speed with C++ is a big enough task!) — we should push things back a year.
Aside: Our initial business plan (yes, we actually have one) was to release one game a year, with target sales of 1000/year. This might seem incredibly low or high, depending on your perspective; our desire to sell things through our site (instead of via portals, which probably wouldn’t want our games anyway) and the fact that N was generating a decent amount of web traffic (~2k downloads/day) led us to this decision.
This plan as a whole might seem a bit untenable (yearly income of ~$20k?!), but the idea was that if we managed to avoid going bankrupt for the first couple years, we’d have a back-catalog of several games which would continue to sell. This has worked for others! We had about 6 months of savings, and a 1-month contract lined up for the fall, _and_ Microsoft had just contacted us about maybe doing N on XBLA (this is several blog posts in itself)
So, back to Robotology. Now that we had MORE THAN AN ENTIRE YEAR to work on stuff (instead of just a few months), we decided to do things right. And that meant writing a proper physics simulator!
The world would be 100% physics-based (all animation/etc. would be driven by motors), so that players could really screw with enemies. Of course, this requires a simulator that’s better than any existing simulator — free ones such as ODE can simulate a walking robot, but it takes a lot of tweaking, and in the end it’s neither super-stable nor fast. Commercial simulators such as Havok, aside from being way too expensive, are similar to ODE — they’re great for lots of loose tumbling bodies, but jointed/articulated motorized limbs are not their forte. Which brings us back to where we left off, last time on metablog:
“This lead us to start from scratch, building an entirely new and different ‘robot simulator’..”
The first thing we figured out was we really wanted to have proper rigid bodies to work with — all of our previous physics things were particle-based.
The first simulator took about a month, and was called “bondshop” (no idea why, aside from the fact that constraints between bodies were called “bonds”, and we like “shop”s): check it out (opens in a new window)
That demo is a pretty lame ragdoll — it looks particle-based. Rest assured that each limb is a rigid body (look at the torso — it’s rigidly connected to several things!), and check out the funky constraint regions: instead of just constraining a point on one body to a point on the other, we experimented with rectangular, circular, and arc-shaped regions.
Bondshop was based on solving constraints between rigid bodies geometrically: given two points (one on each body), it would figure out how to translate+rotate each body such that the points coincided. This was totally based on geometry instead of physics, but it worked pretty well: it was very stable and didn’t blow up. Like all of our solvers, it used “relaxation”: basically, instead of trying to solve everything at once, solve things one at a time and hope that all of the individual solutions add up to the correct global solution.
For the technically inclined, a paper we came across that presents a similar approach is A Procedural Approach To Solving Constraints of Articulated Bodies.
This approach was nice in that it was simple (no heavy calculus/linear algebra), fast (the demo isn’t exactly blazing, but it’s Flash, which is at least 100x slower than C++), and stable. But, bondshop was lacking in a couple important ways: we couldn’t figure out how to apply our method to angular constraints (very useful for simulating limbs — you need to be able to specify min and max bend-amounts), and we couldn’t figure out a simple way to implement motors, to get the limbs moving around on their own.
So, we reluctantly moved on to try other things; this involved hitting the books and learning some of that “math” stuff we did such a good job of avoiding at school.