[MUD-Dev] BIZ: Who owns my sword?

Crosbie Fitch crosbie at cyberspaceengineers.org
Mon Sep 15 09:35:21 CEST 2003


From: Matt Mihaly

>> Hmmmn. I thought an avatar did own things? An avatar is the
>> fictional character that the player controls, yes?

> Avatars own nothing under any country's legal code that I'm aware
> of. Only legal entities may own things, and a collection of
> database entries is most definitely not a legal entity.

Ah. I'm talking two universes, two jurisdictions, here.
E.g. MiddleEarthOnline: Bilbo owns his hobbit-hole (until someone
else, say Frodo, inherits it). If the player John Doe is controlling
the avatar Bilbo, then the player doesn't own the hobbit-hole, the
avatar does. Real-world law should apply to the player, not the
player's avatar. Hobbiton's jurisdiction caters for that quite
nicely.

I can just imagine legal squabbles between the sherriffs of hobbiton
and the county court of Los Angeles, or whatever.

Maybe their argument would be that if a player is even tacitly
understood to be exclusively in control of something (whether
virtual or not) that by law, they can begin to demonstrate
ownership. But, then if I build a sandcastle on the beach, I might
consider myself its owner. However, it's an emphemeral
ownership. Perhaps that's the way virtual items should be assured
unownable, i.e. to establish that they're ephemeral. Never let the
player hold the bits in their hand that wholly represent the
ephemeral item (and its exclusive control), and continually
demonstrate that items are indeed ephemeral (as per my previous
example, by making them disappear, like gold coins taken from
excursions in faerie turning into autumn leaves upon return).

Maybe even control can be made ephemeral, e.g. just like dogs will
desert a particularly obnoxious master, perhaps avatars can say
"Sorry John, but you're just too much of a dork for me, and Jane has
been in the queue for me for ages, I'm going to give her a turn.".

>> We're talking about a hypothetical game. How do you know how much
>> it'll sell for compared to the investment it took to produce?

> Because I do this for a living. If you think I'm wrong, feel free
> to prove me so. If you can make a mud that can just "take the
> money and run" and turn a profit (say, 1000%) large enough to
> justify the risk involved with what you're talking about, I might
> start to think I'm the crazy one here.

Ah, I see, so you've realised you can't say anything about a
hypothetical game, and figure you can deflect that failure back to
me, i.e. for me to prove that you can make money out of a
hypothetical game.

I don't want to be too absolutist here, but it seems to me there's
very little you can prove or disprove about a hypothetical game.

> Even worse than the fact that your model doesn't provide a way to
> make a profit from ongoing revenue (which is where the money in
> muds is), your model specifically invalidates the possibility of
> an exit strategy (ie being bought out, going public, etc). Good
> luck getting anyone to give you money on those grounds in the
> games business.

There are many profitable transactions that don't rely upon ongoing
revenue (sale of a car, house, piece of bespoke software,
performance, etc.).  Similarly, there are many profitable ways of
obtaining ongoing revenue (car leasing, house rental, software
licensing, employment, etc.).

There is nothing intrinsically bad (that I'm aware of) about not
being able to profit from ongoing revenue, whether in the case of
games or anything else. Obviously, the decision you make when
attempting to profit from your house say, will be "Do I rent or do I
sell?". If you're telling me that there is no possibility of making
a profit from a hypothetical game if you sell it in one shot as
opposed to renting it for ongoing revenue, well, that's a cool
crystal ball. My one tells me that "Hey bud. Possibilities are a
much safer bet than impossibilities. You stick with me.".
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev



More information about the mud-dev-archive mailing list