I realize that the existence of an ancient D20 in no way implies the existence of ancient role-playing games.

(Although I am totally grooving on the idea of a bunch of dorky Romans playing a game of Advanced Greeks & Gods, Second Edition...)

But it makes me wonder: What (& when) was the world's first RPG? I'm thinking of a concrete game, with rules and an unpredictable outcome, not just an group story.

Hmm...

Good question ... I'm going to ask some friends who design board games if they know.

It may very well be that Gygax et al "invented" the RPG as it is. They were using strategic skirmish rules (play by mail), and miniatures rules, and someone among them wanted to make a "character" out of their miniature, thus the rules were created for individual PCs. They most likely formalized it first.

Though, as a loose form of play, roleplaying may be built into us, from dolls and army figurines to plastic pegasi and LEGO minifigs, children are constantly playing out scenarios as a group.

I am just surprised that the d20 is that old. I definitely thought those multifaceted die were a modern invention, created in conjunction with D&D. The dice are one of the things that make the game so compelling (quote unquote "we are gambling with our character's lives".) If I were "loaded", I would definitely buy the green d20 and use it in my games as a wondrous relic bringing fortune and doom to all who roll it.

What's the THACO on a Christie's Auctioneer, anyway?

Plato and Pythagoras wound solid geometry and philosophy and mysticism together. Divination frequently relied on what we would think of as chance. This might have been carved for a complicated game of craps, or for a kind of fortune-telling, or something between.

Tarot is, was, a game too.

Surely someone now uses RPGs for divination or advice.

The Romans played all kinds of dice games. Originally they used sheep knuckles. That said, a 20-sided die is basically a random number generator, more suited to divination, as noted above, than "simple" games. "Exotic" religions were both popular and not entirely legal in the second century, so it makes sense that they would resort to less public techniques than entrail-reading on the Capitol.

Here are some freaky meditations on polygons, platonic solids, and dice for RPGS.

http://members.aol.com/dicetalk/polymore.htm

There was a recent RPG set in ancient Rome that used traditional Roman knucklebone dice to resolve actions.

The game is called Fulminata and here is the URL.

Dude, that rocks. Where'd you find that?

Nice site. thx.

That gives us a pretty good starting point to understand a lot more about variables, and that's what we'll be examining next lesson. Those new variable types I promised last lesson will finally make an appearance, and we'll examine a few concepts that we'll use to organize our data into more meaningful structures, a sort of precursor to the objects that Cocoa works with. And we'll delve a little bit more into the fun things we can do by looking at those ever-present bits in a few new ways.

Seth Roby graduated in May of 2003 with a double major in English and Computer Science, the Macintosh part of a three-person Macintosh, Linux, and Windows graduating triumvirate.

Inside each stack frame is a slew of useful information. It tells the computer what code is currently executing, where to go next, where to go in the case a return statement is found, and a whole lot of other things that are incredible useful to the computer, but not very useful to you most of the time. One of the things that is useful to you is the part of the frame that keeps track of all the variables you're using. So the first place for a variable to live is on the Stack. This is a very nice place to live, in that all the creation and destruction of space is handled for you as Stack Frames are created and destroyed. You seldom have to worry about making space for the variables on the stack. The only problem is that the variables here only live as long as the stack frame does, which is to say the length of the function those variables are declared in. This is often a fine situation, but when you need to store information for longer than a single function, you are instantly out of luck.

When the machine compiles your code, however, it does a little bit of translation. At run time, the computer sees nothing but 1s and 0s, which is all the computer ever sees: a continuous string of binary numbers that it can interpret in various ways.

Note the new asterisks whenever we reference favoriteNumber, except for that new line right before the return.

We can see an example of this in our code we've written so far. In each function's block, we declare variables that hold our data. When each function ends, the variables within are disposed of, and the space they were using is given back to the computer to use. The variables live in the blocks of conditionals and loops we write, but they don't cascade into functions we call, because those aren't sub-blocks, but different sections of code entirely. Every variable we've written has a well-defined lifetime of one function.

When the machine compiles your code, however, it does a little bit of translation. At run time, the computer sees nothing but 1s and 0s, which is all the computer ever sees: a continuous string of binary numbers that it can interpret in various ways.

When compared to the Stack, the Heap is a simple thing to understand. All the memory that's left over is "in the Heap" (excepting some special cases and some reserve). There is little structure, but in return for this freedom of movement you must create and destroy any boundaries you need. And it is always possible that the heap might simply not have enough space for you.

When compared to the Stack, the Heap is a simple thing to understand. All the memory that's left over is "in the Heap" (excepting some special cases and some reserve). There is little structure, but in return for this freedom of movement you must create and destroy any boundaries you need. And it is always possible that the heap might simply not have enough space for you.

But some variables are immortal. These variables are declared outside of blocks, outside of functions. Since they don't have a block to exist in they are called global variables (as opposed to local variables), because they exist in all blocks, everywhere, and they never go out of scope. Although powerful, these kinds of variables are generally frowned upon because they encourage bad program design.

Inter nos - Between us