Okay guys, the new server is now servin’ up delicious content for everyone on all of our sites. Let us know if you notice any unusual sloth or pages not loading — there are always a few bugs to work out. Our mail server was down for a few days, if anything bounced please resend!
Please bear with us over the next little while, loyal readers — we’re shifting our sites around and moving from our cheapass webhost to a proper server, and there will probably be a few kinks to work out. Rest assured, we’ll be back soon, and hopefully with a much more awesome setup and less down-time on the sites!
(In case you missed it, you can check out the first video in this post.)
The graphics are of course still just debug stuff, and all collision shapes are capsules, as this was much simpler than having to specify polygonal shapes for each segment of each body.
The environment is also obviously not at all what the final game world will be like, but as we haven’t yet implemented a camera we aren’t able to do any scrolling; the treadmill and “hamster wheel” scenes come in handy for testing extended walking 😀
It’s really exciting to finally feel like we’re getting somewhere, after so much prep work establishing the foundation. We still have a lot of work to do on physics-based animation, in terms of both modelling and control, but it’s just great to finally be able to use the systems we’ve spent so much time building.
In the video, all movement is animation being driven based on time; the next step in terms of modeling movement is to add some sort of feedback to the system, since currently it’s all just blind forward animation (i.e “wind-up toys”). Instead of being oblivious to physics, the playhead driving the animation should be coupled to the physical state of the robot so that, for example, if a robot’s foot is stuck on something, the animation doesn’t just keep playing back regardless. That would be silly! We have a few ideas but there aren’t any good references around so we’ll be more or less stabbing in the dark. That’s okay, we’re good at stabbing. Er, metaphorically.
Control also needs a lot of work; for the video we were just using the keyboard to set the speed of the motors driving the animation, but moving forward, some sort of higher-level controller which can steer the motors is needed. There are thankfully a few good papers on integrating high-level logical control with low-level continuous control — hopefully it won’t be too complicated to add slightly more intelligent brains to the robots!
We also have a lot of work to do on the tools side; we made a basic parametric model which can generate legs and feet, but it’s quite rudimentary and can’t handle, for instance, wheeled or flying robots. Oh yeah, for sure we need wheeled and flying robots 😉 It’s definitely a huge improvement from hard-coding everything — making a biped now only takes ~20 lines of code to define some parameters which are then used to generate the necessary data, instead of 200+ to make all the shapes and constraints by hand. But what we really can’t wait for is when we finish a more visual editor which will make defining custom shapes even less tedious 😀
So, that’s about it for now. How are you liking all these posts? It’s prolific around here!
We’re going to get back to working on the character controller (used to model the movement of the player and smaller robots), and we have about a month to get something playable done for the IGF deadline…it will be tight, so maybe don’t expect much in the way of posting for a little while!
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!
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, herearesomelinks 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.
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.
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.
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.
We repeated the previous step approximately one billion times, on various pieces of fabric. Gotta use that screen while it’s wet!
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!
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.
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!
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.
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.
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.
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.
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.
Next we iron the top hem. Ironing is essential for easy sewing later on.
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.
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.
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!
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.
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!
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!)
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?
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!)
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.
(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 🙂
