[MUD-Dev] When is the game a game?

[Travis Casey]

On Tuesday June 26, 2001 14:40, Caliban Tiresias Darklock wrote:
> On Mon, 25 Jun 2001 22:49:23 -0400, Travis Casey <efindel at earthlink.net>
> wrote:

>> Well, my point of view is rather on the philosophical end -- that
>> it's a game from the time that it first *could* be implemented.

> I was thinking along those lines, but then you sort of run into
> the "vaporware" thing.

Well, there's vaporware and there's vaporware.  A game could be
developed to where people were playing it internally, but it didn't
have all the features it was supposed to be released with -- and as
long as it's not released or shown to anyone, it's vaporware.

In other words, there's a long way between an idea and the completed
form of that idea.  At some point in that stretch, the idea becomes
a game.  I think it's when you've designed it to the point that
someone *could* play it, or something that would be a lot like it.
Others' opinions will differ, of course.

>> I've heard arguments that a game is the game system + people
>> playing it -- but we don't call the boxes on the shelves in
>> stores "game systems" or "potential games" -- we call them games.
>> That implies that they are games even when there's no one playing
>> them.

> I've been thinking along the lines of "what is a game?" and the
> answer keeps coming back "something you can play". So I've been
> thinking, when does the game become something you "can" play?

That's hard to answer... it depends on the order that you do things,
and, more than that, it depends on what you consider "play".

Let's try a concrete example.  It's easy to get in trouble this way,
but I'll try to be general.  :-)

Consider a 3-d shooter, along the lines of Doom.  The game designer
specs it out, and the development team starts working on it.

First thing they do is make a simple walk-through display: no fancy
graphics yet, but it takes a file that represents a level, displays
the level, and lets you move around in it.  Is this a game?  Well,
to someone who enjoys maze games, it might be.  To someone who
doesn't like maze games, but does like shooters, it might not be.

> Take, for example, the corollary example of a Diku server with no
> areas installed. Is this game complete? Certainly, you cannot play
> the game as it stands, but you don't need to add *game* to
> it... just data.

I would say it is a game -- just one without a scenario.  Without a
scenario, the game may not be playable... but then, without other
people, Monopoly isn't really playable, and most people will call a
Monopoly box "a game" rather than "a game system".

(Now, one could easily say that game developers need more precise
terminology -- and I'll happily agree with that.  Right now, though,
I'm talking about "a game" from a fairly abstract point of view.)

> Or look at a P&P RPG. Without an adventure of some sort, is the
> game complete? Given the three "core" AD&D books -- Player's
> Handbook, Dungeon Master's Guide, and Monster Manual -- do they
> comprise a game?  How much can you strip out of the game before it
> stops being a game?

I'd say that D&D is a game, even without a scenario -- you can
substitute a GM who's capable of making one up as he/she goes along.
(Such a GM doesn't come with the game?  Well, again, players don't
come with a Monopoly game...)

> Is a set of polyhedral dice a game in and of itself, even without
> a set of rules?

To this, I'd say no.  You can easily *make* a game with them, but
they are not a game in and of themselves.

> Is a set of rules which uses those dice a game, even without the
> dice?

I'd say yes.  If someone handed you a Monopoly set without any dice,
would you say, "This isn't a game", or "This game is missing its
dice"?

>> Thus, it seems very arbitrary to me to consider it not to be a
>> game until someone actually codes it.

> I would tend to agree... but then the question of "playable"
> starts to get messy. My system includes an autopilot, which is
> easy to implement on a computer. But by hand? You MUST be joking.

Now we're getting into the category of "complete" vs. "incomplete"
games.  Your game may not be complete without the autopilot... but
does that mean it's not a game without the autopilot?

To put it another way, if you'd implemented everything in your game
but the autopilot, would you say that it wasn't a game yet?

> You can't even map out the game universe in three dimensions; it's
> non-Euclidean by nature. You probably couldn't even map it in
> four. As a mathematical construct handled by a machine, it
> works. As a physical construct examined by people, it just plain
> doesn't.

What does that have to do with anything, though?  I've run D&D games
that had dungeons that could not be mapped in three dimensions, and
probably couldn't be in four.  Heck, I've run D&D games in which the
dimensionality of a structure changed during gameplay.  Not being
able to map something in three dimensions doesn't mean that it has
to be handled by a computer.

> Which leads to a corollary question: is a game that sucks still a
> game?  How much can it suck before it crosses the line? ;)

I know you're joking, but you answered your own question -- "a game
that sucks" must be a game, or you'd have to call it "a game-like
thing that sucks."  :-)

--
       |\      _,,,---,,_     Travis S. Casey  <efindel at earthlink.net>
 ZZzz  /,`.-'`'    -.  ;-;;,_   No one agrees with me.  Not even me.
      |,4-  ) )-,_..;\ (  `'-' 
     '---''(_/--'  `-'\_) 

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev