Thursday, December 18, 2008

Procedures (part 4) - your ever growing world


Thankfully, this post is going to be a fairly short one. Continuing with the ESNA (Epic Solitaire Notebook Adventure) theme. Ultimately, we are pretty much done with the heavy baggage of the "procedural" elements of the game at this point. But I might as well finish the game up. So....

As noted in the previous post, the basic turn structure is A)move to a new Region, then B) draw a card to see if an event happens there, based on matching up the land icons on the card with the region where the player is currently at. While the last post contained all of the information required for basic monster creation and handling (although not combat), which is run using the letter symbology, the question remains: "What happens if you draw an event that ISN'T a letter?" As say, for example in the card to the left here?

The +1 icons are a good thing. Instead of a creature encounter, this allows you to add or improve buildings to your little paper empire.

There are three types of buildings in the game: Villages, Temples, and Castles. You've already started with a Village when the game began. If you are in a Region where an Event DOESN'T happen, then you "visit" the building in that Region (if there is one) and perform the special actions that those Buildings can trigger.

Villages allow for rest, which will restore lost Health.

Temples allow for study, which increase your character's Level.

Castles allow for Quests, which let you go on specific "adventures" to gain big gold and magical treasures.

Getting a +1 icon from an Event card let's you build a new Level 1 Building of your choice in any Region that does not currently have a Building. Only one Building per Region please! Or, you can increase any pre-existing Building's Level by 1, up to a maximum of 10.

At this point, the game needs to have a bit playtesting to determine the best cost ratios for each action that the buildings can provide. But it's best to start simple.

Resting at a Village:
Paying 1 gold to a Village will restore an amount of Health equal to the Village's Level.

Study at a Temple:
Paying "100 times the desired next level" in gold at a Temple will increase your character's Level by 1, and increase your character's maximum Health by 50. Additionally, you cannot increase your character's Level beyond that of the Temple's Level.

Example: Increasing your character's Level from 2 to 3 would require you to find/create a minimum Level 3 Temple. Pay 300 Gold at that Temple, to increase.

Creating Quests are worth another post. But the only thing that's missing from this being playable is combat. So that will be coming next.

Labels: , ,

Tuesday, November 11, 2008

Following the Procedures

Recently, a much-awaited digital game FINALLY hit the market. Spore, by Will Wright, for those who aren't aware of it, is another in the long line of his sandboxes. While these types of games have game-y elements, there is no main goal or story to complete. Granted, Spore does have this in a small amount: the object is starting with a single cell organism, eventually evolve and go off and conquer planets. However, it's really more about mucking about, and seeing what happens.

What makes Spore unique is the way that the data is handled. Instead of having massive teams of artists developing massive amounts of content for the various races, creatures, globs of primordial ooze, etc, all of this is handled procedurally. Basically, creatures aren't defined by what the artists make them look like, but instead, by simple software definitions of said creature, and the program just "figures it out." This allows for immense flexibility, as you just apply a few random numbers to a creature template, and TA DA, you have a living, breathing creature that knows how it's supposed to walk, fight, and otherwise generally behave.

What does this accomplish? Well, for one, size. The game doesn't need to have a bunch of pre-programmed walk motions, designed specifically for a pre-drawn animation cycle, designed by an artist. It just needs to know that the creature has three-legs of X size. Since artwork and texture are generated on the fly from this thinking, there's no need to have to import 100 Megs of texture images. It's just created as needed.

Additionally, this allows the users to make infinite combinations of creatures, without having to deal with creating their own textures and monster-shaped polygonal meshes. And once on the internet, suddenly there's millions of creatures, all defined by users, polluting the in-game universe, with very little "real artists" getting their hands in the mix.

One of the more imaginative side effects of this is the way creature data can be moved from one player to another. Since creatures are defined by various database attributes (as opposed by pre-created artwork), the file size of any creature is REALLY TINY. Sharing a creature is as simple as "taking an in-game picture" with the camera tool, and forwarding that image to your friend. What the game does is store all of the creature attribute data in the alpha channel of the picture; what is amazing about this is that all of the data that it takes to accurately replicate a creature is actually smaller, file-size, than the JPG IMAGE OF THE CREATURE ITSELF!

In fact, it is so easy to move creatures around is that if you want a creature from the Spore website, you simply drag the image from the website into your Spore program. Quite amazing stuff. (I've been amazed at this kind of stuff before, feel free to click this link.)

Anyway, what can we learn from this, in a table-top world. Obviously, when you are talking about player-creation, a few notables come to mind, such as Dungeons and Dragons, or really any game out of the RPG genre. But there's an interesting table-turning factor here; while Spore is a world where users create all of the elements in the world. D&D seems to be, aside from some character creation aspects, where the players create the world, and populate it with pre-designed denizens from a Monster Manual. I'm not saying that all D&D groups do this; I'm sure there are many out there that truly build a complete world on-the-fly; but most of the money made on RPG is based on creating a system, and then having the players buy countless expansions of new content, as opposed to creating their own.

So, where am I going with this?

One of the secrets of a successful print-and-play game (successful being a term that is rather fungible in this genre) is having a tiny component list; the less components that are required to print out and cut and paste and prepare, the better. No one wants to spend 3 hours building a game that isn't potentially fun; but maybe if it took the player 15 minutes, it's worth the risk of the time.

However, typically, a simple component list also waters down the game a lot, down to a simple game (unless it's some wacky abstract, where the depth of play comes from a more analytical nature). So, the question arises, how do you make an interesting, long-playing game with as little components as possible?

A completely viable solution to decreasing the component list is reducing as much data as you can to being procedural, as described above. In other words, the game should not necessarily come with all of the data pieces, but instead should just have the required rules to build the data units as you need them.

Aside from compactness, this also creates a game where each game is unique. You don't need expansion cards later to "refresh" the game, as the game constantly refreshes itself through the building of the data as you progress....

Soon to come, part 2, an example game....

Labels: , , ,