Vyde

We're Moving!

2008-07-26T23:11:00.003-05:00

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

2008-04-06T10:36:00.002-05:00

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

2008-02-07T20:01:00.000-06:00

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

2008-02-01T07:08:00.000-06:00

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

2008-01-26T09:13:00.000-06:00

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!

2007-10-13T12:20:00.000-05:00

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

Portal available by itself!

2007-10-12T06:55:00.000-05:00

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

2007-07-17T13:48:00.000-05:00

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

Gameplay Powerups

2007-07-14T11:40:00.000-05:00

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.

2007-07-06T23:29:00.001-05:00

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!)

With Apologies to Nethack

2006-10-15T20:28:00.000-05:00

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"

2006-10-11T05:53:00.000-05:00

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.

Evolutionary Gaming

2006-05-22T21:59:00.000-05:00

I've been fascinated recently with evolutionary/genetic algorithms. My favorite, of course, is electric sheep, but today I caught glimpse of a simpler one, Evolve.

This kind of approach to dynamism got me thinking about how social voting algorithms could be worked into a game. To have a game (single-player or multiplayer) tune itself to the player's desires would be fantastic, surely. But forcing the player to submit a vote explicitly is a bit much. Instead, what mechanisms could be used to imbue the engine with the capacity to observe the player and tune something (the physics, the environment, the textures) according to the player's tastes?

I find myself thinking about how much I dislike desert levels in games. I hated it in all the Star Wars games that ever used Tatooine, I hated it in Diablo II, I hated it in Ratchet and Clank... I just hate desert levels. But whether it's the sense of dryness, the wasteland quality, or just that piss orange color, should the engine be able to detect that I don't like it?

In a game like Vyde, the player will ideally encounter areas having many different themes. Travel far enough, and you may encounter a fire cave, then an ice cave, then a rainforest cave, not necessarily in that order. But can't something be said about the users that deliberately avoid certain types of areas? If a player repeatedly encounters a fire cave and retreats within sight of it, can't the engine assume that that user just doesn't like (i.e. won't play through) fire caves? And if that assertion can be made, wouldn't it make for better gameplay if the engine tunes itself to avoid that type of level? (This assumes, of course, that we're talking about an engine whose responsibilities include randomly generating territories, but the principle could've easily been applied to, say, the random item generation algorithms that drove the Diablo series or even Nethack.)

I want Vyde to be procedural to an unprecedented degree. Though Spore may beat me to it, I'd still like Vyde to have self-tuning capabilities that make it possible to encounter variations on themes based on the areas I choose to explore.

The system itself shouldn't be hard to implement. The engine would keep counters related to the number of times a user encountered a certain type of area. An encounter would be defined as, well, the event that occurs when the engine decides to switch themes in response to a freshly-broken tile. Even if the engine is capable of creating an infinite variety of areas, it can cull old tallies and maintain some kind of cache of "recently explored themes" that it can use to govern its future theme-choosing behaviors.

Projects like electric sheep and Evolve always make me wonder if, given enough participation, an "ideal" result could emerge. I'm still reading Emergence by Stephen Johnson, and even in my humble capacity as a hobbyist I feel obligated to recommend it to all game designers.

There is a terribly encouraging trend emerging in the capability of hardware to outthink its users, and when applied to gaming, it isn't hard to imagine a day when a game can rework itself to a player's tastes. Could we be so bold as to assume that it would increase the marketability of replayability?

Progress Report

2006-05-21T17:41:00.000-05:00

This post is actually quite a bit late, as the prototype described here was completed a few weeks ago at least. But life has been hammering, hammering, hammering at my free time. I wanted to dedicate the proper amount of time to this post.

My goal for this first prototype was to create a simple console application that would let me move a "cursor" around a grid of tiles that would expand as needed. The cursor would be capable of moving only up, down, left, or right based on which arrow key was pressed. At each step, a printout of the cursor's location would describe what tile it resided upon and what that tile's relationship to its parent grid was.

The object model for this prototype works something like this:

The "world" in the prototype is comprised of Tile instances. TileGrids are special kinds of Tiles that contain other tiles. I thought it was clearer to make the distinction rather than just have Tiles contain other Tiles. It makes type checking a little easier and makes the code a bit more readable overall.

Every Tile instance can be parented by a TileGrid. A new TileGrid is created whenever the cursor attempts to move away from an unparented Tile or when it crossed the edge of a TileGrid.

The TileCursor calls the TileMunger's encapsulate function when either kind of movement occurs, causing a specific Tile instance to be parented by a new TileGrid and placed within the new TileGrid's list of Tiles. As the cursor moves farther and farther away from its origin Tile, more and more TileGrids are created in a recursive fashion.

A given tile is parented by some grid, which may be parented by another grid, which may be parented by another grid, etc. This grid hierarchy is organized into "tiers" that the cursor traverses to move among the tiles. When the cursor is told to move across the edge of a grid, it "ascends" the tier hierarchy until it is able to move without crossing an edge. At each step, the TileCursor has the TileMunger create a new parent grid if necessary. When it's high enough, the cursor moves in the requested direction, and descends again until it rests on the same tier on which it started, making sure to adjust its position at each step to correspond to its original position along the original grid's edge. As it descends, the cursor has the TileMunger subdivide tiles to create the necessary grids.

In this prototype, each grid is 3x3 tiles in area. Each grid has a coordiante system with [0,0] in its upper-left corner. The screenshot above shows a cursor starting in the center of a new TileGrid, at position [1,1]. It then moves one tile south, to position [1,2]. When I tell it to move south again, two things occur: a new TileGrid is created on tier 2, and a new TileGrid is created south of the original grid on tier 1. The grid at tier 2 parents the two grids on tier 1. (I don't really have a good illustration of this yet — that's the next step in the prototype.)

The code to make all this happen is short, but not easy to follow. Most of the work is done in TileCursor.Move(), which works recursively.

What bugs me about this prototype is how intertwined all the components are. I don't like that the TileCursor calls TileMunger methods, i.e. that it is responsible for altering the world. I'd rather the TileCursor be responsible only for hopping from tile to tile, without having the responsibility of initiating the creation of new elements in the world. I think future designs will repurpose the TileCursor to be a "digger" that really is responsible for altering the world. Or, perhaps I'll assign more responsibility to the TileMunger class; but what will invoke it?

I want exactly one class to be responsible for creating new grids and populating those grids with tiles. The TileCursor is not a candidate class, as it should, semantically, be responsible only for pointing to a specific Tile, providing facilites for moving from tile to tile. Currently the TileCursor is limited to north,south,east,west movements in 1-tile hops. I want to eventually create a Move(dx, dy) method, but the current world growth algorithm doesn't facilitate that very well.

I'm worried that I'll get to a point where my cursor movement algorithm will flow something like this:

Does a tile exist south of the current tile?
{perform lots of calculations to "hop" to that cell and find no tile}
If not, create a tile south of the current tile.
{perform many of the same calculations to "hop" to that same cell, create a tile tile there, and return the new tile}
Move to the new tile

Looking at it now, I think I can refactor it into something I'm happy with.

Looking ahead, the next step is to create a GUI that actually renders the tiles that have been created. The first GUI would likely plot only those tiles that occupy tier 0, but I haven't figured out how to start the algorithm. I can't figure out yet where the recursion starts, whether it's on a tier 1 grid or a grid on some arbitrary tier. One problem I'm faced with is translating this nested coordinate system into a normal coordinate system understandable by, say, the System.Drawing API. But I think I can solve that pretty easily by building something that traverses an arbitrary grid and aggregates all tier-x tiles in that grid's hierarchy into a simplified 2D array that can be rendered.

If I can get the tiles at tier 0 plotted onto a canvas, I'd like to then illustrate the creation of grids by painting them as semi-transparent layers on the canvas.

Then, I'll turn my attention to prepopulating the grids with content for the TileCursor to move over, like ore veins. :)

Game, Set, Vyde

2006-04-21T20:45:00.000-05:00

I've been dating a girl named Heather since last Christmas, and she's pretty cool.

She's pretty cool for lots of reasons, but mostly because she plays tennis.

See, when we started dating, I seemed to run out of time for anything else. So no work on Vyde! She got hooked on Lost, so lots of our free time has been taken up catching her up from the beginning. We have Netflix to thank for that.

I don't play tennis. This is important, because it means that I can watch her play tennis instead. I find that watching tennis is a lot more fun than I thought it'd be. It's especially fun when she plays, 'cause she's a power hitter, and there are some ESPN-worthy moments when she's diving for the ball or returning it in a way that makes me glad I'm not in the ball's path.

She plays tennis 2-3 times a week, and I have a laptop. This represents a dilemma, because I can either watch her play tennis, which she likes, or take the opportunity to prototype some Vyde ideas outside in the spring air.

She seems to like me being there either way, so maybe it's not as much of a dilemma as I think. After all, she's been bugging me to mention her in my Vyde ("veed", she says) blog. I wonder if I throw her some props now and then if she'll continue to be OK with me working on a laptop while she plays tennis...

Over-engineering

2006-04-10T21:08:00.000-05:00

So BlackTigerX says in his most recent comment that what I described in my last post is a case of over-engineering (with a hyphen, 'cause that's what turned up the most results when I Googled it). He's very right, and not being acquainted with me he probably has no idea how funny his observation is.

My tendency to over-engineer is dramatic. Always has been. Perhaps it's a character flaw, but I tend to like to figure things out before I attempt them.

I will often spend a significant amount of energy just thinking about a problem. I suspect many folks look at me and think, "Why doesn't he just try something? Anything?"

The answer is this: because when I do that -- try something just to see what happens -- I invariably throw out the result. The reason is always the same, too. Invariably, without digression, I run up against that "something I didn't think about" that causes my whole mental model up to that point to collapse.

Mix that behavior pattern into the feedback loop where it combines with over-engineering, and you will have undoubtedly spent twice too much time trying something that proved useless.

I've done this too many times to repeat it anymore, so now I tend to just think about the problem. That way, I reason, I will run into those showstoppers in my head, where the cost of failure runs no more than that of a still-maleable mental model modified.

But I adjusted my strategy lately. I'm trying to make a concerted effort to break problems down into more manageable chunks. I'm doing it both at work and at play. Some of the results have been encouraging: I find that I'm spending more time working on Vyde now that I have a more concise set of immediate goals. But I also find the results a little troubling: with less design and more attempts, I've found that I'm throwing out solutions and then repeating those mistakes in a different way later. Though rejected attempts seem to spur a new line of reasoning, I think it may be an illusion, as the new path tends to run up against the same problem more often than not. You'd think that taking a different approach would lead to at least a different kind of problem, but no, the problem I didn't take the time to think through the first time shows up again. I think this lends some credence to the idea that design really is worth doing, and over-engineering is something to reduce, not eliminate.

I've noticed a similar pattern at work. There come times when my complicated designs get the better of me. Today, for instance, I all-of-a-sudden felt overwhelmed by the complexity of my current project. Specifically, my ability to unit test has reached a plateau: building in layers seems to lead to testing procedures for higher-level constructs requiring a lot of low-level legwork. That is, if an instance is created as a product of low-level code, my unit tests for higher-level operations on than instance require building the instance from scratch.

Wait. I'm doing it again, aren't I?

Perfection is the Enemy of Completion

2006-04-06T19:50:00.000-05:00

It's true. So why must perfection be so damn attractive?

I've been thinking a lot about Vyde despite the lack of blog posts. The problem is that I'm wrapped up in creating an elegant system that I'm losing interest in building a game around it.

This is a trend that's showing up a lot lately. I'm finding I have to keep myself in check lest I get lost in problems that I arguably create myself.

Most recently, in Vyde's design, I've been wrestling with something that most other game developers would probably find trivial: a tiling system. How do I want to represent the tiles that makeup Vyde's playfield? How do I want to generate random patterns? How do I want to persist generated maps to disk?

OK, so those are the simple problems. Then I stem off additional problems from those: should tiles be composable? Should I be able to zoom into a tile and have it generate its own innards in a pseudo-fractal fashion? Could such a system be used to allow the camera to zoom into the insects crawling along the cave walls, allowing the player to see how the insects dig?

How should I build the system that generates and connects parametric, randomized geographic features? Considering I want to be able to hand-craft special rooms and have the game consume them, and that I want to be able to apply "random" features as the game chooses, does that demand a common superclass? Assuming it does, do I need to come up with a "painting" paradigm that is analagous to the way you paint onto a Bitmap object using the Graphics class? Should I develop an "applicator" class that applies features from a factory into a region I specify?

How are regions connected? Do hand-crafted rooms need to have connector regions specified so that the random tunnel generator knows where to "connect" to the room? And how to I plug in different tunnel generation strategies into the generator? Is this a job for a factory pattern or a strategy pattern? Or both?

And if a room is placed on a seam between two sectors, is it the applicator class's job to figure out what to draw in one sector and what to draw in another?

And what happens if the room has some kind of special behavior attached to it? How do you reconcile the room being split into two pieces on the map if it spans multiple sectors? If the tiles are composable and every tile has its location specified as an offset from its parent tile's upper-left corner, then is a room really a subtile located at some offset from its parent? Does this demand variable-size sectors?

And if so, what are the implications of drawing graphics if their coordinate system is variable? If the world runs in all directions infinitely, how do you specify a coordinate system using finite numbers, and how can you nest coordintae systems to facilitate the zooming mentioned above? The "world tile" might have to be parented on-the-fly when the player crosses the edge of the last available tile...

Oh wait... how do you make a tiling system?

Spore: A Future Direction in Sandbox Games

2006-03-11T00:41:00.000-06:00

Everyone should go look at http://video.google.com/videoplay?docid=8372603330420559198&q=spore. This is an amazing video that I was pointed to by my friend Tim. I must be seriously out of touch with the game industry lately, 'cause I had no idea this game was even in the works. I am breathless with anticipation for this game, which is scheduled to be released Q4 2006.

GameProducer.Net

2006-01-03T21:31:00.000-06:00

Found an interesting blog the other day: GameProducer.net. Though I don't necessarily agree with his views on when to give / not give out freebies, it still looks like a well-done site.

Vyde + RSS + OPML = Vrississopemihl

2006-01-02T00:17:00.000-06:00

I've mentioned a couple of times now how I'd like Vyde to be extensible, and even have a web-based component for things like software updates and mod distribution. Today it occured to me that developers could use RSS to broadcast the existence of new mods or updated mods, and the Vyde client could be told to subscribe to OPML files — published online by developers or enthusiasts, or compiled locally in an editor — thereby allowing players to roll their own "option package" for Vyde.

Here's a use case:

I'm Jeff, and I play Vyde. I am also a developer, and make a Vyde package available on my site that contains some hand-crafted rooms for inclusion in Vyde's random map generator. I've also got a less popular mod that contains some cheat codes of my own design.
I have a friend, Danny, who also develops add-ons for Vyde. He makes a package that contains a +3 laser drill item for inclusion by the Vyde world generator.
Danny has a friend, Chris, who publishes a story add-on for Vyde. It adds text for certain NPCs that advances a bizarre story.
The most current version of my mods available at http://www.vyde.com/pub/mods/2005-11-04/churches.vpk and http://www.vyde.com/pub/mods/2006-01-01/hotcoffee.vpk.
The most current version of Danny's mod is available at http://www.danpack.net/vydemods/laserdrill.vpk.
I publish an RSS feed at http://www.vyde.com/pub/mods/currentmods.xml that contains pointers to my most current mods. I also publish an OPML file at http://www.vyde.com/pub/jeffvyde.opml that points to my RSS feed and Danny's RSS feed.
Danny publishes an RSS feed for his most recent mod at http://www.danpack.net/vydemods/list.xml. He also publishes an OPML file at http://www.danpack.net/dannysvyde133tness.opml that points to his RSS feed, my OPML file, and his friend Chris's RSS feed.
I like to play Vyde using my own add-ons and Danny's add-on. But I don't like Chris's add-on because it isn't canon. So I configure my Vyde client to tune into my OPML file, which excludes Chris's RSS feed. When I play, I get a church room, some cheat codes, and Danny's +3 laser drill, but no story modifications.
Danny likes to play Vyde using his own add-ons, mine, and Chris's. He configures his Vyde client to run off his OPML file. He gets my church room, my cheat codes, his +3 laser drill, and Chris's story modifications.
All Vyde players tailor the game's mods to their tastes. Everybody gets the most recent mods as long as the developers keep their RSS feeds up to date, and those who like to clone others' play styles just use the public OMPL files.
They praise me for my game's modability and send me presents in the mail.

I like this idea, but of course it's pretty far away. Who knows what the RSS/OPML crusaders will have done by the time I get to this point.

Problemoid #1: Unified Environmental Feedback Architecture

2006-01-01T23:43:00.000-06:00

Happy New Year to all. I'm going to start making mini-posts that I'll call problemoids. They'll have a number and a kneejerk name assigned to them. These are visions of finished-product I have in my head that demand some kind of design or implementation decision.

Today's problemoid is as follows. Given a random feature in a map, that feature will have attributes and contain objects having attributes that should be affected by some relation the feature has with the rest of the map. For instance, a randomly generated tunnel may have a "dripper" prop placed in it — a little scenery touch that shows some water drops falling from the ceiling to the ground, probably resulting in a moody "bloop" sound effect. But whether or not a dripper appears may depend on several factors, perhaps the humidity value assigned to that region of the map or the temperature in an ice-themed feature (higher temperature = ice melting = more drippers). The attributes upon which the prop's creation depends must be expressed in a uniform way so that the dripper creator and other interested factories can tap into them, especially when developers decide they want their hand-crafted features to take on some dynamic morphology. I want the environment to have a feedback mechanism.

How do I create a unified attribute exposure/consumption architecture? What's a good way to expose actionable attributes to the API for use by me and others who extend Vyde later? Are we talking about every actor in the engine having a collection of "VydeAttribute" objects that can be reflected upon, queried, etc. by the factory? Or perhaps invert the control and have the factory's creator inject the attributes and the formulas that consume them into the factory when it's instantiated?

Falling Sand Game

2005-12-26T04:17:00.000-06:00

I just spent 3 hours playing with this.

Random Generation Framework

2005-12-24T11:59:00.000-06:00

So I set out last night to continue working on the "feature painting" design, then got really sidetracked into the wonderful world of random number generation.

This is the class diagram I was messing around with. The original idea was to use this as an opportunity to experiment with generics, so I started with an abstract, generic RandomGenerator<T> class that would, conceptually, serve as a top-level class for producing random things. To create random numbers, I'd implement a RandomGenerator<int> or RandomGenerator<float>. But I also wanted to create random tiles or features as well. In fact, I'll eventually want to be able to randomize virtually any property of the game.

I just had an idea. Just now.

Anyway, I said to myself, "OK, this is good kind of class to have. Making it generic will serve to benefit me later if I build other generics that accept RandomGenerators." But then I started to realize that numbers, tiles, features, etc. don't all fit into the same classification of selectable things...

While I was thinking about implementing RandomGenerators for int and float types, it occured to me that I will probably want the ability to define, at runtime, a strategy by which the RandomGenerator chooses what numbers to output. That got me investigating probability distributions, and I learned plenty of fascinating things about discrete and continuous distributions and how greek they are. But the fact remained that, at least when choosing numbers, I'd like to be able to affect the selection by somehow instructing the RandomGenerator to use a uniform, logarithmic, Poisson — whatever — distribution.

But how to you apply such distributions to collections of tiles or features? Does it make semantic sense to say, "choose from among these objects using a uniform distribution?" Yes, in that case every object in the set has an identical probability of being selected. But I can't make semantic sense out of "choose from among these objects using a logarithmic distribution." To me, with my earthworm-like understanding of probability, such an action requires a sorted list. But how do you sort a list of tiles?

It occured to me that when selecting from a list of objects like tiles or features, the list in question will likely be a collection of object/probability pairs, not just object references. Each entry in the collection (Dictionary<Type, float>?) would identify a thing (unique to the set) and a probability that that thing will be chosen if something is selecting things from the set. This seems like a good idea, but I still can't wrap the idea of a logarithmic distribution around it. In this case, it seems like accomplishing a logarithmic distribution would be a matter of defining the pairs' probabilities according to a logarithmic curve. That makes defining the probabilities my responsibility, and as I'm sure you all know I don't like to work when I can get a computer to do it for me.

So I'm stuck on this: how do I come up with the RandomGenerator<T> class I seek? How do I make it so simple that all the user (me now or plugin developers later) has to do is implement (or if I make the class concrete, instantiate) RandomGenerator<WHATEVER> and get something useful out of that?

The diagram above is a fractured representation of my thoughts last night. I was trying to create an abstraction above the idea of a set and a continuum, and have that abstraction (a "source") serve as the pool from which a RandomGenerator selects its output. But ultimately I ran into this wall: a generator of random numbers is fundamentally a different engine that a random selector of things from a set. But I'm not sure they should be. I'm trying to get over this wall at the moment.

Faced with this problem, I decided to take a step back and regroup my thoughts. I could spend the next several months coming up with a really cool random generation framework, but I'm still itching to have a tech demo of a map generator. These are the thoughts I had. Clearly I couldn't completely tear myself away from the problem.

I'm obsessive like that.

vyde.com + object01.*

2005-12-24T11:53:00.000-06:00

Just registered vyde.com and my own personal object01.com and .info domains. The latter will be used later next year when I finally get around to setting up a media server from what will be my new house.

There But For the Grace of CLS Go We

2005-12-23T17:19:00.000-06:00

I am once again pissed off that the .NET CLS doesn't seem to have a concept of an unsigned integer. This is just ridiculous. I want the Vyde API to be CLS-compliant so others have a broader variety of language choices, but all the unsigned types are non-CLS-compliant. Having to define all my coordinate spaces in terms of negative-thru-positive is just annoying. Who the hell needs negative numbers anyway? I mean really, WTF?

Maze Algorithms

2005-12-20T22:01:00.000-06:00

By the way, here's the link to the page I mentioned describing various maze algorithms: http://www.astrolog.org/labyrnth/algrithm.htm.

Wrath Lands Tutorials

2005-12-20T21:59:00.000-06:00

Spotted this set of tutorials on Digg today: http://www.rdxgames.net/projects/wrathlands/index.html. These tutorials discuss the creation of a text-based RPG created in C++.

Gyoop-Gyoop-Gyoop

2005-12-19T23:12:00.000-06:00

Had an interesting thought while watching King Kong this evening. In the spirit of Super Mario Bros., why not have Vyde randomly insert sub-caves within the map? These would likely appear as open or unlockable doors — discoverable by happenstance or by uncovering them — that the player would press Up to enter, and contain some kind of bonus room or other interesting feature.

Cave Drawings

2005-12-18T15:18:00.000-06:00

So here's the plan. What I want to do for my first piece of code is create a rudimentary random cave generator whose results can be rendered to a simple bitmap. I want to be able to create an image (2 colors probably -- black and brown) that resembles the tunnels you might find in an ant farm.

To that end, the diagrams you saw in the last post represent my first approach toward the objects that I'm thinking about for implementing this project. I'm a big believer in designing complex even if results are simple, 'cause that usually makes for the most reusable code, which leads to quicker development over the long term.

The composable tiles thing could be tricky. By having every tile in the game potentially comprised of other tiles, and every tile itself potentially a member of a greater tile, I hope to have a tile / map architecture that allows the following features:

Pseudo-fractal map expandability: while a traditional tile-based map is limited in 2 dimensions by the coordinates describing the tiles' positions, adding this other dimension (the w axis, let's say) lets me describe any tile as being located at some offset within a parent tile's coordinate space, which in turn is located at some offset within a parent tile's coordinate space, and so on. Everything can be described as offsets of offsets, with the only "anchor" being the highest-level tile that has no parent. If the space afforded by that tile is exhausted, then just add a parent.
Neat zoomability: I always liked Black & White's ability to seamlessly zoom from a view of the entire land to a few blades of grass. While I can't yet figure out what kinds of interesting details can be found by zooming into a Metroid-flavored tile, I may think of something later. I could potentially have some kind of computer console in the world that, when zoomed in far enough, presents a real-time view of the immediate sector's map -- tiles within a tile.
Elegant serialization of map sectors: if a tile is capable of serializing itself, then nests of tiles can be serialized by ensuring that a tile's serialization algorithm also serializes all its subtiles. This kind of serialization remains flexible. Serialization strategies can be attached to entire branchs of the "tile graph", with some strategies suited for in-memory serialization / caching and others suited for persistent storage when the game is saved or loaded.
Interesting rendering possibilities: related to zoomability above, cascading tile drawing by having parent tiles also invoke child renderers could be useful.

This will be a fun little experiment. I found a great page on maze generation algorithms and am anxious to discover the best framework that will make not only random generation possible, but also the inclusion of prefab elements. For example, I'd like the ability to create a church room (say, a screen big) with specific decorations and whatnot, then register that room with the engine in a way that causes the engine to insert my hand-made church in the otherwise randomly-generated map if some condition is met.

Here are the sub-tasks for this project:

Create a geography generator that operates on tilesets (blank canvases) that I specify.
Apply a rendering system (got something up my sleeve here) that turns the modified tileset structure into a bitmap that can be painted onto a Winforms app.
Try to extend the tech demo so that the user can pan the map and see more geography generated in real-time, while simultaneously commiting existing tiles to persistent storage.

Here's a reasonable question: have I designed enough of the game (gameplay, story, etc.) to go this far in implementation? Probably not. Knowing exactly what features I want in the game -- having an itemized list of gameplay elements -- that would be the best blueprint for building code. But here's the thing. This is a hobby, and I (along with ZMan, apparently :) am itching to see something that actually does something.

My philosophy is this: Vyde as a game is far too big to design all in one go. I set out on this journey with every intention of letting the project grow organically. To that end, this map generator is a prototype. It's a proof-of-concept tech demo that I believe will serve to give me a better idea of what my limits are and tune me to a more focused direction later on.

Let the game begin!

Some OOD

2005-12-17T17:58:00.000-06:00

I've been thinking a lot about the architecture for Vyde's world, and have laid out a couple of diagrams that describe the tile structures I've got in mind as well as a very rudimentary framework for modifying the world canvas.

Seeding Some Concept Art

2005-12-05T21:02:00.000-06:00

I asked my brother to draw some concept art for Vyde for my Christmas present. He asked me to come up with a list of some things I wanted. So here's a list of some things. It's up to you which ones you do, bro.

Merry Christmas. :)

Music For...

bustling activity in a well-settled area; up-tempo marches or waltzes? Forward-moving, building in cycles. Low tech feel (say, drums) or high tech feel (say, high bpm w/ lots of instrumentation) — either one.
a newly discovered "holy place" like a locked tomb or deserted ruin; "something's about to happen" music
unexplored territory; moody, down-tempo, meanering, ambient. Might include sampled sound effects like dripping water, wind through a tunnel, etc.

Sketches of Things (portraits & iconic representations for, say, an inventory screen)

a pickaxe
a found piece of a long-broken holy relic
a cartographer's map

Sketches of People (character sketches & maybe a single side-view sprite, maybe the size of Samus)

a worker/digger/laborer
a cleric
an explorer

Sketches of Locations (moody perspective views & screenshot renderings ala, say, Metroid — think tile-based game)

a half-finished dwelling
a shrine (to what?)
an uncharted tunnel

New Addiction

2005-11-17T21:04:00.000-06:00

OK, I've been out of pocket. Partly because of things going on at home, but mostly because of Egosoft's X3: Reunion.

This is a sandbox game. It's not perfect by any stretch, but it is such a valiant attempt at the genre that it has to be given kudos. This is game that you can really play in, and it rewards those who like to explore.

Now then. What about Vyde?

I've been polishing my programming skills at work in recent weeks. To great effect, too; I've designed a system or two now that I'm really proud of, and have managed to take away more than a couple of lessons that I plan on applying to my game design. What I'm finding most challenging right now is mastering the application of design patterns. There is such merit in studying these patterns -- it only benefits a programmer to learn them in spite of how their pursuit can seem like a time sink. But some work completed today made my pattern crunching worthwhile. So that's good. Why didn't they even expose us to these at school?

It's also good that very few interesting games are coming out in the near future. Once my X3 addiction wears off, I'll be able to concentrate more on Vyde.

Weak excuse, I know.

Threading in 3D Gaming

2005-11-17T21:03:00.000-06:00

Cool article on something that everybody should be thinking about: http://www.gamasutra.com/features/20051117/gabb_01.shtml

Plugins & Scripting

2005-11-01T20:25:00.000-06:00

I finished my first plugin architecture today for a project at work. It was really cool, actually; very easy with .NET's AppDomain.CreateInstanceAndUnwrap(). I'm very encouraged by this: the prospect of making Vyde heavily plugginable is becoming more attractive. Not only that, but in making the aforementioned plugin architecture I learned up on .NET's CodeDOM and its implications for scripting in-game elements. I'll be looking at this a lot closer. I wonder about the pros/cons of adopting C# as a scripting language...

Namespacery

2005-10-31T21:01:00.000-06:00

Three core namespaces:

VydeEngine: also known as the Jeff Engine, or the Object01 Engine. This is the part of the project where I try my hand at writing a game engine that could conceivably handle any game I throw at it. It'll handle all interaction with video, audio, and input, and contain any of the abstraction layers I decide to use for whatever APIs I employ.
VydeNet: this part is the most up-in-the-air. It'll contain classes that act as the underpinnings of the networking that will (?) connect Vyde clients to either Vyde servers or other clients. The more I think about it, the more I like the idea of a web-enabled distribution system of my own design.
VydeCore: this one has the Vyde game in it. All the game classes, all the logic, and rules of the universe. VydeCore would, ideally, be applicable to any other game engine, should id or Valve decide that Vyde is worth buying, of course.

I've been hunting for a good book on game engine development. And I mean real game engine development: textbook kinda stuff; architecture, OOA, patterns, etc. Hopefully somebody out there has some recommendations, 'cause the ones on Amazon et al. are kinda all over the place.

3 Motivators in One Day!

2005-10-28T22:02:00.000-05:00

Somebody's trying to tell me something.

First off, everybody who's able must download and experience the Lost Coast map for Half-Life 2. Guess what? It's the first game level I've ever seen that has developer commentary audio built in. And I found it inspiring. Stuff like this makes me proud to be a gamer.

Gabe Newell and the rest of Valve Software have released the Lost Coast "tour" as an experiment to gauge the interest of the community in learning about Valve's production process. I encourage everyone reading this, whether you've played the map or not, to email gaben@valvesoftware.com and recommend that his team do indeed keep producing this kind of material. It's good for us, and it's good for a somewhat stagnant video game industry.

Why didn't anyone have this idea before? I'm sure as hell going to include commentary in Vyde where I can. And I predict now that Valve just slapped a "DUH!" moment on every video game maker out there, we'll start to see commentary tracks on more and more games. I can't wait.

Second, the Visual Studio 2005 RTM was released yesterday! Happy day! I'm absolutely in love with this IDE. I've been using it at work and have gauged a 400% productivity increase.

Third, ZMan posted a link to a whole page of Managed DirectX Tutorials at C-Unit.

I'm gonna go work on some OOA for Vyde now. Again, if anyone has any recommendations for blog hosts, please endure the CAPTCHA and post a comment about it.

Off Topic: Blogger out?

2005-10-27T19:58:00.000-05:00

So does anyone have any recommendations for another blogging host? I'm finally cluing in to the sentiment that blogger.com is... disliked.

Progress & Nibbled to Death by Ducks

2005-10-13T22:41:00.000-05:00

I know, it's hard to take the Vyde guy seriously when he updates so infrequently. I'm sorry about that. And Peter Molyneux is probably sorry too, he's responsible for most of my absence. Made a little bit of progress recently; finished the first four MDX tutorials in the August SDK, and was very pleased at how straightforward they were. Though there were a few differences between the example code and ended up actually compiling, nothing was unintuitive. So far I really like what Managed DirectX provides. What I'd like to try next is that rudimentary tunnel generator I was talking about earlier. I'd like to do a few things to improve my understanding of what I've worked with so far, like the path of execution of OnCreateDevice to OnCreateVertexBuffer, a conceptual understanding of vertex buffers in general, and a better understanding of PositionNormal vs. PositionColored vertex types. I have so little time for this right now. Groan.

SAND. All I want is sand.

2005-10-11T20:05:00.000-05:00

Here's something that I promise to do with Vyde if and when I ever finish it:

I promise, here, with God as my witness, that I will make a sandbox mode available from the time you install the game to the time you decide to stop playing it. I will not, under any circumstances, make sandbox mode an unlockable.

Peter Molyneux, I have a bone to pick with you. After offering a sandbox mode in Black & White, you for some reason chose to make sandbox mode in Black & White 2 a condition of beating the game. This is a bad thing, considering the emphasis Black & White 2 places on real-time strategy, which happens to be my least-favorite genre of all time.

I am a man who likes his sandboxes. I treat a sandbox game like I treat a good drink: it is something you enjoy on your own terms. I do not want to have to enter a combination to get into my fridge. I do not want to have to jump over a hurdle or burn a certain number of calories in order to be granted access to what I want, when I want it.

I am a man who likes his sandboxes. I can play in a sandbox game and appreciate it for what it is. I can eye it with the same candor and objectivism that I would eye a piece of art.

I am a man who likes his sandboxes. Though I don't own one, I can appreciate people who own an aquarium. And though I don't own one, the video game whose development I'm chronicling here is inspired by, and is a tribute to those who own, ant farms.

I am a man who likes his sandboxes. I am the type of person that buys a game sight unseen, reviews be damned, simply because its precessor offered an interesting sandbox.

And for that last reason alone, you should make sandbox mode available from the start.

I really don't like RTS games, though admittedly the first 3 lands of B&W2 have been easy to win with a building strategy.

Off Topic: OMG MY HEAD EXPLODED!

2005-10-05T08:11:00.000-05:00

You guys! Seriously! Must look!

Autodesk ACQUIRES ALIAS!

They all called me crazy. They said, "3D Studio will never make inroads into Alias territory! And you're a fool for thinking so!"

But I showed them all! Enjoy your influx, Alias, then prepare to fade away! WOOOHOOOOOO! So long! Farewell! Bye bye! Good riddance! Soon you will know the true power of a unified modifier-based object model and usable interface!

The Real Fix for Stuttering Apps

2005-10-03T19:18:00.000-05:00

Hopefully this is the last I'll have to say on the subject: I downloaded the latest CPU drivers from AMD's web site and so far the system is performing as I would expect. None of the stuttering I'd seen previously.

Vyde Should Have Lighting Like This

2005-10-02T00:37:00.000-05:00

http://www.daionet.gr.jp/~masa/rthdribl/

And that's all I'm gonna say about that.

Hello Process!

2005-09-29T21:45:00.000-05:00

I just created my first Windows service. Its sole purpose in life is to look for a Firefox process once a second and, if one is found, sets its CPU affinity to CPU0.

Works like a charm. :)

In lieu of posting binaries, which is what I'd much rather be doing, here's the source code, written in C# in Visual Studio 2005 RC. The trick is adding the service installer and using installutil.exe to install the service assembly. See Adding Installers to Your Service Application on MSDN.

I love .NET. I was intimidated by all the stuff I saw in MSDN about setting affinity until I got to .NET. Mmmm. Process.ProcessorAffinity()... Auughghghghghghh...

namespace AffinityMonitor
{
    public partial class AffinityMonitor : ServiceBase
    {
        public AffinityMonitor()
        {
            InitializeComponent();
        }

        protected override void OnStart(string[] args)
        {
            System.Diagnostics.EventLog.WriteEntry("AffinityMonitor", "AffinityMonitor service started");
            backgroundWorker1.RunWorkerAsync();
        }

        protected override void OnStop()
        {
            System.Diagnostics.EventLog.WriteEntry("AffinityMonitor", "AffinityMonitor service stopping");
            backgroundWorker1.CancelAsync();
        }

        private void backgroundWorker1_DoWork(object sender, DoWorkEventArgs e)
        {
            while (true)
            {
                Console.WriteLine("Tick!");
                Process[] processes = Process.GetProcessesByName("firefox");
                foreach (Process p in processes)
                {
                    p.ProcessorAffinity = new IntPtr(1);
                }
                System.Threading.Thread.Sleep(1000);
            }
        }
    }
}

(Nevermind.)

2005-09-27T18:19:00.000-05:00

After turning off Cool 'n' Quiet and several days of working just fine, the PC's back to stuttering again. *sigh*

Trying to Vyde

2005-09-26T20:28:00.000-05:00

Every time I get the urge to contribute to Vyde, I end up having to do something else. Was out of town this past weekend, am gonna be really busy at work this week, have to come up with an exercise routine, and will be out of town again the weekend after this one. So not a lot of brainpower has gone toward Vyde lately, but a little bit has. I want the gameplay to include scanning, ala Metroid Prime. And that thought led me to remember that I want to include stats, too, ala GTA. I've got some ideas on the random world generator, but have not implemented anything yet. Finally seemed to have figured out the stuttering app problem; AMD's Cool 'n' Quiet technology seemed to be the culprit (or at least the root cause). Turned it off and haven't had any problems in a few days. I've started looking at basic DirectX tutorials, and continue to look for more. I have a feeling that if I can get a program drawing 1 textured triangle, I can get one drawing 12 (10 if you take out the "fourth wall" of a tile), and with 6-10 triangles I have a tile. With a tile abstraction I can start stringing tiles together. We're getting there. Just got a lot of other stuff to do. Yay hobby! BTW, found a nice article on the 5 things every RPG should have. I thought it was spot-on, and even insightful in places.

Adventures in Concurrency: Fix for Stuttering Apps!

2005-09-20T21:03:00.000-05:00

So I downloaded the DX9 August SDK and started having a look at some of the samples.

It helps to realize early on that trying to build the samples using the release candidate of Visual Studio 2005 acquired at the PDC (this is a sweet IDE) won't go off without a hitch. Though there are VS2005 solutions included in some of the samples, the UI toolkit they use to do a lot of the UI legwork references the wrong version of the .NET Framework (900). Tearing out the DirectX, Direct3D, and Direct3DX references, and replacing them with references to their respective 12xx equivalents seems to solve the problem.

Anyway, when I got the BasicHLSL sample to build, I ran it and saw constant stuttering. The timer in the UI was jumping back and forth in time. So, having already had problems with stuttering in Firefox and, the other day, Painkiller, and having solved both those problems by setting those processes' CPU affinities to a single CPU, I reasoned that the same thing was going on with this DirectX sample.

A bit of Googling turned up an article on MSDN about the QueryPerformanceCounter sometimes suffering from BIOS problems on multiprocessor computers. Further Googling schooled me in a problem with AMD's Cool 'n' Quiet technology.

Went to ABIT and upgraded my BIOS, and guess what? Problems solved. Firefox & Direct3D samples -- no stuttering.

So FYI, BIOS version 17 for the ABIT Fata1ity AN8 SLI cured the problem. I suppose it's just coincidence that the release notes for that version indicate a fix for the Cool'n'Quiet technology.

Oh, and might I add that the FlashMenu utility that ABIT dishes out is quite helpful: first time I ever flashed BIOS from within Windows. It even has connectivity to the ABIT website for finding, downloading, and installing the latest version automatically. Very cool. Happy with this board I am.

UPDATE: Ignore everything! Woke up this morning and the PC is back to its old ways. Rrrr.

Lack of Managed DirectX Tutorials

2005-09-18T22:59:00.000-05:00

I spent some time today looking for Managed DirectX tutorials, and haven't found a whole lot. So far, the best set I've found is at pluralsight.com. A lot of the tutorials out there, Managed or otherwise, use 3rd-party libraries to "assist" with the process. But those turn me off pretty quickly. I want to understand the inner workings of something, not just get to a finished product. The DigiPen series lost its appeal when I realized that it was teaching how to code around an existing engine. I may just start reading through the MSDN material instead.

Off Topic: The Sad State of Hobby-Level 3D Production

2005-09-18T15:59:00.000-05:00

I've been spending some time looking at the options available for producing 3D content for Vyde. Up until a few minutes ago, I was hopeful that either Autodesk Gmax or Alias Maya Personal Learning Edition would supply me (a hobbyist, mind you) with a good 3D modelling and animation program for producing Vyde content.

Not so! Both are merely advertisements for their respective parents, 3DS MAX and Maya. By themselves, Gmax and MPLE don't permit you to do anything except "experience" the software. They are both cleverly-disguised shareware -- free, untimed trials that are useful only to those who have or intend to purchase the big app. Out of the box, Gmax won't export to anything but Plasma 3D.

Seriously. Who uses Plasma anymore?

Gmax is actually a case study in a marketing effort gone horribly wrong. Have a look at the titles that support Gmax "game packs". I can count them on two hands. Autodesk decided to needlessly inject a layer of development between the consumer and the game house, with the burden of development placed on the game house! Why? When a game house decides to grant extensibility powers to their customers, they typically release their own tools to do it. Where does Gmax fit into that business model? Nowadays, why would a game house devote extra resources to supporting a 3rd-party editor (Gmax) that wasn't used during the production process?

I can't even download MPLE; the site shows me some fantastic blank pages when I try, but no hint as to where I can get it.

What is a hobbyist to do? Blender3D? Ugh. I really tried Blender; gave it a good, honest, college try. Maybe it's because I'm an experienced 3DS user, but it was a pain in the ass to use.

I'll be on the lookout for alternatives, but in the meantime I may just reinstall my old educational copy of 3DS MAX. Version 3.1. Yay.

Hobbies shouldn't be this expensive.

www.vyde.info

2005-09-18T14:48:00.000-05:00

I've registered www.vyde.info, for those who are interested. For the time being it will act as an alias to vyde.blogspot.com.

Multithreading

2005-09-13T19:48:00.000-05:00

I just finished the second concurrency talk here at the PDC in LA, and it's got me really jazzed about attempting multithreading in Vyde. Possible applications I can think of at the moment include decreasing load times, offloading random level generation to a separate thread(s), or handling the simulation of the world in one set of threads and rendering in another. The conference is outstanding; the talks are very high quality and offer lots of useful insight into whatever you went looking for. Met the ZMan last night and a bunch of us went and had a couple of beers; it was a blast. You meet lots of interesting people at conferences like this. (Not nearly enough women, though. :)

Growing a Game Organically: Water Frequently

2005-09-10T16:29:00.000-05:00

I forget why the idea popped into my head, but I remember it popped loudly. In the unforgiveable amount of time that has passed since my last on-topic post, I've been thinking a lot about how to begin this project's implementation. I am wholly dissatisfied with the idea of designing the entire thing first and then implementing it -- I need to write some code and get at least one triangle displayed on my ridiculously fast video card.

Today I'm going to load up on Diet Sprite and finish the series of webcasts that I began a while back. It should take several hours, but I have little else to do this weekend before flying out to LA for PDC '05.

Oh right... the thought. So I'm thinking to myself that one approach to starting some code would be to design the entire game first (or the first version of it, anyway) then hack my way through it, meeting any and all requirements I set out for myself in a checklist fashion. Or, thought I, I could just let this be a hobby instead of a deadline-oriented project. I could instead make small pieces in a logical progression, and let the game grow organically.

The order in which things are done would be important, and even more important would be the coding style that produces very modular building blocks. Much like I assume God or whoever built the universe, I'd have to start with the most atomic piece I can think of, and then build on that, and build some more, and build more depending on what is needed (according to me). First task might be to create a simple tile: a 3D block that represents a unit of space in the game. With an almost Platonic concept of a tile form, I've produced something useful without having lost the freedom to change course. Then I might augment that with decorations or behaviors. Then maybe inanimate objects within tiles. Then maybe some physics to govern how those objects behave. With a tile model (and its constituent parts) in place, I could build a tile grid. With a tile grid full of tiles, I can begin adding random generation to the mix, making sure to compartmentalize that functionality such that it can be upgraded in the future without affecting the rest of the engine as it evolves.

To some I'm sure this seems obvious. But it hit me like a ton of bricks, as I'm usually a very process-oriented (and deadline-oriented) person -- have something usable at every step in case someone schedules a demo for the next day without telling you until the next day. But this new job is doing wonders for my problem-solving and learning skills -- I can see that I can combine play with process.

It's like Legos, if Legos were run through a multi-stage graphics pipeline.

Time to get started.

Off Topic: Simple Question

2005-09-05T19:20:00.000-05:00

How is it, in Battlefield 2, that you can shoot an enemy soldier 5 times in the face with an assault rifle, from 20 feet away, zoomed in, and not kill him? Is that what they're calling realism these days?

Off Topic: Grow RPG

2005-09-05T02:20:00.000-05:00

Grow RPG will consume about 3 hours of your life before it lets go of you. I have no idea why this is so addicting, but solving it is strangely gratifying.

Grow v3 will consume about 1:50 hours after you solve Grow RPG. :)

Off Topic: Gish!

2005-09-05T00:09:00.000-05:00

Everybody go play Gish right now. WOW this is a great game. May be worth a purchase just to encourage games like this. The abandoned mine levels are so Vyde-ish. The physics are a blast, and the lighting is just great. Well done Chronic Logic!

Off Topic: Half-Life 2 Finished

2005-09-04T00:24:00.000-05:00

Finished Half-Life 2 today. Overall, I liked it a lot. Here's what I took away from it (spoiler-free):

Needless to say, the use of physics was outstanding.
Too many of the levels had insufficient ammunition.
It was often too difficult to see everything that was going on, though that did contribute to a sense of immersion.
The enemy design was great. The Combine looked truly menacing.
Great voice acting and great casting. Robert Culp as Dr. Breen was lots of fun to listen to.
The game was far too linear. It would have benefitted from more opportunities to (and motivation to) explore.
Not enough weapons!
OUTSTANDING graphics. The Source engine is truly a thing of beauty.
Cool story. I kinda wish that we knew more about the G-Man and Freeman's relationship to him.
Formidable AI. Even friendly NPCs are smart enough to get the f!@$ out of your way when you're trying to move around.
Good mix of action and problem solving.
Remarkable sound design. Probably the best of its class. The amount of detail to be found in the sound effects (like the way that gunshots change "depth" with distance) is not to be overlooked.
The ending was slightly anticlimatic. Kind of abrupt.
The animation, especially facial animation and headcrab animation, was top-notch. Scripted sequences were engaging and not annoying; they segwayed into action sequences well.

Definitely worth the price of admission. Gotta finish Thief III next.

Skill System

2005-08-31T21:12:00.000-05:00

First, I should say that I'm making a concerted effort lately to narrow down the specific gameplay features that Vyde will possess. It's difficult, but it's time to start crossing the threshold between brainstorming and design.

That said, here's another feature I haven't touched on yet: Vyde will have a skill system. But it will be non-traditional in that numbers won't play a huge part in it, at least not as far as the UI is concerned.

When Ultima Online was released several years ago, I was interested enough in it to get a copy and play for a while. I really liked its skill system: it was intuitive in that you improved your skills in the trades that you actively practiced, but it spoiled the suspension of disbelief by exposing numbers for each skill to 3 signficant digits. I decided back then that numbers aren't necessary for a skill system that is targeted toward an immersive environment. But this sour taste was mitigated by the fact that UO's system wasn't outwardly level-based; that is, your skill progression within any particular character level was linear, not stair-stepped.

Stair-stepped skill systems (like Diablo's) are, to me, the most unrealistic and unenjoyable methods of advancement in a game. Deus Ex and its sequel both suffered from this problem, though their systems were masked a little more cleverly through the use of tangible "things" that made your skills better if they were plugged in.

At any rate, here are the characteristics I want to borrow from skill systems that I like:

The player will be able to specialize in a wide variety of skills, including machinery, shooting, mining, rappelling, botany, etc.
The player will improve skills by practicing them.
The player will be able to assess his skill level in two ways: by observing the time or trials required to practice a skill successfully, and by consulting a bar graph. The bar graph will provide a "feeling" for the player's skill levels. Though very accurate in a programmatic sense, the bars will not have numbers associated with them.
Skills will atrophy with disuse, at rates related to factors such as last use, frequency of use, etc.
Skills can be improved by watching another player practice the skill, albeit at a much slower rate (passive learning).
The player can improve his skills at an accelerated rate by learning from a teacher (active learning).
Tasks in the world may require one or more skills to be completed successfully in a reasonable amount of time.
Rather than wasting resources attempting tasks and failing at them, Vyde will rely on a system that relates skill level to time required rather than yield produced. When building a machine, low machinery skill will result in the machine taking (much) longer to build, not the consumption of lots of raw material in exchange for very low yield. While there will be waste involved, it will not be nearly as prevalent in Vyde as it was in, say, UO. Time to complete tasks may involve random timing elements to prevent completion from being too predictable, time-wise.
Skill level can improved faster by having the user provide "hints" during the process. For instance, a tinkering task may be completed in less time if the player is able to gesture an on-screen pattern with a high degree of precision. Similarly, strategic clicks in the process (ala Thief III's lockpicking UI) can act as shortcuts in the process.

Like in GTA:SA, the player should become good at what they do most, but be able to change their line of work if desired.

Off Topic: GF4 Ti4600 R.I.P. All Hail the New PC.

2005-08-31T20:51:00.000-05:00

It's not quite dead. But 3D acceleration doesn't work on it anymore. It's been almost 5 years since I purchased this wonderful piece of hardware, and up until recently it has been a trusty, high-quality card.

It seems to be overheating. Symptoms include "the stuttering problem," coupled with batches of scrambled polygons (esp. Half-Life 2) after recovery. The problem gets worse the more I play.

I decided that heat was the likely culprit based on these problems (and after no solutions cured the problem), and so I tried cleaning the card. Now, the VC's fan has been less than well-oiled for a while now; it occasionally scrapes the bottom of its housing. It doesn't rotate as well as it should. But what really impressed me this time around was how much dust I pulled out from between the heat sink's fins. I think the spaces between all the fins were clogged up. I tried getting the top plate off the heat sink/fan housing, but stripped all four screws with jewelers' tools. The fan obviously has dust inside its mechanism, and there's no way I'm gonna get it out without tearing the cooling system apart.

The video card functions just fine when it doesn't have to do a lot of number crunching. For that reason I'll keep the card around.

So here's the thing. I was on the last chapter of Half-Life 2 when all this really got bad. So, that and the age of my current PC served as reasons for me to purchase new guts for my 'puter. I'm pretty happy with what I've picked out, though I'm having trouble relating my rationales to friends. :)

I'm going with an AMD 64 X2 4600+ dual-core. Here's why: I think the dual-core paradigm is gonna hit us like a ton of bricks. I plan on learning a lot more about the desktop part of the wave at Microsoft's PDC in a couple of weeks, but I think the gaming industry is going to pick up on it soon, too. The PS3's multi-core nature should at least get the industry's engineers thinking about new ways of doing things by the year's end, and hopefully in the next 2 years we'll see creative solutions to the problem of how to apply multi-threaded/parallel processing to consumer-level games.

I'm loading this CPU with 2GB RAM and a BFG 7800 GTX. I want to hear my computer thinking.

Truth be told, now that I've made the purchase, I find myself thinking more and more about how Vyde could take advantage of monster hardware like copious amounts of RAM, parallel processing, and God's own video card.

VydeFS

2005-08-25T20:23:00.000-05:00

One more thought on that whole infinite playfield technology thing: I kept assuming that Vyde would have to be able to use the same frame of reference for all tiles. But that isn't the case. There's no reason the engine can't store playfields in separate files, then stitch those files together in real time. Games store different levels on disk as separate files all the time; Vyde's "levels" are just a little different in that they're created dynamically (and likely infrequently), with each level's bounds representing the minimum/maximum extents of a single "considerable" playfield. This would allow the game to be as infinite as possible for right now; the limitation becomes how many possible filenames (or files) a hard drive (or drive cluster) can index. My friend Adam sent me a spreadsheet recently detailing exactly how cheap drives are right now. :) Oh, and Happy Birthday to me. :)

Off Topic: Half-Life 2

2005-08-22T21:44:00.000-05:00

OK, so I bought Half-Life 2. I'm not sure what chapter I'm on -- chapter 7, I think. It's the one where you're driving up the coast.

Overall, I like the game. It runs better than expected on my PC, though there are these annoying hiccups (in this and other games in the past) that occur in somewhat regular patterns. These hiccups usually cause the game to completely freeze and get stuck on a piece of sound, playing over and over, until about 5-10 seconds go by, and then everything's normal again. I don't think these hiccups are load-related; I've had them in other games before and was somehow able to make them go away, but I can't remember how. I think it had something to do with a network service. In Process Explorer, I see spikes in HL2.EXE's kernel usage, but no corresponding spikes in any other process, so I can't figure out what's contributing to it.

So though I like the game overall, I have these little pangs of something that I'm not sure how to qualify. I feel disappointed that the game can be so formulaic -- firefight, puzzle, firefight, puzzle, interact with friendlies, firefight, puzzle, firefight puzzle, interact with friendlies, etc. But though I'm disappointed with this, I can't imagine it any other way.

The game is very linear. Free-form gameplay only exists in as much as you're able to explore some of your surroundings for supplies, but only rarely do you find anything and take pleasure in just having found it. Though I must give credit to the, uh, "cameos" that appear when you do venture to the far corners of a level and look somewhere at just the right time. (Those who've played the game should know what I'm talking about; don't want to spoil anything.) Anyway, that's a fun element. I pat myself on the back whenever I find one of those spots; it's almost a fair trade for having not found supplies.

Anyway, you feel like you're playing a movie; everything is very scripted and event-driven, and you aren't given any choices like you were in Deus Ex. I suspect the designers favored fast-paced gameplay, and I think it works. It's just not my favorite. I much prefer to be able to sit concealed in a corner and spend minutes planning an approach vector that will alert the fewest number of guards. :)

The physics are, of course, awesome.

Voice acting is top-notch.

Some of the puzzles are clever, but might be a little anticlimactic.

Graphics in general, even without a native DX9 card, are just plain cool. The outdoor environments are very immersive.

No complaints about the AI. The City Protection forces are actually intimidating, but make for very satisfying kills. The creatures are not terribly bright, but can make for some very frustrating dogpiles.

Not enough stealth gameplay for my tastes. Too many times the enemies just "know" where you are and come right to you. You can't seem to evade them; I'd be happy with them just changing to a more defensive, inquisitive stance.

The music isn't as impressive or... relevant, I think... as other games like Deus Ex or Thief. I'm kind of ambivolent about it. I'm listening to the soundtrack for Deus Ex right now, and I can always remember exactly where I was in the game when I hear a particular track.

Weapons are great, but there's not near enough ammo in some levels, even on easy difficulty. I want a sniper rifle real bad; I suspect I just haven't found one yet.

The animation is probably the best part. The character animation is fluid even between "moves," and the facial expressions are a marvel. The first thing my brother noticed when I showed it to him were how expressive the characters' eyes were. That's always been missing from games like these. The lack of eye detail was very distracting in games like Deus Ex and especially Thief III. God, the characters in Thief III are so emotionless; they look like they're interested in everything. Every one looks like he would be more comfortable to be in a Vitruvian Man pose.

I'm looking forward to playing more. After I finish Half-Life 2, maybe then will I finish Thief III. After that, I don't have any more FPSs on my list.

Correction!

2005-08-22T21:38:00.000-05:00

Wikipedia does have several entries on gameplay. I have no idea why my last search didn't turn up anything.

I love the second sentence: "Proper use is coupled with reference to "what the player does"." How much closer could I have gotten? :)

Focus on Technology

2005-08-22T20:38:00.000-05:00

I think I have to retract a statement I made earlier.

At my new job, there is a focus on experimenting with new technology. This can involve evaluating new technologies produced by others, or development within our own department. Whereas my last jobs were very regimented by comparison, this job is very free-form. And like in video games, I perform best in free-form mode.

I've had a lot of opportunities in the two months I've been working now to design systems that I've had 100% control over. And as it turns out, I find a lot of pleasure in optimizing, tweaking, and retuning these pieces of clockwork to better do their job. In fact, I'm learning to think in different ways, and I think that's bleeding over into the Vyde effort. I'm finding it really hard to keep that "WRITE SOMETHING!" idea out of my head, and all the minion ideas that come with it screming "TRY THIS!"

As I was reading over my blog up to this point, I realized that I may have jumped the gun by saying (more than once) that I want Vyde to be an experiment in gameplay and not technology. The more I think about it, the more I want to make Vyde a platform for technological ideas, too.

But there's a catch. Vyde is admittedly a "public" project, in as much as I'm publishing my progress on this blog and will likely make works-in-progress available to anyone who's interested in seeing them. But I'm afraid its publicity is going to be disappointing to some who are interested in seeing new technology ideas. As much as I'd love to promise that I'll come up with a new, better mousetrap, I can't, and I expect that a lot of the eureka moments I have will probably be impressive only to me. It's happened before: I derive a clever way of doing something that I pat myself on the back for, only to find out that it has been done several times before, and I just didn't know the right phrase that would bring my Googling self to it. So you've been warned: don't expect too much. :) I've been known to impress people, but so far it's been people who are in another industry. I can't recall having ever impressed seasoned computer scientists.

Enough of that then. Here's a problem I've been baking at 450 for several days now:

Unreasonably Infinite

Assume that Vyde will, in fact, be boundless, with tiles stretching in all directions. It's reasonable to assume that every tile must be describable in 2D coordinates -- x and y. But even a 64 bit integer isn't infinite. And I'm pretty f$@#ing dedicated to this infinity concept. So further assume that when I say infinite, I mean truly infinite, not "mostly infinite," or "reasonably infinite." I mean unreasonably infinite. The player should be able to move in any direction without the possibility of running into an artificial boundary. So how is Vyde's coordinate system supposed to work when a tile could potentially extend beyond the reach of the machine representation of an integer?

I keep coming back to some kind of exponentiated coordinate system. Something that permits a tile's X or Y coordinate to be represented by more than one integer: a tile needs exponents, but an infinite number of them.

Say the machine can't deal with anything outside a signed 8-bit integer. A tile in such an environment would be constrained to lying somewhere within the square defined by corners [-127,-127] and [128,128]. What happens when I make a tile at [129,129]? At that point, Vyde's coordinate system would have to be extended. Whereas it previously used an exponent of 0 to describe tile locations, it must now use a base of 1. 129 = 128¹ + 1. But that only affords the player 128²⁵⁵ + 128, or 2.18 x 10⁵³⁷ tiles (to the right of the origin).

What happens when the player discovers immortality and exceeds that boundary? The limits of the machine's numeric representation (and its hard drive, no doubt) are once again exceeded. So, naturally, another exponent is needed. With apologies to Knuth, we keep adding exponents until we reach SuperV, or 128^{256^{256^...}} tiles in any direction. We can't do that, 'cause eventually the limits of the computer's memory will be exceeded just holding exponents.

Generally, the Vyde world can be thought of as a bunch of tiles. Every tile (which in this case could consist of sub tiles) must be addressable by some Cartesian coordinate. Even if tiles/zones/partitions/whatever were stored on disk separately, with no concept of each other, and stitched together by the engine as needed, each zone would still have to be assigned an address in, well, the infinite domain.

I think the problem at this point is how to overcome the CPU's immutable limitations of numeric representation. It's not a problem of scale, it's a problem of size -- the engine can be built to only consider one "piece" of space at a time. If the CPU's registers could be grown indefinitely by simply spending money as needed, this might not be a problem. So instead of relying on the CPU's representation of numbers to afford us an infinite address, let's instead think of an array of disks, which can be expanded as needed by simply spending more money.

Until addressability becomes a problem. Even under the assumption of infinite space, time must be spent locating a given address. Bummer. Space vs. time always gets you in the end.

Space vs. time is only a constraint so long as computing power remains constant. As computing power increases, so do both space and time. So isn't this a problem of scalability instead? Can the Vyde engine be built so that it can augment its numeric representations as needed, as long as we, the users, promise to provide it with the resources it needs?

What if a law were passed that said all software must be capable of representing any year, not just 4 digit ones (or ones that would fit in some unit of addressable memory)? How could that problem be solved?

And if I get stuck on this problem, what solution will I accept as "good enough?"

Focus on Presentation

2005-08-21T20:12:00.000-05:00

I have a highly developed sense of aesthetics. No matter the game, I've always focused on the aural and visual details, and when they aren't there, it truly spoils any immersion that I might have been experiencing. (If GTA hadn't been so freeform (and had duller physics), I'd have been turned off by its looks pretty quickly.) Riven continues to be my standard for graphical excellence, and Doom III is my standard for the real-time-3D-environment subset. And I'll never forget the first time I heard cavernous echoes in Super Mario World. That was just cool.

What I don't want to see in the development of Vyde are technology demos made up of solid-color tiles and characters that slide through a tunnel without animation. The left part of my brain is going to get bored with this project really quick if I don't constantly supply it with eye candy. My right brain never gets bored, so I'm not worried about running out of technical things to do.

I want to see drops of water falling from the ceiling of tunnels, and I want to see water rippling when I walk through it. I want to see steam coming through cracks in the walls.

I want lights to cast shadows, and I want to see debris from all wall carving. I want to see sparks when something's being repaired, and I want to see characters get progressively dirtier the harder they work, not to mention damage skins.

I want to see multiple backgrounds scrolling in parallax. I want a sense of claustrophobic narrowness in single-tile tunnels and I want to feel staggering scale in caverns that reveal massive geologic features in the far distance. (Getting to them is a problem I haven't solved yet... remember how those artificial boundaries annoy me...)

I want realistic physics — force, impact, and elasticity. Acceleration and braking based truly on mass, and even the ability to chain objects together (I envision minecar trains passing through some of the tunnels). I want fire to spread, and I want water to put it out. I want explosions to cause chain reactions. I want rocks to look like rocks, and I want water to look like water. I want flames to look like flames, and I want metal to look like metal. I want to see reflections in reflective surfaces. I want to see surfaces affected by lights' angles of incidence, dammit!

Design Visions

2005-08-15T22:08:00.000-05:00

I have a vision of the player being able to take the job of a repairman, sent to fix equipment and perform maintenance on buildings.

I envision two types of background: one that is close to the foreground, and climbable by the player, and one of just empty space, with big parallax vistas in the background.

I envision the player making his initial living as an ore miner, sent to gather minerals for deposit at designated drop-off points in exchange for cash. As the player is promoted, he is able to micromanage his own mining operations, and raises capital to place new drop-off points in the frontier.

Wise Man Say: Engine With No Road Make For Short Trip

2005-08-14T14:20:00.000-05:00

I think I just had a sour revelation.

All week I've been thinking about the engine that's going to power Vyde, what its architecture might be like. My brain's just in that zone this week, due to a project I've been working on at the office, which has to do with optimizing processor I've built.

But as I was sorting through the two week old notes that I have yet to post much about, it occured to me that the engine architecture is the last thing I'll be working on before implementing the actual game code. Nuts.

Here are the top-level topics I had laid out for my notes:

Gameplay, Mechanics, and the Vyde Canon
Editability
UI
Asset Development
Engine

I reason this way: the engine's design will be directly impacted by the the characteristics of all four of the higher-priority items. Simple, no?

Here's a preview of what to expect in future posts:

Gameplay

I hate this word. Not even Wikipedia has an entry for it. What is gameplay? Gameplay is like pornography: it's easier to define what it isn't than define what it is. So, true to form, I will attempt to define what it is. (Who knows... I might even make a Wikipedia entry out of it.)

Gameplay, to me, is comprised of all the abilities afforded to the player.

Two games that differ in how the player jumps have different gameplay. Two games that differ only in the character's appearance do not. A game that allows the player to initiate a conversation by bumping into an NPC has different gameplay than one that allows the player to converse by clicking on an NPC from a distance.

On a more subtle level, two games that differ only in NPCs' ineffectual abilities (those that do not impact the player's abilities) do not have different gameplay; they only require different strategies. However, two games that differ only in the environment's ability to affect the player's abilities do have different gameplay. Super Mario Bros. 2 (not the American version, the Japanese version I think, known to us Americans as "The Lost Levels") used essentially the same engine and mechanics as Super Mario Bros. But in certain levels, wind was added to make traversing single-tile pillars more difficult. This wind affected Mario's ability to move, effectively forcing the player to consider traditional abilities (walking & jumping) as having different mechanics.

Player abilities can be abstract, extending beyond environmentally effectual abilities, such as being able to kill an enemy with a fireball, to interaction with game metadata, such as being able to dispel fog of war in an real-time strategy game. Indeed, the player's ability to explore -- discover new areas or aspects of the game -- contributes heavily to gameplay.

Being able to change one's abilities constitutes an ability. Grand Theft Auto: San Andreas allowed the player to rise the ranks of gangsterhood by accomplishing goals, and as a reward for building up his street cred, the player was allowed to recruit more and more gang members. I would argue that the gameplay was improved by virtue of the player's abilities being so dynamic. In the postmortem for Deus Ex, Warren Spector said, "Have you patted your player on the back today? Constant rewards will drive players onward. Make sure you reward players regularly. And make sure the rewards get more impressive as the game goes on." I am a big believer in that philosophy, and believe it was pulled off to great effect in Deus Ex (not so much in Deus Ex 2), but I confess I'm a little worried that it will be particularly difficult to accomplish in Vyde.

The effects an an ability produces in the game world contribute to the nature of the ability. Therefore, if Vyde allowed the player to fire an explosive round that destroys earth tiles, enemies, and treasure chests. That would constitute different gameplay than an earlier version that contained explosive rounds that were identical in every way except being incapable of destroying earth tiles.

Mechanics

Closely related to gameplay is game mechanics. A little easier to grasp, and a little less abstract, a game's mechanics are comprised of the rules that govern the game world. Mechanics (gravity) can affect directly gameplay (jumping), but not the other way around, although making changes to gameplay without regard to existing mechanics can have some bad consequences.

Game physics are the most obvious example of something contributing to mechanics. Game mechanics can also include the mechanics of economy, the mechanics of travel, and/or the mechanics of creation and destruction. Simulation games tend to tip the focus scale from gameplay to mechanics, concentrating more on what the player can't do rather than what he can do. In that way, I think mechanics can be thought of as those aspects of the game that affect the player's strategy, whereas gameplay is what enables the player to perform a strategy.

The Vyde Canon

I actually do have a backstory for Vyde floating around in my head. It's not well-formed enough to publish, but will need to be fleshed out to complete this first-priority phase.

For those who have always heard the word canon and don't know what it means, it's roughly the "official" elements of story in a work of fiction. Vyde's canon will address a few key elements of the world's background:

Where is the surface and what are the implications of finding it? "The surface" is going to be kind of like dryland in Waterworld; it's widely thought to be unattainable and has an almost holy quality to it.
Where do the inhabitants of Vyde come from? (Will talk more about it later, but the decision so far is that there's not going to be any breeding of the player's race in Vyde.)
What drives the inhabitants of the Vyde mine?
Why is the player in the Vyde mine and not elsewhere in his race's world?

Editability

Back to implementation. I want Vyde to be radically editable. I want the Vyde engine (platform?) to provide developers with a rich environment for producing and distributing compelling additions and modifications to the Vyde world. Key features here include automating the distribution, acquisition, and integration of mods. Ideally, the Vyde engine should be capable of transparently and silently scouring the internet for mods, and then integrate that new content into the world, even as the player is playing. This feature alone will demand a substantial amount of thought. So far I'm thinking that mods will have to obey a strict policy of addition rather than actual modification. That is, instead of being able to alter the player's skin, a mod will have to provide a mechanism by which that new skin can be acquired in game. Likewise, rather than editing the appearance or behavior of a pickaxe shop, the engine instead integrates such a mod as an additional spawning possibility. This could gel well with my attitude toward the modification (not augmentation) of the Vyde canon. That is, I define the canon, and it is immutable by anyone other than me. I know that's Lucas of me, but that's the way it's gonna be until I decide otherwise.

User Interface

Vyde's user interface has not been fleshed out well at all. I have only briefly touched on the idea that a windowing system will be required, and that perhaps the mouse will be the best way to target things in the environment. Beyond that... ? So far, I think UI will likely dictate how the engine is designed. CS purists are probably rolling their eyes, but it can't be argued that an engine can be optimized according to the nature of its user interface.

Asset Development

3D Studio MAX. The End.

(OK, so it's not that cut and dry. But it should be.)

There is a myriad of tools available for producing the assets that will be required to produce Vyde. But 3D Studio can even be used for texture creation! And UI skins, and fonts, and...

*ahem*

I'm keen to learn how I might integrate Gmax into Vyde. I haven't taken the time to get a grasp on exactly what the licensing issues are yet, but I'm optimistic.

Of course, Photoshop is an invaluable tool for 2D asset creation. But for things like texture creation, I'm an even bigger fan of Darktree Textures.

Maya... Maya Maya Maya. Maaaaayaaroony. Free Personal Learning Edition, lousy user interface. Tool of the pros that produces great results, buggy as hell. Extensible via MEL, years of experience in MAXScript. Great film & video features vs. years of targeted development toward the game industry.

I do not like Maya. Never have. Probably never will. It will be a desperate time when I start making Vyde assets using this tool.

It's a moral dilemma: put the price of 3D Studio MAX on my credit card when the time comes, or... not?

The Engine

Easy. OK, a byte can have 256 values. And a game engine consists of a finite number of bytes. Then it follows, mathematically, that I just have to pick the right values and put them in the correct order (which depends on the processor, of course).

I wonder if Blogger provides enough space to hold all the posts I'll be making about engine development?

Once the phases above are complete or underway to a requisite point, I think engine development can begin. Highlights:

How will the engine handle disk IO? Knowing very little about the state-of-the-art, the random and streaming nature of this game seems to demand IO that is fast rather than compact. I envision additions to the player's data file(s) being written first and compacted later, maybe even with the aid of a separate tool. Remember, theoretically the size of the data file will be bounded only by the user's available hard drive space.
How is data cached? What factors must be considered to best exploit managed code's garbage collector?
Would the engine benefit from a Carmackian client-server architecture, even if the focus is on single-player?
To what degree does the engine serve data to other engines on the net?
How are offscreen events simulated? If the player is 500 scale miles away from a massive battle in their hometown, how are that battle's results simulated and stored without adversely affecting the player's unrelated adventure? If a tree falls in the cave, does it get written to the data file now or later?
How should random world generation be implemented? What about random puzzle generation?
How can the engine be designed to best facilitate it being used as a development testbed? Or, how can the engine be made to be a development tool and a game platform at the same time? What kind of debugging facilities need to be built into the engine, and how are they invoked at runtime?
How does the engine discover, acquire, and integrate mods?
How is the world modeled, and how will that model affect the engine's design?
Would the engine benefit from multithreading?
How can music be made dynamic (changes based on circumstances)?
To what degree do we focus on single-player aspects over multiplayer aspects?

The Game Engine as an Operating System

2005-08-14T13:26:00.000-05:00

Among the notes I took a couple of weeks back, I wondered whether there would be any merit to treating (or building) a game engine like an operating system. My thoughts on the matter didn't go very far beyond just asking the question, but today I found an interesting blog post where the maker of the Sylphis 3D engine asks the same thing.

It's an interesting idea, I think. I actually have more experience with operating system architecture than game engine design (and that's not saying much), and I wonder what analogies would have to be employed to fully connect the two concepts. Harry K. suggests that actors in the engine (essentially any entity in the game, concrete or abstract) would all be considered processes running on the OS. But that can't be the extent of it. Processes demand resources from an OS; what resources do actors demand from a game engine? Perhaps they demand scheduling, or a handle to some aspect of the world. (Aspects are...? Are such aspects actors?)

What is memory in a game engine? If the game engine is treated as a virtual machine, is there utility to having virtual hardware?

How many layers of abstraction does this virtual machine need? Is the virtual processor distinct from the virtual OS? Is there a virtual file system?

I need to review one of my college textbooks on OS architecture. I really like thinking about this idea, but I fear it's all over my head at this point. I can't do anything very conducive toward its research except ask questions.

Harry K.'s post is good, though I think it benefits from more than one read.

Thoughts On UI

2005-08-08T20:37:00.000-05:00

Famous last words: I think the UI for Vyde will be pretty simple. I'd like to keep user interface elements to a minimum in favor of context-sensitive elements that appear in response to actions on the environment.

I liked the approach that Molyneux took with Black & White. Everything was very intuitive, and the gesturing interface was actually pretty cool, though I'm not going to attempt that in Vyde.

At its heart, Vyde will be a platformer. The character will need to be able to move left, right, up, and down. In that respect, I see the player's movement happening in a fashion similar to, say, Mega Man. To that end, I don't see a need for any more keys than WASD.

Haven't decided on jumping yet. Either the character will need to jump and be unable to scale background walls (ala Diggles), or the character will be able to jump, and therefore require another way to climb to higher places or descend gently to lower places.

Now that I think about it, the ability to rappel downward and ropeclimb (grapple) upward is appealing. I always loved Bionic Commando, and the physics of it are probably not that hard (Worms did this also).

Let's stick with that idea for a moment: Worms made use of a grapple gun by allowing the user to choose a direction with the mouse, thus firing the gun in that direction. The player in Vyde could use the same interface, and a grapple gun could be a primary tool for use in exploration. This could be restrictive though, unless care is taken to allow the player to climb on top of a ledge that had been attached to from underneath. The game will probably have one-way surfaces, but most of "earth" in the game will be solid from all directions. Only grappling to the left or right side of a floor tile will permit climbing to the top of that tile. Here's my first piece of published concept art. :)

Anyway, I feel the keyboard will be pretty straightforward. The mouse will play an equally important role. It will symbolize what the player is interested in and provide a context-sensitive interface to all the actions he can perform. I'm fond of radial interfaces: I'll probably put together a prototype of one soon. The context menu will likely appear in response to the right mouse button. Right-clicking objects in the environment (or the environment itself) will permit various actions, whereas right-clicking on the player character will produce a context menu for selecting items or opening dialogs, like an inventory screen. On the other hand, if I choose to use the right mouse button as a secondary action key, then a well-placed keyboard key could bring up the context menu instead.

Here's a kicker: Vyde will likely demand its own window system. Not only will there be the requisite "New Game, Continue Game, etc." dialog, but we'll need an options screen, a map, and a dialog to control the economic aspects of a factory. I can't say I'm thrilled about writing an entire window system; there may be others out there I can use instead of making my own. But I've had some experience with event-driven UIs. Might not be too difficult if I'm willing to sacrifice some complex layout facilities.

I wonder if XUL could be used here? Hm...

Brainstorm Death Toll Increases

2005-08-07T12:57:00.000-05:00

I was reviewing the notes I mentioned in the previous Brainstorm post, and I think I got carried away. Now, granted, it was a brainstorming session. Ideas are supposed to come out and not be eliminated for any reason until the pruning stage. But I hate the pruning stage. When you're looking at a wishlist that includes every feature under the sun, you can become discouraged very easily. You know you can't implement all of them immediately, but the idea of ever finishing the entire set seems out of reach.

Now is the time for me to decide which features will be included in the first effort. I have to put together something that runs, if for no other reason than to stay motivated. But it's tough to choose. In the entire wishlist, there's not a single feature that I only kinda want; I want them all, and for what I think are good reasons. But I don't want to choose some first and then find I didn't leave room (programmatically) for the rest. I hate backtracking, so I try to solve everything at the outset. That attitude has proven detrimental in the past.

This is gonna be a huge game that's never finished. And I'm the only person who will work on it. I'm generally in favor of and enjoy the results of organic growth in a program, but I am terrified that I'll have to tear down the entire engine to support a feature that I deemed too difficult to implement early on. I know that if the design is perfect, then this is a moot point. But in my career I've not come up with a perfect design yet, and somehow I doubt that a hobby project will serve as the first one.

I have to think some more on how to approach this. I suppose I could dedicate a post to each feature or idea, and see if thinking it out helps me come up with a compelling reason to keep it or leave it. That effort alone will take a few months if I really throw my mind into it.

*sigh*

In other news, I bought a new sketchbook and mechanical pencil the other day (the weird kind with the free-sliding lead). If nothing else I can come up with some more concept art.

Gotta stay motivated...

Off Topic: Ridiculously Clever Games

2005-08-06T15:54:00.000-05:00

Everybody go play the games at Experimental Gameplay right now.

Off Topic: Call for a Thin Keyboard

2005-08-04T20:23:00.000-05:00

Doesn't anyone make flat keyboards anymore? I want Mac flat. Or Logitech diNovo flat, but without the questionable mouse and keypad that I'll never use. Are they called something else?

Serendipitous Inspiration

2005-08-01T22:31:00.000-05:00

Look what I found: http://www.xgenstudios.com/play/motherload/. Just bought the premium edition.

Recovering From a Brainstorm

2005-08-01T21:33:00.000-05:00

I took a couple of car trips to Atlanta this past weekend and had some time to kill, so I took my Dad's digital voice recorder with me and took about 45 minutes worth of notes. I just finished transcribing them into a mindmap and am sifting through them in an effort to put together some good posts about the experience. Here are some of the highlights:

Can the Vyde engine be modeled after an OS?
How are simulations made to stay compelling over time? Does a simulation without boundaries constitute a compelling experience?
NPCs — their actions, dialogue, location, inventory, and relationships to the environment — need to be describable via one or more XML files, which are placed in a known location, where the engine will discover the data and integrate it into the game, seamlessly and silently.
How can pools of water be plausible in an infinite, side-scrolling underground space? I like the idea of being able to swim through pools and surface in another area, but the resulting environment would make no physical sense. Can plausibility be sacrificed in this case for the sake of fun?
With regard to story, what kind of theological elements would be interesting? What if "the surface", which we'll never see (more on that later), has a mystic, holy quality to it?
Minigames!
Engine needs to be able to maintain a queue of items that need to be given spawn priority. Discovering certain things in the world should add other things to the spawn queue, for discovery later. This would facilitate scenarios such as the player finding a fortress key but not the fortress to go with it (yet), or vice-versa.
Could corruption in data files be compartmentalized and isolated, then rendered in the game as a cave-in?
Games nowadays need to adopt the same customizability paradigms that we're seeing in programs like Firefox. Let the entire game be parametric.

All for now. I've got a lot of braindump to work through, so more posts will be forthcoming.

Off Topic: Facade Broke the Rules

2005-07-29T23:29:00.000-05:00

By the way...

After waiting for Facade to download overnight, then waiting for it to install while I was at work, I got home today expecting to be able to play it. Instead, upon launching the program I received an error message telling me that my computer was too slow to run it. Apparently it requires a 1.6GHz processor, and 1.4GHZ+ processor wasn't up to scratch. I have seen no evidence in the form of screenshots or feature lists to suggest that it requires that much horsepower. I don't care what kind of natural language processing or emotive engines they've build into the thing.

It's like telling a student they can't take a class because they failed to recite 30, but not 29, numbers from memory.

When a warning on a site says a program will not run on a processor slower than 1.6GHz, even when italicized, a person who's after a new game cannot be expected to take the warning literally. From a usability standpoint alone, all anyone wants is the download link, and that's all anyone will look at. What are you accomplishing by placing such artificial constriants on the acquisition process?

If I gave up on a project whenever I'd been told something wouldn't work with my current equipment, I'd have accomplished very little by now. Traditionally, I've been unable to afford the equipment necessary to run most of my preferred tools at their peak condition; so I make do. My best friend once said that if the computer has taught our generation anything, it's patience.

I dare the developers to prove to me that the lack of < 0.2GHz will prevent me from studying the technology behind their work. If the game runs slowly on my machine, then so be it. If I have to disable machinery in my OS, so be it. If I have to exhaust my RAM, then I'll exhaust my RAM and start thrashing the hard drive. It is presumptuous and arrogant to think that I will be unable to derive value from this program because I miss the mark by 12%.

What makes me even more mad is that there was a Georgia Tech brain involved in this. This shouldn't surprise me.

It is a sin to perform this kind of test. Developers may not use unreliable benchmarks as a gauge to determine whether a program will run acceptably, and they most certainly may not refuse to run a program based on that measurement. I, the user, will make the decision as to whether the program runs acceptably. If I invest the time to download the 800MB monstrosity using a dubious BitTorrent distribution method (it's slower than Christmas, but I'm helping other users get shafted...), then I expect to be able to run the executable without being met with a damned decree!

It's a shame too, because now it's unlikely I will remember to look at Facade once I upgrade my processor.

Don't tell me what I can't do.

Off Topic: HD Fixed! (GOD DMA PIO!)

2005-07-29T23:23:00.000-05:00

I finally discovered the cause of all my PC latency. It turns out that Windows XP had knocked down the transfer mode of my IDE controller from Ultra DMA 5 to PIO, and never told me. I performed a fix I found on the internet, and my PC's been good-as-new all night.

(See the next post for my rendered opinion on why software should not try to outthink its user.)

The moral: be sure to check your IDE controllers' transfer modes and ensure they're not using PIO. Chances are better than average that Windows might have tried to outthink you. I checked two computers at work today and both had the same problem.

With my new found performance I fired up the Half-Life 2 demo again, and it worked way better than before. I played through both levels with no appreciable latency. I'll have more to say about Half-Life 2 in an upcoming post. I found it very immersive and want to implement some of the "common sense physics" it demonstrates into Vyde.

BTW, does anyone know why Blogger's Preview mode looks so bland? Is there a stylesheet that governs the preview? I'd much prefer to get a WYSIWYG preview rather than what I'm seeing instead.

Off Topic: Templates & Cool Stuff

2005-07-28T20:45:00.000-05:00

Tweaked the template for the blog a bit. It was way too narrow for my taste and the sidebar wasn't floating like it should have. I hope this version makes better use of screen real estate.

(I read almost 200 pages of Jakob Neilsen's Designing for Web Usability today while waiting for Windows Vista Beta 1 to install. I've been infected.)

(You know, you'd think a book subtitled "The Practice of Simplicity" would have less than 400 pages.)

Added links to my Furl and my Stumbles in the sidebar.

In other news, I'm currently downloading the 800MB "Facade" at the BitTorrentastic rate of 11KB per second. I read about this game (?) in a Gamasutra article today and saw that it was co-developed by a fellow Ramblin' Wreck, so needless to say I'm curious to see what it's like.

Another interesting article on Gamasutra about storytelling in video games. I've been thinking lately about whether to add story elements to Vyde out-of-the-bo... um... bitstream... ? or whether to leave it a "sandbox" that players can build and distribute stories for. More on that in future posts.

Everybody should read Donald Knuth's Things a Computer Scientist Rarely Talks About, a very entertaining read. I'm actually reading it before reading 3:16: Bible Texts Illuminated, and it gives me something to look forward to.

Also, have fun with the Zombie4. :) My friend Eric found this one after I showed him the Zombie Infestation Simulator. It made me think that Vyde might have some plague elements that could be fun. >:)

And a new favorite of mine: Interactive Buddy. What's cool about this toy is that there are so many places you can go with it. I can think of at least a dozen things I'd like to add to this one, including stick-figure skeletons, armor, and physical fitness, complete with exercise equipment.

I use Bloglines to read my RSS feeds. I imagine adding Vyde to it would be very simple. :)

Also found Aardvark today, a CSS inspector for Firefox. Very cool.

The Windows Vista Beta 1 would not install on Virtual PC today. It crashed five times in three different ways throughout the day. Gave up on it finally when somehow the installer got confused on how to format the drive (which it didn't have a problem with the first time I tried it).

If anyone can point me to last week's episodes of SG-1 and SG-1: Atlantis, please do. My stupid cable box reset while I was out and my TiVo recorded 2 hours of high-quality black.

Features & Requirements: 3D

2005-07-27T21:19:00.000-05:00

(First off, does anyone know how to tame Blogger's WYSIWYG editor? Why must it specify font size every time I want to put something in italics?)

Time to start listing some of the features and requirements I've been thinking about. I want to get them written down so I can start brainstorming about what is worth doing and what is overkill. I'm going to devote a separate post to each feature/requirement.

3D is the biggie. I put it here as a requirement, but it's the one I'm most unsure about and have been spending the most time thinking about. Thing is, I'm a 3D guy by heart. Years of using 3D Studio (back to the DOS days baby!) taught me that I'm pretty good at modeling and texturing cool-looking things, and my computer graphics training at Georgia Tech taught me most of what I need to know about maintaining and manipulating a 3D scene in real-time, programmatically. I'm actually fairly confident that I could build the necessary engine to support a decent 3D scene, but not so sure about the time required to build all the assets. Even constructing a single tile — say a piece of hallway — can be a lot of work. 'Cause a single piece of hallway is going to have the basic wall shell, then adornments like rocks & pebbles (to hide sharp edges), then more other decorations like wooden bracing and hanging vines and whatnot. I know that clever scene building can relegate the adornments to separate passes, and therefore separate assets, but still, for a game of this scope we're talking about a lot of 3D work just to get basic artwork in place. Not only that, but there's the matter of a 3D Studio license. (Tried Blender. Really gave it an honest college try. But I can't jive with it.)

One alternative is 2D (like Abuse 2D). If I could think of a way to build an engine that could swap out 2D for 3D with the change of an XML file, I'd probably do that, if for no other reason than to have a proof-of-concept written more quickly. The engine could be like Super Metroid's, even with cool effects, but I worry that it wouldn't be as engaging. Dynamic lighting would be very difficult in 2D. And I get the suspiscion that before this adventure is over I will have started dabbling into low-level GPU effects like pixel and vertex shading — that's something I've always wanted to learn. Then there's the artwork. I just know I'd end up building the artwork in 3D then rendering it to the requisite 2D sprites. If only I could draw artwork like we've seen in Metal Slug. That game really captures the look I'm after, but I've never attained that level of stylization.

Another alternative is what I'll call 2.5D. This would involve much more rudimentary geometry combined with 2D sprites. The player, NPCs, and other objects in the world would be animated sprites strategically positioned in the Z-plane to not interfere with each other. I wouldn't go as far as, say, Paper Mario; I'm thinking something more like Dungeon Keeper I's approach. This approach has a hidden benefit: a basic 3D engine serves as the foundation, and that 3D engine can be enhanced over time. If the OOD of the project is clever enough, the sprites can be swapped out with 3D models as the assets (and skills) become available. This approach lends itself well to using placeholder art while I work on the low-level engine mechanics. With the help of Photoshop (oh please, Paint.NET, please enhance your feature set with all haste!), pencil sketches could have their backgrounds keyed out and be mapped onto some quads, serving as entites in the environment. That might actually have some stylistic merit...

Overall I think building a solid 3D engine will be most gratifying. But it can take a long time to make one, and even longer to populate it with assets that are up to my standards. Perhaps a 2.5D approach is the way to go. It serves as an attainable first step towards what I really want, and lends itself well to organic growth.

If I could even pull off something as simple (!) as Dungeon Keeper's engine (turned on it's side), I think I'd be happy with that — that would make a good first milestone. It had a lot of the features I'm after: a 2D playing space rendered in 3D with lighting effects, clever adornments, and dynamic elements all comprising a map that can be tunneled through to build a world.

Diggles comes to mind again. That game's engine might as well have been Vyde Alpha. It even includes things like ladders, elevators, and random tunnel & room generation.

Yep, Dungeon Keeper and Diggles shall serve as engine inspiration for this project. I wonder if I can get Dungeon Keeper running in XP...

Making a Game On the Left and Right Sides of the Brain

2005-07-26T19:03:00.000-05:00

Two things motivated me to post today. First, I got a sweet new flat-panel monitor. A Dell 1905FP; I use an 1805FP at work and really liked it, then found that they're discontinued on Dell's site. Anyway, got it hooked up and it's a thing of beauty.

Second, and more importantly, I was checking my RSS feeds this morning and lo and behold, I see the ZMan of The Z Buffer giving me a nod! I emailed him and told him that seeing Vyde mentioned in what I consider a really useful site was just the kick in the pants I needed to start working on this thing again. Thanks again for the mention. :)

I had planned to pepper today's post with some sketches I did a while back, but I can't find my sketchbook. I think it's still at my apartment in Nashville. They'll get put up soon.

I visited Nashville this past weekend, and had a chance to fire up my PlayStation. Played GTA:SA for what must have been 3 hours straight. Felt good! Drive fast, crash, shoot people, dive out of planes, swim, gamble... those are six things you can't do in any other game.

GTA:SA is, IMHO, the best freeform game in existence today. To my mind, freeform gameplay is severely underrated today. Sandboxing is the most fun I ever have with games, and GTA:SA is the biggest sandbox available, with the most things to do in it.

But even so, after playing it for a while (using the save game I created after I beat the game), I realized that even the best freeform game can get boring. Eventually you run out of creative things to do, or new things to see. Here are some of the thoughts that occured to me while I was entering the boredom zone:

There ought to be a way to meet and "remember" pedestrians. They should all have daily routines and not be limited to walking around randomly. I'd like to see pedestrians enter buildings, pick fights, steal vehicles (any vehicle), gamble, parachute, and all the other things I would be able to do in the game. In a game with more resources, I'd like to be able to engage pedestrians in conversations. In a game like GTA, I'd like them to provide things from useless banter to current events, kinda like Animal Crossing.
Cars appear too predictably.
There's not enough activity in special zones, like airports.
There should be more side-missions available: air taxis, harbor tours, car repair, stealth thievery that actually works when you get in the designated vehicle, the ability to control multiple gangs and assign them missions, safehouse decoration, asset tuning, building demolition, hitman missions, team sports, manage a restaurant, etc. Insert favorite activity here.
There should be a way to bribe cops on a more long-term basis; or make them fear you.
There should be a way to accrue "evidence" against you that contributes to your likelihood of being busted.
Any pedestrian should be a candidate girlfriend.
Pimping should really work like pimping.
You should be able to shake down shopkeepers, or even take over entire establishments.
More various smuggling missions.
More micromanagement in general. When the game is done, more focus should be put on turning the GTA world into a simulator.

Anyway, lots of things. It's a shame that GTA on the PC isn't more extensible -- I could make a serious hobby out of making mods for that game.

Now, I understand that companies like Rockstar suffer from deadlines, budgets, personnel, etc. But since Vyde is a hobby project, I can theoretically add anything I want to it over time. So needless to say, to get the maximum enjoyment and education out of the entire process, and potentially open the game to the public, extensibility shall be a feature.

I know I'm opening a dangerous can of worms wanting to make Vyde as extensible as possible. But it lends more credence to the idea that I might want to concentrate initially on building an engine rather than diving straight into a game.

But I've got to be honest: I'm not totally open to the idea of 1) making Vyde open source, or 2) making its modability available to the general public. This might be something I just have to get over, but of the few things I take real pride in, I think Vyde's gonna be one of them. The left side of my brain is very sensitive how my work is treated.

We'll see. I'm nowhere near that point yet.

What I've been struggling with most recently is the left side that wants to design, and the right side that wants to build. I'm a professional computer scientist, and as such, the principle of "90% designing, 10% coding" was drilled into me pretty hard. But I'm aching to prototype something. Trouble is, whenever I get started on a project, it tends to grow very organically. I add features and functionality where and when I think they're needed, and not before. That's a tricky philosophy to adhere to when making a game.

I don't want to end up making a bunch of little programs unless I know they can be assembled into something greater than the sum of their parts. Problem is, I don't know how to design an open-ended system. I've seen some of the best examples of extendible systems: 3DS MAX comes to mind, as do the Quake and Unreal engines. I wrote a lot of code for 3DS MAX back in the day, and actually had to write a mod for Quake as a homework assignment at Georgia Tech. It's been a long time, though, and I'm not sure I could pull any bits from memory that would help me identify patterns in making open-ended engines.

If anyone has any pointers in this respect, please comment!

I could spend the rest of my life designing the perfect game engine. But perfection is the enemy of completion.

Do I draw the design on paper? Do I adopt well-formed UML 2.0 in Visio? I have to psyche myself up to the fact that I'll have to make many, many revisions, give up on lots of work that just doesn't work, and ultimately be frustrated by a design that worked right up until the time it should have.

It's times like these that I start to realize how overwhelming the prospect of producing an entire video game from scratch can be. I'm gonna be responsible for the design, the code, the art, the sound, the funding, the distribution, the asset management, and whatever else I don't know about.

I haven't even picked a programming language yet. And then there are scripting languages to consider.

I haven't chosen to use 2D graphics or 2.5D graphics yet.

Is now the time to make those decisions? Probably not. The more I think about it, the more I think I just need to spend some more time sketching stuff out, and writing down concrete design concepts. In the meantime, I'll continue to browse the game development resources I find, and post here.

On that note, here are a couple of images I found that seemed to remind me of the Vyde concept I'm brewing. (If you're interested at all in cool CG, see 3D Artists.)

All for now. More later. Gotta find my sketchbook.

Development Environment for Vyde

2005-07-17T17:44:00.000-05:00

I regret purchasing Visual C++ .NET. I will probably never use it. I reached this conclusion last night when I tried to play with PopCap Games' SexyApp framework, written in C++.

I can't imagine that the behavior I get out of VC++.NET is intended. IntelliSense just seems to, well, not work correctly. It confuses declarations with definitions (and often can't even identify definitions), it can't find symbols, and the drop-down lists that are supposed to help you navigate your code just aren't wired to anything. They just don't work -- click a symbol and the cursor doesn't move.

I had this problem inspecting the Quake II source a while back, and even found an old Usenet post about it.

If I didn't know better, I'd say something was corrupted. But I've tried clearing out the IntelliSense files, and even tried reinstalling the IDE. I just can't get it to work as expected.

So! What am I likely to develop Vyde in? Not C++. I know that any game worth its salt is supposed to be written in C++, if for no other reason than the efficiency boost the compiler brings to your binaries. But I have to wonder where C++ is going as a tool.

Microsoft is obviously not devoting the same amount of attention to C++.NET as it it so C#.NET and VB.NET. (When you think about it, do C++ and .NET really make sense together?) And then you have things like Managed DirectX, which are no doubt supposed to encourage development on the .NET platform.

And having done some graphics work on .NET this week at work, I can't say I'm totally turned off to the idea of writing a game in it. If nothing else, it'd be an interesting experiment. I'm all about ease in this project: I will take time to build the requisite amount of code, but I do not want to spend time wrestling with the tools that are supposed to make development easier.

Part of me wants to write Vyde in C++, but that same part of me can't come up with a knockout reason for doing so. I really don't think C++ has an indefinite lifespan, and the tools for writing code in it are just lousy. I like IDEs; I believe in IDEs. But I haven't seen one yet that makes C++ development any easier than writing in Notepad, including Visual Studio 2003, which is just sad. I worry that writing the game in C++ will date it, and make it harder to add new features (or integrate new technology) later in its admitedly drawn-out lifecycle.

One factor that weighs heavy on this dilemma is the crop of existing engines out there. Almost all of them seem to be written in C++ (and this makes me think that 1) I'm missing something, or 2) too many zealots think C++ is a requirement for game development). But the idea of writing my own engine, from scratch, appeals to me. After all, this is supposed to be a learning experience.

I haven't finished the webcast series that I started -- the one on game development in C# + Managed DirectX. I've been playing Thief III instead. Once I'm done with that game I think I'll write a big review of it -- things I think should've been done differently -- and work on assimilating that experience into this project.

Webcast Review: Basic Programming Concepts and Introduction to C#

2005-07-03T21:09:00.000-05:00

Just finished watching the first webcast in the "Learn to Write C# the Fun Way" series at http://www.microsoft.com/events/series/msdnvideodev.mspx, titled "Basic Programming Concepts and Introduction to C#".

It was, as expected, very elementary, targeted strictly towards non-programmers. Some interesting factoids about the game industry, particularly sales figures and statistics.

Tried downloading the demo of the game, but when I run it I get a TypeInitializationException. Hopefully when we get to building the engine it will work better. This series is pretty recent -- May 2005 -- so I don't imagine this is a fundamental DirectX version problem or anything. We'll see.

There are 8 webcasts in the series, and it appears that each one is about an hour long. This one could have gone quicker if there weren't so many polls and redundancy.

Back In the Habit

2005-07-03T19:51:00.000-05:00

So here's my dilemma: I've got this idea in my head that I want to realize into a video game, but now that I have some free time after moving to a new job, I'm finding that I want to play video games more. I fired up SimCity 4 the other day and have been having a lot of fun with it, and just got Thief:DS working today. Never finished that one 'cause work got to be too heavy. Anyway, the desire to play games is coming back, and its tricky to balance that with the desire to make a game.

I did make some progress Friday night. Found a series of webcasts on Microsoft's site entitled "Video Game Development: Learn to Write C# the Fun Way." Looks intriguing. Downloaded all of those and am about to watch the first one. The idea of writing this game using Managed DirectX is appealing, and the idea of learning a new language (C#) on the way is appealing, too.

There are several new links in my Furl archive, and I keep adding more.

Off Topic: Got Thief:DS to work again!

2005-07-03T19:47:00.000-05:00

My computer is still acting odd, but at least I was able to get Thief:DS to run again. Thief wasn't starting correctly, hanging on a blank screen when I ran the executable. Turns out I had DirectX configured to run in debug mode on my system, and that was causing the problem for whatever reason.

Still got that weird interrupts problem, though. I tried disabling USB in my BIOS, per several internet posts that suggested it can be the cause of excessive context switching, but it didn't seem to solve the trick. I worry that my hard drive really is going bad: no matter how many times I chkdsk, I get errors every time, and chkdsk /f reports no bad sectors. Maybe my IDE controller is hosed, or my motherboard is dying. Groan.

Search-Driven Gameplay

2005-06-26T00:15:00.000-05:00

What if the goal of a game was to search for something in the virtual world? What if you could command a group of NPCs to help you search for it?

What clues would the world provide to you?

How does the world hide the thing?

What happens when you find it?

Off Topic: Building a New PC

2005-06-23T20:34:00.000-05:00

I've felt guilty not updating in so long, but unfortunately I haven't contributed a lot to the cause lately. Moved to a new state, new job, and I've had some other stuff going on that's knocked me out for a while.

I titled this article "Off Topic" 'cause it doesn't exactly relate to development. I'll pepper the blog with some off-topic articles now and then. This one is about my effort to upgrade my PC.

Need a new processor.

Need a new motherboard.

Need new RAM.

Need a new graphics card.

I tried playing the Half Life 2 demo the other day, and my computer was chewing on it like dry pork chops. Looks like a cool game, and I want to be able to play it. But I had to turn down all the graphic detail settings just to get the audio to play correctly.

I built my current PC in December 2001, and got my video card in early 2002. Here are the specs I want to upgrade from:

Motherboard:	Soyo KT333 Dragon Ultra Black
CPU:	Athlon 1600 XP
RAM:	512MB Samsung 266MHz 2?00
Graphics:	Nvidia GeForce4 Ti4600

It's lasted for almost 4 years now, and all things considered it's done pretty well. But it's suffering from an odd problem right now that I don't know how to fix. (Has to do with excessive hardware interrupts during hard drive activity.) Anyway, 4 years is an eternity for even an amateur enthusiast like me, so it's time to upgrade.

My philosophy when upgrading a computer is this: buy the best, last the longest.

I'm reading up on Intel's and AMD's dual-core processors, and the motherboards that love them. But most of my attention now is focused on what GPU to get. Nvidia just releasted their 7800 GTX, and it looks pretty slick. So far, at least until ATI makes their announcement later this week, Nvidia's on top of the heap. And I've always liked Nvidia, and never cared much for ATI. I think Nvidia makes better drivers and have more reliable hardware in general. ATI's come a long way since their All-In-Wonder days, but something about them tastes bad to me. And generally, their hardware doesn't outperform Nvidia.

Anyway, I'll be keeping my hard drives (unless this odd problem turns out to be a symptom of some kind of failure), and my DVD-RW, and my case. Probably my fans, too. The power supply might need to be replaced.

Haven't done a lot of pricing yet, but I figure this effort have a substantial cost attached to it. Good thing there are a lots of articles to be read, 'cause I'm not gonna be spending a lot after this. :)

Enhancements to the Visual C++ .NET 2005 IDE

2005-06-06T16:53:00.000-05:00

Found this series of articles on the new Visual Studio .NET 2005 IDE. I'm not sure how many of the features discussed are specific to C++, though.

Thoughts on Game Engine Anatomy Parts I and II

2005-05-30T02:56:00.000-05:00

Finished reading Game Engine Anatomy Parts I and II. Had these thoughts:

Do I want a 2D game in a 3D engine?

I think so. Or, rather, a 2D game that utilizes hardware acceleration. The vision I have for Vyde includes some sophisticated effects that I think would be best accomplished in a bona-fide 3D space, but a 2D view would make camera handling easier, and could have an impact on how I store the scene graph.

Some of the effects I'd eventually like to see:

Real lighting w/ shadows that complement the dark mood of an underground tunnel system
Physics-based particle effects for crumbing rock, cave-ins, or even ragdoll character animations.
An environment similar to Diggles' (neat game I found in the bargain bin one day; suffers from terrible engine bugs)
The ability to zoom in/out
The ability to go into first-person view, ala Dungeon Keeper

You know, Diggles is worth talking about. This game is very close to what I envision Vyde to be. But I think Vyde would focus a little less on resource management and more on exploration. But the variety of gadgets and "rooms" available in Diggles is very inspiring. I've never tested to see how far out you can go in Diggles... for all I know it's boundless.

What do I know about picking an implementation?

I can program in any language, but I like some more than others. Similarly, I can eventually write any kind of engine, but as I mentioned in a previous post, I want to focus on experimenting with gameplay instead of hacking through technology. So things like Managed DirectX intrigue me. I wonder if a game like mine could be written in C#.NET? How would the .NET CLR affect the game's performance?

What about game assets?

I'm a 3D Studio + Photoshop guy by nature. But I don't have a functioning copy of either anymore. I'm moving into a new, better-paying job soon, so maybe by the time the serious art needs come around, I'll have those kinds of tools.

Source control?

Now might be the perfect time to try my hand at Subversion, recommended to me by my old college buddy Eric. I've been using CVS for a little less than 2 years now, and I think I'm getting tired of it. Don't really feel the need to invest in something like SourceSafe, though its asset management features may deserve further investigation.

Using an existing engine? Hm. I'm torn on this one. On one hand, I want to concentrate on gameplay, not technology. On the other, I always need an excuse to keep my programming skills up, and I'll admit I'm curious to see what the process of building an engine is like. But I don't feel like I'm quite ready for it yet. Still gonna take a look at PopCap's engine.

Modularity

If I go with building my own engine, how modular to I want to design it? Theoretically, I could really go nuts and build an engine whose 2D/3D renderers were interchangeable, but I think that's probably more trouble than it's worth. But in general, building an engine would definitely stretch my OOD muscles.

Another article to read: 3D Pipeline Tutorial

Sandboxing

How can I design, from scratch, an engine that is especially suited towards sandboxing gameplay features? Scripting comes to mind. Level editing in-game comes to mind, too. I remember the old DOS game Abuse. It had a really sophisticated scripting system and level editor built into the game, invokable with a menu command. That is, you could pause the game and begin editing the level right around the bullets and characters suspended in pause. Very cool. I'd like to be able to have some kind of in-game console or GUI instrumentation that would let me inspect things in the playfield and alter their properties. Be playing the game, pause and enter edit mode, right-click on a shooter to discover its fire rate, alter it, then resume playing and see the effect. An architecture that facilitates this would, to me, be worth its weight in gold. But it would demand a sophisticated GUI... hm.

Resources: FlipCode & Game Engine Anatomy 101

2005-05-30T00:38:00.000-05:00

Flipcode is a site that the CTO of Cyan, Inc. pointed me to years ago. I follow it regularly if for no other reason than to see the image of the day. http://www.flipcode.org

Flipcode pointed me to a series of articles from 2002 entitled "Game Engine Anatomy 101", starting at http://www.extremetech.com/article2/0,1558,594,00.asp.

I'll be looking into PopCap Games' freely-available game engine later.

...

In looking at PopCap's site, I discovered a new game that I liked well enough to buy: Heavy Weapon! This game is great. Pure mayhem!

Vyde is Born

2005-05-29T23:06:00.000-05:00

Well this will be interesting. A blog about a video game -- designed, written, produced, and catered by me.

I'm keeping this blog as a log of my progress for two reasons:

So others who might be interested in learning about my progress can keep up on it, and maybe learn from it, and
To motivate myself.

So here's the setting:

Vyde is the name I've chosen for the game I'm making. The name has no special significance; it's pretty much a made-up word that I thought sounded like a place.

Vyde, as an idea, started back in college. I was a member of Georgia Tech's video game club, Entertainment Software Producers (ESP). Back then, I fancied myself a game designer rather than a game programmer, and came up with an idea for a 2D side-scrolling game involving a randomly generated, boundless map. The game was to serve as a research project, with the goal of answering a few different questions, but mainly this one:

What are the gameplay implications of a game whose playfield has no boundaries?

I've always, always been frustrated with artificial boundaries in games. Like that fence that encircles the first level of Diablo II: why can't you just hop the fence and keep going? Or the ocean in GTA: San Andreas: you've got a bloody plane, why can't you see what's on the other side?

Of course we know the answers to these questions -- the games have boundaries, artificial or otherwise, to accommodate things such as resource limitations and directed storylines. But I've always been a fan of sandbox games, and have felt a compulsion to blend sandbox games and directed action/adventure games. Imagine SimCity with "GTA mode".

So Vyde is a philosophical quest. Can such a game be made compelling and fun to play? What would keep a player coming back for more? Is such a game suited for a 2D world or a 3D world? What must the interface be like?

Now then. With the philosophical foundation in place, I've spent another part of my CPU time coming up with a theme. I want something that I can stick to for artistic guidance that keeps the game from being just a tech demo once it's actually buildable. So here's what I've come up with...

Vyde is a mining game. The player(s?) assumes the role of a miner(s?) in an underground environment. The player will have the ability to interact with the environment, which shall be dynamic in many ways, and the creatures that inhabit it, whose motivations are so far undefined. Elements of the world (geology, flora, and fauna) will have autonomous properties that exact change in the environment without player interaction, thereby keeping the game fluid -- ever changing, rarely static.

This description satisfies me in that it provides an interesting canvas with the following characteristics:

It lends plausibility to the concept of infinite space (a vast network of underground tunnels and cavers) without resorting to the tres chic outer-space.
As a starting point, constraints on the variety of elements of the world are easily chosen. That is, you've got a lot of room to brainstorm on elements like story, the environment, creatures, artistic styles, etc., without fear of becoming uninteresting. At the same time, you're not saying, for instance, "The game shall be set in space," which has absolutely no boundaries and way too much possibility, which to my mind stymies design by introducing too much "What if I included _____? That can happen in space," and thereby overloading my brain and making me want to go do something mindless, like play City of Heroes. :)
I've always been fascinated with mining, and environments that mimic it. Metroid is my favorite game of all time because of how I feel about the claustrophobic, alien nature of it. It's safe to say that Metroid shall be a major source of inspiration for this project.
The description (and any description like it) does not enforce a particular point-of-view (2D/3D) or interface approach. I want to keep implementation an unmade-decision at this point. Not enough design has happened yet. However, so far, all my thoughts on Vydehave led to a 2D side-scrolling mindset. A game that lends itself to a 2D, side-scrolling gameplay style serves as a good starting point for a hobby-level project. Ultimately, I want to concentrate more on gameplay theory as my exploratory domain rather than technology, as the latter is often dependent on the state-of-the-art. That, and I want to be able to play this thing quickly, and use the immersiveness of the work-in-progress to both reinforce the immersion and fuel brainstorming for additional features. I do not want to focus my initial efforts on building the next great 3D engine, or developing the next great geometry streaming technology. (I've even considered developing the prototype in Flash. More on that later.)
It mandates variety and an aspiration towards continuous evolution. (After all, this is gonna be a hobby.)

Now then, what I plan to include in this blog is whatever pops into my head during this adventure. Articles I've read, games I've played, ideas I've had (and ideas I've shelved), technologies I try, screenshots, links, code samples, and more. A veritable "whatever" of design history documentation.

I hope I enjoy doing this as much as you enjoy reading about it.