We are disappointed, but are happy to lose to a game that people feel so passionate about — that is, simply, a beautiful thing. Congrats, Torchlight, and good luck to all the games in the next bracket. Thanks to DIYGamer for holding a fun contest, and for making N a part of it!

Being a part of this tournament was an overwhelmingly positive experience for us — we were so inspired to see the response N received, it was really encouraging. Reading the comments here and on the tournament pages, and seeing so many votes and so much incredible support for N made us remember how awesome all of you guys are, and we want to enthusiastically thank you for that

You guys rock.

Now’s your last chance to save N from a fate worse than death: defeat at the hands of a Diablo clone*! NOOOOOOOOOO000000000000oooooooooooooooooo…………

http://www.diygamer.com/2010/06/torchlight-tournament/

*yes, a Diablo clone by the creators of Diablo is admittedly not so much a “clone” as it is just another revised version of Diablo; this is a bit like calling N+ an N clone. Still.. enough with the passive mouse-based WoW-type ARPGs! When is someone going to make a Diablo clone that lets you actually fight the monsters a-la Demon’s Souls, instead of just clicking on them?!

Yes, that is correct: now is your chance to pick up the best version of N+ (according to us anyway) for only 400 Microsoft Currency Units! That’s 5 buckazoids if you’re from Xenon.

In other news, N has progressed to the quarter finals in the great DIYGamer Indie Games Tournament.

Thanks to everyone who voted — you guys rock!

This time around, we’re up against Torchlight, a game we’ve been meaning to try but haven’t yet got around to — which is probably a good thing considering how addictive Diablo can be! Apparently they have a large and active online community, so we’re not really sure what our chances are of making it to the semi-finals. We’re keeping our fingers crossed!

You’ve got one week (starting June 16) to vote for your favorite here: http://www.diygamer.com/2010/06/torchlight-tournament/

In game-development-related news, we’re in the process of porting N’s main “game simulation” code from AS1 to AS3; so far we’ve already found quite a few bugs, some of them pretty nasty (assignment in a conditional expression?! Thank you Flex compiler for warning about that, we would have missed it again).

We managed to fix the “stuttering up slopes” player behaviour; we had always assumed this was caused by faulty collision at the seams between tiles, but it turns out it has nothing to do with collision! Stuttering is caused by how we were calculating and applying friction, leading to the player becoming intermittently airborne every few frames.

Of course, we only discovered this after having completely rewritten the collision system to be geometry-based (tiles only exist in the editor now)… gah! But this is actually fine, since this new collision system is intended for general use in future projects (and tutorials), and is leaps and bounds easier and simpler than the big mess that it replaced. Silver lining!

We also figured out why bounceblocks launch you so much further if you “waggle” back and forth on them when moving downward: for some reason, we were applying drag to both vertical and horizontal movement when the player is standing. This makes no sense, because if the player is moving vertically then they can’t actually be in a “standing” state…except of course in the case where they’re standing still relative to a bounceblock which is traveling upwards.

With stuff like this, we’re trying very hard to keep things feeling as close as possible to the original, but unfortunately we’re finding that it’s impossible to make things identical without also duplicating behaviours which we’d prefer to eliminate.

For instance, the only way to fix the stuttering glitch was to alter the player’s velocity, since that velocity is what moves them into the air. But altering the velocity makes the movement feel a bit different — even a fraction-of-a-pixel change applied to a single frame (which is what was required to fix stuttering) results in a markedly different trajectory over the following few seconds. Markedly!

Thankfully we have a really nice testing setup where we can run the original unmodified player simulation “on top of” our revised version, which lets us see immediately where and how they diverge. In the case of stuttering, we were able to tweak things to be almost identical.

Our mantra for this rewriting process is “Always remember how badly George Lucas ruined Star Wars.” We’re really hoping that the changes we do make will be appreciated rather than reviled

In any case, dear N fans, we have your feedback close at hand, and we are considering it thoughtfully. We’re positive that although the revision will not be identical to N v1.4, it will be awesome — rest assured, we love this game immensely, and will make sure we do it justice.

You can vote for your favorite game here (until June 8th (we think)) : http://www.diygamer.com/2010/06/braid-tournament/

Now, on to more heady material.

Faithful readers may have noticed that lately we’ve been vacillating between projects, working for a month or so before moving on to something else. While this is a nice change of pace after spending 2009 focused on Robotology, and while we do intend to continue working on “blue sky” prototyping/R&D activities, we feel that it’s important for us to start working on something that we intend to finish.

Out of the many potential future projects, there is one which looms especially large over the rest; one which many have been waiting for and which we have committed to developing, albeit at an undetermined date. We are of course alluding to “v1.5″, the final update of N.

After half a decade of collecting suggestions and feedback from users, our list of desired features/changes contains many hundred entries, some trivial (add a running total to the kill count) and some quite complex (fix that stupid stuttering-up-slopes collision bug).

The main reason that we’ve been delaying this update for so long is that we realized that we really ought to port the codebase over to Actionscript 3 (it was written in Flash 5/AS1), and if we’re going to do that then we might as well just rewrite the whole damn thing. This is mostly a practical, pragmatic plan: there are many wishlist features that are currently almost impossible to add into the existing code, which will be much simpler to add as things are rewritten/ported. We’re also extremely reluctant to leave all of the joys of using a “proper language” — type safety! callstacks/debugging! — and descend into the horrible mess that is AS1.

Anyway, when we sat down to roughly plan things, we discovered that there are some very fundamental questions which we don’t know the answers to; after 5 years, the landscape of computing, gaming, Flash development, and pretty much everything else has changed considerably. For example: would users prefer to run N in a browser, or as a stand-alone application?

Therefore we’ve started a series of polls on the forums (http://forum.ninjarobotyeti.com) in order to solicit feedback from you. Now’s your chance to let us know how you would like v1.5 to be!

Please check out this thread for details: http://forum.ninjarobotyeti.com/viewtopic.php?f=17&t=6040

That’s all for now

Check it out here:
http://www.diygamer.com/2010/05/diygamercom-indie-games-tournament-2010-bracket-tournament/

N is up against Minecraft in the first round, which we think is a really smart pairing because both games have online fan communities, so it should be a fair fight.

Anyway, voting is happening right now, at the other end of this link:
http://www.diygamer.com/2010/05/nninja-minecraft-tournament/

We urge everyone to participate in voting for their favorites; the whole concept of an “indie game tournament” is such a great and fun idea, we hope that it spreads as far and wide as possible. Tell your friends!

In other news, we’ve been working on several small things for the past couple months. Sadly nothing is really in an exciting enough state to post about yet.. hopefully at least one of these projects will be developed enough to announce/show in the next few weeks. Stay tuned!

Concerning Office Yeti:

Prototyping went well, and we now have a 3D simulation/graphics system working and most of the graphics and gameplay mocked up. There are a few remaining technical tasks, such as adding a proper pathfinding system, but we’re more or less ready to begin making the “game proper”.

There were some interesting challenges that we came across during prototyping; depth-sorting ended up being much more involved than we anticipated, and we implemented a cell-and-portal system for the first time — typically we just throw everything into a simple grid, but that wasn’t the best fit for this game’s world. So we learned a lot, even if it took a few more weeks that planned. Very exciting.

We don’t know how much we’re going to be showing until it’s in a more advanced state. Definitely we’ll be writing something about our depth-sorting method, since we had a hard time finding any recent, useful information on this subject — these days everyone’s using graphics cards where z-buffers handle hidden-surface-removal for free. In Flash it’s not so easy!

Concerning Robotology:

In hindsight, a large part of the stress we felt was due to unrealistic expectations. We had assumed that two years (come on!!) worth of prototyping/R&D should be more than enough on that front, and proceeded to schedule production based on that.

What we should have realized, which is very obvious now, is that what matters isn’t how much time has been spent on prototyping, but what is actually working as a result of this work. Whether it’s because it takes a long time for us to figure things out, or because we were trying to figure out a lot of stuff, 2 years was apparently not enough time to get it all sorted and production-ready. Oh, it’s so obvious now.

There seems to be a disconnect between the best practices we’d like to follow — namely, as everyone suggests, “get a quick&dirty prototype knocked up to test your concept, then iterate” — and what we’re actually able to do.

This is something we want to figure out, because we can definitely conceive of how to prototype a game design which uses only existing solutions/technologies, but we’re unclear how we’re supposed to go about prototyping a game that requires e.g balancing self-locomoting bipeds if the technology for solving that problem doesn’t yet exist. Prototyping in general seems to imply that you start with a set of known solutions and proceed from there, but if there are unsolved technical problems then it’s not clear exactly how you can prototype anything without first solving the hard problems, which of course isn’t an easy “quick&dirty” process.

Philosophical musings aside, the bad news (or at least, the disappointing news) is that we’ve probably got at least another year of work to do before everything is fully figured out:

• We have robots blindly following animations…but we have no control system to select the animations or procedurally modify them in order to achieve goals (such as remaining upright, walking to the left, reaching for an object, etc.)
• We have a smooth vector-graphics system…but no animation system to drive it, and no editor to define shapes or movements.
• We have runtime simulation of articulated characters…but no toolchain to generate the data which describes those characters.

Player movement is still a work-in-progress; there are many promising leads but each of the various prototypes still exhibits some unwanted glitches or other problems.

There are a lot of self-contained problems here, which we plan on approaching as small stand-alone projects. We’re very much looking forward to that.

Something we just finished doing was going through our collection of “ideas” files and combining them into a more organized single list. This was a really fun process since we had forgotten about a lot of the older game ideas, and it allowed us to see that many of the game ideas we’re interested in tend to cluster in groups of related concepts.

We don’t know what we’re going to do with these ideas; we hope to start banging out 2-3 week projects which explore the basics of some of them, such as “lighting/visibility in a 2D environment”.

Many of these little gems seemed amenable for use as smaller proof-of-concept projects en route to Robotology. For example, the player movement/control code could be the basis for a game where players explore a simple tile-based environment. The rest of the game would be simple (i.e no need to worry about animation, AI, etc) but the player movement would be a working model of what we want for Robotology. We test our player control theories, and create an interesting offshoot as well. Everybody wins!

And finally, don’t worry, a new version of N is definitely on the to do list as well.

We don’t know yet how exactly we want to approach things; GDC is always very inspiring and motivating, so we’re hoping that the next week or so of chatting with other game developers will get the creative juices flowing and lead to us deciding upon a plan of action for the immediate future.

The the past few months have been quite stressful and busy, with a constant stream of things coming up that required our attention…resulting in us never having the time and/or energy to properly make with the blogging.

To jump straight to the crux of the post: we’ve decided to put Robotology on hold for the immediate future.

We spent the end of 2009 trying to prepare a “vertical slice” of the game in order to meet a grant milestone; this was a rather soul-crushing process of cutting, cutting, and cutting some more, until the game that remained was not the exciting, interesting game we are determined to make. Realizing this made us aware that something was wrong, and that action was needed in order to move us back on track.

Now, obviously some amount of compromise is required in order to actually ship a game, we’re quite aware of the dangers of a “ship when it’s done” mentality and Duke Nukem Forever and all that. Don’t worry, we’re on it.

The problem is that the features we would have had to cut or simplify in order to release the game in the near future are basically the entire list of what we set out to achieve: physics-based locomotion, vector-graphics animation system, powerful and friendly editors. When you remove these, you’re left with yet another physics-based platformer which neither of us was really interested in working on or playing.

The reason for Metanet Software’s existence is to provide a channel through which we can release our work, so that we can be able to make the games we want to make.

Obviously we would love to release a new game every year, or every month, but at the same time we would both prefer to never release another game than to release something we aren’t happy with and don’t love.

As we worked we saw how far we were from realizing the game we had envisioned, and how little time we had left before our deadline, which put us under a lot of stress; a combination of “it’s been so long since we released a game!” and our own impatience at still not being able to play this game we’ve been collectively dreaming of for years.

This stress made it harder to concentrate and work well, which began a feedback loop of more and more stress and less and less good work getting done.

At some point we realized that we don’t have “little time” left, in fact we have our entire lives — maybe we don’t need to kill ourselves to get this done, especially if we’re not going to be happy with the result.

While we were struggling with Robotology through November and December, the proverbial “carrot on the stick” was that once it was completed, we would be able to spend 2010 working on the many small experiments and game ideas that have been accumulating in our “to do” lists over the years.

We decided that instead of trying to press on with Robotology, it would be better for us and for the project if it was put on hold for the time being, allowing us to take a break from it by working on those small projects (one of which is prototyping Office Yeti). Exciting!

The realization that we maybe needed to take a break from Robotology was even more frustrating because of how great everyone else is doing; it seemed as though all of our friends and peers were excelling in 2009 and accelerating into 2010, while we were stuck in a morass. We’re so inspired by the amazing work our friends are doing, and it was difficult to admit we weren’t getting much done with our project. It was indescribably heartbreaking to make the decision to put Robotology on hold: it meant shelving our dream game, and accepting the harsh reality that we had failed, and that we’ve let people down.

Andy Schatz’s recent experience with Monaco, as detailed on his blog, has somewhat reassured us that this is the right decision to make — or at least that it isn’t necessarily a terribly bad course of action to take! Let’s hope

And so, the beginning of 2010 was an extremely low point in the history of Metanet Software, but since then we’ve come to realize that this situation isn’t really so bad: we’ve learned a lot, and have an incredible amount of useful tech which will serve us well in other projects.

Most importantly, once our decision had sunk in, we found that we were excited and inspired, and that we both had a renewed energy toward making games.

We can’t wait to start expanding some of our ideas and experiments over the next few months, which will hopefully result in some new, fun projects. Plus, Robotology isn’t gone for good — now that it’s no longer an albatross, we find ourselves getting excited about it again and wanting to work on some of the remaining problems/challenges. Many of the outstanding tasks, like the level and character editors, were perfectly suited to be stand-alone projects, and we’re looking forward to working on them.

Being able to return to these projects whenever we get an idea or insight rather than having to have solved everything like, yesterday — being free of the constant pressure and stress of getting it finished ASAP — really feels great.

We’ve moved from devastation to hopeful optimism, and we’re on our way to inspiration, so overall, this whole experience might have been more positive than negative — can’t go wrong with that.

Another post about Robotology is in the works, sort of like a post-mortem, although since it’s not dead, maybe it’s more akin to a physical or routine check-up?

Anyway thanks for sticking with us, faithful readers, and stay tuned for more.

Also, we finally added “coming soon” pages to www.robotology.org and www.officeyeti.org. Check ‘em out!

That’s it for now — we’re still trying to get something substantial done for the IGF deadline. More on that next week!

We’ll keep you posted!

See it here on Vimeo (higher quality) and Youtube (lower quality).

(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!