387 lines
		
	
	
		
			20 KiB
		
	
	
	
		
			Plaintext
		
	
	
			
		
		
	
	
			387 lines
		
	
	
		
			20 KiB
		
	
	
	
		
			Plaintext
		
	
	
| This is a guide on what is an acceptable map and what is unacceptable.
 | |
| Only acceptable maps will be put in the official Crossfire map distribution
 | |
| 
 | |
| ------------------------------------------------------------------------------
 | |
| 
 | |
| Map Naming/Directory Scheme:
 | |
| 
 | |
| Note that these rules are ordered in importance, eg, if a rule conflicts,
 | |
| the lower number rule takes precedence.
 | |
| 
 | |
| 1) Each city should have its' own top level directory (eg, scorn, navar_city,
 | |
|    santo_dominion) and be accessible on a world map. All buildings in the
 | |
|    city and located nearby or related to it are in the respective city
 | |
|    directory. City/town names are also used for nearby regions. If one
 | |
|    desires to create a new city then create a new top level directory with
 | |
|    the city name and use the new city name for the region in the maps that
 | |
|    are associated with the new city.
 | |
| 
 | |
| 2) If the map is part of a larger quest, a /quests/name_of_quest/ directory
 | |
|    should be made, and all the maps for the quest placed in there (also see
 | |
|    NOTE below about number of maps per directory). If some portions of the
 | |
|    quest has maps in cities or other places, a README should be included
 | |
|    explaining this. Note in general, having README's for all quests
 | |
|    explaining the flow probably isn't a bad idea in the case someone else
 | |
|    needs to work on it.
 | |
| 
 | |
| 3) If a map is independent (eg, the map is one you just go there, kill and
 | |
|    get exp), it should be in the /dungeons/ directory. If the dungeon is
 | |
|    comprised of several maps (eg, multilevel dungeon), a subdirectory
 | |
|    should be made to hold all of these maps (also see NOTE below about number
 | |
|    of maps per directory).
 | |
| 
 | |
| 4) Maps should fall into one of the categories above - if it does not, and
 | |
|    you are not sure, send a message to crossfire-devel@lists.real-time.com.
 | |
|    
 | |
| NOTE: If a map or set of maps is near a particular city then place the proper
 | |
| region in the map header. Use of the map maker's name as part of the
 | |
| directory structure or map name is not encouraged and may result in maps
 | |
| being excluded from CVS. While this type of directory scheme was done in the
 | |
| past it is now deprecated. Attempt to use a logical tree structure for maps
 | |
| and try to avoid dumping more than 15 to 20 maps in a single directory (this
 | |
| does not apply to /world/). Dumping a massive number of maps in a single
 | |
| directory is highly discouraged, Just Say No.
 | |
| 
 | |
| ------------------------------------------------------------------------------
 | |
| 
 | |
| 1) Check that all exits lead where they are supposed to.  Unless there is
 | |
| a specific reason an exit leads only one direction (like a trap door or
 | |
| perhaps a teleporter), players should be able to exit back from where they
 | |
| came from right when they enter the map.
 | |
| 
 | |
| One way exits/entrances should only be used on objects in which it is
 | |
| obvious it is one way.  A house is not an obvious one way entrance.  Remember,
 | |
| players may not have the three hours of time it takes to find the exit
 | |
| after being trapped in a map (a work around for this can be have the trap
 | |
| lead to a safe place with no exit which contains a savebed.  Thus, the 
 | |
| player could save and come back at a later time to find the exit.)
 | |
| 
 | |
| 2.1) Try to make sure the maps are multi player accessible.  In towns, this
 | |
| means the road should be at least a couple squares wide, buildings should not
 | |
| be trapped in corners in which case one character standing in front blocks
 | |
| access, etc.
 | |
| 
 | |
| 2.2) Try to make corridors in dungeons or mazes a few squares wide -
 | |
| especially if there is only a single path.  If it is a maze with several
 | |
| different paths, single width corridors are acceptable.  The main problem
 | |
| here are big labyrinths in which only one monster attacks at a time, and
 | |
| which there is only 1 or two routes.  If two players enter such a map, the
 | |
| one that went in first will be in the lead the entire time.
 | |
| 
 | |
| 2.3) Avoid spiral or single path mazes that just have monsters lining the
 | |
| corridor.  These are not very good for multiple players, not particularly
 | |
| interesting (map justs consists of killing all the monsters), and tend to be
 | |
| an easy and safe way to gain experience.
 | |
| 
 | |
| 3) Don't put:
 | |
| 
 | |
| 3.1)  extremely valuable treasure right next to the entrance, or
 | |
| nearby.  Players should need to work to get treasure.  If the treasure is
 | |
| fairly worthless (food, or non magical items), this would be acceptable.
 | |
| But a character should not be able to pop in, pick up a potion, spellbook,
 | |
| or a lot of diamonds, and then pop out again, without ever meeting
 | |
| a monster.
 | |
| 
 | |
| 3.2) Don't put monsters of high experience point near to entrance where they
 | |
| are trapped. Low level player could boost their experience high by using some
 | |
| weapons or spells from distance without danger. For example find a trapped
 | |
| troll and get wand of fireball.
 | |
| 
 | |
| 3.3) monsters on top of other monsters.  A troll should not be sitting on
 | |
| top of an oriental dragon.  The only exception to this would be if a monster
 | |
| could be on top of another monster (making sense) and hiding it at the same
 | |
| time.  A troll on top of an oriental dragon does not make sense (could not
 | |
| fit), nor can the troll hide the oriental dragon.  Using tricks like these
 | |
| which are only applicable due to display limitations is something that
 | |
| should not be done, nor should the player need to click on every monster he
 | |
| encounters to see if something is below it. (as a side note, doing this
 | |
| will tend to lock the monsters into position, making them unable to move.)
 | |
| 
 | |
| 3.4) Large groups of monsters that can be killed quickly with spells.  A
 | |
| fairly popular tactic to make high level maps is just to put 30 dragons (or
 | |
| other tough monsters) in a big room.  Do not do this.  All the player needs
 | |
| to do is cast a dozen icestorms, and quickly gets millions of experience.
 | |
| Likewise, it is unlikely that any more than 2 or 3 large (multisquare)
 | |
| monsters will be able to attack a player or party at once - the remaining 25
 | |
| will be blocked from doing anything.  This then makes it so that having 30
 | |
| dragons is not any tougher than having 3.
 | |
| 
 | |
|  If you want to make a high level map, instead of tossing a lot of monsters
 | |
| on it, take existing monsters and make them tougher.  Increase their
 | |
| hit points, level (which then means spells they use do more damage), add
 | |
| immunities or protections, remove vulnerabilities, change attack types, etc.
 | |
| Try not to totally change the characteristics of a known monster - a normal
 | |
| dragon should still be dragon like.  Also, remember to adjust experience
 | |
| that the monster gives.
 | |
| 
 | |
| 4) Try to keep the treasure in line with the difficulty.  5 potions should
 | |
| not be given out for defeating orcs or gnolls (even if there are a lot
 | |
| of them), but if you need to defeat several dragons to get to the
 | |
| potions, that is fine.  Likewise, if it is likely a lot of spells will be
 | |
| needed to defeat the monster, and those spells have a chance of destroying
 | |
| the items, then perhaps a few extra items to take this into consideration
 | |
| is not a bad idea.
 | |
| 
 | |
| 5) If use of a specific skill/class/spell is needed to complete the map,
 | |
| that should be stated near the map entrance.  How clearly this is stated
 | |
| depends on the circumstance.  If use of a certain skill is needed, there is
 | |
| probably no good way other than to state that a skill is needed.  If use of
 | |
| a certain spell is needed, stating that a spell caster of XX level might be
 | |
| sufficient, with the assumption that a spellcaster of that level would have
 | |
| the spell.  It is safe to assume that all characters can fight, but
 | |
| spellcasting (especially certain spells) should not be assumed, and thus
 | |
| should be stated.
 | |
| 
 | |
| Also, don't put in hidden rooms requiring dimension door if they only real
 | |
| way to know about them is pure luck or looking at the map.  If you want to
 | |
| do something like that, at least put some clues in.
 | |
| 
 | |
| If a certain skill would make a map easier, but is not required, you don't
 | |
| need to necessary state it.  The idea of this is that it can be frustrating
 | |
| to wander into some map, complete most of it, but find out you can't
 | |
| finish the map because you lack some skill or spell.
 | |
| 
 | |
| 5.1) A map should be designed so that a character can never be
 | |
| trapped in a room (except via other player interaction.)  A character should
 | |
| never be forced to dimension door or word of recall out of a map because
 | |
| some gate closed behind him.  For a character without these spells,
 | |
| it would mean death.  A simple method around this is put a lever on
 | |
| both sides of the door.  If the door is opened by special actions (saying
 | |
| things, dropping things), just put the lever on the hard to get side of
 | |
| the gate.
 | |
| 
 | |
| 6) If a map require multiple players to simultaneous be on it to solve
 | |
| the map, put a sign or message so players know.  Such maps would be those
 | |
| that require manipulation of levers or buttons in certain sequences in
 | |
| order to get through gates.
 | |
| 
 | |
| Don't make ends of maps require multi users.  This ruins that map for
 | |
| single players (not able to complete it), and makes a map that requires
 | |
| multiple players for only a small portion.
 | |
| 
 | |
| 7) Try not to make the maps too many levels deep.  To get to the goal,
 | |
| it should not require a 6 hour continous sitting, as the player works
 | |
| through each map to get to the next.  Multi level maps are fine - just
 | |
| don't over do it.  One way to do this is have several maps with a key
 | |
| or other special item at the end.  The final map could have the various
 | |
| battles, and then a series of gates/altars which uses up these keys.
 | |
| 
 | |
| 8) Shops:
 | |
| 
 | |
| 8.1) Don't put super stores in any towns or villages you create.  With the
 | |
| growing number of maps, players can already make a trip to all the different
 | |
| towns to try and find certain items.  A one stop find all shop is not
 | |
| interesting.  A good maximum size is about the same size of the shops
 | |
| in the starting village.
 | |
| 
 | |
| Also, making six magic shops of that size and putting them in the same
 | |
| town is not any better than one large magic shop.  If you want to have
 | |
| specialized shops, then make each shop smaller.  If you just want one
 | |
| shop that sells every type of item (magic, armor, weapons, food, etc), then
 | |
| a large shop is permissable.
 | |
| 
 | |
| 8.2) Make sure the entire interior the shop is covered with tiles.  Likewise,
 | |
| don't put shops that lead to areas without tiles without going over one of
 | |
| the 'magic doormats'.  A player should never be able to get an unpaid
 | |
| item out of a shop, whether via exit that does not go over the magic
 | |
| doormat, or through spells.
 | |
| 
 | |
| 
 | |
| 9) Don't make maps which require high level characters that low level
 | |
| characters can wonder into without warning.  Put a warning sign nearby,
 | |
| or gates or doors so the player can see they are in over their head, instead
 | |
| of instantly getting toasted the second they enter the map.
 | |
| 
 | |
| 
 | |
| 10) The structure of the map should make sense.  That is to say,
 | |
| if you enter a house, the house should then not have a tower inside.  Or
 | |
| a door to a shop.  In other words, if a map has an exit to another map,
 | |
| that exit should make sense (ie, another level, tunnels, dungeons
 | |
| all make sense.  However, another building the size of the original
 | |
| does not make sense.
 | |
| 
 | |
| 
 | |
| 11) Try to keep the difficulty throughout the map(s) about the same.
 | |
| The first monster in the map should not be the most difficult monster,
 | |
| nor should the last monster be orders of magnitude more difficult
 | |
| than anything before it.
 | |
| 
 | |
| It is very frustating to play a map, killing most every monster without
 | |
| much difficulty, only to find that last monster unkillable.
 | |
| 
 | |
| It is reasonable to have the monster increase in difficulty.  Also, if the
 | |
| map has no quest or end goal, then having a very difficult monster around is
 | |
| not unreasonable, as long as it does prevent the player from progressing to
 | |
| the next map.
 | |
| 
 | |
| 12) Do not put directors with bullet, lightning, fireball, etc. that
 | |
| are a loop or continuous.  Example:  Do not have two directors, each
 | |
| facing each other, with a bullet wall firing into them at the side.
 | |
| 
 | |
|  Having numerous directors is fine.  But make sure that eventually,
 | |
| there will be an exit/detonation point for the fired spell.  Having
 | |
| loops that go for over typically bring the game to a halt, as the
 | |
| objects just multiply and the game consumes more and more cpu time.
 | |
| 
 | |
| 
 | |
| ------------------------------------------------------------------------------
 | |
| The following are various suggestions for making good or interesting
 | |
| maps.  A map that does not need to follow all these hints to be accepted,
 | |
| but following these hints will make for more interesting or playable maps.
 | |
| 
 | |
| 
 | |
| 1) Try to create only small maps.  If you have a large map in mind, try to
 | |
| see if you can possible split it up in several separate sections, and place
 | |
| those sections in different maps.  Many small maps use much less memory than
 | |
| one large map, since crossfire doesn't yet support swapping of portions of
 | |
| maps.  Also, with small maps, the time to load it from and store it to disc
 | |
| becomes so short that it's impossible to notice.  In this context, small
 | |
| means about 32x32, though it's actually the number of objects in the map
 | |
| which count.
 | |
| 
 | |
| What is potentially more critical than the size of the map is the number 
 | |
| of objects (memory usage), and live objects (cpu usage, as each would need
 | |
| to be processed.)  
 | |
| 
 | |
| Also, remember that if you make very large maps, all generators will be
 | |
| cranking out monsters whenever anyone is on it.  This could mean that a lot
 | |
| of monsters have been generated before a player even gets to the area where
 | |
| they are being created.
 | |
| 
 | |
| Related to this:  If a map contains multiple levels, make multiple maps.
 | |
| Many times, if the level is small, the mapmaker may think I will just put
 | |
| all the levels on one larger map.  This makes the map a little less readable
 | |
| to others.  Also, things like magic mapping and dimension door can lead to
 | |
| unexpected results.
 | |
| 
 | |
| 2) Make a plot!  A map withot a plot becomes just another mindless
 | |
| "Kill'em all".  For instance, create a story which explains why there
 | |
| are npc's here and monsters there, fragment the story up and put
 | |
| bits and hints of it in various writables (books) and npc-conversations.
 | |
| 
 | |
| If you are going to make a mindless kill them all map, at least put some
 | |
| reward in the map that can only be accessed after all the monsters have been
 | |
| killed.  The only thing worse than a kill them all map is a kill them all map
 | |
| which you get nothing out of.
 | |
| 
 | |
| Avoid maps where all the monsters are lined up, and only one can attack
 | |
| you at a time.  This just makes an easy (and relatively safe) way for
 | |
| a character to gain experience and treasure, and is not especially
 | |
| interesting or challenging.
 | |
| 
 | |
| 2.1) A good idea for the rewards at the end of quests are specific 
 | |
| items (luggage, spellbook of some otherwise not available spell,
 | |
| special weapon, spellcrystal, etc.)  It is much more interesting to
 | |
| put a specific item instead of something like a random artifact.  Feel
 | |
| free to mutate or otherwise change existing artifacts to create your own.
 | |
| 
 | |
|  This has two advantages: one, the player will get to know where certain
 | |
| items are.  Having to search endlessly for a specific item gets tedious.
 | |
| Two, it reduces the incentive to keep repeating the quest (repeating
 | |
| quests is not inherently bad)  If the reward is a random artifact, a player
 | |
| may very well keep repeating the quest until the item he looks for comes up.
 | |
| By doing specific items, this will not happen.
 | |
| 
 | |
| 3) Make puzzles!  Use all those different object types: buttons, handles,
 | |
| doors, altars, pedestals, triggers, timed gates, etc...  Hide special "keys"
 | |
| needed to get further in special places, and use text-puzzles to describe
 | |
| where they are hidden and how they must be used.  The possibilities are
 | |
| endless!  Remember, you can also hide buttons under floors, making it more
 | |
| difficult for the character to find the trigger points.
 | |
| 
 | |
| 
 | |
| 4) But don't make too much big labyrinths. Making of labyrinths is (too)
 | |
| easy with crossedit, just select auto-joining and make zig-zag with mouse.
 | |
| But the results of these are quite tiring.  If you make ones, try make
 | |
| some idea into it.
 | |
| 
 | |
| Related: Don't make maps where the only way to find something is examination
 | |
| of each and every wall.  For example, don't have a big map with lots of walls,
 | |
| but the key to moving onward is to find the weak wall and pass through it.
 | |
| Nor should big mazes full of invisible walls be made where the way to get
 | |
| through it is just by going in some direction, finding out you can't move
 | |
| anymore in that direction, go some other one, etc.
 | |
| 
 | |
| 5) Give the npc's information!  An npc's knowledge about hidden treasure surely
 | |
| makes it interesting to have a conversation with it.
 | |
| 
 | |
| 
 | |
| 6) Feel free to add some traps, but be careful to not make them too
 | |
|   deadly without adequate warning.
 | |
| 
 | |
| 
 | |
| 7) Don't mix the monsters too badly.  Let there be at least some logic
 | |
| behind why they are grouped in a single room.  Undeads together with
 | |
| undeads, for instance, but not together with kobolds...
 | |
| Big dragons usually don't live together with mice...  Fire immune creatures
 | |
| generally dislike ice immune creatures.
 | |
| 
 | |
| Also, limit use of monsters that multiply rapidly (mice, slimes).   A map
 | |
| that is easily overwhelmed with these creatures quickly becomes useless.
 | |
| 
 | |
| 8) Give your maps a meaningfull name (like John's tower, level 1).
 | |
| This way, these can be used instead of the map paths in the highscore
 | |
| file.  Also, in terms of the actual file name, try to use numeric 
 | |
| level identifiers (ie, maze.1, maze.2, ... instead of maze.first, maze.second,
 | |
| etc.)  The former maps the levels sorted a little bit nicer in the
 | |
| directory.
 | |
| 
 | |
| 9) Try to make the map so that it links in with the existing world.  Most
 | |
| people want to make their own continent, which is then accessed by ship
 | |
| or other fast means.  While convenient, this creates many island
 | |
| continents.  The problems with this are that any feeling of relation is lost
 | |
| (where is that island continent), and it makes item searching in shops very
 | |
| easy - if you can access half a dozen shops quickly and safely by taking
 | |
| boats, you have a decent chance of finding the item you want.
 | |
| 
 | |
| Also, it seems that when most people start making maps, the first thing they
 | |
| do is create a new town or village.  There are already a lot of towns and
 | |
| villages out there.  If you are just going to create a few new buildings,
 | |
| instead of going to the effort and time of creating your own island with a
 | |
| town, just create the buildings, and plug them into one of the existing
 | |
| towns or the terrain someplace.  Many of the towns right now have many
 | |
| unused buildings.
 | |
| 
 | |
| ------------------------------------------------------------------------------
 | |
| 
 | |
| Technical map hints:
 | |
| 
 | |
| 1) If you are creating a new archetype, it only needs to go into the general
 | |
| archetype distribution if it has an image associated with it, or it has
 | |
| general use (a new monster).  Something that uses already existing images
 | |
| can be set up in the map file itself (through setting various variables).
 | |
| 
 | |
| 2) When modifying an existing archetype into a new one (either new face
 | |
| or new type), use the archetype that has the most variables in common.
 | |
| Thus, if you want to create a monster called a 'bouldar', it is probably
 | |
| best to take a monster of some sort and change its face instead of taking
 | |
| the existing boulder archetype and changing its type, hit points, speed,
 | |
| etc.
 | |
| 
 | |
| 3) Changing color is no longer possible in maps - instead, a new face
 | |
| and image must be created, and then put in the standard distribution.
 | |
| The archetype collection script will automatically pull out face information
 | |
| from archetype files.
 | |
| 
 | |
| 4) Try to keep maps readable by other people who might edit them.  Thus,
 | |
| instead of modifying a woods space so it also acts as an exit, just put an
 | |
| invisible exit under the woods space.  This has the same functionality, but
 | |
| it makes it much easier for other players to see what this space does. (Side
 | |
| note - if you want it so that players actually need to apply the space
 | |
| to enter, you will need to change the face of exit for this to work.  If
 | |
| you do this, you should also accompany it with a magic mouth.)
 | |
| 
 | |
| 5) Make sure you set the difficulty field in the map attributes to
 | |
| somethign meaningful.  Crossfire will calculate a default dificulty, 
 | |
| but its formula is hardly ideal.  The difficulty of a map determines how
 | |
| magical the treasure will be (and some treasure types won't show up 
 | |
| unless the map has a certain difficulty level.)
 | |
| 
 | |
| 6) Don't be too intimidated about writing new code if there is something
 | |
| you would like to be able to do, but just isn't supported.  If you are not
 | |
| the code writing time, make a suggestion.  Worst case is it gets ignored.
 | |
| But many times, I have written code because I had some idea which just
 | |
| was not possible at the time (ie, the apartment in the starting town
 | |
| required an expansion/change of the unique item code.)
 | |
| 
 |