Before we get to the title topic, we’re thrilled to announce that N+ will be the Deal of the Week next week on XBLA (July 6-12 2009). 50% off: Hooray! Just in time for summer vacation for a lot of you! Everyone else: quit your job for the summer!

If for some crazy reason you or someone you love (or even someone you hate) have yet to download N+ XBLA — the gold standard and best of the various versions of N+ — now is your chance to save some money.

And now, the main attraction: it’s been a long time coming, but we finally have a video to show!

Although don’t get too excited.. the graphics are all debug/placeholder, so it’s nothing much to look at.

Vimeo (high quality.. relatively anyway)
YouTube (lower quality)

(Hopefully we’ll figure out how to get screencapture and exporting working a bit better in the future, this initial vid is unfortunately a bit choppy — sorry about that.)

It’s just a simple demonstration of how robots in the 2D world will change direction in a physically-valid way; typically this sort of movement is faked (for instance, in Super Mario Bros objects just “flip” instantaneously, however this only works because their simulated shapes are symmetrical and unchanging — only the graphics actually “flip”), or relies on movement in 3D.

We wanted to try something different. Since our goal is for all movement to be physically-based, we needed a solution which would allow robots to change direction while their movement remained valid in the 2D “flatland” simulation. This way, any external constraints (such as grappling hooks) that are interacting with a robot will continue to behave normally, with no popping or other glitches as the robot changes facing direction.

Our solution is to morph the collision/graphics geometry (which defines the shapes of each rigid body), while simultaneously morphing the physical constraints (which define the way the body moves). “Morphing” is just a non-rigid transformation.. moving around vertices or joint angles or whatever. Currently this deformation is purely kinematic; we decided that driving the morph via physical motors was one step too far in terms of complexity, although it would be possible to do. We’re already somewhat behind schedule, so keeping it simple is a priority. Since the actual rigid bodies are free to move during the morph, the robot continues to be responsive and reactive regardless of its current deformation state. Nice!

This particular test biped is representative of how the larger robots will be modeled; it’s made of over 100 points bound to 14 rigid bodies. For smaller robots, we’ll be morphing the graphics geometry, but the dynamics model will probably be simpler or symmetrical (for instance, the 6-particle + 5-stick model we used for the ragdoll in N).

The process of getting this to work nicely was a lot more complicated than we anticipated (hence the two month blog-posting delay — sorry!) but it was a great experience since it made all the unanticipated problems obvious and we managed to find solutions to most of them. It also impressed upon us the need for better tools — that biped is defined by almost 800 lines of code, painstakingly hand-transcribed from graph paper and Flash mockups! Ouch. We thought that would be quick-and-dirty; instead it was long-and-painful-and-dirty

The good news is that during implementation it became obvious that morphing could be used for much more than simply changing the facing direction of robots; it could be used to effect any sort of shape-change, allowing us to model transforming robots. We’re still not sure how far in that direction we want to go though, there are enough technical challenges as it is, but it sure would be cool

That’s it for now — Happy Canada Day!

Filed under: dev, n+, news, robotology by M&R
10 Comments »

First of all, we have a few new winners for Contesque #3, at long last. The first win goes out to Duncan, who sent us a whole bunch of drawings of N+ costumes. We chose the one we thought was the most fun

Duncan’s Ninja Mask

And next, we have to share what may be the most awesome thing we’ve ever seen. Previously, we thought we knew about hardcore fans — you know, the people who play N using the invisible ninja, or that complain that the 80s column is too easy. The people that can beat the most difficult N+ level pack in an hour, and dominate the leaderboards with their skill and panache.

It turns out we were only kidding ourselves, for the bar of hardcore-fandom has been raised — to the Nth degree, as it were — by Lokitrickmaster, and his AMAZING N+ TATTOO!!

Loki’s Tattoo 1
Loki’s Tattoo 2

It’s a really awesome feeling to see something you helped create resonate with gamers; thanks so much for sending this in Loki, you rock!

This officially concludes the third Contesque, for obvious reasons — we don’t want anyone to die trying to top that! Congrats to you two, and check your email. Thank you to everyone who sent in a submission, it was great to see so many creative and cool people with wonderful senses of humour We hope you’ll come back for our future contesques!

And now, by special reader request, lets go through some screenshots from recent weeks and document what we’ve been working on. As the title suggests, these will not be very pretty and may not make a lot of sense…currently the “real” graphics system isn’t hooked up to the simulator so you’ll just be seeing debug graphics (showing the collision shapes, constraint points, etc).

Mostly we’ve been working on finishing v2 of the simulator, but we’ll throw in an editor pic just for fun. (Click the title of each section to pop the screenshot up in a new window.)

Constraint Solver Stress Test
Here we have a thousand or so rigid bodies linked into a long chain with point-to-point constraints (aka “pin” constraints, aka “revolute joints” for Box2D users); a few points along the line are pinned to the background.

There are no collision shapes on the bodies, so they’re just drawn as lines, but each line is a full rigid body. Of course, the bottleneck in most simulators is collision detection (at least, this has been our experience…might be we’re just bad at collision! ahaha.) but it’s still nice to know that the simulator can solve several thousand constraints per frame. Just like in Little Big Planet, we’re not relying on “sleeping”, i.e we’ll be simulating the entire world all the time, which seems much simpler in the long run when trying to nicely handle large user-made worlds.

Also we should point out that we’re using only 2 constraint-solving iterations per frame. We can actually get away with 1, everything is stable, but there can be artifacts due to constraint ordering (forces generated by constraints solved later in the frame aren’t “felt” by earlier constraints until next frame)… We’re still not sure what we’ll end up doing, possibly we’ll use different iteration counts depending on the type/priority of the constraints (i.e offscreen mechanisms use 1 iteration, onscreen mechanisms use 2, etc.)

The revised solver probably isn’t that much faster than the old solver (it may even be slightly slower since it’s quite generalized in comparison), but it is a LOT simpler and much easier to use. A huge plus!

Circle Collision Stress Test
Capsule Collision Stress Test
These two are just quick tests to make sure that we can handle many hundreds of collision shapes moving around. Again, it’s really nice to see good stability and lack of penetration with just 2 solver iterations, check out those circles!

The second version of our simulator required that we rewrite our collision detection system, since the old simulator supported only rigid polygons and the new simulator is more generic. We needed something that could support simple and cheap shapes (circles and capsules) as well as non-rigid shapes (such as simple telescoping/deforming shapes).

Also, the old version was pretty slow, at least in comparison — we were doing all sorts of sweep tests and complicated predicting, in the end we decided that a better (and simpler) solution is to use static non-swept collision tests and just take smaller steps to prevent objects from passing through each other.

Thankfully we didn’t need to actually rewrite everything, most of the low-level stuff like the grid system and whatnot was reusable and the rest just needed a bit of revision to work with the new simulator. The main collision loop is now only a couple dozen lines of code, super nice and simple

Collision detection is definitely still a bottleneck with this type of simulator: the constraint solver moves shapes around, which can cause collisions in mid-frame, which means you need to either (a) perform collision detection with each solver iteration, or (b) generate collision constraints between shapes that aren’t currently colliding but might collide during solving (i.e nearby shapes). The former results in lots of additional collision tests, while the latter results in lots of additional constraints to be solved, so either way there’s more work to be done than in a velocity-based solver.

We’re hoping once we finish the game and have time to write up some tutorials, other people will experiment with this sort of simulator and find some new solutions to this problem.

Constraint Paths
This picture shows a constraint “path” (a chain of line segments and circular arcs forming a closed loop or open strip of geometry) anchored to a rigid body (the capsule), with two particles connected via constraints to points on the path. If you pull one of the particles, it will stay connected to the path and will drag the other particle along the path with it.

This is a bit complicated to describe, but essentially “paths” are how we model moving platforms and conveyor belts and stuff like that. If you look closely on the left side, you’ll see a little square on the path, this is a “bead” which describes movement along the path, adding 1D degree-of-freedom to the system.

If you consider a 2D rigid body, it has three degrees of freedom: position along the x axis, position along the y axis, and orientation (”rotation about the z axis” if you’re picky).

Now imagine that the surface of the body isn’t fixed, but is like a loose belt or piece of string that’s wrapped around the body, and which can slide around the surface: this is what the bead models.

You can think of a constraint path as a rail or wire that the bead slides along. The name “bead” is meant to suggest a bead sliding along a wire; the position of the bead along the wire can be described by a single number (its position/distance along the wire from some fixed reference point on the wire), hence it adds one degree of freedom. You can constrain points along the wire, and as the bead moves those points will move too (and vice versa — pulling on a point will cause the bead to move). This lets us model conveyor belts, and also lets us move platforms along complicated routes, all by adding a motor which pushes the bead along the wire. Hooray!

Anyway, while the basic idea remained the same, we had to revise/rewrite all the constraint path code from the old simulator…so far we’ve tried two or three different ways of describing both path geometry and bead position/movement!

The really nice thing about this revised version is that the constraints don’t know or care if they’re working on points embedded rigidly in a body, or points embedded somewhere along a path which is itself embedded rigidly in a body!

The old simulator wasn’t so nice: to interact with belts, you had to create a proxy particle which was attached to the path via a special “point on path” constraint. External constraints could then pull on the particle, and the particle would in turn pull on the path via the PoP constraint. This was a bit hacky: you didn’t want the particle to be too heavy, or else you would notice mass being added to the system when you started interacting with belts, but if the particle was too light the solver wouldn’t converge well. It’s much nicer to just embed a point in the path’s degree-of-freedom and let constraints work on that directly. Yay!

Conveyor Belt Test
This shows a capsule with a bead/path wrapped around it, acting as a “tank tread” to drive the capsule up a hill; there’s an object pinned to the conveyor belt — perhaps a robot whose grappling hook is attached to the tread?

We’re not sure how much we’ll use conveyor belts like this (i.e to model tank-type entities rather than the regular use of “moving floor” that you see in Umihara), but it’s nice to know that it’s possible and happens automatically without special-case code. Who knows, maybe that moving floor you run across will later turn out to be the bottom of a large robot’s foot?

Rope Simulation Test
Along with collision, rope was something that needed to be totally rewritten, and it was pretty fundamental. The old version was failing to deal nicely with situations involving small penetration which can happen when objects pile together.

This post is getting way too long, so in the interest of brevity we’ll just say that we’ve tried two or three completely different ways to model rope, and we’ll be documenting them whenever we get a chance to write some tutorials! This new rope is a lot of fun though, here you can see it wrapped around a bunch of boxes.

Rope+Belt Redux
This was just a quick test to make sure all the different systems interacted nicely; you can see a rope which has one end embedded in a path, so that pulling on the rope will pull the bead along the path.

While it took only a couple weeks to rewrite the basic core of the constraint solver, revising all the other bits which interacted with the solver (collision, belts/paths, rope) took a lot longer than we had anticipated. Now that it’s finally over, we get to work on stuff like controllers and motors and moving things around in the world using constraints. Getting closer to the fun stuff, finally!!

Editor Screenshot
Finally, a pic of the “inflated skeleton” editor. You can see the purple area, which is a “secret region”: it will appear to be solid until one of the link-points (the circle-with-plus-shapes) moves, disconnecting the chain of geometry that defines the secret area and opening it.

This is pretty hard to describe, and it was definitely tricky to implement! We may not have mentioned this before, but we want exploring and discovering secret areas to be part of the game (we really enjoyed it in Gish and Loco Roco), and this dynamic-hidden-area system will allow levels which are layered like an onion.. previously solid shapes in a level may turn out to really be hollow spaces with an entire new level inside! Mmm, delicious onions.

Anyway, this concludes our review of the past couple months of work. We’re going to start really trying to post more frequently, so that each time we do post it’s a smaller, easily-digestible read and not a gigantic endless novel of a post.

Onward to pithyness!

Filed under: contesques, dev, n+, news, robotology by M&R
27 Comments »

It’s that time of the year again — we’re off to San Francisco for the 2009 Game Developers’ Conference. Woohoo! We really can’t wait to meet up with all the other developers, it’s basically the only time we ever get to see anyone in person other than the Toronto devs

Wish us luck at the Game Developer Choice Awards! We still haven’t heard anything about the results of the XBLA Awards, but apparently last year they announced the winners at GDC, so probably we’ll find out sometime this week. Thanks again for voting — hope N+ wins something!

Catch you on the flip-side

Filed under: misc, news by M&R
16 Comments »

To start, a reminder that today is the last day to vote in the XBLA Awards! http://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: http://www.metanetsoftware.com/robotology/screendump2009-3-10_17_57_26.png

Filed under: dev, n+, robotology by M&R
16 Comments »

We’re happy to say you can now vote in the 2nd Annual XBLA Awards. Here’s how:
http://www.xbox.com/en-US/community/events/xblaawards/

Voting is open from now until March 10. One week only! We just downloaded the voting application and noted that it weighs in at 37 MB, so it’s twice as large as N+, even considering all three level packs! If only there were an award for ‘Most Content in the Smallest Package’! N+ would be a shoe-in. Or is it “shoo-in”? Anyway, it would win

N+ is up for three awards (there’s more detail in our previous blog post), and we think we have a shot at Best Co-Op Multiplayer Game because of N+’s stellar performance in that arena. If you enjoyed N+, please consider voting for us! It would really mean a lot to us.

Get out there and vote, everyone — and don’t forget to rock it!

Filed under: n+, news by M&R
3 Comments »

It’s been brought to our attention that N+ is up for some XBLA Awards:
http://majornelson.com/archive/2009/02/26/the-second-annual-xbox-live-arcade-awards.aspx

This is awesome news, and we’re totally thrilled. Thank you Microsoft! It’s an honour to have been nominated, and we would love to win!

And that, dear readers, is where you come in. It’s that time again, time to Rock the Vote! Loyal N and N+ fans have a pretty solid history of vote-rocking: they’ve helped us win the 2005 Audience Choice award at the GDC for N, and the 2008 PopVox People’s Choice award for Best Console Game for N+ XBLA. And now, N+ fans with Xbox360s everywhere have the opportunity to help us win one of three awards!

Here’s how to vote (starting Tuesday March 3): http://www.xbox.com/en-US/community/events/xblaawards/

Before we continue, we feel it’s very important that you understand we’re not asking you to vote for N+ if you feel there’s a better candidate for the award. By all means, listen to your heart. But if your heart is at all confused, we hope you’ll consider swinging the vote towards N+!

The awards N+ is up for are:

Best Original Game
Castle Crashers
N+
Braid
Penny Arcade Episode 1
Schizoid
Age of Booty

Now, there’s no way we’ll win this award against huge hits like Braid and Castle Crashers. It’s phenomenal that N+ was nominated, and we really appreciate it, but the competition is just too awesome.

Best Co-operative Multiplayer Game
Castle Crashers
Schizoid
Bionic Commando Rearmed
N+
Geometry Wars Retro Evolved 2

Here’s where we’re hoping to shine — N+ Co-op Multiplayer is one of our proudest achievements. It’s surprisingly fun: as gripping and frustrating as Single Player mode, but the addition of multiple players breathes new life into the gameplay and eases the frustration ever so slightly. Plus, designing levels for Multiplayer was extremely satisfying, and by all accounts they are super fun to play through. So we feel we have a good shot at this one!

The last award we’re up for is this:

Best Innovation in XBLA
Braid (time travel)
A Kingdom for Keflings (use of Avatars)
Fable II Pub Games (retail game integration)
N+ (level sharing)
Duke Nukem 3D (dynamic replay)

It is a special honour to have been nominated in this category. We really appreciate that — it indicates to us that the value of our level sharing system is still apparent, even though it’s far from what we intended. That is heart-warming! However, there’s no way we’ll win against Braid. Come on, level sharing vs. time travel? No Contest.

That’s it! Congratulations to all the nominees, there are excellent games in each category and we know you voters have quite a task ahead of you.

If you enjoyed N+, please consider voting for us! It would mean a lot. Also, tell your friends!
Again, here’s the link with info on how to vote. http://www.xbox.com/en-US/community/events/xblaawards/

Rock!

Filed under: n+, news by M&R
13 Comments »

Yes, it’s the 1 year anniversary of the release of N+ for XBLA. It’s been a great year — reception has been very positive, sales exceeded our expectations, we’ve been nominated for awards (and even received one two- check out Brilliam’s review here!) and we’re just so thrilled that so many people gave it a try, even though the graphics are simple and we’re relative unknowns. Thank you so much, everyone.

We did a Postmortem for Game Developer Magazine, if you want to hear more about the storied history of N+, look for back issues. It’s a gripping read.

We’re still not able to enable full-on level sharing for N+, which is a disappointment, but we hope the three level packs eased that pain a little. Unfortunately those three will have to suffice, as we’ve run out of space in the player profile! We’ll take all of these things on to our next projects though — we’ve learned a lot, and will hopefully be able to employ that knowledge in future games.

To celebrate, we’re putting the last batch of t-shirts up in the Metanet Etsy shop and are having a huge sale — all cuffs and notebooks are buy one, get one free. The Etsy system isn’t set up for combo discounts (at least as far as we can tell), so we have to do this a little hackily (hey, it’s consistent with the way we program!): buy which ever ones you want and we’ll refund you the difference.

Also, we’re updating Metanet Software website and will be updating the blog skin to match the new site design, to keep things fresh. Enjoy! We’re also starting a newsletter. Hooray for newsletters!

And don’t forget, Contesque #3 is still open — if you’d like a taste of one of the various flavours of N+, we still have a few copies of each, so get those creative juices flowing and keep those entries comin’! Thanks to all those who have entered already.

Thanks again for all your support, everyone — we really appreciate it!

Filed under: news by M&R
30 Comments »

First, some quick news:

N+ is a finalist for “Best Downloadable Game” in the Game Developer’s Choice Awards! We feel so honoured to have been nominated.

Also, we’re part of a group that just started in Toronto, the Hand Eye Society. The first meeting was last Thursday and it was great! Looking forward to more. If you’re in the area, you should definitely check out future meetings.

Anyway, continuing with our review of the current state of development, here are some of the things currently “on the operating room table”:

OpenGL-based Vector Graphics
We were getting a bit burnt out on the editor, so we decided to change gears for the past couple weeks, and have been working on the graphics system. Our two main goals are smooth Flash-quality vector shapes, and pixel-perfect fonts (i.e no ugly blurry text); so far things are going well. Trying to nail down the specifics of how the graphics system will work internally is a bit daunting, since we have very little experience with that sort of thing, but all of our tests indicate that the look we’re trying to achieve is definitely going to be possible in “plain” OpenGL (fixed-function pipeline, no shaders).

Right now it looks like it’s going to be hard to get lines less than 2 pixels wide looking nice and smooth; this means we’ll have to revise some of our mockups to see if we can get by with thicker lines. Or maybe we can live with a few jaggies.

In the future we’re definitely going to look into shader-based vector rendering, since the quality of thin-line-drawing can definitely be improved beyond what’s possible in fixed-function land. For Robotology we decided we didn’t want to have to deal with the testing mess involved in making sure our shaders work on everyone’s card.

Character Modelling
We’ve started fleshing out exactly how the robots are going to be represented in-game. Our initial “ideal” plan was that their representation would be identical to that of the world — they would simply be geometric shapes moving around, and the only difference between a sliding door and a walking robot would be the relative complexity of the physical model (and of the controllers driving each model’s motors).

The motivation was to remove the artificial separation between “world” and “objects” which many games impose — a separation which is a necessary optimization for some games — and in doing so to encourage emergent interaction between entities. However, some special cases seem to be necessary. In Little Big Planet, the world/object duality is avoided by making all of the objects out of pieces of “world”, but the result is enemies which are substantially different from the player character.

Since we’re aiming for robots which are similar to the player character, the only workable solution so far seems to be to abandon our initial “purist” plan. For instance, the scale of robots in the world is much smaller than the world itself, and this smaller scale lends itself to different collision representations — such as using circles and capsules rather than polygons to describe the limbs of smaller robots. There are also some behaviours which are specific to robots: for instance “changing facing direction” (flipping across the y-axis). This was initially going to be handled by morphing the shape, but since we cut non-rigid animation/geometry we had to address this one specific use.

The different scale of robots, combined with the specialized collision shapes and animation problems (flipping “facing” direction), suggested a specific robot body model which will let us automate some of the body-creation and animation process. Sacrificing generality for the sake of this optimization seemed like a fair trade.

There are a few parts which we’ve researched and sketched out, but have yet to plan in detail — usually because they depend on some other unfinished system, and so are subject to change:

Animation System
We’re going for no kinematic animation, and having everything driven by motors. This is an idealistic goal like “no separation of world/bodies”, which we’re hoping will make the simulation more stable (kinematic bodies interacting with dynamic bodies are a recipe for problematic behaviour) and development more simple, since there will be a single path for all animation. Some parts of the animation system will be more “procedural” (i.e balance controllers or whatever will have to use the current state of the world when calculating a target pose), while other things will be animated more traditionally (i.e with keyframes driving the target pose). We’re hoping we’ll be able to achieve something like this.

There are a couple systems which look like they might not make it — at least, we’re going to leave them out of the first release (though we’ll keep them in mind and try to make sure they’re feasible to add later):

Procedural Music
We aren’t going to try anything too fancy — we just thought that rather than static songs or loops, we could make a simple system which would mix together various loops to form songs on-the-fly. Obviously this sort of thing it a much better fit for more abstract electronic music, where it’s possible to assemble multiple loop “palettes” which work together in various combinations. For the the time being we’re just planning on the usual looping music tracks, and hopefully later we’ll have a bit of time to add something more dynamic.

Procedural Level Generation
This is more of a “blue sky” feature, but something we’re extremely interested in (especially given the amazing Spelunky). Procedural generation of graphic design and architectural layouts suggests that developing a method to generate platformer levels on-the-fly is a definite possibility, however we haven’t given this feature much time or attention since it’s a huge and open-ended problem. We’re planning on getting the core game working, then focusing on stuff like this which builds upon the core.

That’s it for now… Part 3 coming soon!

Filed under: dev, game reviews, robotology by M&R
9 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!

Filed under: dev, robotology by M&R
14 Comments »

We don’t want to sound paranoid, but it seems like people are trying to start controversy where none exists!

We recently did a short interview with Ryan Rigney (who also wrote this article on N+). In it, we mentioned that there was a limit to the amount of saved data that could be stored by a given XBLA title. We didn’t say this limit was “stupid”, because it’s not — it’s understandable.

So it makes us suspect a conspiracy — or at least someone somewhere being a complete tool — when this same interview is linked to with the overly sensational (if not completely fictitious) headline “N+ Creators Unhappy With Microsoft“.

To nip this in the bud: if you read the actual interview, you will see that while we do point out two things we ran into problems with (saved data limit and level sharing), we’re not “unhappy” with Microsoft about them — in the latter case we even expressed that this was an understandable decision on the part of the lawyers, in response to the constraints of what could and couldn’t be done to remove offensive leaderboard content!

Seriously.. WTF?!?!?!

Filed under: news by M&R
17 Comments »