Originally posted by M&R | August 9, 2008
Finally a Robotology post! We put this off again and again, as there’s so much backlog that we didn’t quite know where to begin, but enough is enough — let’s just start with what we’ve been doing lately, and hopefully we won’t miss anything too important.
This post will be a bit abstract — rather than documenting work we’ve actually done — but it’s something we’re trying to figure out so we’re hoping that the act of writing about it will jar some useful ideas loose. Fingers crossed!
One of the main things we’ve been struggling with lately is how to make our simulator more “game-friendly”. This is an historical struggle, since the tile-based simulator we used for N was quite awkward.
Our problem in that case was that we were so busy getting the simulator to work — figuring out how to “do” collision detection and response — that we didn’t put enough consideration into how it would eventually be used.
As a result it was very “sim-centric”, good at simulating a pile of boxes or circles sliding and colliding around the tile-based world, but virtually useless at anything we actually wanted to do with it. About 1/4 of the development time for N was spent hacking at the damned simulator just to make it useable in a game context!
We want to avoid making the same mistake in Robotology, since this time around the sim is much more complex and thus will be that much more of a horror to try and fix up after the fact. It’s not yet clear what the fundamental problem is; probably if and when we ever figure that out we’ll be well on the path to a decent solution.
One thing is for certain: the basis of the problem is that there is, ahem, “friction” between the competing goals of a real-time physics simulation and a videogame. Yes, you read that right, it was indeed a terrible physics pun. They say ‘don’t quit your day-job’; this is an example of why 😉
This may seem forehead-slappingly obvious, but it was something of a surprise for us. The root of the difference seems to be that a simulation is characterized by a constant set of rules, while games are much more about context-sensitivity. There’s a chance this may be specific only to 2D side-view games, which usually contain all sorts of physically-impossible behaviours. Nevertheless, it seems like the desire to have a set of constant invariable rules, and the desire to constantly be changing the rules, are two opposing…”forces”, if you will. (Zing!)
When developing a simulator, you tend towards a single monolithic closed system where everything is known and set up ahead of time, and then “run” — you stack up the dominoes, you tip one over, and then you watch things play out as a consistent set of rules is applied each frame. Perhaps this is the natural form of a simulation because in reality the rules of physics are constant?
When developing a game, on the other hand, you really want more of a loose set of tools which you can use, but which you’re free to ignore or subvert if that’s what’s more appropriate or conducive to fun-generation. You want the simulation to be a facility that is subservient to the game itself.
A good example is the problem of mass. In a simulator, you would assign a mass to every object and that’s that: those masses determine the weighting of constraint forces and how the objects interact when they collide or are connected via constraints; heavy objects aren’t moved as much as light ones.
For a game, rather than a single mass, you might want a custom, per-constraint weighting so that you can tweak interactions. For instance, if the player is swinging a wrecking ball at some crates, you want the ball to be heavy enough so that it sends the crates flying, BUT light enough so that the player is swinging it, and not the other way around. A single mass value may not be enough to achieve both behaviours; being able to assign different effective masses for ball<--->player and ball<--->crate interactions is really useful. Then again, if you overdo it, you run the risk of undermining the simulation — for instance if an enemy grabs the player, the enemy won’t “feel” the full weight of the wrecking ball, because they’re interacting with it indirectly via the player (who is set to be “heavy” relative to the ball).
This is an annoying tug-of-war, but at the same time the fact that there’s no one good solution (yet) is what makes it an interesting problem to work with — we could potentially figure out something new!
Most games tend to stick to one end of the simulator-or-game axis, not a lot of games combine “game” and “sim” in equal amounts. Boom Blox and Armadillo Run are good examples of the sim-heavy end of the spectrum: each is basically a pure simulation sandbox. At the other end of the spectrum are games like Super Mario Bros (or N), where the simulation is very basic and governs only some small subset of the game object behaviours.
Gish and Soldat are maybe the best attempts to properly fuse simulation and game in equal parts, but in both cases it’s still not a perfectly even match — the former is more simulation, in that player movement is quite complex compared to Super Mario Bros, while the latter features a simulation limited only to projectiles and ragdolls. Both are excellent games, and really capitalize on their chosen position in the sim/game spectrum, but they also show that there is a huge amount of space left to explore in terms of different approaches to physics-based games.
One offshoot of trying to cram as much simulation as possible into Robotology is that all movement in the game will be physics-based. This may seem like no big deal, but actually this is a GIGANTIC can of worms. The vast majority of animation in games is kinematic — the animation system just plays back pre-recorded data, ignoring the current state of the rest of the world rather than interacting with it. In some cases the illusion of interaction is achieved by artfully blending between various pieces of prerecorded data based on the current state of the world, but that tends to be a massively content-heavy proposition involving lots of animation data.
The other big pain with attempting to drive everything via physics, at least in a 2D platformer, is that there are a huge amount of genre-specific behaviours and tropes which flagrantly denounce physical reality. We’ve mentioned the biggest culprit previously: changing facing directions. It’s ubiquitous, but it’s also completely impossible to simulate in a consistent way. This is still something we’re working on because we think it plays an important role.
It’s not all bad though — aside from the thrill of figuring this out, driving everything through the simulator actually has one main benefit, which is that it will (hopefully!) result in a much more stable simulation. Typically there are all sorts of problems that happen on the boundary between dynamics and kinematics. For instance, if a physics-based object is squished between two kinematic objects, there’s literally nothing the solver can do: since it’s unable to move either of the kinematic objects, a valid world state is impossible to reach, and the physics object is bound to blow up, shoot out to infinity or misbehave in some other way. Driving everything via physics means the solver will always be able to find a valid state for the world.
At least, that’s the theory. Hopefully it’s got “potential” (ahaha).
Stay tuned for some actual info about what we’ve been working on! And maybe some more horrible physics puns.