Jake Eakle on Wed, 29 Nov 2006 01:32:31 -0700 (MST)


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [s-d] RFC: The Grid


I love it! I really like the starting map framework - this could even allow
us to have multiple, widely varying sorts of Grid game at the same time.

It would probably be good to have each starting map define its own timing
rules, and team divisions, too - for some games, you might want to be able
to have one-move-a-day free for alls, and in others you might want one team
moves once every nweek.

It looks like it will take some work to make it happen, but if we start
simple until we get the hang of it I think it'll be great.

On 11/29/06, Daniel Lepage <dpl33@xxxxxxxxxxx> wrote:
>
> The Grid failed not only because it was hard to maintain, but also
> because it was hard to follow. The display became very difficult to
> read once lots of objects and properties started piling up in
> different squares, and it was irritating to re-count squares all the
> time to make sure you were taking the action you thought you were.
>
> I would like to suggest a smaller gridlike game, one that I suggested
> a long time ago but never followed up on. Being short on time, I'm
> not going to write a new description of the idea, but instead I'm
> going to copy from my original message:
>
> 1) It's a partially cooperative game. The players would be divided
> into three teams, and various aspects of the Grid would encourage
> cooperation between the teams and within the teams, while other
> aspects would encourage competition between teams and between
> individuals within a team.
>
> 2) It's round-based: we define a 'starting map' for each round, which
> is an initial state of the grid, plus a list of 'goals'; when all the
> goals are completed, the round ends, and a new starting map is
> selected; the next round then begins.
>
> 3) It doesn't change suddenly. New objects, concepts, and abilities
> could be proposed, but unless special measures were needed, it
> wouldn't be possible to do anything with the new things until the
> next round (and then only of the starting map incorporates them).
> This means that everyone has a bit of time to consider what new
> things do before they get used, and gives anyone who might be trying
> to automate chunks of this a chance to code up objects before they
> need to handle them.
>
> So, for example, we might do something like this...
>
> We define the following objects as Grid Objects:
>
>   * Spawn Points (S): this is where players can put themselves on the
> Grid if they're not on it. Players can only spawn at these points.
>   * Walls (W): this is just a space that can't be moved through.
>   * Blocks (B): These are walls, except that a player can push one
> out of the way if the space behind the block is vacant.
>   * Laser Death Trap (L): if a player enters one of these, e Dies and
> is removed from the Grid. If another object is pushed in, it gets
> destroyed.
>   * Gold Coin (G): if a player moves into a square containing a coin,
> e automatically picks it up.
>
> When the round ends, each player gains 5 points for every coin
> possessed by a member of eir team, and an additional 8 points for
> every coin e possesses.
>
> With those objects, we make a map like this:
> S - G B - B G - S
> - W W - W - W W -
> G W G G L G G W G
> B - G - B - G - B
> - W L B G B L W -
> B - G - B - G - B
> G W G G L G G W G
> - W W - W - W W -
> S - G B - B G - S
>
> We define the following as the goal:
> The round ends when all Gold Coins have been collected.
>
> Then the game for the round would be a race to get all the coins,
> pushing through the blocks to reach them before other players do. You
> want the members of your team to get all the coins; but you also want
> to get more coins than the rest of your teammates. By pushing players
> into Laser Traps, you can cause them to die (perhaps they lose a coin
> every time this happens?). OTOH, it's also possible to get a
> situation where the only way to get a certain coin (and thus to end
> the Round) is to die and respawn at a different point. In such a
> case, each player would want somebody on their team other than emself
> to die and do this, so you'd have fights within teams to see who can
> force a member to go after the last coins first.
>
> While all this was happening, we'd also be proposing new Grid Objects
> and new levels with those objects, maybe using some of the objects
> from earlier levels as well.
>
> When the level ended, we'd vote on which of the proposed levels to
> begin next, and so forth.
>
> Does this interest anyone?
>
> If we also add the restriction that each square can contain at most
> one object, then we could easily use MediaWiki's template system to
> generate images of the current grid. It would require one square
> image for each object, and then we'd do the same thing that the chess
> macro does to make the image (see http://en.wikipedia.org/wiki/
> Template_talk:Chess_position for info on this).
> --
> Wonko
>
>
> On Nov 27, 2006, at 10:29 PM, all players wrote:
>
> > Back in the First Era of B Nomic, a major part of gameplay was the
> > Grid - a rectangular grid of spaces in which players and all manner of
> > other entities roamed looking for buried treasure (or, more commonly,
> > performing elaborate scams centered around the alchemic properties of
> > gnomes). The Grid eventually fell apart, having become far too complex
> > for a single person to keep track of all game activity. Now that we
> > have a wiki, however, perhaps the grid can be ressurected - with the
> > important change that each player is responsible and required to
> > recognize their own grid actions on the wiki.
> >
> > A basic proposal to start us off might be something like:
> > {{
> > Create the following rule:
> > {{
> > __The Grid__
> >
> > There exists a game object known as The Grid. The Grid consists of a
> > 20x20 cartesian grid of spaces known as Grid Squares. Squares may be
> > unambiguously referred to using the notation (x, y) where x and y are
> > integers in the range of 0 to 19, inclusive.
> >
> > Each Grid Square may contain zero or more Grid Objects.
> >
> > The portion of the Game State referring to The Grid or Grid Objects is
> > the Grid State.
> > }}
> >
> > Create the following rule:
> > {{
> > __Grid Actions__
> >
> > Any Game Action which alters the state of The Grid or any Grid Object
> > is known as a Grid Action. Unless otherwise explicitly stated in the
> > rules, when a player performs a Grid Action, e must also summarize and
> > recognize all changes to Grid State on a Public Forum, as well as
> > providing a summary of what Grid Objects are on The Grid and where,
> > and any state pertaining to them.
> > }}
> >
> > Create the following rule:
> > {{
> > __Avatars__
> >
> > Avatars are Grid Objects. Each player may possess at most one Avatar,
> > and each Avatar is always possessed by a player. Should the player
> > possessing an Avatar cease to exist, eir Avatar does as well.
> >
> > A Player may destroy eir Avatar at any time, as a Grid Action.
> >
> > If a Player does not possess an Avatar, e may create an Avatar at any
> > empty Grid Square, provided the following conditions are met:
> > * Eir Avatar has not been destroyed in the past three bdays.
> > * The destination Grid Square does not contain an Avatar.
> >
> > A Player may, as a Grid Action, move eir Avatar from its current Grid
> > Square to any adjacent Grid Square, provided that the following
> > conditions are met:
> > * Eir Avatar has not been created or moved in the current bday.
> > * The destination Grid Square does not contain an Avatar.
> > }}
> >
> > }}
> >
> > At this point we'd declare a wiki page to be the public forum for the
> > grid state or something along those lines...
> > _______________________________________________
> > spoon-discuss mailing list
> > spoon-discuss@xxxxxxxxx
> > http://lists.ellipsis.cx/mailman/listinfo/spoon-discuss
>
> Daniel Lepage
> dpl33@xxxxxxxxxxx
>
>
>
> _______________________________________________
> spoon-discuss mailing list
> spoon-discuss@xxxxxxxxx
> http://lists.ellipsis.cx/mailman/listinfo/spoon-discuss
>
_______________________________________________
spoon-discuss mailing list
spoon-discuss@xxxxxxxxx
http://lists.ellipsis.cx/mailman/listinfo/spoon-discuss