This post is the first of a series wherein we’ll try to get everyone up to speed on what the hell we’ve been doing in the 3 years which have elapsed since we made N.
Also, we’re new to this whole blogging thing, so please bear with us as we attempt to find a suitable writing style.. there’s so much “back story” to Robotology that it might take several posts just to get to the present. Finally, we’re not sure if this sort of post is going to be interesting or not — reading other indie developer’s blogs (see links on the right panel) is appealing to us, both as gamers and peers, as it provides all sorts of interesting information. So, we’re going to give it a shot — please let us know if you have any suggestions.
And so, it begins:
We’ve been working on Robotology since early 2006; while it’s still nowhere near complete, we have made quite a bit of progress.
Our initial design concept was simple — a 2d physics-based platformer where the player has a grappling hook/rope that can be used to interact with the world. This concept had been in the back of our minds, not coincidentally, ever since we came across the SNES title Umihara Kawase, which might be described as “a 2d physics-based platformer where the player has a grappling hook/rope that can be used to interact with the world”.
Our intention wasn’t to clone Umihara, because frankly we don’t think it’s all that much fun: the player’s movement is too slow/boring, the springy nature of the rope is too random, and in general one can’t help but have a strong sense of “this should be an immensely entertaining game, but just isn’t for some reason”. Despite its flaws, Umihara is still interesting/intriguing enough to bring me back for a bit of rope-based platforming every few months — proof of the premise’s promising potential, as it were.
This ties in to our modus operandi, the game development analog of (Douglas Adams’) Dirk Gently’s method of “Zen navigation”: start out trying to clone an existing game, but end up getting side-tracked as ideas are suggested by the in-development technology.
This strategy is incredibly useful in that you begin the development process with the best of all possible design documents — a fully functioning game. That makes it very easy to nail down exactly what sort of technology you need to build, which is great if, like us, software engineering and design specification isn’t your strength; the hard problem of “what do we need to build” is made much simpler, leaving only the problem of “how do we build it”, which is much less daunting.
Of course, once you’ve got that technology working, chances are that you’ll find uses for it that are much more interesting than those you originally intended. This probably works better if the game you use as a starting point is at least somewhat interesting, novel, or weird.
Tangential asides aside, Umihara was tragically ahead of its time — it definitely pushed the envelope of what you could do on an SNES back in the day, but didn’t quite realize the full potential of rope-platforming. Maybe it was the silly walking-fish enemies..
Or, perhaps it would be more precise to say that it is our more sincere hope that, provided we do a good job of Robotology, Umihara will be seen as tragically ahead of its tim. And also its time.