Robotology: Triage Part 2, Under Construction

14 Feb / by: M&R / 9 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!

comments ( 9 )

  • Gosh this game just sounds stellar really.

    Also good luck at GDC, you guys always mop up there!

  • hi im not new to ur blog but this is the first time I make the comment lol . This post just show how rock this robotology is! Looking forward , really looking forward to ur guys project.

  • On procedural level generation-
    I’ve been doing something like this myself, and it’s actually easier than I thought it would be.

    Of course, it still looks pretty messy (particularly the pipes, which tend to get a little too convoluted at times), as you can see.
    Plus, the nature of the levels (particularly the fact that it’s very tile-based) is probably not at all the sort of thing you’re after… But it works for what I’m doing. =P
    There seem to be many entirely different ways to do it, though. I imagine in Spelunky he used something fairly similar to what I’m using (but more sophisticated, since his levels are more “tunnely” and less “random blocky”). And in Nethack, the rooms are planted around randomly and tunnels are drawn to connect them (or at least that’s how I assume it works). Then there’s Worms… I have no idea how that works, but it seems to be very mathematical (generated rather than produced, if that makes any sense at all), and that probably wouldn’t work as well for something more geometric.
    Of course, I’m also not even sure how well any of this fits in with what you’re describing.

    It is interesting that you bring up Spelunky, though.
    I was working on a game that was basically going to be a platform roguelike, but then I found out about Spelunky. It’s shockingly similar to what I was trying to do, and to my immense frustration he did it extremely well.
    So I ended up scrapping most of my work and starting over based on earlier ideas (more of a roguelike platform shooter than just a roguelike platformer), because I still liked the concept, but I now wanted to do something more unique (since I was trying to be original in the first place)… So far I think I’m succeeding. It helped to rework the setting, too.
    But, of course, this now has absolutely nothing to do with anything. =P

    In summary: If I can do it (at least on some level), you certainly can if you invest enough time in it… I’m not exactly the programming type, after all, and you guys seem to be much more competent. xP
    However, if you don’t plan on making it random (and I infer that you do not), the real question is whether it will actually be worth your time….

  • vector graphics is the main reason I’m still with flash. it’s just so smooth and easy and it works the same on any computer.

    Although have you considered commercial game-style anti-aliasing, where you render the scene jaggedly in a double (or more) resolution, then you shrink it, averaging pixels for a smooth look

    that’s probably the first thing you thought of, and probably has some graphics-card implications, but just throwing it out there.

  • Thanks maximo!

    @PurpleSquerkle: that looks cool! I wouldn’t worry about it being too much like Spelunky, the world could use more than one roguelike platformer 😉

    @mattk210: we’re hoping to support FSAA/MSAA/etc on top of our edge-smoothing method, however it doesn’t produce the best results on its own.. 4x oversampling just isn’t as nice-looking as Flash 🙁

  • How’s the grappling hook implementation coming along?

  • Spelunky <3 (Thank you for showing me its wonders)

    All these procedural considerations sound wonderful…

    Plus if you’re still here reading comments PurpleSquerkle, I’ve noticed a lot of repeated terrain segments in Spelunky; this might lead to a more… tunneley-solid environment. (For example those horizontal lines with holes in them that you can climb up if you have any idea what I’m talking about :3)

  • Yeah, I wonder whether he didn’t have several preset “chunks” that were generated in addition to the randomness… Ever seen those snake pits?

  • Yeah, snake pits are special.

    I think it’s not so much preset chunks as areas of differently-randomized terrain (so a snake pit is a big pit with snakes and some side-pockets). Once you get to the 5th level and then the 10th and maybe afterwards some more, the levels are drastically different. (example – the 5th to 9th? level is a ‘forest’, and there are a lot more long downward drops, there are trees, and waterholes…) So there are definitely differently-generated areas, and different guidelines to follow.

    However this is off-topic :<

Leave a reply