Robotology: Triage Part 1, The Cutting-Room Floor

06 Feb / by: M&R / 14 comments /

The past few weeks have been fairly unproductive, at least in terms of writing code; now that the editor back-end is mostly fleshed-out, the minutia have begun their inevitable soul-sucking death-by-a-thousand-cuts. After the first 90% comes the last 90%, as they say 🙂

We’re still in the “figuring things out” phase of design for the graphics and animation systems; we’ve learned the hard way that planning is just as important as the actually-writing-code phase, if not more so. So, lots of little snippets and tests have been made, but nothing substantial has been built.

In order to keep this blog trickling along, we thought it might be a good idea to review all the ideas that aren’t going to make it into Robotology. As we get further into development (or pre-production really, since at this point we’re still prototyping systems) the need to simplify by ruthlessly cutting features increases.. and as much as we really like some ideas, getting the game done comes first. Having our ideas shot down is softened somewhat by the knowledge that we’re the ones who would have to implement all this stuff!

Anyway, here’s a list of some of the bigger ideas which were scrapped.. hopefully they will be revived at some point in the service of future games:

Non-Rigid Physics
Our constraint solver can handle constraints between non-rigid shapes; combined with “smooth skinned” geometry (vertices are bound to a blend of rigid frames, or to a frame which is itself a blend of rigid frames rather than a single rigid frame) this would allow a lot of interesting behaviours to be modeled, such as physically-based morphing.

Unfortunately, the software engineering component of this feature (i.e how to support rigid and non-rigid constraints without having to explicitly write a combinatorial explosion of constraint types) proved to be too much trouble, so we’re sticking to rigid-body physics only.

Non-Rigid Geometry
Originally we intended to support rigid, smooth-skinned and deforming/morphing polygonal shapes; as with non-rigid physics, this ended up being a big pain in the ass in terms of exponentially increasing the work involved. Plus, once non-rigid physics was scrapped, this was basically useless (since it would be a purely graphical effect rather than making an actual difference in the game world).

Additionally, non-rigid shapes cause further complications, such as having to maintain a valid triangulation for concave shapes, or having to ensure that deforming polygons never became self-intersecting. In the end, this feature was abandoned with no small amount of relief. Still, this is something we’d really like to revisit, especially since our collision system can handle deforming/soft shapes just as easily as rigid bodies.

Circular Arcs
The circular-arc-shaped tiles in N were really fun to move across, and we were planning on bringing the same sort of shapes to Robotology: all objects would be defined as chains of line segments and circular arcs. Unfortunately, moving from tile-based to more generic “anything goes” geometry made supporting circular arcs a lot more complicated — they were awkward to work with in many ways, from editing (what’s the best interface for manipulating the properties of an arc?) to collision detection (moving-arc-vs-moving-arc isn’t directly solvable).

We’re still using circular shapes for some things (circles are great collision shapes for limb joints, and rounding the corners of motion paths makes belts and point-on-path constraints behave much more smoothly) but they had to be cut from collision/world geometry in order to maintain our sanity.

Heterogeneous Geometry Generation
The original plan for the editor was to support multiple paradigms for generating polygonal shapes: tiles, platonic/regular polygons, inflated-skeletons, etc. These “shape generators” would be black boxes which would output generic polygonal geometry that users could then further modify (manipulating individual vert positions, performing CSG union/subtraction between two shapes, etc) and annotate (defining special surface properties for some line segments, such as “slippery” or “conveyor-belted”).

One of the reasons for this initial plan was to mitigate the risk of attempting the “inflated-skeleton” geometry generator — we didn’t know if it would even work, let alone be useful, so it was nice to have a simpler fallback (i.e tiles). The whole idea behind using “generators” was that we wanted to avoid, as much as possible, the agony of having to build polygonal shapes point-by-point; using higher-level building blocks like tiles is much easier and faster.

This plan separated the geometry-definition from the annotation phase, so that regardless of how a shape was generated, we could use a single tool to “paint” different materials onto its surface. Also, regardless of the constraints imposed by the generating phase (i.e tiled-based editing will generate only shapes that look tile-based) users would be free to manually screw around with the polygons.

The problem with this plan was that the editing workflow sucked — while the representation of shapes inside a generator was designed for ease-of-editing (such as placing tiles in the tile-based editor), this representation was lost when the generic polygon was output. Once a shape has been “baked” into explicit geometry, there’s no way to reverse the baking (i.e to recover a set of tiles, given an input polygon).

Of course, users could load the original tile data, but they would then lose all their annotations! The system created a one-way workflow: make shapes, and then tweak them and annotate them (i.e set material/surface properties). Users could always edit the shapes by manipulating them like generic polygons, but could never get back to the nice/easy representations (tiles, skeletons) without having to totally redo all their material-editing. This discourages the sort of iteration that we think is vital to making fun platforming levels.

In the end we decided to focus only on skeleton-based geometry, and to integrate material/property editing into this model. Another motivation for this was that many 2D games are tile-based, so by abandoning that common modeling paradigm we’ll hopefully end up steering Robotology into a more unique space “automatically”.

While the editor is still an ongoing task (we’ve discovered that a skeletal representation doesn’t lend itself perfectly to surface-editing, since the surface is implicit in the skeletal representation), it seems like it will work out in the end…fingers crossed! 😉

That concludes our review of what’s NOT going to be in Robotology. Stay tuned for posts on stuff which will be included, coming soon!

comments ( 14 )

  • Are you aware there is an Umihara Kawase game coming to the DS? I don’t know if it’s something new or a remake of an older game in the series (it is a series right? Not just a single game?).
    Just thought you should know, if you don’t already.

  • Thanks — we hadn’t heard about that! We picked up the PSP version in October, and it kind of sucked (the physics was all wrong), hopefully the DS version turns out better.

  • It’s a bit disappointing to hear that all that stuff isn’t going to make it in, but I was sort of shocked in the first place that you were trying to pull it all off.
    At any rate, it sounds like a cool game regardless. =)

    (By the way, I’m enjoying N+ quite a lot! =D)

  • Mmmmm coding…

    Any chance of a workable demo for PAX? (fingers crossed) :P.

  • circular arcs were actually pretty trivial for me to implement (although I imagine your system is a lot more complex). if it’s all rigid, arcs function pretty similar to vertices in terms of what sort of calculations you need to do on them right? and moving arc-moving arc is just a sweep test like, with some allowances for bits of circle that are not part of the arc. I guess arcs are easier for me to work with because I actually used your suggestion from a forum topic a long time ago where vertices (and the rest of the geometry) are “inflated” into arcs and collision is handled as if the player is a point (It only works for circular objects though).
    In my editor, the interface is point-by-point, but I plan to add the ability to save collections of polygons as “stamps” to manipulate. Arcs will be added by scrolling for radius and clicking for arc endpoint (and a toggle for minor/major arc if necessary). From what I’ve got so far, point-by point can be quite productive with the right tools.

    Yeah, I’m done spouting ignorance now. Whether it has these features or not, I loved me some Umihara and I’m sure I’ll love this. And streamlining the physics can be a good thing: look how successful N is with all its simplicity.

  • The problem we had with sweep tests was that we’re not sweeping objects along a linear path, we’re sweeping each surface segment individually (i.e imagine a square which moves to the left and rotates 90deg, the paths traced by its corners are not parallel).

    Actually, for some reason we totally forgot about the other huge problem with arcs — they’re incompatible with the way we’re modeling friction.
    And the way we’re handling rope doesn’t work with arcs — we would need to sample the arcs (i.e break them into segments). Basically they’re a huge pain 🙂

    It definitely seems like there should be an easier way to get arcs working alongside line segments.. we just decided it wasn’t worth wasting any more time on.

    Also, your project sounds cool! Point-by-point definitely is a good choice for making shapes, we were just worried about how well it would scale to a large level (for instance, Soldat levels are really unweildy). Describing shapes and then using the shapes to make the level is a great idea!

  • Is there any news on getting the server for N+ DS up and running?

  • We haven’t heard anything, but we’ll ask..

  • Hey guys, so this is the follow up game to n_v1.4
    Correct? I know this has probable been asked a thousand times but any idea when it will be released and will it be free like n_v1.4

  • When is Robotology complete constructed?

  • can you speak german?

  • Please answer me soon.
    I think my English is good
    enough to read your response. 😉

  • I’m looking forward to play “Robotology”. gibts das auch in Deutsch?? is that also available in german?

  • Thanks
    is this game already available?
    (in english or in german – both is OK =D)

Leave a reply