[MUD-Dev] Containing automation?

[Ling]

On Mon, 26 Jul 1999, Caliban Tiresias Darklock wrote:
> On 01:39 PM 7/25/99 +0100, I personally witnessed Ling jumping up to say:

> >Lately, I've had a huge leaning towards having an actual R&D cycle.
> >
> >Player submits design, game time passes whereby the thing is "designed".
> >Player gets feedback on feasibility, he then gets to alter the design or
> >carry on.  Prototype is built, tested to expose limitations (or not as the
> >case may be).  Done.
> >
> >The main reason was to not overwhelm the player with options on designing
> >a vehicle.  Just limit the choice to a few types then let the player
> >design more later.  It also turns blueprints into a commodity.
> 
> But doesn't this fall prey to Mac syndrome? You pull it out of the box, and
> it's easy to work with... but then you get under the hood and it's so
> tremendously complex that you may as well not even bother. I would expect
> some few people will design blueprints, and that one blueprint will
> eventually be viewed as the top end of ship development. This one blueprint
> will be the goal of every player, they'll all buy one, and in the end you
> may as well not have had ship design in the first place. 

Hope not, the design process I've got in mind involves a significant
amount of GM intervention.  The design is submitted rather than done by
following some sort of rigid construction system.  It is more akin to
going to a department and saying: I want a tracked vehicle to send into
the jungle with space to hold 10 researchers for a duration of a week and
an operational range of 2000 miles with the following equipment.... 

Intellectual work on behalf of the players should not be too much. 
Provided they don't ask for something outrageous, what would be needed is
a lot of game resources (ie: game money) and patience to wait for
something to be developed.  The advantage is that the GM can take time to
evaluate the design and its impact on game balance.  If the GM doesn't
like it, the development can either take lots of time and/or money or the
prototype could have some (crippling) flaws.  I would give the prototype
some flaws anyway for game colour.

> This is sort of like what happens with computer software. Lots of people
> make word processors, but the general consensus is that MS Word is the one
> to use, so only MS Word does any significant business. Compare office
> suites, development environments, graphics programs: on a Windows PC, these
> are virtually synonymous with MS Office, MS Visual Studio, and -- to add in
> a non-Microsoft product -- Adobe Photoshop. Even though there may very well
> be better products available depending on your needs, doesn't the
> complexity of finding such products pretty much mandate picking the one
> everyone else uses? 

Since the end design is out of player hands, the GSV Ultimate Ship the
Second is not possible.  It is kinda like the original Battletech 2025
catalogue of mechs.  They were all flawed, you just worked with what you
liked best, no one had a definitive choice.  By making your own and
specifying parts to the final bolt, it could be tailored exactly.

> Okay, player-owned ships don't have compatibility issues. ;)

Always worth considering writing it _in_ to enforce in-game brand loyalty
to particular manufacturers.  Like how some Rl manufacturers use custom
nuts and bolts so it has to be serviced by only certain people.  Then
again, I want to have brand names in-game.  You may differ in desires.

A desirable side effect of this blueprints idea is that designs evolve
since it would be cheaper and easier to evolve a design.  For gearheads, a
design really would have a history that isn't just made up.

> >On Sun, 25 Jul 1999, Caliban Tiresias Darklock wrote:
> >
> >> The real key to this plan is that any and all of those forty devices can be
> >> removed or replaced at any given time. You may, for example, go out
> >> exploring and need a vast number of unusual sensors on your ship. Since you
> >> don't need them all the time, when you decide to go into sweep-and-clear
> >> mode and run around killing everything, you can sell or discard the sensors
> >> you don't use often and replace them with weapons. When you log off for the
> >> evening, you can discard some of your weaponry and replace it with ship
> >> defenses in case of ambush. 
> >
> >I've gone for the one drone = one function model where a ship would hold a
> >zillion drones to do the work.  Kind of similar with different fluff
> >around the edges.
> >
> >What ever happened to the Star Trek mentality of "recalibrating" the
> >sensors? :)

[snip realism and writing a full blown simulation engine plus the lack of 
fun in that for both player and coder]

I was only joking, I was referring to the concept that one sensor suits
all as opposed to having a sensor for each and every item type.

Since I take the latter approach of having specialised drones for every
operation, I'll be a hypocrite for seriously suggesting having some sort
of reality where you have to analyse the environment to identify even the
simplist items. 

> >> We've discussed a change in which we would split the available devices into
> >> "hardware" and "software" devices, with some devices needing both hardware
> >> and software, but I'm holding off on this concept for the moment because it
> >> may be too complex for people to understand.
> >
> >How about all devices are hardware things but can be augmented with the
> >addition of software.  Or maybe have software that uses devices in novel
> >ways...
> 
> The recalibration idea actually led to this thought, since it seems

Odd but untrue, I wrote the above paragraphs in reverse order.  Maybe my
mind made the connections before I figured what was happening.

What I mean by having software use devices in novel ways is say putting a
sensor and some sort of utility device together with the right software
turns it into a weapon

> reasonably obvious that a great number of sensors are really just software.
> The bandpass filter example above, for example; obviously there's a little
> more than that involved, for various reasons. But you should be able to
> just stick a card in your ship's computer and have it figure out how to
> report the trace wormhole energy *as* trace wormhole energy. It's not that
> you can't see it, after all, the computer just doesn't know what it is.
> While a laser battery or missile platform is obviously hardware, the
> targeting of such a device is software. While it seems like a good idea in
> theory, it may just be too much for most players to grasp.

I wasn't thinking of software as in scripting.  Just as another game item
to be bought, sold and bartered.

What you could do, instead of taking today's stance on software which is
easy to manipulate (read: copy), make it come on chips.  Say the
equivalent of ROM or biological wetware, then you have a good reason for
not letting players copy software in-game.  Software then becomes an item,
not information.

> Likewise, to many players it may seem intuitive that if you can *buy*
> software, you can *write* software. Unfortunately, for every player like
> us, there will be dozens who are unwilling or unable to write out complex
> scripting functions to automate their ship. This also leads to the
> possibility of people thinking so far outside the box that they destroy the
> balance of the game; it creates so many thorny issues, I just don't really
> want to open that can of worms.

If software means scripting, yep.  Otherwise, no.  You can't really do
much if all software did was give a +1 modifier.

I might like my games to be ridiculously complex but when I design games
for others to play and _enjoy_, I strip it down on the outside and make it
look simple.

  |    Ling Lo
_O_O_  In flux, please use: kllo at iee.org





_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev