We recently received an interesting email from Dr. Benjamin Alterman, a clinical psychologist certified in neurofeedback therapy. With his permission, here’s what he had to say:

Dear Metanet Software,

I’d like to express my thanks for the important contribution your game N has made to many of my patients. I am a clinical psychologist specializing in neurobehavioral therapy for disorders of attention, anxiety, and impulsivity in adolescents. For a portion of their mental training, we run N on a PC with the AV signal channeled through a switch that responds to the patient’s brainwaves or skin-conductance. When the patient’s autonomic nervous system becomes excited or brain becomes agitated beyond a certain threshold, the AV signal is automatically cut-off and the game paused until the patient can again play with perfect composure.

Better than any other game I’ve employed, N is beautifully adapted for this purpose. In practice mode with the timer off, not only does the game-play allow for pausing even at critical junctures whenever the AV signal is interrupted, but the level design also allows me to teach patients with learning disabilities and attention deficits how to gather information from failure, identify new strategies, practice the execution of those strategies, and then, following additional failures, reassess their strategies or need for further skill acquisition. This training teaches them meta-awareness which helps them to develop frustration tolerance in real world academic and social environments in a way that talk therapy alone does not.

So, thanks again for your fine work. It has made a substantial difference in the lives of many young people and their families. (Incidentally, they also really enjoy watching their N-body bounce around after it becomes a corpse.)

Best wishes,
Benjamin Alterman, Ph.D.

We were amazed and humbled to hear that; that N could be a part of something so progressive and cool is simply inspiring.

It would have been pretty awesome if we could have shipped N+ with an AV switch peripheral, so that everyone could try this sort of training…that’s a great idea for the sequel, whenever that happens!

Thanks for writing, Dr. Alterman, you rock! We’re happy we could help

In other, less awesome news, the N+ DS/PSP community servers are officially no more. We received word from our stalwart contact at Atari that the valiant efforts to rescue the data servers for N+ DS and PSP (from Silverbirch, the now-defunct developer of the handheld versions) and reinstate them on-site at Atari have failed, and since the project has unfortunately been something of a financial failure, the community servers are not a priority and will now be abandoned. We fully understand the decision on Atari’s part, and cannot fault them at all; it just sucks for everyone awesome enough to buy the DS/PSP versions of N+.

We are saddened by the news, since this marks the end of a (rather short) era of sharing levels and playing multiplayer games on the handheld systems, but we are not surprised; this was an inevitability that we think unfortunately arrived long before it was due. Players will have to be content with single player levels moving forward — hopefully the quality and quantity there will suffice.

Thanks to everyone, for playing N+. We hope you continue to enjoy it! Let’s have a moment of silence for N+ DS and PSP’s online content.

That’s it for today’s trip through the mailbag; coming “soon” (in the next couple weeks): a new video of in-development Robotology stuff. Mark your calendars for some vague date in the future!

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

We’re incredibly pressed for time today, so sadly this final daily post may not be the detailed and frankly hilarious post you’ve come to expect. If you’re just tuning into this blogstravaganza, here are some links you might want to check out.

Yesterday we provided some insight into the other things we like to spend our time doing, such as getting crafty, and subtly implied that we’d be returning to the dev-related today. If you guessed that today’s much anticipated topic is Robotology, you totally get 28 points.

We generally tend to vacillate between supreme confidence and terrifying anxiety about this game. Despite months and months of work, it’s still nowhere near complete, but at the same time we’ve managed to get most of the vital parts figured out. Many of these systems are currently up and running, and we’ve learned a lot in the process.

Our roadmap for the next few months is basically “crunch crunch crunch” (mmm! sounds so delicious.) trying to get something complete for the IGF deadline, and then crunch some more trying to get something finished for the end of the year (our hard deadline with the sincerely wonderful OMDC). We also need to wrap up the Office Yeti prototype.

In order to meet these deadlines, we’ve spent the past week getting organized so that we can properly apply some sort of triage to the remaining tasks (we are getting so good at triage). Previously we simply had lists of tasks in no particular order, broken up only by topic (i.e graphics, editor, bugs, etc) which we would trawl through randomly to find the next problem to work on; now we have a nice hierarchical series of tasks which has been sorted according to priority vis-a-vis our deadlines.

This was a somewhat depressing process, since it required cutting features entirely, and postponing others for the foreseeable future; still, it was ultimately worthwhile since we now know exactly what we have to do in the immediate future, and moreover we know we can get it all done.

So what specifically are we working on now? We’ve been stuck on control and animation for a while; basically we have a great simulator which lets us model motorized contraptions, but we now need to add AI/logic which drives the motors in order to accomplish things. From the high-level AI architecture to the low-level motor control, this is a problem which isn’t very well documented — most people seem to be content to have dynamics-based animation systems which amount to ragdolls following keyframe animation data, and leave it at that.

This is itself is far from trivial to get working, but even harder is figuring out some way to add feedback to the system, so that the ragdoll isn’t being dragged forward blindly by animation playback, but is instead controlled by a system which takes the current state of the ragdoll into account.

Of course, once we do find a working strategy, the real challenge will be to develop it into a flexible solution that can be applied to the various types of mechanisms we want to control — we don’t want to have to hand-code control systems from the ground up for each type of robot or moving object! Yikes. Ideally we’ll be able to plug together pre-existing control components to create each robot’s control system; barring that, we’ll have a set of common control functionality/utilities and then we’ll write each controller by hand using this “toolbox” rather than from scratch. Still better than nothing!

Aside from control, our other immediate task is getting a proper graphics system up and running. We have various prototypes which demonstrate that our basic ideas work, but we need to take these and create a proper rendering pipeline. This would be a relatively straightforward problem, except for our complete ignorance of how graphics systems are typically organized — we’re used to having this problem already taken care of by the Flash runtime, so we have no idea where to even begin.

Anyway, that’s about all we have time to get into right now, unfortunately! We really can’t wait to write up some tutorials on everything we’ve learned, but of course that will be a while since we need to get the actual game done first

And so ends the legendary blogathon. We accomplished pretty much what we set out to, namely to get you readers up to date on where we’re at, and to give our abysmal blog posting statistics a much-needed kick in the ass. We’ll be back in the not-too-distant future with more news about Robotology, hopefully with some more video or screenshots so you can see how things are progressing along with the explanation.

That’s it for now! Thanks for reading, and for all your comments — we really appreciate it.

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

For those of you just joining us on our quest for daily blog posts so as to show up our usually abysmal posting statistics, you can find part 0, part 1 and part 2 via those links.

Yesterday, we introduced you to the crazy world of Office Yeti, our next next game, which will be released after Robotology (our next game). We hope you enjoyed your brief stay there — a more in-depth look is on its way.

We also tried to imply that we do spend some time on more than just games. Now, we know you’re used to seeing game- and dev-related posts on this blog, but we’re going change it up a bit and switch gears before we conclude our daily blog-posting extravaganza; let’s hope you sharpened those link-finding skills back in Blogathon post 1 — you’re gonna need ‘em!

At long last, there’s new stuff in the Metanet handmade merch shop! Can you believe it?

Long ago, when we had some extra time in the evenings, we spent some of it devising and constructing simple but fantastic tote bags. We currently use the prototypes for books, food, sundries and what have you. Very durable, very cool. Check ‘em out!

(Note that the contrast between fabric and ink is always fairly stark — differences in the photos in our Etsy shop and the how-to below are purely because of unusual lighting and the therefore necessary screwing-around in Photoshop. Sorry, we’re n00bs!)

Something we like to do here at Metanet is to try to be creative in non-computer-related ways such as making music, making short films and making handmade merch — it takes the edge off coding all day and keeps us motivated to get back. To give some insight into what we do when we’re not making games, playing games or hanging out with Socialites, indies and other Toronto friends, here’s a brief look at how we made the fabulous Metanet tote bags, in 15 Steps of Varying Difficulty.

1. Let’s start with the Metanet logo patches. To make the screen, we used the incredible Print Gocco, a Japanese screen-printing machine we bought in Japan on our first trip. It’s regrettably no longer being produced; supplies are scarce, and each print makes us appreciate how cool it is even more. Here’s an action shot of Mare burning a screen. SO COOL. This is the screen. It’s transparent where the ink comes through, obviously.

 

2. We cut out pieces of fabric to print on, and printed the image using black screenprinting ink and a squeegee (really, we’re using a chef’s plastic scraper thingy from a kitchen store. Works just as well!).

   We’re going for a distressed/deliberately messy effect, so even minor misprints are okay. Interestingly, that eliminates a lot of stress, which leads to better prints. Win-win!

   After removing the screen, you’re left with glistening, clean lines and a strong sense of satisfaction. Let’s take a closer look at that delicious print. It’s even cooler in person.

 

3. We repeated the previous step approximately one billion times, on various pieces of fabric. Gotta use that screen while it’s wet!

 

4. Next we trim the excess fabric. Over and over. Again, the deliberately messy aesthetic we’re going for means we don’t have to worry about perfectly straight cuts. Nice!

 

5. And now on to the bag itself. Washing, drying, and ironing fabric is the first step. Or series of steps, really. We used various weights, colours and prints of cotton canvas for durability and variety.

 

6. We cut out fabric based on a pattern and with the help of some rocks (nature’s fabric weights). The bags are unlined, so only one piece is necessary. Our pattern has gone through several revisions as you can see by the masking tape!

 

7. We painstakingly measured and cut black webbing for each bag’s handles. We bought webbing in bulk because it is cheaper that way, and more awesome. That roll was twice as big when we started this project, and was oodles of fun to roll around the office. We got two and raced ‘em. When you’re working with nylon or poly webbing, don’t forget to melt the cut ends so they won’t unravel.

 

8. Here we are sewing a Metanet logo patch to bag fabric. Fraying of the patch’s edges suits the style we’re going for, so turning the edges under isn’t required. By Grabthar’s Hammer, what a savings.

 

9. Next, we iron the patch to make it sit smooth and flat, and additionally to further set the ink. This may seem superfluous, but it’s the little details that make these bags special.

 

10. We sew the side seams right-side-out first, then iron and sew the sides again with the bag turned inside out. Why? French seams, bitches! French seams are very strong, plus they conceal the cut edges of the fabric on both sides of the bag, so the seams will look neat and won’t fray or fall apart. French seams: another innovation brought to you by Metanet Software.

 

11. While the bag is inside out, it’s a good time to fold the bottom edges into corners. Then we measure and sew them down. Et voila, a simple square gusset that will enable the bag to, for example, hold several textbooks side by side.

 

12. Next we iron the top hem. Ironing is essential for easy sewing later on.

 

13. The handles are then positioned and pinned, making sure they match up.

 

14. Almost there. The top hem is next. French seams in cotton canvas can be tough for domestic machines so we mainly avoided them; we invested in more horsepower for the MKII totes for a different sort of finishing. Not to worry, several from the MKI run have been in use for a year now and are holding up impeccably.

 

15. Finally, we hand-drew some fancy logos on the tag, trimmed, and marvelled at each finished Metanet tote bag.

From step 6 on, each bag takes about 30 minutes to put together. Not too shabby! And as for the bags themselves, well they’re not shabby at all. Except the logo patches, but it’s a controlled shabby Here’s another bag Mare made for herself using a slightly different technique. Yes, it’s just that fun to make tote bags. Who knows, maybe this will inspire you, brave reader, to get crafty too.

Tomorrow will probably be the final daily post — we’re starting to run out of material! Yes, that was a craft-related pun.

Hopefully this brief spate of posts will get us back in the habit of posting more frequently than once every two months — it definitely reminded us how fun it is to write. We’re really excited about writing up tutorials on some of the stuff we’ve been working on for Robotology; sadly we need to finish the actual game first, and a lot remains to be done on that front.

Was the previous sentence an example of foreshadowing?! Tune in tomorrow for the exciting conclusion of The Blogathon.

Filed under: dev, merch, misc, news by M&R
9 Comments »

Those of you who only check this blog once a month — a perfectly reasonable strategy, given our previous rate of posting — will be shocked to know that this is in fact our third consecutive daily post! We can’t believe it either! (Here are links to part 0 and part 1 of the daily blogathon, in case you’re just tuning in.)

Those of you who have read the previous post may recall that the most salient news item was the recent Hand Eye Society Social #4 (the “Quadrocial”), and the many exciting voyages and adventures which arose as a result of said event.

Those of you who managed to read all the way to the end may even remember a passing mention of our presentation at the Social; this was the “cliffhanger” of yesterday’s post… OR WAS IT ?!

Yes, it was. We just wanted to throw in another little cliffhanger there, just to make sure that we really milked this sweet mystery thing for all its worth. And so, without further prolonging what must seem like an agonizing eternity of prelude, we’re happy to announce:

OFFICE YETI

A brief aside on the subject of the title of this post: those of you not familiar with Star Trek and/or our forums may not be aware that, prior to our formal announcement of its existence, Robotology was simply referred to as “TNG” (short for “The Next Generation”)*.

Thus the code-name that was selected as most appropriate for the game which — assuming we have our druthers (we’re rifling through drawers and looking under furniture for them right now, but not to worry, we’re sure they’re around here somewhere) — will succeed Robotology was naturally Deep Space 9 (neatly abbreviated to “DS9″).

Of course as this was a purely private code-word, intended for internal use only, and we had already decided upon the proper title (for reasons which will become obvious once we reach the conclusion of this aside), the formal code-name DS9 was never actually used. In hindsight, the entire exercise in code-naming could therefore be considered somewhat frivolous, but that’s how we roll around here — such is our wont.

Okay, back to the topic at hand.

So, what is Office Yeti?

Office Yeti, which we’ve been prototyping lately, is a single-player action/puzzle/simulation game in which players assume control of a yeti who works in an office.

But, you may be asking, how did HR come to inadvertently hire a yeti? Why a Yeti, and not a Sasquatch? Is this all some sort of hilarious inside joke?

For now these questions will all remain unanswered; the important point is that you’re a tiny little character in a tiny little simulated office building full of even tinier characters and objects, all of which are going about their business more or less oblivious to the fact that you are, to put it bluntly, non-human. Just like in an office in real life!

The game we’re most drawing inspiration from is Skool Daze, which is sadly not that well known despite having both a sequel and an excellent Windows remake.

A quasi-mathematical graphic description of the game might look something like:

[Skool Daze] + [Harry the Handsome Executive] + [Metanet] = [Office Yeti]

Other games we’re drawing from include Rampage and Factory.

Great premise, right? We’ve only been working on this part-time for the past few months, so there isn’t much to show yet; we have the basics of the physical simulation working (objects moving around and colliding), some basic objects mocked up, a prototyped graphics system, and a good shared vision of the general direction we want to take things. Hopefully the next time we post about it, we’ll have some screenshots or something to show — for now it’s all under wraps. Delicious, delicious wraps.

We’ve already hit our first big snag: depth-sorting a 3D scene is apparently not as trivial as we had assumed it would be! Luckily we managed to find a solution which is working so far, and which we should be able to extend as the need arises. We’ve always wanted to try non-perspective-projection 3D, and the oblique angle we’ve settled upon is totally exciting for us…a third dimension!! That’s one more than our typical amount!

The actual game mechanics at this point are quite vague; we have a long list of things to prototype, but its impossible to say what will end up working and what won’t. Our first goal is to get a simple little artificial-life office simulation working; from there we’ll drop in a big ol’ yeti and see what happens. We’re expecting hilarious mayhem.

The general idea is that the yeti is free to interact with the environment just like a normal worker, but also has a unique set of abilities: eating people, climbing walls, smashing things — you know, typical yeti behaviours.

The graphic design will be quite iconic, similar to instructional data-graphics such as airplane safety cards or warning signs; the movement and physical interaction of objects will — hopefully — combine to create sort of a “living shopping-mall-map” effect.

As many of you may know, we’re also hoping to work with our friend Edmund McMillen, whose art has always stood out in our minds as awesome. We’re not sure yet on specifics — the ball has just started to roll — but we’re pretty confident we can figure something out despite being roughly in opposite corners of North America.

Office Yeti was actually conceived of long before Robotology, or even N; at the time we were both working in offices and thought that it was a really rich and under-explored setting for a game; also it was fun to fantasize about various ways that havoc could be wreaked upon an office environment.

We then came across Skool Daze (thanks to the truly wonderful Home of the Underdogs), which is an amazing example of taking a game and setting it in the middle of a simulation, with the simulation simply being the setting/backdrop of the game rather than the direct focus.

Of course, we realized that we had no hope of being able to make the game that we wanted, so we kept the idea on the back-burner until such a time as both our own skills and the chosen development environment (Flash, so that people can play while they’re at work, naturally) were capable of handling that much awesome all in one go.

Finally, that day came — we were at a point with Robotology where getting the game done was more a matter of “when” rather than “if”; the hardest problems had been solved, and we just needed time to iterate on the game design until things clicked. Thus we decided that it was the perfect time to start Office Yeti.

And that, dear readers, is your official introduction to our next project. We’ll keep you posted!

Next time on the Metablog: is that all? What else have we been doing this year?!

footnotes:
[*]: TNG is actually an abbreviation of “The Next Game”, but to acknowledge this would completely ruin all of our hilarious Star Trek jokes, and so instead we choose to ignore it.

Filed under: dev, history, news, office yeti by M&R
14 Comments »

For those of you just tuning in, this is the second part of our spectacular series of daily blog posts; the first part (part 0) is here.

Yes, daily updates.. it’s exciting!

Today’s post was really meant to precede the events on which it is based, however we unfortunately weren’t able to find time while everything was going down. Those of you with a gift for detecting hyperlinks may have already discovered the topic of today’s post cleverly hidden in post 0; kudos to you! The rest of you will want to pay special attention to words in this and other posts which appear ever-so-slightly darker than the rest of the text: Surprise! Those are links. And there are a lot of them in this post, so please be ever-vigilant — in fact the very first sentence of this very post contains one! In-post minigames: that’s our gift to you.

Let’s start with some history: a while ago, a friend of ours, Jim Munroe, decided he didn’t already have enough to do; apparently book authoring, graphic novel writing, artsy games incubating, movie producing, and baby making (this last feat strangely absent from his “What I’ve Made” page) weren’t enough for him He also wanted to inspire all the local game-developy people into joining some sort of alliance. A code-alition, if you will.

(Fun fact: any random selection of 5 people in and around the Greater Toronto Area will contain no fewer than 3 people who know Jim Munroe, each through a completely different channel than the others. This is the origin of the popular party game “2 Degrees of Jim Munroe”)

So, Jim rounded us developy-types up and started The Hand-Eye Society, convincing us of its merits using beer and superior logic.

(Aside: Raigan debated the chosen name, proffering (and preferring) alternative titles for the organization such as “TOTOromi” and “Toronto Indie Games Source”; in doing so he only narrowly avoided being the first member subject to mass shunning.)

(Another aside: Now might be a good time to introduce another in-post minigame: see if you can guess which statements are real and which are confabulations!)

So: having established the existence of the Hand Eye Society, we can now explain that there is a bi-monthly event referred to as The Hand Eye Society Social (Raigan’s suggested nom-de-event was “Gameboree”), located at a well-hidden local bar in which Socialites (that’s what we call each other) present in-development games and other items of interest to appease a usually jeering, unruly crowd.

Each Social is hosted by a different Socialite; those whose offerings are accepted are hoisted aloft and feted until the wee hours; those whose presentations are deemed unworthy are, or course, shunned.

We gave a quick summary of a project we’re currently working on, and flew in our friend Alex Austin — whose games you’re probably aware of — as the evening’s main event. In fairness this clever strategy was not of our own devising, we merely adopted the practice from the original Social host (Jim Munroe, again.. that guy is everywhere!) of inviting a foreigner to face the crowd.

And so it was that Alex found himself not in his native California, but on strange, unfamiliar soil, in an alien climate so frigid that he was forced to bundle up in a jacket and tuque (apparently called “beanies” in the US), despite it being the middle of summer. Seriously, it’s not usually cold like that in the summer up here, that was really unexpected!

Here we can see Alex proceeding through Canadian customs. (the Sentinel II air-blasting system is at this point only ceremonial.)

Here’s Alex as an anonymous informant providing testimony from a mysterious lair in the sky. We dragged Alex to various parties and get-togethers around the city. Here he is crushing one of our many buildings, perhaps in response.

Amongst the countless atrocities he was forced to endure during his stay, surely none was more abhorrent to such a freedom-loving soul than our terrifying socialist system of alcohol purveyance. Here he is, looking suitably stricken.

When the magical night of the Social finally arrived, Alex gave the assembled Toronto Game Friends a behind-the-scenes look at the multitude of incredible games he’s working on right now, leaving everyone impressed and motivated. He’s making roughly a dozen different games at the same time! It’s somewhat daunting; we can only assume it’s the fresh California air which allows such prodigious feats.

And so, Alex’s presentation won over the audience, and he enjoyed the rest of a successful, though frigid, weekend in Toronto before returning to the balmy state he calls home. Thanks again, Alex, it was so awesome to have you in town!

This Social was an historic moment for many reasons. For instance, it was the very first Social attended by the infamous Mathew Kumar, an investigative games journalist embedded here in Toronto. It was also the very first fourth Social, a feat which will probably never be duplicated.

And now, we’ve brought you up to speed on the Hand Eye Society, which concludes the second, and still quite over-long (we’re working on it!), daily blogathon post.

Next time: what of Metanet’s presentation at the Social?

Which game did we present? (infuriatingly vague hint: it was not Robotology!)

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

It was pointed out in the comments that we average a paltry 5 blog posts a year at this rate. That is beyond terrible and we apologize wholeheartedly. It seems like on every blog post we earnestly promise to post more often, and then two months go by and we still haven’t found the time. This time, we mean it — this time, we have a plan!

So prepare yourself, brave reader, for the stupendous onslaught of…

DAILY POSTS ON THE METABLOG!!

Yes, that’s right: for the next several days we vow to post every single day. In a row. Not only will this enable us to write individual blog posts which are less book-like in stature, it should also help to bolster our woefully low rate of posts-per-year. In your face, statistics!

On a more practical note, part of the problem with our lack of timely blog posting is that it takes a disproportionate amount of time to write a post — it seems like it should take an hour at most and then we find much of the day has gone by and it’s still not done. This particular post had been especially daunting since, as time passed, there were more and more things to write about, creating a snowballing infinite loop of blog-posting-procrastination. For reasons which we’ll hopefully get to at some later date, spending the entire day writing a blog post wasn’t really going to work.

Hence our insanely brilliant discovery of the idea to post smaller amounts at a daily rate, thereby avoiding the infinite regress of non-daily-blog-posting. Daily blogging: another mind-blowing innovation brought to you by Metanet Software Inc.

So fear no longer, for the time has come: post we shall, and with gusto! And about more than just the fact that yes, we are indeed finally posting something; despite our name, most of the time we do try not to be too meta.

Today’s item of interest: XBLA game rating

For those of you who aren’t on the cutting edge of console OS/interface updates, some background: a ratings system was recently added to XBLA, allowing players to assign each game a rating of 1 to 5 stars, either via the 360’s menu system or the website.

This is a really welcome feature, since it will (hopefully) prevent the worthwhile games from getting buried under new releases. In the Community Games section (”Indie Games” now, apparently) this was especially a problem, so kudos to Microsoft for enabling this feature — we’re sure it caused their lawyers many a sleepless night. Or something. Who knows why it wasn’t implemented earlier — the point is, it’s here now, and that’s awesome!

Of course, for some inexplicable reason the actual implementation seems to be half-finished, or perhaps half-broken, since you can rate games you haven’t bought or even downloaded the demo for… but it’s better than nothing, right? Right?

To get to the actual point: so far, 11k people have rated N+, and we were delighted to find that its rating is quite good. Thank you so much! This is definitely a great start, but we were a touch underwhelmed (if that’s a word) by the math: it turns out that means that less than 1% of gamers who have tried N+ have given it a rating.

We briefly considered some sort of “cash for votes” program, but it was quickly abandoned due some pretty obvious problems; aside from the glaring ethical (and possibly legal) issues, the volume of XBLA users (well over 10M by now) means that even at payments as low as 10 cents per star, we could very quickly become superbankrupt. (Superbankruptcy is like regular bankruptcy, except that subsequently the company may form a neutron star or black hole.)

In light of the above, we’re just humbly asking everyone to rate N+ with however many stars they feel it deserves. Please take a few minutes, rate N+, and spread the word — every little bit helps!

This concludes the first of many daily posts which shall be forthcoming on this, the Metablog.

So, what adventures await us tomorrow?

What exactly is the elusive “Hand Eye Society”, and what transpired on the evening of August 27th, 2009?
(spoilers: this is and this did)

Will Mare and Raigan ever learn how to write posts of a lesser verbosity?

And what of the identity of this mysterious foreigner in our midst?

Tune in tomorrow for more of the incredible postings of Mare and Raigan! Same bat-URL, hopefully similar bat-time. (Okay that sentence was hard to write. Being unabashedly cheesy and ridiculous is harder than it looks!)

Filed under: misc, n and n+, news by M&R
8 Comments »

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 and n+, news, robotology by M&R
56 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 and n+, news, robotology by M&R
28 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 and n+, robotology by M&R
16 Comments »