Before we get started on the continuing saga of Robotology, we should quickly give you an update on Contesque #3, The Creativity Contesque. Thanks so much to everyone who entered! We saw some really great work. However, since we received far fewer entries than expected, instead of immediately awarding a prize, we thought we’d keep the Contesque open longer, to give more of you a chance to show off 🙂 So, everyone, until further notice, send your art, crafts or costumes related to N+ to PDLC2 [at] metanetsoftware [dot] com — if we like what we see, we’ll send you a copy of whichever version of N+ you want. Hooray for creativity!
And don’t forget, the Metanet Etsy shop is open and ready for your holiday orders.
Alright, on to Robotology.
When we first started working on the simulator, we didn’t yet know how the editor would work. We knew that we wanted to use a higher-level editing paradigm than “user must manually place polygon vertices”, but we had no idea what the solution would be. So, to be on the safe side, we just assumed that the editor would export geometry in a generic format: simple (non-self-intersecting, no holes) polygons. That way we could start working on the sim without having designed the editor.
This decision led to a lot of hard work on collision detection, since developing algorithms that work with general concave polygons is quite complicated compared to simpler, more constrained cases like boxes or convex shapes. We learned a lot — which we can’t wait to share via tutorials once this game is done! — and things are working well so far. Unfortunately, as is the case in many simulators, collision is definitely a bottleneck in our physics system.
Using simple polygons (the most unstructured, generic data format possible) as the interface between simulator and editor was a safe bet in that it allowed the two systems to be uncoupled and thus developed at different times. One nuance we failed to appreciate is that scene editors are often privy to lots of extra information — information which could make the collision system’s job easier — and that by reducing the interface between the two systems to generic polygons, we were throwing away lots of useful info!
In hindsight this should have been obvious, since we know of many existing game engines which use extra data generated automatically by the editing paradigm. Quake 3 is a good example: the editor is CSG-based, with users creating shapes by cutting and welding convex “brushes” with each other. Any sort of scene can be created with these tools, but since the building blocks are more structured than “triangle soup”, they contain lots of great info that can be exploited. For instance, covering a scene made of “triangle soup” with convex primitives is a very hard problem in the general case, but since the editor directly works with convex primitives (brushes), a set of convex shapes that covers the scene already exists “automatically”, without having to build one up from scratch. Bonus!
Anyway, now that we’ve (mostly) figured out how the editor will be working, we’re aware that a much more efficient collision detection solution would be possible, given the extra info that’s made available by our editing paradigm. But since our current collision system is working just fine, and in the interest of actually getting this game done at some point, we’re going to be leaving things as-is until they become a problem.
The editor UI/frontend is still only partially planned — and it will no doubt be an ongoing task for the rest of development, as we iteratively figure out what works and what doesn’t. However, the design of the editor’s backend (the world model, and operations which manipulate this model) is complete and we’re starting to build it. This is pretty exciting as it is the most up-front planning we’ve ever done, and it’s really paid off — what started as an intractable, frustrating mess of desired features is now a realizable, fleshed-out plan of action, complete with pseudocode for all of the major algorithms.
Figuring out how the editor will work has let us make headway in other areas, such as the graphics/rendering system, as we nail down implementation details concerning how geometry will be represented and manipulated. It’s also the realization of several years of rumination and discussions we’ve had concerning 2D geometry and what sort of paradigms might be worth exploring beyond the usual tile-based and CSG methods. Hooray!!
Excellent! I love hearing updated on Robotology! I can’t wait to play the game!
You should have more playable demos or at least record some teasers or pics or something!
We definitely will, once we have something more to look at than aliased lines on a screen 😉
I love updates too! Now to work on some N artwork…
But before I go, are you aware that nmaps.net is not currently working when you try to access it? It says there is a server error. I’m sure you’re onto it already though.
Who doesn’t love updates? 😀 Good to hear some very definite news that there will be an editor (not that I really had any doubts, but still~).
—> Come on, people, get creative and use your initiative! You have nothing to lose! :3
I made a picture but then accidently sent it as a paint.NET file, so I resent it as a jpeg, but the second email I sent had the same subject so they might think I sent them the same email twice. Oh the perils of being me.
maaaaaaan…. you guys are SMART!!!
PS: Let’s eat some pho soon, okay?
Question!
Does it have to be N+ related? Can it just be N related?
…I bet everyone from the forums knows what I’m thinking of entering. 😛
Fascinating. It’s always so cool to be able to read about the development of a game from the ground up. I’ve previously been interested in making games and this is a great look into the mind of the designers and programmers.
Thanks!
Given the problems and solutions that you have encountered I wonder if you would develop the next project in a different order. For example, you realised that there was a better way of doing collision detection whilst writing the editor. Would it have helped to start with the editor, getting the look of what you wanted, then worked towards developing an engine that would meet your designs?
looking forward for your project! But where is N 1.5?
@Barry: We just discussed that yesterday! The problem is that it’s hard to make an editor when you have no idea what you need it to do, and working on the runtime parts helps you figure that out a bit, so there’s some chicken-and-egg.
Having said that we probably could have spent a bit more time upfront trying to figure out how the editor would work, since the scheme it uses is one which we previously (and in hindsight over-hastily) dismissed as impossible to get working.
@13oyg: Unfortunately it’s going to be coming after Robotology is out 🙁
Also, about Contesque submissions, we may consider submissions related to N, rather than N+, if they’re amazing. Send ’em and we’ll see!
This sounds like it’s really coming along! Great news! Do you think a release date could be estimated yet? I cant wait!
If i was the one releasing this game, i would release it with a small fee. a few pounds or something – you’ll deserve it for all of this ^^
Well can you predict when robotology will come out? In couples months, several months? or in couple years?????!!!!!
Please make at least part of this game free…
It’ll be a few months at least.. we’re also very impatient to play it, so we understand where you’re coming from 😉
What I think you both should do is, when you finish a version of the game where all you need left to do is build levels, you should give the few of us who continuously post on here to help build levels for the official release.
Just an idea. 🙂
Sweet a few months is great, (even if it is an “at Best”) I was pegging this as an early 2010 release. The faster the better, so long as it doesn’t sacrifice quality (but I don’t think we have to worry about that 🙂 ). Anyways, you guy have done a great job keeping the info flowing. But like almost everyone else here is probably thinking, nothing is fast enough when it comes to finding out about another game by the Awsome and Incredible creators of N and N+. A beta would be awsome lol, or a demo, or a a gameplay vid, or a screen shot… pretty much anything lol. But ether way, as long as it progresses like it is so far this is going to be one heck of a game. Keep up the way above good work 😀 .
I know I’m being a bit of a nag, but umm… Did you ever figure out what was going on (did Atari get my address, what did they do with it, etc.)?
Now it’s been almost two months…. 🙁
Anyway, what sort of environments will robotology have? I get the impression the graphics will be relatively simplistic, but will all levels have the same basic look (will it be something like N where it’s just plain gray on a lighter gray background?), or will there be multiple tilesets?
Thanks guys, it’s great to know you’re interested in Robotology — we’ll do our best to make it awesome 🙂
@Purple: We’ve emailed Atari several times for you, and they say they’re working on it. We will email you when we get a response!
We’re not sure about environments yet, we have a couple of ideas we need to try before we can decide.. more on that soon though!
OK, thanks!
I was curious, how exactly will physics come into play in Robotology, besides in the grappling hook?
Will there be Gish-like physics puzzles, or something similar?
We don’t know yet 😉
The basic idea was that there will be nothing in the simulation code that distinguishes between “object” and “world”, so moving parts of the world will be moved via motors just like the enemies.
In _theory_ all of the controller code should be agnostic to whether it’s moving a platform up and down or moving a robot’s foot forward and backward, BUT in practice this will probably get cut and we’ll just write task-specific controllers.
Probably not the right place to say this, but thanks for the note you guys wrote in the shirt I bought the other day. It made me respect you both a lot more. You’ve made a valued customer out of me, and I’ll support everything you do.