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/
====================================
====================================
====================================
