With Apologies to Nethack

I took a few hours today to rework parts of the prototype I'm working on. I altered my "cursor" code to allow arbitrary leaps across the tile grid. Then, I augmented the console shell app to visualize where my cursor was, like so:

{2} TileGrid 137
{1} TileGrid 1 @ [16,16]
{0} Tile 649 @ [14,30]





   ############################
   #                          #
   #                          #
   ############               #
     #                        #
     #########                #
        ###                   #
        #                   ###
        #########        ####
           #        ######
           #        #
           #     ####
           #    ##       ####   #
           #         #####  #   #
    ########        ##      #   #
    #              ##   #####   #
    #     ##########   ##     ###
    #     #           ##      #
    #    ##     #######      ##
    #   ##         #       ###
    #   #          #      ##
    #########      #     ##
        #   #      #     #
        #   ########## ###
        #          #   #
        #          #   #
        #     @    #   #
        #     #    #   #
        #     ##   #   #

This shell app lets me use the cursor keys to move around the boundless playfield, digging tunnels as I go. Pretty neat. Each hash mark above is a Tile instance, and all the Tiles are held in TileGrids. The only thing stopping me from putting a U-clamp on an arrow key and letting it go all night is memory. With any luck, that won't be a hurdle for much longer.

The next steps, I think, are to solve serialization and facilitate garbage collection. Every tile grid (the view above is a single grid which may have others adjacent to it) needs to be serializable to disk, but because grids can be nested, serialization and deserialization need to be recursive. Also, because I want tile grids to fetch their children or parent on an as-needed basis, I don't want to just serialize the entire object tree starting from the top-most tier. Instead, I want to serialize a grid as a series of references to other serialized objects. The serializer would decide what parts of the TileGrid graph can be "culled", then write those to disk and reclamate their memory. The deserializer would lookup and deserialize only the grids it thought it needed to satisfy a particular view.

If I can get that IO working, then I need to figure out how/if to apply WeakReferences to the linkages between grids and tiles, so that the garbage collector is free to collect tiles that, for whatever reason, are deemed "unnecessary" for rendering. Experimenting with applying garbage collection to this kind of playfield is something I'm itching to do. Building a playfield manager (playfield = memory) that's smart enough to know what needs to be held and what can be released will be a fun challenge; I haven't done that before.

I can envision a solution that involves a mark & collect approach: start with the grid on which the player cursor resides, and climb the TileGrid tree, marking each TileGrid until the top is reached. Then allow the serializer to write out all "unseen" tilegrids to disk. The approach could be tweaked with different heuristics that aim to keep in-memory a working set of TileGrids relevant to the player's view or movement direction.

Status Update and "The Long Zoom"

This is my first post in quite some time, and unfortunately someone else's work inspired me to write it, rather than my own.

Stephen Johnson has written an interesting piece for the New York Times called "The Long Zoom". In it, he discusses conversations he had with Will Wright about Spore as a game and a philosophy. I recommend reading it.

What about Vyde? There's good news and bad news. The good news is that since my last post I have written some code. The bad news is that it's only a console application demonstrating my idea for a boundless tile grid. On the outside, it's not terribly interesting, and it's generated more questions about the approach's value than it's answered.

I think about Vyde every day, but life has gone and gotten busy. I have this great girlfriend with whom I spend a lot of time, and as a couple we spend a lot of time doing couple things. So when I have free time, I'm typically so tired that I just end up playing WoW (Ramshackle/Anvilmar) for an hour or two.

So, Vyde is still, for the most part, a picture in my head. I've setup a Subversion repository to hold the technology prototypes I've been working on, but I still consider myself to be early in the design phase.

My most significant decision lately has been to settle on the shape of Vyde's first public appearance. I'm going to build a web application to exercise the tile engine, dependent on an ASP.NET web service. In my mind's eye, I envision a simple tile-based playfield in which multiple clients can move around and "dig". My thinking so far leads me to believe that, forgiving some concurrency issues, this probably won't be too difficult to pull off. The hardest part will be coming up with some art assets to use for the tiles.

At this rate, it's hard to imagine ever being "done" with Vyde, but I keep telling myself it's a hobby. You could argue that it's better to have a perpetual hobby than one which will end predictably.