We’re getting ready to leave for Game Developers Conference 2010, but we wanted to do a quick update before leaving, since it’s been so long since our last post.. as usual.
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.
