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?