| Daniel Lepage on 28 Mar 2003 01:20:01 -0000 |
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
| [spoon-discuss] Lots of stuff |
-------------------- On Pooker:It's a nice idea, but that's really an A Nomic thing. If nothing else, the proposal ought to be giving most of its passage points to Rob, as it was really eir idea, IIRC. But also, that was A Nomic. This is B Nomic, and although we may share a player or two, and may be run off the same server, we're not the same game, and I think I'd like to avoid taking too many ideas from other games.
Besides, I had some other ideas for cards, that make them more like Magic Cards than Poker Cards.
-------------------- On Multiple Grids: It would be interesting, certainly.On the multiple location issue, I would suggest each player existing on only one Grid at a time; perhaps 'avatars' could be purchased/earned/otherwise obtained to allow players to act like they were on multiple grids at once. On the defining objects for them issue, I would suggest making 'classes' of Grid Object; a given Grid might allow, say, all class-A objects, and nothing else, or all class-C objects that can be produced by Mixing Gnomes, plus all class-M objects that cannot be destroyed, or things like that. Alternately, the Grids could have classes; so a Bomb Gnome might only be useable on D-class Grids, or Force powers could only affect objects on A,B,or F class grids. That sort of thing.
Or maybe both? An entire new Grid could be created by saying, "There exists a 12x5 C-Class Grid open to class D,E, and A objects called the Foo Field." Other general properties could be more efficiently expressed as a chart: Name Class Objects VoidLevel Size Covered DefaultSubst DefaultElev
Foo Field CE AEF -10 12x5 No Turf 2I'm imagining a standard method for creating new Grid objects based on charts, as well:
Name Subst Mass Complexity Type Value Special Spiked Club Wood,Metal 4 1 Weapon 15 NoneMine Metal 3 5 Other 60 Armable, Triggerable Surg. probe Metal 1 12 Tool 50 Repair(2), Analyze(8)
Perhaps we could even establish an SQL table containing all Grid Objects and their properties, for easy lookup and storage.
On the lots of squares without multiple Grids idea:I had at one point planned a 7200 square grid. The idea was that the current grid would be expanded to 60x60 by adding a 20-wide swathe of water around it, making it an island. Smaller islands could then be created within these bonus 3200 squares; for any sort of war-based subgame, this would be excellent, allowing oceanic vs. landgoing units, tidal control spells, and volcanos to come into play, among other things. The other 3600 squares would be another 60x60 grid *underneath* the first one; most of these squares would be filled in, and thus inaccessible (those under the islands), but the rest would be the 'underwater' level; then underground waterways could be carved running under the main islands; I envisioned strong, fast currents running along these, so that any Speeder equipped with a waterproofing could go in at one end of a tunnel and come out almost instantaneously at the other end. Tunnels could be drilled from the surface of an island down to the underworld waterways; thus, if you were in a fortress under siege, and you knew that any moment your walls would collapse, you'd be captured, and something bad would happen to you, you could blow a hole in your fortress and escape through the nautical maze under the Grid. With special upgrades on your speeder (or perhaps with a high enough strength and race Merfolk) you could swim upstream to escape people who couldn't follow you, and let timed explosives be carried back towards your enemies by the current.
But that might overcomplicate things. --------------------- Okay, next issue: Rules on the GridI don't think every rule should be on the grid (do we even have enough squares?). But some rules, I think, would be very interesting on the Grid. Certainly Rule 10, for all the argument it's caused, would be an excellent Rule to have a war over.
Both this and the idea of Rules as living things would, IMHO, be ideal uses for the Level system - one Level could be reserved for Carryable Rules, another for Living Rules, etc.
Living Rules might better be implemented as a Subgame, though (perhaps if INH ever got going again?)
---------------------- What Gets Reset in a Reset?Personally, I think that the total leveling of the field is a bad idea, if for no better reason than that it means that someone who's invested a lot of time and effort in improving eir position in the game is, once a Reset happens, in exactly the same situation as someone who just joined a week ago and hasn't done anything since.
I believe that certain intrinsic properties of players should be kept through Resets, because otherwise things like the Force which can take a long time to build up, become worthless - if it takes three nweeks to get up enough force to advance to the next Jedi Level, and you get reset to Untrained every five nweeks, then why bother?
To bring back the WarCraft III analogy, yes, in a battle between two armies where all else is equal except that one has a level 10 Ogre Mage and the other only has level 1, it's more likely that the level 10 guy will win. But when is all else ever equal? Having nine extra levels on your champion doesn't help if you're attacking a fortified base with an army otherwise identical to the one behind the guard towers. And even in a straight out battle, if the level 10 guy sends all eir troops plunging straight at the other guy, while the level 1er lays a bunch of stasis traps and bombards the enemy with catapult fire and headhunters without losing any troops, the 1er's gonna win. Having a bigger hero is by no means the deciding factor in Warcraft, nor should it be in B Nomic. While a veteran player may be able to cream a newbie in one on one combat, if the army/fortification system is well set up, the real battle will be decided by who's best at using what they have, not by who can pick up a gnome from two squares away.
This is not to say that *all* abilities need to be kept through Resets... One interesting approach I found in a game called "Rumble", which was based on the idea of superheroes beating each other up for no particular reason. The idea was that before the game started, every player would come up with a couple 'Super Powers', which could be anything they wanted, from "Every turn, gain three hit points" to "if you get up and do the chicken dance, every other player must do the same or lose 30 hit points." These abilities were then put into a pool, and one by one they were pulled out. When an ability was pulled out, each player would write down how much they were willing to pay for that ability; all players would reveal their bids simultaneously, and whoever bid highest would lose starting hit points equal to eir bid and gain the ability.
What if some special abilities were passed on like that? So at every reset, we could all bid on who wanted to take over the Ministry of the Force, or Wealthy Bastard Enterprises; you could get instant promo to Jedi Lord, or control over the sale of Speeder parts, but you'd have to pay more than anyone else was willing to to get them....
--------------------- On the Uber-PropI've been thinking about standardizing and generalizing much of the current system, and it seems to me that the best way to do that would be to create a new class of Object, call them New-Style Objects or NSOs, which have certain properties that eventually, all objects will have. The idea is that changes could be made in how NSOs behave to generalize things; while this was happening, other objects could be ported from Old-Style Objects (OSOs) to NSOs. Once the transition is complete, the Old-Style rules could be deleted, and NSOs could stop being called New-Style Objects, and just be called Objects.
This would make the transition fairly easy, and wouldn't require a single massive overhaul prop.
For that matter, we could create a second Grid using the guidelines put forth in the Uber Prop, and move things from Grid 1 to Grid 2; then scrap Grid 1.
Just for the record, I got the above idea from Python, where a new, easier to manipulate class of object is being introduced; the idea is that eventually, all objects will be derived from this class instead of the current base class, but right now the older class is still hanging around for compatibility purposes.
--------------------- On a GuideYou know what would be helpful, if the grid is going to become obscenely complicated in the near future? An Object Guide. It could be stored as part of the object database mentioned above - under, say, Big Stick, you'd find it's mass, type, uses, and a 'description' string, which might read, say, "The Big Stick, as the name suggests, is simply a large piece of wood. Specifically, they tend to be about three feet long, thicker at one end than the other, and somewhat bumpy and rough-hewn. It is the crudest weapon to be found on the Grid, being useful only to hit things; as such, it is very simple, and requires almost no intelligence to use. Naturally, Ogres love it.
Big Sticks can be found pretty much anywhere, and there is almost always at least one on the Grid at any given time."
If we had a basic syntax system, such as those employed by Wiki pages, such entries could be made to contain tables, links to the other objects they mention,
-------------------- Closing RemarksUm... I don't have any Closing Remarks, except to request Comments from anyone and everyone, about anything and everything.
How's my vision look? -- Wonko _______________________________________________ spoon-discuss mailing list spoon-discuss@xxxxxxxxx http://lists.ellipsis.cx/mailman/listinfo/spoon-discuss