[crossfire] map design guideline (was: Summary)

Nicolas Weeger nicolas.weeger at laposte.net
Sat Jun 9 11:21:20 CDT 2007


> introduce a "map design guideline". Only maps which won't violate the
> policy are allowed to add / stay.

Yes. I'd be slightly less restrictive, though - you'd be allowed to commit 
part of a quest, adding other elements later on, provided you document 
somewhere what you plan to add / you commit not too long after.

> A map should make sense. It has to be harmonious and coherent. For
> example, if you slay a dragon and reach the dragon hoard, you'll find
> some random_treasure, like a hauberk, dagger, water, cake, ... Wow, this
> dragon was able to collect real valuable stuff... But usually the dragon
> will burn the hoard with fire. No treasure at all.
>
> So a dragon should have a cave, with an entrance where you can fight and
> hopefully slay it and at the end of the cave the dragon hoard. Don't let
> the dragon burn it's own treasure.

Well, you could argue the player should be smart enough to figure a way to 
have the dragon don't burn his treasure :)

> What's the idea of this map? Why there are lot of trapped monsters. Who
> trapped the dragons there? For which purpose? Why they're not famished or
> who fed them and how? Or how do they come in and out? What's making a
> titan there? Having some vampires in the underground town seems
> reasonable, but what about the titan and the dragons? I don't understand
> this map. And there are lot of maps like this.

Well, IMO we shouldn't try to explain *all* maps and *everything*.
Overall story, then small hints, whatever.
For instance, from the wiki, why the world evolved this way.
Trying to justify the existence of all and every maps is an exercice in 
futility imo - but that doesn't mean we shouldn't try to harmonize maps.
(and if you start in this way: what is a Bed to Reality? why do you return 
there when you die? why do maps reset? :))

> Indeed, the most popular map is raffle1_3.
>
> <OT>
> Ok, on metalforge it's "ElectricHatchery", but that's only because
> "Flank" is camping there all the time. Other player hardly gets the
> chance to do this quest.
> </OT>
>
> So maps where player could easily gain exp are prefered. It's important
> to keep / create some hack and slay maps.
>
> Or maps with easy treasure are also very popular. I guess intwell is
> played so often because of the easy to get glowing crystal...

This is more a map balance issue. Arguably raffle gives enough benefits to be 
always claimed. So either reduce those benefits, or add more maps.
This is also server dependant, btw - I don't know if all servers have map 
claims.

> Another point, the mix of monsters. Should also be coherent. Maybe we
> need some more monster types, to avoid a bad mix of monsters without
> having just one or two monster types in the map.

Yes. And describe what monsters can coexist with what monsters.

> There's also some coding stuff missing. Don't let players solve a quest
> more than once. Flag a player who started a quest and only let players
> enter the quest map with this flag and without the "quest finished flag".
<snip next paragraphs, replying to those too>

This is really a map design issue. Using existing archetypes, or scripting, it 
should be the map maker's decision to implement such a restriction.
At some point common functions could be added, or examples written to help map 
makers.
As I said in another mail, I'm ready to script functions map makers need :)

About the "catching" part, that could be part of the game, but remember that 
having a player-managed economy (in this case monsters trading) is hard to 
maintain. Also I don't really want players to need to catch monsters 
sometimes to train just because no one did it.


Nicolas
-- 
http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref 
de l'aléatoire !]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070609/005afa66/attachment-0001.pgp 


More information about the crossfire mailing list