Skill System

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.

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

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

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!

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

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^256256... 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

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

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

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:

1. Gameplay, Mechanics, and the Vyde Canon
2. Editability
3. UI
4. Asset Development
5. 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:

1. 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.
2. 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.)
3. What drives the inhabitants of the Vyde mine?
4. 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

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

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

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

Everybody go play the games at Experimental Gameplay right now.

Off Topic: Call for a Thin Keyboard

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

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

Recovering From a Brainstorm

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.