[MUD-Dev2] [DESIGN] Spore and MMOs

Michael Chui saraid at u.washington.edu
Tue Sep 4 21:20:22 CEST 2007


Let's see how many of these I can respond to today. I'm doing this
backwards, by the way.

On 8/27/07, Lachek Butalek <lachek at gmail.com> wrote:
>
> The only issue I can see preventing this from happening - on a
> non-technical level - is possessiveness of success. If I brought my
> hockey team a victory early in the playoffs, I would want to see them
> all the way through to winning the cup. If I capture a flag in a WWII
> sim I don't want some other idjit losing a critical bridge later on in
> the war - that's my success to lose.
>
> If these concerns can be overcome I am convinced that "massively
> single-player" games will be used to great effect in the future in
> many different genres. It would be a free content generator, a
> credible simulation randomizer, and a great community builder.


I agree that that's an issue, but I think that it can be mitigated or even
wholly responded-to by encouraging players to train their own people and
teach them how to play better. The idiot lost a key position? Have a
debriefing session where it's explained how and why he lost it, then have a
sparring session afterwards that lets him try the scenario again.

On 8/27/07, John Buehler <johnbue at msn.com> wrote:
>
> Coming from the MMO side of things, the latter is more or less what I've
> come up with as well.  Instead of quests advancing player state, let them
> advance global state.  Any given quest then needs to be reserved by a
> player
> or group of players so that they can take their shot at advancing that
> global state.  (A quest to change global state can be anything from
> eliminating rats in somebody's basement to assassinating an enemy leader)
>
> With such a structure, the massive game breaks down into a series of
> single-player and multiplayer vignettes, all of which are contributing to
> the global state.
>
> Although this is apparently little more than a variation on questing, the
> sandboxing of players into temporarily-isolated experiences means that the
> exact technology that is used in small-scale gaming can be used to
> entertain
> players who are ostensibly in a massively multiplayer setting.


True, it -is- little more than a variation on questing, but it's a really
important variation.

One of the things I have always hated about MMOs is that you're cast into
the role of Hero, but in truth, you're more like a camper obeying the "leave
no trace" rule. We remember Einstein because he fundamentally changed
physics; but I hear whispers of names of really, really old players and
their mark on the world? Oh yeah, a really cool piece of custom fluff. What?

If you go and slay a dragon, it should stay dead. On one hand, this may mean
that no one else can slay it. Well... too bad. Why should an MMO deliver the
same content to everyone? People aren't all the same. (Counterpoint: people
play because their friends want them to experience the same thing they did.
Response: then make sure not everything is a quest?) If the dragon is dead,
then perhaps a mountain pass opens up and a new kingdom is a possible
starting point for new players.

...I stray from the point. I'm sure this tirade has tired out the veterans.
=P

Counterstrike is a perfectly good example.  Let a group of players volunteer
> to tackle the task of "capture this point" and they are literally thrown
> into Counterstrike and faced with their task.  If they succeed, then the
> global state is advanced, and the map point is considered captured.  Or
> consider the technology of the game Crysis.  It won't work for 100
> players,
> but it'll work marvelously well to entertain 8 players for the duration of
> a
> combat task.


Well, EVE shows that it can work for 100 players. However, we can also agree
that pulling together 100 players isn't terribly easy. That, and 8 players
takes so much less server load...

This structure also permits many different types of entertainment to coexist
> because the game changes for each type of task.  There can be Crysis-style
> combat, chess-style diplomacy, poker-style big business, Tycoon-style
> crafting, etc, all intermeshed into a vast graph of state transitions,
> moving towards some global set of goals defined by the game designers.


Chess-style diplomacy sounds singularly fascinating. I don't know if we
should change topics for that, or if it even belongs on this list, but can
you elaborate? =D

On 8/27/07, Mike Rozak <Mike at mxac.com.au> wrote:
>
> The meta-question is: A community develops around any game/genre. How much
> is that community allowed/encouraged to affect the gameplay? At one
> extreme
> is a highly PvP world, or Second Life. At the other is a single-player
> game
> with forums. Lots of stuff can happen in-between... and it isn't
> necessarily
> a linear spectrum either.


Well, that depends a lot on what you mean; certainly there are different
kinds of gameplay for different people. That's part of what's interesting
about this idea: people working at a high-level, strategic command would be
phased out and in the background during an FPS-style capture-this-hill. Or
they would change roles, who knows. On the other hand, you might have a
fully participatory democracy for decision-making (groan?) and certain
decisions might require a quorum of (one faction's) playerbase.

On 8/27/07, Johnicholas Hines <johnicholas.hines at gmail.com> wrote:
On 8/27/07, ghovs at plex.nl <ghovs at plex.nl> wrote:
>
> While I don't think this is such a terrible idea, play-wise, I can't
> help but think... couldn't you do almost this with instanced events in a
> current MMO?
>
> Besides that, there's the massive issue of having a local service send
> authoritative data ("they won", or "they got the loot") after having
> itself resolved something through gameplay, or not. Cheaters would have
> a field day after the few hours it would take them to figure out your
> super secret protocol that they agreed to not investigate at all as per
> your EULA.


Sure. So if you do an MMO, take out the need to render everything that's
-not- an instance, and then host everything on your own servers, would that
work?

On 8/28/07, cruise <cruise at casual-tempest.net> wrote:
>
> Thus spake Michael Chui...
> > I see two paths for this. One is the "truly single-player" approach. In
> > this case, you'd be doing what Spore is doing: making stuff, uploading
> > it to a server for inclusion into others' games and that'd be the end of
> > your contribution.
>
> I see this only as an automation of the mapping/modding scene that
> already exists, really; that has been happening for a long time.


On MMOs? Or even RPGs?

In fact, it seems an excellent way of combining multiple different
> gaming genres - strategy and FPS are the obvious mixes, but even
> something like adventure games could be included with a bit of thought.
>

Well, I -am- talking about the phenomenon formerly known as MMORPG. A couple
possibilities:

1) Full-on storied events that effect overall strategy. Ignoring the
combat-style RPGs and even the rogue-based RPGs (Hitman?), how about stories
that effect the grand scheme of things? You know, diplomacy that consists of
something more nuanced and human than "If we team up, we'll kick that other
guy's ass." Perhaps painfully, but something like, "King Paul propositioned
Queen Joan; therefore, I'm not going to ally with him because I consider
that ungentlemanly."

2) Adventure games? Quests! "George, go kill that dragon and fetch me the
sword of a thousand truths." Then you can strategically hand it over to a
warrior or commander on the front lines and they'll be bad-ass in combat.

On 8/28/07, Ren Reynolds <ren at aldermangroup.com> wrote:
>
> In the middle I guess there is the Metaverse model of sharing things
> across discrete worlds.


I like this idea, and noticed recently on Raph Koster's blog ("How much does
the world matter?") where he writes: "The trend in future virtual worlds may
be to remove the assumption of spatial relationships between nodes (rooms,
zones, apartments, worlds, whatever) and instead have spatiality solely *
within* said places. Patches of coordinate systems in a floating sea of
hyperlinks. And likely, smallish patches focused around areas of interest,
so that the spatial simulations are dense with stuff and stuff to do, rather
than there being large swaths of empty coordinate space with nothing in
them."

On 8/29/07, Aurel Mihai <aurel.gets.mail at gmail.com> wrote:
>
> There's a lot of good to be said for massively single player gaming.
> Multiplayer can get really intense and I know a lot of people that
> have either withdrawn from multiplayer or never started in the first
> place because there are too many very dedicated players out there that
> raise the bar too high for casual gamers. Massive single player games
> would let a player step back from that crowd while still feeling like
> their effort makes a contribution to something bigger.


I agree; and the model I'm suggesting also brings out the possibility of
something that's much less... easily encapsulated by a term. It has a
"massive" scale, in that it involves potentially thousands of players, but
it's still conceivably multiplayer in that the actual action can have
multiple people interacting at once.

However, that leads to the issue of how a player chooses where to step
> into the gameplay. If he wants a top level command position (the
> 'chess' model), can he just pick that? Does he have to earn it through
> lower level command? Through some sort of FPS squad leadership? In
> that sense, is there a grind to get to where you need to go? That
> could be a problem, but it would also be a bad thing to let just
> anyone control where the battalion marches next.


Obviously, you should rarely, if ever, have a grind. To me, a grind is a
demonstration that your design is deeply flawed. Daniel Cook's recent
"Chemistry of Game Design" explains why.

If he wants top leadership, then we ought to remember that such strategic
leadership is not the same as tactical leadership: it requires different
skills. Thus, it should be possible to demonstrate skill at high-level
command without risking those commanded. I have no idea how to accomplish
that. Perhaps we could let the players come up with it: I like the
flexibility of EVE's role/title management system, though my corp has
certainly not made full use of it.

Also, how much meta gaming has to go on? Games like WoW that demand
> hours of continuous time for a single activity are still in existence
> and will be for a while, but an increasing portion of the gaming
> community is getting older and working so they can't be sitting around
> waiting for the commanding officer to get orders from the rear admiral
> who needs to consult with his staff...etc... before the squad enters
> 30 minutes of combat and takes out a flag.


Well, I can think of a couple solutions to this:

1) Autonomous command. A squad leader can choose to make strategic decisions
on his own initiative, as in Battlefield. A possible balancing mechanic:
this player cannot do high-level commands, like airstrikes or fortification,
in order to support his own forward motion.

2) Real-time command. Look at web-strategy games like Utopia and Earth: 2025
hosted by Swirve. These are played in real-time, except that the amount you
can do per-hour is limited by resource constraints (you can only attack once
per hour, for instance). If you fail to log in and make changes, the world
goes on and your country gets stale.

I am actually not sure how to apply that to the design apparent. =P

What's going to turn this around
> and convince everyone that it's better now to have small group actions
> contributing to a large group that nobody sees around all at once
> anymore?
>

Well, most likely the same thing that got people into the bigger is better
mindset in the first place: trying it, having fun, and getting their friends
to try it. If it's fun and it's marketed, then it'll accrete. And the
audience is there for it, I think; at PAX there was a moment where it was
declared that "more save locations" was a potential selling point.

-- 
-Michael Chui



More information about the mud-dev2-archive mailing list