To start, a reminder that today is the last day to vote in the XBLA Awards! https://www.xbox.com/en-US/community/events/xblaawards/
And now for the third and final chapter in the continuing saga of what’s up with Robotology lately: things that are working well (but may still need some tweaking/adjustments as we go).
Ironically — or perhaps not technically if you’re some sort of irony stickler — in the weeks since this post was initially written we’ve come to realize that our simulator is in need of a big overhaul. More on that below!
The Constraint Solver
The purpose of a physics solver is to act as an arbiter between the objects in the world. For instance, a small robot might be trying to occupy the same point in space as a large robot’s foot — this obviously can’t be allowed, and the solver will figure out how to move the robots’ bodies so that the illusion of physical reality is maintained. So far our solver is working well: it’s extremely stable and capable of modeling complex articulated mechanisms. More importantly, it’s easy for us to understand and make changes to. For instance, defining new types of constraints or new functionality (such as “breakable constraints”) is easy. Or, let’s say “relatively easy” 😉
The Collision System
Aside from the constraint solver, the other major part of the simulator is the collision detection system; our method is relatively expensive compared to simpler solutions (such as what we used in N), but it can handle situations which simpler systems can’t, such as concave-vs-concave shapes.
Sadly it looks like Little Big Planet stole some of our thunder, at least in terms of simulation — their collision detection and constraint solving is really great! — but we’re trying to remind ourselves that ultimately the game is not defined by these systems alone, and there’s plenty of opportunity for development.
“Fat-skeleton”-based Geometry Editing
The way this works is hard to describe — and currently we’ve only got a temporary “for testing purposes only” front-end — but the basic technology behind the editor is working well. Maybe one of these days we’ll get with the 21st century and figure out how to youtube a quick demo 🙂
Conveyor Belts and Rope
While it’s possible to simulate both of these mechanisms as chains of bodies connected by joints, we really wanted to do things differently. Or rather, we wanted to do things the same way they were done in Umihara Kawase, which is quite different from the “explicit chains” model. Thankfully the friendliness of our constraint solver made adding both of these effects fairly straightforward, and we’ve even managed to extend things a bit: belts are physically simulated, so that rather than always moving at a constant rate, they can be pushed/pulled by other objects in the world. Possibly this feature isn’t super-important — there’s a good chance we’ll end up setting them to be so strong that they maintain a constant movement as in Umihara — but it’s nice to maintain the integrity of the solver. As long as all movement in the world is simulated rather than “faked” (i.e kinematic, non-reactive animation), it decreases the chances of weird problems caused by the non-systematic interaction of physics-based and non-physics-based bodies.
At least, this is what we’re hoping for 😉
As we mentioned above, we’re in the process of rewriting of the simulator in light of a couple things. The main problem is that it’s entirely polygon-based, while it has become apparent that we really need simpler shapes (like capsules and circles) to represent smaller robots. Similarly, when a robot is only a couple dozen pixels tall, it makes more sense to model its dynamics with a simpler model — such as a few particles connected by sticks, as in N — rather than several rigid bodies connected by constraints.
The “legacy” simulator is very old, much of it was written before we had a proper grasp of the math going on behind the formulas we were using; we were trying to get things working as quickly as possible, and the result is that it assumes rigid bodies throughout the code, which makes implementing other types of things, like particles, quite awkward. At the time this was an unavoidable compromise, since we lacked the ability to abstract out the type of mechanism being simulated. We’ve since figured out the math required to let us connect two different sorts of dynamical beings (such as rigid bodies and particles) together with constraints, without having to explicitly program all the possible combinations. This in turn has given us the ability to support features like non-rigid shapes (i.e legs which telescope) and other sorts of representations that will be useful for smaller robots.
We definitely don’t want to be stuck making this game forever, but our accrued experience thus far should let us rewrite the simulator in a short period of time — we’re mostly done after only 2 weeks, so this will hopefully be chalked up as worthwhile “refactoring” of old code. The new flexibility (and especially ability to optimize hotspots) is definitely nice.
So the simulator is sadly no longer in stable condition, however the surgery should be routine and the patient is expected to make a full recovery 🙂
p.s – just for Maximo, a recent screenshot showing a test of the wonderfully smooth graphics — the actual biped model is temporary: https://www.metanetsoftware.com/robotology/screendump2009-3-10_17_57_26.png