We're Moving!

From now on, I'm going to be blogging about Vyde at http://www.object01.com/, where I've started a more general blog about other things I'm interested in. I'm going to intersperse Vyde posts among the rest, because I anticipate my posting frequency to drop even lower than it already is. (That, and I think dasBlog is a much better blogging platform than Blogger.)

I've been thinking a lot lately about how this blog failed to motivate me. In a weird way, I think it actually slowed me down; I think I rationalized not doing small things because they didn't seem worth posting to the blog.

So I'm chalking it up as a failed experiment. Shrug. Life goes on.

Working Set Prototype in Silverlight

I wanted to implement a simple prototype that implemented the kind of working set that Vyde will probably use. It's available at http://object01.dyndns.org/vyde01/. I implemented it in Silverlight and learned a few things along the way.

After my last post I decided to stick with simple integer coordinate systems. This visual aid really drives home the fact that it would take a long time to reach the world's edges; more than enough time to develop a better coordinate system that pushes that boundary out much farther.

Silverlight is interesting. It has just as many idiosyncrasies as Flash, and some are even less intuitive. I spent most of my time in "Intellisense discovery" mode, hitting that trusty period key and Ctrl+Shift+Space to try and learn what operations made sense in a given context.

So far, the most unintuitive thing I've seen is the pattern of using, say, a Canvas.Top attribute on a rectangle element to position that rectangle's top edge. It doesn't fit with the other patterns they've established in Silverlight, like encapsulating objects inside tags representing operations to be done to those objects, like <Border>, or using a simple attribute (like just "Top") to get the idea across. Why they had to involve another namespace I don't know. It makes me ask all sorts of questions, like what would happen if the Rectangle weren't in a Canvas? Can a Rectangle not be in a Canvas?

Despite the awkwardness that I think stems from a serious lack of documentation, being able to implement this piece of code in C# with full Visual Studio 2008 IDE support was a delight.

Getting it to work in IIS7, however, was a pain. The new IIS7 administration tool is so much different than its IIS6 predecessor. Not only are all the day-to-day operations located in different places, but the whole model for the web server and its applications has changed. It doesn't seem to be as simple as "drop a folder into wwwroot, configure it as an application." Doing that prevented my app from seeing the Silverlight assembly. Very strange.

Anyway, enough about my environment wrestling. This is the first real progress I've made toward a playable Vyde in a long time, and it feels good. This gives me a real jumping-off point for something a little more visually appealing, like maybe a random maze generator. If I could fill these white screens with more interesting tile-based rooms, it'd be a snap to persist them to a server and let people like you push the world outward farther and farther. It'd be interesting then to draw a big overview map after a month or two to see what directions people went in.

And of course, until I get a better coordinate system implemented, I'll have to implement a fence for those clever ones out there who take C-clamps to their arrow keys.

A Coordinate Puzzler

Say the Vyde universe is expressed in a 2D coordinate system designed to faciliate indefinite expansion in all directions. Further assume that it's a multiplayer game, and one person in a two-person group wants to see an arrow on their screen pointing in the direction of the other. In what ways might the orientation of the arrow be calculated?

If the coordinate system were simply integers, that'd work fine. And fortunately there are specialized types (F# has BigInt) that facilitate arbitrarily large integers. But what if the system needed to be more complex, as hinted at in the last post? What is necessary to faciliate such an indicator in the game's interface?

Bionic Commando: Rearmed

All fans of the classic Bionic Commando on the NES must see Bionic Commando: Rearmed, the 2D remake that accompanies the new 3D rendition being produced by Capcom.

What a good choice for a remake. What a good decision to make a remake!

Back to Work

So I got married back in November, and after than we had Thanksgiving and Christmas. My time since then has been spent catching up at work and making the first motions toward buying a house. (Oh, and I got a Wii.)

Now that my wife and I are in a conservative spending mode we're spending a lot of time at home. This affords me a lot of time to either play video games or spend time working on one. It's high time I got back to work on Vyde.

I've been spending a lot of time lately thinking about how to facilitate an infinite 2D playfield. It's a problem of address space: how do you address any point in space in an infinite space? My first instinct was to find a way to organize space such that addressing a point was a matter of first finding an area containing that point, then addressing a smaller area within that area, and so on until you arrived at the point you desired. This was the principle behind my most recent prototype&emdash;it worked alright and facilitated very fast jumps through space of arbitrary lengths.

The Quadtree Approach

That approach was powered by a kind of quadtree. But rather than concentrating on subdividing an existing space like so many quadtree algorithms do, I wanted to grow the quadtree from the inside out: as additional "world" was created the quadtree would add another level to its hierarchy to contain it.

I wondered about how I'd store a world expressed in this way: when it comes time to persist the world to disk, how do you write it? The quadtree was divided into nodes and leaves, with nodes being areas containing smaller areas and leaves being some concrete piece of world, maybe about as large as a screenshot. I thought I could write the nodes and leaves to disk such that each "file" had a notion of its children and parent. From such a (spatially indexed) filesystem I could rebuild the world when it came time to load a new game.

Then I wondered about how I'd work with such a playfield in memory. A 2D side-scrolling game needs some concept of a working set: those "tiles" of the world that are kept handy in memory in case the player revisits them. As the player moves through the world, that working set has to be updated without interfering with gameplay. So my attention turned to addressing not just a single point in space, but an area of the world: something that would be returned from a call to a method like, .GetTilesSurroundingPlayer().

All this thinking about complicated data structures overwhelmed me. But the exercise proved worth doing: eventually all that thought helped me realize (once again) that I was making things too complicated. It dawned on me that I was confusing a storage system with a coordinate system, and it further occurred to me that indexing&emdash;being able to quickly locate a piece of data&emdash;is a layer on top of storage.

Storage

Storage of the world need not be complex. Individual areas, each of an arbitrary size, can be stored on a regular filesystem as files, folders, or whatever; the format of the bits that manifest themselves into a piece of the world isn't especially important (yet). How they're organized on disk is also a decision that can be deferred until later.

What's important is that there can potentially be an infinite number of "pieces," and whatever storage mechanism stores them must accommodate that. But of course there's no kind of storage today that can do that. Modern file systems are limited in the number of files they can store, hard drives are limited in size overall, etc.

Instead of solidifying a storage system now, what I need to get the game going is an intermediate layer that abstracts it all away. As additional storage is necessary, that layer can be changed: augmented with additional address space, media support, etc.

Coordinates

In a 2D world, even an infinite one, any point in space can be described using two coordinates: X and Y. When people think about 2D coordinate systems, X and Y's typically assume an integral or floating-point type. But as this discussion of Dungeon Siege describes, a coordinate need not be a single number. It may instead be a more complex data structure.

So, to address a point in an infinite world I need a coordinate system where a single dimension can extend forever and remain addressable. Again, abstraction to the rescue. I don't have to invent that now; I can abstract it away with something that, say, for now only uses integers to describe X and Y. As the game evolves, a cell whose position was once was described as [874338,9713424] might be described with four XML files that locate that cell on a distributed storage system.

Indexing

If the world can be chopped up into small areas that are each addressable and storable, then maintaining performant lookups of these areas becomes my central concern. I learn more and more all the time about how relational databases build their indexes and the constraints placed upon the data's organization on disk. This is a topic that will take a great deal of time to school myself in, but I think it'll be an important part of the game's architecture. Right now, I think I can safely ignore it. With properly-abstracted coordinate and storage systems in place, I think indexing would be a layer sandwiched between them.

Crafting the World

The problem I'm focused on most lately has to do with how I'll craft the tunnels and caverns of Vyde when the canvas is comprised of these individual areas. More on that later.

For now, I'd like to focus on building another proof-of-concept. This one will allow the player to move through an empty space, creating new areas or loading existing areas as necessary.

Portal Complete!

It's almost worth the $20.00 just for what you hear at the end. :)

Portal available by itself!

Portal is now available standalone from Steam, outside any bundle, for $19.95. I've been looking forward to this one ever since I played the game that brought the idea (and its developers) to Valve, Narbacular Drop.

Spore on TED Talks

A new TED Talk features Will Wright giving another demonstration of Spore: http://www.ted.com/talks/view/id/146.

Gameplay Powerups

Super Metroid had one of the greatest power ups I've ever known in a 2D platform game: the x-ray scope. Once you acquired it, you were able to scan your immediate area for invisible holes that led to other areas you previously had no idea existed.

This powerup—and lots of other powerups from days gone by—added a gameplay element. You all-of-a-sudden had an ability you didn't have before. Perhaps more importantly, it added a gameplay element well into (~50%?) the game. But to my mind, Super Metroid powerups demonstrated something that other games at the time didn't "get": powerups can extend the life of the game. A powerup can make the player want to re-explore the entire world. Isn't that powerful?

Unfortunately, even Super Metroid didn't fully exploit this property of powerups. The x-ray scope was more a necessity for completing the game than a novelty. Precious few areas had any discoverable chambers that existed only to be explored for exploration's sake. (Not to mention that the Metroid games never really had any concept of "plunder" or loot, like coins or trophies that would make the discoverable areas worth exploring.)

But what happened to gameplay powerups? Today the word "powerup" borders on being obsolete. Instead, most games tend to focus on attaining better versions of existing equipment: a better gun, a better sword, better armor, etc.

The last time I saw a gameplay powerup that seemed to have untapped potential was when I played Super Paper Mario; the magical 3D wand was such a clever bit, but again, it was a necessity, and may not have lended itself well to being introduced late in the game.

I'd like Vyde to place a special emphasis on exploring powerups as a link between the player and the environment. I want Vyde to have powerups that make you want to re-explore and experiment with the world. I'd like to invent powerups that aren't designed to allow you to reach your one-and-only goal (finishing the game), but are instead designed to extrude the world into another dimension of play for play's sake.

After all, as has been hinted at already, a boundless game makes for some serious challenges in keeping the player engaged.

Next, I'm going to wax philosophic on the concept of loot in games.

Yes, We're Open! Please Call Again.

I know, it's been almost a year since I posted anything. Right when I was about to, I went and got engaged (http://www.heatherandjeffgetmarried.com/). I'm still thinking about Vyde, and have even wrote a little bit more code. I've been wrestling with how to pull of a framework for a playfield "working set", and I've kind of thrown out the object model most recently demonstrated here. (I was confusing a storage system with a coordinate system.) But since my last post I've come down with a bout of paranoia about releasing ideas to the public. I mean, they seem like pretty good ideas. It'd be a shame if somebody, you know, patented them for fun. Getting married is hard work. Thanks to the one of you who still read this, I suppose. (You know who you are, Tim. You're a gentleman and a scholar with a worldly knowledge of RSS. Good show!)