MARATHON: INFINITY: MAPMAKING TRICKS GUIDE by Wolf Feather/Jamie Stafford FEATHER7@IX.NETCOM.COM Initial Version Completed: December 4, 2002 Version 6.0 Completed: March 2, 2002 ==================================== ==================================== ==================================== JOIN THE FEATHERGUIDES E-MAIL LIST: To be the first to know when my new and updated guides are released, join the FeatherGuides E-mail List. Go to http://www.coollist.com/group.cgi?l=featherguides for information about the list and to subscribe for free. ==================================== ==================================== ==================================== CONTENTS Spacing and Length Permissions Introduction Applesauce Bridges Doors Elevators Forced Submersion Lighthouse Mini-maze Multi-floor Features Off-parallel Corridors One-way Street Overlapping Floors Scrolling Panels and Liquids Sounds Stairs Temporary Mapmaking Items Visibility Contact ==================================== SPACING AND LENGTH For optimum readability, this driving guide should be viewed/printed using a monowidth font, such as Courier. Check for appropriate font setting by making sure the numbers and letters below line up: 1234567890123456789012345678901234567890123456789012 ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz ==================================== PERMISSIONS This guide may ONLY be posted on FeatherGuides, GameFAQs.com, PSXCodez.com, F1Gamers, Cheatcc.com, Absolute- PlayStation.com, InsidePS2Games.com, RedCoupe, gamesover.com, CheatPlanet.com, The Cheat Empire, a2zweblinks.com, Gameguru, GameReactors.com, cheatingplanet.com, vgstrategies.com, CheatHeaven, IGN, hellzgate, Games Domain, RobsGaming.com, ps2fantasy.com, and neoseeker.com. Permission is granted to download and print one copy of this game guide for personal use. ==================================== ==================================== ==================================== INTRODUCTION This guide is designed to help those who wish to make their own gameplay maps (levels) for use in Marathon: Infinity. Mapmaking is done by using Forge, which is included on the original Marathon: Infinity game disc. For those like myself who acquired the game fairly recently, it likely did not come with a manual, so the only Forge assistance available is the small set of tutorial films included with Forge. What is presented in this guide takes the information from the tutorial films and goes beyond. I apologize if some of this information is included in the Forge manual, but - as mentioned above - I did not receive a Forge manual. ==================================== ==================================== ==================================== APPLESAUCE The standard door can be used as a trap. Set so that the door opens and closes VERY quickly and that it causes damage WITHOUT reversing when it encounters an obstacle, any creature or player caught in its path of motion it will suddenly regret moving so slowly >:-) Also, while selecting a Door automatically defaults to Extends from Ceiling, there is no reason why it cannot be set to Extend from Floor or Extend from Both. There is no limit on the size of a door, so long as the total viewing distance and the number of transparent vertices do not exceed the limits of Forge and Marathon: Infinity (should either of these instances occur, an alert box will be displayed in Forge). This means that an entire corridor can become a 'door,' which sets up a rather nice trap. A single corridor can be set as a door which never deactivates. Giving this 'door' a FAST rate of motion and a LONG delay/pause can surprise unsuspecting players. If the Speed is set to 55 and the Pause set to 300 seconds, the player might pass underneath this 'door' several times in five minutes and not suspect anything. Then, while the player is underneath the 'door,' the 300 seconds expires, and the player is suddenly crushed >:-) At the very least, the player may come back toward the corridor and find it suddenly blocked, forcing the player to find another path to a desired area of the map. I also like to use two or more corridors as 'doors' connecting other areas or cross-corridors. The beauty of this is that the three 'doors' can all have the same Speed, but differing Pause lengths; also, some can be initially Extended and others initially NOT Extended. This means that when a player comes to a set of 'doors' like this, one may already be closed, and one or more already open. If the 'door' which is closed looks just like the surrounding wall, the player will not suspect anything unless she or he happens to see it (or the other 'doors') move. Then, while the player in underneath an open 'door,' it suddenly slams down and the player is crushed >:-) If the 'door' trap is to be used with a lengthy corridor, there are two options which should be used to permit the player to pass unharmed. First, the Pause should be just long enough that the player can begin running through the corridor as soon as the 'door' opens, and be able to get safely to the other side just before it closes and the player is crushed; this can take some time to find the exact Pause length required for the player to JUST make it to safety. Second, one or more 'safe havens' should be added to either side of the corridor along its length; these can simply be one World Unit by one World Unit by one World Unit in size (if there are two or more 'door' traps, a single 'safe haven' can be placed between each pair). Of course, there is no rule stating that mapmakers MUST allow players safe passage >:-) Also, ANY entity can be crushed in these traps - including the massive Juggernauts. A particularly nasty trick to use - especially in a map intended for multiplayer/network play - is to make a hidden teleporter, perhaps hidden behind a door which looks indistinguishable from the wall around it. Then, when the player steps onto the teleporter and stops, the player is wisked away to a tiny enclosed room with NO doors or windows to provide a means of escape... and the ceiling and/or floor in this tiny room are actually doors set to crush anything or anyone in the room at regular intervals >:-) A player who is excited about finding a hidden element in the map will suddenly be extremely dejected (and/or extremely angry) at being killed in such a manner >:-) ==================================== BRIDGES One thing must first be made clear here: There is no such thing as a 'true' bridge in Marathon: Infinity or Forge, meaning that a player on a lower level cannot see who or what is on (or rather, 'in') a bridge above. However, it IS possible to create a multi-level area where a player on a lower level can 'see' the base and side(s) of a bridge on an upper level. There is, however, some 'trickery' involved here. The creation of a bridge within Forge takes some careful planning. First, two levels are required which will overlap to some extent; this could be simply a corridor for the upper level, the base and side(s) of which extend down from the ceiling of a tall lower room. Second, BEFORE creating the upper level (the corridor, etc.), the first level needs to be created with polygons specifically designed and placed to accommodate the upper level itself with some EXTRA ROOM to spare (to ensure that the Forge and Marathon: Infinity engines will not become confused). For example, the asterisks below show the polygons for a lower room, with the middle third of the room designed to accommodate a bridge: *************************************** * * * * * * * * * * * * *************************************** * * * * * * * * * * * * *************************************** * * * * * * * = Lower Room * * * * * * *************************************** In this example, the lower room has a floor of 0.000 World Units. If the mapmaker wants the floor of bridge itself to be placed at 2.000 World Units, then the central third of the lower level's ceiling will need to be somewhat lower than that (again, to ensure that the Forge and Marathon: Infinity engines will not become confused); I prefer to use a difference of 0.500 World Units at a minimum, and experiment from there, making any changes as necessary - therefore, the ceiling for the central third of the lower room should be set to 1.500 World Units for this example. Next, the polygon for the bridge itself (here, a corridor) can be added. The bridge polygon must not extend beyond the boundaries of the central polygon for the lower floor in order to create realism and to avoid confusing the mapmaker later: *************************************** * * * * * * * * * * * * *************************************** * * =========================================== = * * = = * * = =========================================== * * *************************************** * * * * * * * = Lower Room * * = = Bridge * * * * *************************************** Now all that remains is adding textures :-) One interesting feat - if it fits with the theme or the look desired by the mapmaker - is to use a different texture on the base and sides of the bridge as viewed from the lower room. The Scrolling Panels and Liquids trick can be quite useful here; for example, if the map uses a lava-based setting, then perhaps the sides of the bridge in this example can have a (fast) horizontal scroll on each side of the bridge, with an optional (fast) vertical scroll on the underside (base) of the bridge. If this does not seem appropriate, simply using a different-colored texture can make the bridge more prominent. Similarly, the bridge could be given a different lighting index and the other textures in the room, thus making the bridge either more prominent or more difficult to see. A mapmaker may also wish to have a bridge which bends. This is done in the same manner as the example above, although more polygons will obviously be required. At the point(s) where the bridge is to bend, however, the mapmaker may wish to use a 'blank' polygon (i.e., a space of nothingness in Forge) to create the bridge support at the bend(s). Bridges can also be a hindrance. For example, if the northern and southern walls of the lower room in the example have windows so that players in rooms at the same level of elevation as the bridge can see down into the lower room and fire upon enemies there, the players will not be able to see each other because the bridge obscures a clear view to the raised room on the other side of the lower room. This can be reduced to some extent if the bridge itself bends; this all depends upon the whims of the mapmaker. Returning to the example of using a scrolling lava texture on the base and sides of the bridge, it could be a good idea to add a soft lava sound to the UPPER/BRIDGE polygons. This way, a player who during the course of a match or game in Marathon: Infinity is both on the lower level and on the bridge/corridor itself will have an easier time believing that seeing the scrolling lava from below and hearing the lava from within the bridge/corridor itself are interconnected. If enough space permits, it may even be a good idea to add a 'window' with a scrolling lava texture on the sides of the upper corridor WITHIN the space which would be the bridge itself; seeing lava from both the inside and the outside of this corridor/bridge will add even more believability to the game or match during play. ==================================== DOORS Doors are rather easy to create in Forge by selecting a polygon, identifying it as a Platform, and then using the pull-down menu in the top-left part of the top-up window to select the type of door; other parameters for the door can then be created as needed. However, there is one caution about doors, and that is using them when there is a difference in ceiling elevations on either side of the door. For this scenario, assume that a corridor comes from the right and into a tall room on the left, while the floor for the entire area has an elevation of 0.000. If the left side of a door has an elevation of 3.000 and the right side of the door has an elevation of 1.000, then two problems will be presented. First, the left side of the door (facing the room) will be patterned from floor to ceiling (3.000 World Units), even though the desired door itself is only 1.000 World Units in height. Second, when the door is activated, it will actually open the full 3.000 World Units (unless specified otherwise in the Platforms pop-up window in Forge). While this may not be a functionality problem, it does look strange at best. Instead, a mapmaker would be smarter to divide the corridor into three segments, each with an elevation of 1.000. This way, the door will only be textured for 1.000 World Units, and will only open by 1.000 World Units when activated. This could also have the added benefit of providing a player with a corner in which to hide to avoid detection or an incoming attack. ==================================== ELEVATORS The elevator concept is perhaps best used in Forge and Marathon: Infinity without any elevator doors. This also means that should a player not be paying attention and there is a nice sniping point near the elevator on each floor, the player could be hit or eliminated by an enemy >:-) Elevators are constructed using platforms and buttons. However, it would be best to have each elevator only travel between two floors. This does not mean that a map cannot have three or more floors of action; this simply means that a player wanting to go from the lowermost floor to the uppermost floor would need to use two or more elevators. Another caveat is that unless an elevator is rather wide, it will require two openings to the floors. This is because Forge will not permit the same set of polygon indices to be used to connect polygons on two different levels or floors, as this creates extreme confusion for the Forge engine. Therefore, it may be best to have a 'front door' and a 'back door' for an elevator, with each 'door' accessing a different floor of the map. An elevator will also require four different buttons. Two of these buttons will be located on the outside of the elevator, one on each floor. The other two buttons will be located inside the elevator, so that once can be accessed when the elevator is at the lower floor and the other can be accessed when the elevator is at the upper floor. This will take a bit of time to render, and the buttons inside the elevator will need to be positioned so that they do not overlap with any other polygons of the map. Buttons must be 0.5 World Units wide and 5/8 World Units high. They must be at least 1/8 World Units 'deep' in order to recess them into the walls and separate them from anything else. Since the buttons must be at least 1/8 World Units 'deep,' I prefer that the short entryway connecting the elevator itself and each floor be 1/4 (0.25) World Units in depth, allowing plenty of room for the elevator call button on the outside at each floor. As for the settings of the elevator itself, it will obviously need to be a platform. The Initially Active option should be deactivated. The Initially Extended option should be activated only if the mapmaker wants the elevator to begin operation from the upper floor (if this option is deactivated, the elevator will begin operation from the lower floor); this may not be an important distinction within Marathon: Infinity, but it can be of tremendous importance for the mapmaker during map creation. The elevator platform should also be set for Deactivates At Each Level. This will ensure that the elevator stops on each floor. This is also why the elevator cannot have more than two floors to function as a 'true' elevator, since two sides of the elevator will be used to connect to various floors, and two sides will (likely) be used for the buttons which activate the elevator from its inside. While this should already be set to its default setting, the mapmaker should ensure that Extends From Floor is activated, and that the Floor to Ceiling checkbox is deactivated - unless the mapmaker specifically wants to use this elevator as a trap to squash any players inside >:-) If for any reason the elevator does not function properly, the mapmaker may need to deactivate the AutoCalc options and manually enter in the minimum and maximum heights for the elevator platform itself. Similarly, the speed of motion of the platform may need to be adjusted. If a map has multiple floors and there is one elevator which functions as an express elevator between the lowermost and uppermost floors, that elevator platform should have the fastest speed of motion of all other elevator platforms used in the map. Two important notes: 1.) Without any elevator doors, a player or monster will always be able to jump down an elevator if its platform is positioned at the lower floor. However, the player cannot move up the elevator in this situation, unless the elevator shaft is filled with a liquid. 2.) When an elevator is in motion, another player can bring the elevator to a halt by pressing one of the elevator call buttons on the outside of the elevator shaft on each floor. This will effectively trap a player or monster inside the elevator shaft (unless it is entirely filled with a liquid) until a player reactivates the elevator from the outside. 3.) When it comes to button selection for the mapmaker, there is no difference in operation between the lighted and unlighted button textures. A lighted button will be easier to see, especially if the area's light level and/or texture is a bit dark, but this is simply a visual effect. Two suggestions: 1.) For the sake of consistency, if a map is to have multiple elevators taking players to multiple floors, it may be best to set aside the centermost are of the map to house the elevators. Of course, this does not mean that a player cannot be forced to move from perhaps the southeast corner of a floor to the northwest corner to access the elevator leading to the next floor above or below; in fact, while certainly a bit frustrating for the player, a map created with this design can be excellent for mission-based maps. 2.) While each floor of a map is likely to have a vastly different layout, it could be helpful to the players if each floor have a different set of textures. This will help players to better be able to make mental notes of where they have already been in a map, especially if they need to find their way back to a location they have already visited before. The use of certain pieces of scenery near the elevator openings can also provide players with these quick clues to jog their memory. Certainly, a player can use the Map function within Marathon: Infinity to determine if a location has previously been visited, but if there are multiple floors in a map, then they will all overlap in the Map function, rendering the Map function more of a hindrance (due to visual confusion, since Marathon: Infinity does not distinguish between the current floor and the other floors of the map) than an aid to the player. ==================================== FORCED SUBMERSION Especially if using a liquid which causes damage (such as lava), forced submersion can be a nice barrier/hindrance or a good trap. The general idea of a forced submersion is to have the player unable to see where the liquid goes until the player is actually IN the liquid itself. This provides a nice 'diversion' from the typical, boring, straight corridor. What makes the forced submersion work so well is that the ceiling actually submerges into the liquid, as such: CCCCCCCCCCCCCCCCCCCCCC CCCCCCCCCCCCCCCCCCCCC C C -> C C -> C C FFFFFFFFFFFFFFFF C C FFFFFFFFFFFFFFF FLLLLLC CLLLLLF FLLLLLC CLLLLLF FLLLLLCCCCCCCCCCCCCCCLLLLLF FLLLLLLLLLLLLLLLLLLLLLLLLLF C = Ceiling FLLLLLLLLLLLLLLLLLLLLLLLLLF F = Floor FLLLLLLLLLLLLLLLLLLLLLLLLLF L = Liquid FLLLLLLLLLLLLLLLLLLLLLLLLLF FFFFFFFFFFFFFFFFFFFFFFFFFFF Another variation of this is to use stairs leading into and out of the liquid. Again, the ceiling at some point must itself become submerged for this to truly work. Also, there is no rule that the level of liquid must be the same on both sides of the submerged ceiling. Because liquids (like almost everything else in Forge) are applied to each polygon, the following configuration is entirely possible: CCCCCCCCCCCCCCCCCCCCCC C C -> C CCCCCCCCCCCCCCCCCCCCCC C FFFFFFFFFFFFFFFF C CLLLLLF -> C CLLLLLF C CLLLLLF FFFFFFFFFFFFFFFF C CLLLLLF FLLLLLC CLLLLLF FLLLLLC CLLLLLF FLLLLLCCCCCCCCCCCCCCCLLLLLF FLLLLLLLLLLLLLLLLLLLLLLLLLF C = Ceiling FLLLLLLLLLLLLLLLLLLLLLLLLLF F = Floor FLLLLLLLLLLLLLLLLLLLLLLLLLF L = Liquid FLLLLLLLLLLLLLLLLLLLLLLLLLF FFFFFFFFFFFFFFFFFFFFFFFFFFF This second configuration can be quite useful for using a forced submersion tactic while also granting access to a higher floor of the map. Those mapmakers who want to be REALLY nice to players may provide either an Invincibility Power-up or a Health Recharge on either side of the forced submersion. However, doing so can also be a warning to alert and experienced players that there is likely a trap ahead. Note that the liquid can be in motion in any one direction. A very fast rate of motion for the liquid means that this forced submersion trick acts like a one-way passage. ==================================== LIGHTHOUSE One of my favorites is the Lighthouse. Essentially, this is a single platform whose base is at the end of a VERY low- positioned corridor. When the platform reaches its peak, the character can gain access to a room with windows all around and a nice panoramic view of the area. (Optionally, the 'windows' can instead contain Scrolling Panels and Liquids.) To add more realism, appropriate sound effects such as Wind can be used at a low volume setting (generally at 25% or softer). While the premise of this is simple and straightforward, I find that the part of the room overlapping the corridor does not like to fill all the way to the endpoints which contain the platform. In this case, I instead add another line 1/8 of a World Unit beyond the endpoints for the platform, and fill this area. If the entry corridor is coming from the top of the following image, the floor of the room would then look like this (with the platform at its peak to allow access to the room itself): XXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXXOOOOXXXXXXXX X = Floor of the lighthouse XXXXXXXXOOOOXXXXXXXX XXXXXXXXOOOOXXXXXXXX O = Platform (at its crest) XXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXX Similarly, this can be used to form a Dungeon, with the dungeon itself at the lowest possible levels of the map and the 'safe' part of the map at the higher levels (like simulating a castle). Here, however, it may be best to NOT use a platform, instead simply forcing player to literally drop into the dungeon and fight her or his way back to the surface. ==================================== MINI-MAZE If the mapmaker creates a corridor which is too lengthy, Forge will post an alert box when the corridor is seen from Visual Mode. One way to remedy this is to install a series of doors along the corridor, so that the chances of being able to see along the corridor's entire length is VERY slim. Another, more complex way to do this is to create a mini-maze in the corridor. This is not a true maze per se, but the effect can be just the same. The idea is to use a short section of the corridor for the mini-maze and force the characters to one half of the corridor. In the next space, the characters can again use the full width of the corridor, but they must move to the opposite side to get around another barrier blocking the opposite half of the corridor. In other words, a normal corridor becomes the following: NORMAL MINI-MAZE CORRIDOR CORRIDOR X X X X X X X X X X X X X X X X X X X XXXX X X X X X X X X X X X XXXX X X X X X X X X X X XXXX X X X X X X X X X X X XXXX X X X X X X X X X X X X X X X X X This mini-maze tactic will prevent the player from being able to see too far, and is more interesting than a series of doors... especially when this pattern is repeated. One way to make things interesting is to have doors and/or corridors intersecting with the mini-maze area. Also, this is a nice way to initially hide button and recharge panels. If the mini-maze section is bounded by spaces which are designated as Monster & Item Impassable, then monsters and/or Assimilated marines can be placed within the mini-maze area to surprise the players. Another interesting twist is to combine the mini-maze technique with a staircase. The constant change in both horizontal AND vertical movement can be rather disorienting for the player. This is also a very good tactic to use for LONG staircases (because Forge and Marathon: Infinity both have limits on the visual distances and transparent vertices permitted from any given point in the map). ==================================== MULTI-FLOOR FEATURES This works in conjunction with the Overlapping Floors trick (see below). Here, the concept is to have a single feature which is essentially part of overlapping floors. My favorite type of feature is a 'windowed fountain.' In this concept, the center of each overlapping floor contains a similar Scrolling Panels and Liquids trick (here: water, lava, or sewage) with the appropriate sound effect (see Sounds, below) for each room. Unfortunately, however, the 'windowed fountain' cannot use the same endpoints on more than one floor; this is the same limitation at work in the Overlapping Floors trick (see below). The easiest way around this obstacle is to have the 'windowed fountain' at its narrowest point on the uppermost floor, and at its widest point on the lowermost floor. Depending on how each floor can be accessed, the player(s) may not even notice that the width of each floor's 'windowed fountain' is any different from the width of another floor's 'windowed fountain;' even if one or more players DO notice this, they are likely to not think much about it, especially if there is plenty of action taking place in the same room. ==================================== OFF-PARALLEL CORRIDORS The name of this 'trick' is somewhat of a misnomer, as it does indeed involve parallel corridors - in fact, the corridors are adjacent to each other. What makes this 'off' is that each corridor has a different floor AND ceiling elevation. The off-parallel corridors trick is dependent upon the ceiling elevation of the lower corridor being equal to or less than the floor elevation of the higher corridor. This will make it impossible for players standing 'next' to each other on the different elevations to see each other, although they will certainly hear each other's actions. There is a drawback to using this trick, however: The CPU may randomly generate items and/or monsters along the shared boundary between the off-parallel corridors, resulting in really odd visuals. There are two options here to get around this glitch in the game engine: 1.) The mapmaker can select all polygons associated with each corridor and make them 'Item & Monster Impassable.' This way, nothing can be randomly generated at the shared border... but nothing can be randomly generated IN the corridors either. 2.) The mapmaker can make sure that NOTHING in Set Item Parameters AND Set Monster Parameters is set to randomly generate starting locations for items and monsters. The drawback to this, however, is that items and monsters will ALWAYS begin by being placed in the same area(s), which may not be in sync with the mapmaker's intentions. ==================================== ONE-WAY STREET This trick involves a corridor and a fast-moving current of liquid. This can be particularly good for allowing a player to see into an area, but be forced to find an alternate route into that area. If there are two rooms connected by a brief corridor, for example, a player can stand in Room A at one end of the corridor and see into Room B. However, the floor of the corridor is somewhat LOWER than the floor of either Room A or Room B. This corridor is then filled with a fast-moving liquid with the motion from Room B to Room A, so that every time an attempt is made to move toward Room B, the motion of the liquid knocks the player back into Room A instead. The mapmaker can change the motion rate of the liquid to provide interesting differences in rate (remembering that motion rates of liquid can vary from 0.000 to 0.999, with 0.999 being the fastest speed of a liquid). I prefer to use 0.999 to ensure that the player is NOT going to take the 'easy route' to a desired destination; at slower motion rates, it could be possible for the player to essentially swim upstream, but this will require a tremendous amount of effort (and some players may not feel the required effort is not worthwhile). An interesting note here: A player can inadvertently commit suicide with this One-way Street trick. In the above example, if the player is standing at the edge of the corridor in Room B and there is a target standing at the other end of the corridor in Room A, the player can launch a missile/rocket from the SPNKR-X18 SSM Launcher with the intention of eliminating the target. However, if just after the player launches the missile/rocket she or he steps into the corridor with the fast-moving liquid and the liquid has a VERY fast motion rate (such as 0.999), then the player will be swept along the corridor at a speed FASTER than the missile/rocket and will actually PASS the flying ammunition, impacting with the target so that they BOTH receive extensive damage (or even death) upon the impact of the missile/rocket. Another note: If a player steps into a One-way Street trick and the motion rate of the liquid is extremely high (especially at or near 0.999), then the player will be flung along the corridor with such tremendous speed that she or he will tend to keep moving a LONG distance even after having left the liquid behind. This can mean that the player can be flung far across a large room to impact hard with a wall or any other obstacle in the 'line of fire.' Depending on the speed with which the player was flung, the distance covered, and the angle of impact, the Marathon: Infinity game engine could have a rather difficult time rendering things momentarily once the player has come to a stop - but this difficulty is actually a good thing in this scenario, as it essentially simulates the player's wooziness from such a harsh impact. Also, player control is extremely iffy at best during these few seconds, allowing any nearby monsters or other enemies to pounce while the player is essentially incapacitated. ==================================== OVERLAPPING FLOORS This is one of my favorite tricks to perform in Forge, in large part because when the map is used in Marathon: Infinity, the player will often hear sounds from the other floors just above and/or below, yet will be very aurally confused as to the actual location of the sounds. Especially if this occurs while the player is engaged in battle and/or the player's current floor produces its own array of sounds (rushing water, etc.), the aural impact can really be quite stunning :-) The first trick is to ensure that the endpoints for the creation of each floor do NOT overlap. In other words, if the idea is to have two square-shaped floors one upon another, they cannot have the same X/Y coordinates for the corners, as doing so will greatly confuse the game engine and is generally not allowed by Forge in the creation process. Instead, it is important that one floor either be smaller than the other, or that one floor be shifted in a direction. In other words, one of the following endpoint 'images' must be created in relation to the floors: A B A B A B A B or: A A B B A A B B or: A A B B A A B B Also, it is best to design each floor separately, keeping a mental image of where the second floor will be positioned while working on the creation of the first floor. Obviously, unless players will be teleporting to and from each floor, there will need to be some sort of access between or to each of the floors. The simplest way to do this is by using a corridor. Again, overlapping corridors cannot use the same X/Y coordinates, so it is best if corridors are also shifted. A good method may be to use the following: AAAAAAAAAAAAAAAAA A A A BBBBBBBBBBBBBBB A B A B A B A B A B AAAAAAAAAAAAA A B B A A B B A A B AAAAAAAAAAAAA A B A B C C A = Floor A (Upper Floor) A B A B C C A B A B C C B = Floor B (Lower Floor) A B A B C C A B A B C C C = Platform/Staircase/Drop A B A BBBBBBBBBBB A B A B A B A B A B A BBBBBBBBBBB AAAAAAAAAAAAAAAAA B B B BBBBBBBBBBBBBBB Note that in this example, Level A overlaps Level B, with Level C being either a platform or a staircase (providing access to both Levels A and B), or simply a method for players to drop from Level A to Level B (which would not allow for access to Level A FROM Level B). In the creation of overlapping levels, it is also important to provide plenty of clearance between the ceiling of one level and the floor of the next-higher level. (I personally prefer to use two World Units as my minimum clearance space, to be ABSOLUTELY SURE that there is enough clearance space between levels.) Failure to provide adequate clearance space will confuse the game engine, and characters will not be able to pass 'invisible barriers' where the game believes that a wall should exist. (Note that, depending on the desires of the mapmaker, the 'invisible barrier' concept could actually be a good thing, especially if the player is intended to see a goal but be forced to find a different route TO that goal.) Forge allows players to create maps ranging from -9.000 World Units to 9.000 World Units in overall height. If each overlapping floor is only one World Unit tall and two World Units are provided for adequate clearance space between each overlapping floor, then the mapmaker can create up to six overlapping floors in an area. Note, however, that trying to look at overlapping floors in Forge - or using the Map function in Marathon: Infinity, once the overlapping floors have all been explored - is very confusing visually. In Marathon: Infinity itself, there is nothing which can be done about this. Within Forge, however, the mapmaker can make use of the Height Window (Command-H) and move the sliders to look at each of the overlapping floors individually. This is also another reason to ensure that there is plenty of clearance space between the overlapping floors, as the use of the Height Window sliders is not always precise (precision here requires a VERY steady hand). Using the Height Window in this manner allows the mapmaker to place objects, players, monsters, liquids, sounds, etc., each the appropriate floor, as well as to make adjustments as necessary (perhaps adding a window with a scrolling panel or liquid). There are a number of situations or settings that can be created by using overlapping floors and corridors. For example, there could be a large courtyard with tall buildings and windows on each side, so that players in the buildings can see those in other buildings and in the courtyard, and vice versa. Then, access corridors can be made underground to connect all the buildings, including corridors running UNDERNEATH the courtyard itself. Another possibility is to create a Chunnel-like situation, with two areas of dry land separated by a wide expanse of water or another liquid. These dry land areas can be connected underneath the liquid by a dry corridor. Another interesting concept is to have multiple above-ground areas with NO windows and VERY tall walls, so that the other above-ground areas are not visible. This then requires the players to go underground to where there may be multiple floors of action, plus connecting corridors between the various vertical areas of the map. ==================================== SCROLLING PANELS AND LIQUIDS Another of my favorite 'tricks' is to use scrolling panels and liquids (primarily scrolling liquids). This is based upon the window concept discussed in the Forge tutorial films. For most instances, I prefer to use floors which are each one World Unit in height. Next, I create a window which is the desired length, but either 1/8 or 2/8 (1/4) World Units deep (for the window sill). For the traditional window, the window sill will connect adjoining areas, but since this is designed to be a non-traditional 'window,' the actual 'window glass' itself is a useable surface for the purposes of the mapmaker. Once the window sill is textured (I tend to prefer the black metal pattern for window sills), the actual 'window glass' can be textured. Each environment (Water, Lava, Sewage, Jjaro, and Phfor) has one type of liquid associated with it, and this liquid is also available as a texture pattern. Selecting this pattern and applying it as Horizontal Scroll, Fast Horizontal Scroll, Vertical Scroll, and Fast Vertical Scroll will produce a nice visual result. If the entire corridor or room is ringed with such scrolling liquids, the effect can be quite visually mesmerizing, especially if the room itself is fairly dark and the liquid is as bright as possible. This same trick can be used with almost any of the non-liquid texture patterns; only the Environment's appropriate Landscape-only pattern (Moon, Space, Daytime, and Nighttime) is immune to this trick. Using scrolling Oxygen Rechargers, for example, could really baffle players >:-) Unfortunately, however, only one Texture Mode can be applied to each texture. This is a real shame, as it would be truly great to be able to have Alien Goo set to Wobble AND Fast Vertical Scroll!!! To really make the scrolling panels and liquids 'come to life,' the mapmaker should add appropriate sound to the area. Unfortunately, Forge does not provide sound, so the only way to test sounds is to open close the current map in Forge and open it in Marathon: Infinity. I find that it is best to keep sound levels for scrolling panels and liquids to 25% volume at the most, especially if there are overlapping floors (thus allowing for sounds from overlapping floors to disorient the player). It is possible to make it appear that a 'window' is a scrolling panel or liquid on both sides. This requires using the tactics mentioned above, but with the actual 'window glass' 1/8 of a World Unit thick. However, instead of using Forge's Fill icon to create a polygon, the 'glass' itself remains UNFILLED. To make both sides of the 'window' scroll the same way, it is best to use either Vertical Scroll or Fast Vertical Scroll for the panel or liquid in question; using either Horizontal Scroll or Fast Horizontal Scroll will cause the panel or liquid to move in opposite directions on either side of the 'window' itself. In other words, this is what the player would see for a standalone 'window' in the middle of a room (if the player can move all around this 'window' at will): WWWWWWSSSSSSSSSSSSSSSSWWWWWW W GGGGGGGGGGGGGGGG W W = Wall W W S = Window Sill W GGGGGGGGGGGGGGGG W G = 'Glass' WWWWWWSSSSSSSSSSSSSSSSWWWWWW Note that if there is no separation between the two panes of 'glass,' then both Forge and Marathon: Infinity will interpret this as one continuous area, and there will not be any opportunity to make use of this trick. ==================================== SOUNDS Sounds can be used to add realism to Marathon: Infinity. Forge allows for the addition of numerous sounds from its sound library, but these sounds unfortunately cannot be heard except when testing within Marathon: Infinity itself. The process for adding sounds works in the exact same manner as with liquids. The volume of the various sounds is adjusted by percentages. To make sounds seem TRULY realistic, it is important to design the map so that sounds can be adjusted incrementally as players approach and move away from the source of the desired sound. In other words, if a mapmaker wants to have a scrolling liquid such as lava in a 'window' setting, the sound for the lava must be added in the immediate area, and the sound must be slowly decreased in the surrounding area as players move away from the source of the sound (the scrolling lava). Personally, I like to keep my sounds rather soft, usually no more than 25% of maximum volume at the source of a sound. Then, I decrease the volume by approximately 5% for each world unit moving away from the source of the sound (a percentage change of much more than 5% per world unit tends to make each change rather 'choppy' and very noticeable, thus unrealistic). Since sounds are applied by polygon, it is thus best to create polygons which are a single world unit in width/length near the desired source of a sound. At 5% increments, the sound gradually increases or decreases in volume as the player moves about in relation to the source of a sound. For example, imagine a solo mission map in which the player begins just outside some infested installation at night. There may be only one entrance into the installation itself, and no door, thus allowing the sounds from outside to be heard at some distance inside. The mapmaker may opt for the Night Wind sound effect at 100% (to simulate a REALLY windy location) for the walkway/patio/whatever outside, and a long corridor (straight or twisty, and perhaps including one or more staircases) leading deep into the installation for the beginning of the mission's action. At a 5% change per world unit, at least 20 world units will be required to gradually decrease the volume of the Night Wind sound effect in a manner which seems realistic to the player (in Marathon: Infinity). Note that the use of doors can provide a nice buffer between really loud volumes and softer volumes without a need to gradually change the volume as a player moves about. Since the polygon representing a door can also be assigned a sound effect (and volume), the example above can be shortened. After four world units into the infested complex, the player will experience a change of 20% volume overall. Activating the door, the player can then pass through and suddenly experience perhaps a 50% change in volume once on the other side. The sound volume assigned to the door's polygon should ideally be the median between the volumes of the adjacent polygons (i.e., the polygons on either side of the door). In this example, the 'outside' of the door would have a volume of 80%, the 'inside' of the door would have a 30% volume setting, and the door polygon itself would have a 55% volume setting. Forge allows for the setting of Ambient Sounds and Random Sounds. Random Sounds are for short-duration sounds, such as underground explosions. Extended-duration sounds, such as Water or Night Wind, are Ambient Sounds, as they will theoretically ALWAYS be heard. ==================================== STAIRS Stairs can be a good way to get from Point A to Point B while providing a nice change from the traditional platform or the sheer vertical drop. The degree of the incline of stairs can vary depending upon the width between individual steps. In terms of vertical height, each step of a staircase should be either 0.1 or 0.2 World Units in height. Using shorter steps could make texturing the face of each step a bit difficult; using taller steps could make it difficult or even impossible for the characters to ascend the staircase unless the staircase is submerged in a liquid (in which case the player can simply swim 'up' the staircase, and the entire point of having a staircase is rendered moot anyhow). As for the angle of incline, each step should be no more than a single World Unit wide between steps; this will produce a very gentle incline to the staircase. At the most, there should not be a distance shorter than 1/8 of a World Unit in width between steps; this will produce a VERY steep incline to the staircase. The angle of the incline of a staircase can have a significant impact upon gameplay. If the staircase is long and steep, it will mean that a player on one end of the staircase will have a hard time seeing and/or targeting enemies at the other end of the staircase. If the staircase has a very gentle slope, this will generally not be a problem. Also, if the angle of incline is rather steep, then there will be less horizontal space needed to make changes in elevation, which may be important to the mapmaker. The ceiling of a staircase is also important. To calculate the ceiling, I prefer to leave the ceiling at the same height for the entire length of the staircase, with the ceiling at least one full World Unit above the floor elevation as measured at the top of the staircase. If the individual steps have a very short width, their appropriate ceiling tiles will also have a very short width; in this case, it is perhaps better to enter Textures Mode (View -> Textures -> Ceiling) and apply the ceiling textures in that manner. A minimum width of 0.5 (4/8) World Units is required for a player to be able to travel along a corridor. If the mapmaker uses a width of 0.5 World Units per step, then any step can also mark the start of a corridor (or another staircase) leading elsewhere in the map. This can also be a good way to provide a quick connection between two staircases which are identical to each other but lead to and/or from disconnected locations/rooms. If the mapmaker chooses to have items and/or monsters appear in random locations, many will appear in staircases. This is because each item or monster is initially placed at the center of a random polygon - and each step of a staircase is naturally its own polygon. With so many (small) polygons in close proximity to each other, a player can quickly pick up many weapons or gather a lot of ammunition with minimal effort. Similarly, the same staircase could also be filled with numerous monsters. The way to avoid having these items and monsters initially appear in a staircase is to individually select each polygon of the staircase and mark it as 'Item Impassible' or 'Monster & Item Impassible.' ==================================== TEMPORARY MAPMAKING ITEMS There is sometimes a need to create temporary mapmaking items. In my experience, the most common instance for creating a temporary mapmaking item is when the player will be positioning a button in what will be an unreachable location during gameplay, requiring the player to use a significant ranged weapon (such as rockets/missiles from the SPNKR-X18 SSM Launcher) to hit and thus activate the button. When in Forge, the mapmaker can go into Visual Mode (Command- 1) to place textures and to move about as if a player. In Visual Mode, pressing the 9 key on the numeric keypad (on the right side of the keyboard) will allow the player to levitate, allowing the mapmaker to reach areas that players in the actual game will be unable to reach in most circumstances. For the first scenario, a mapmaker may want a player to approach a wide lava-filled area, but the player must somehow cross to the corridor on the other side of the lava pool. On the opposite wall (to the right of the corridor the player must reach) will be a button which the player must activate using a significant ranged weapon, such as a grenade; this button will then cause a platform/walkway to rise, pause briefly so that the player can run across the lava pool safely, and then retreat to its former 'hidden' position at the bottom of the lava pool. The player can create everything as intended. However, the button is too high for the 'player' in Visual Mode to reach and texture. In this instance, the mapmaker can go into Elevation (View -> Elevation -> Floor) and temporarily change the height of the floor to a position where the 'player' can then easily access (using the 9 key on the numeric keypad) and texture the button area. When finished, the mapmaker can return to Elevation and return the floor to its former/intended position. For the second scenario, assume that the mapmaker wants the player to be able to approach a window, and see and fire upon enemies across a wide gap in another area. In order to ensure that this 'another area' is completely textured, the mapmaker can move the initial Player icon TO this 'another area' and perform any texturing which may be necessary. When finished, the initial Player icon can be moved back to the main area of the map. ==================================== VISIBILITY Depending on the mapmaker's intentions, visibility - or lack thereof - can be important. This refers to both what the player can see (in the immediate area and at a distance) and to what the player will appear like to others. To this end, lighting as well as pattern choices can be highly important. Forge allows the player to set both textures and lighting simultaneously. This is great for a long corridor broken into many small polygons, with each polygon having a gradual change in its textures' lighting. In this manner, the player can move from a brightly-lit area to a much darker area with subtle shifts in lighting as the player moves through the corridor, simulating the real world in this respect. On the other hand, a polygon with a lighting index of zero (the brightest available) can be positioned immediately adjacent to a polygon with a lighting index of twenty (the darkest available) so that the player is forced to quickly adjust to the massive contrast in visibility. Being able to see and be seen - or perhaps be hidden - at a distance can be crucial, especially for network maps with multiple players. For example, imagine that there is a large courtyard area, with two windows a good distance off the ground; the windows are positioned on either side of the courtyard. The rooms behind each of the windows are dark. If Player A stands at the back of a room, Player B in the other room is not likely to see Player A. However, this situation can be 'remedied' or 'thwarted' if the back wall of the room with Player A is brighter, thus silhouetting Player A (and anything else which may be visible through the window, such as a monster or an object). One way to do this is with the Scrolling Panels and Liquids 'trick' (above) with the panel or (especially) the liquid specifically given a light index of zero; using lava in this manner is especially effective, as the reddish-orange color of the lava naturally attracts the eye and thus makes the silhouettes of players, monsters, and objects much more prominent. As a variation of this, the backlighting can take place on multiple levels. For example, if the Scrolling Panels and Liquids trick is used with thin, small 'scrolling windows' in a room, these can be placed at different distances in relation to the window. Thus, Player B (across the courtyard) may not necessarily recognize the difference in distances and may not recognize the need to subtly change the targeting of Player A. RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRW R SSS W R SSS W R SSS W R = Wall R SSS W S = Scrolling Panel or R SSS W Liquid R SSS W W = Window R SSS W R SSS W RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRW This situation can also be thwarted by simply making the light index of the textures in the room with Player A as bright as possible, thus giving Player A no place to hide except to the side(s) of the window (if the window does not extend for the entire width of the room). However, given that some textures are inherently darker in color (such as many of the lava-environment textures) than others, it may be best to switch to a different, naturally-lighter texture to achieve this same effect. ==================================== ==================================== ==================================== CONTACT For rants, raves, etc., contact me at FEATHER7@IX.NETCOM.COM; also, if you have enjoyed this guide and feel that it has been helpful to you, I would certainly appreciate a small donation via PayPal (http://www.paypal.com/) using the above e-mail address. To find the latest version of this and all my other PSX/PS2/DC/Mac game guides, visit FeatherGuides at http://feathersites.angelcities.com/ ==================================== ==================================== ==================================== ======================================================================= Wolf Feather Jamie Stafford ======================================================================= Just as there are many parts needed to make a human a human, there's a remarkable number of things needed to make an individual what they are. - Major Kusanagi, _Ghost in the Shell_ ======================================================================= What isn't remembered never happened. - _Serial Experiments Lain_ =======================================================================