Mapping Guide
Introduction:
I have written this guide to help get you started should you wish to create your own levels for Nali Bricks. It is much easier than mapping for the standard UT2003 gametypes, but there are many points that must be given special attention.
The Beginning:
First, decide how large the map should be. Standard bricks are 64 units tall and 128 units wide, so a medium-sized map may be about 2048 tall (Z-axis) and wide (Y-axis) (plus whatever extra is needed for eye-candy), giving enough room for up to 16 bricks per row. There is no limit to how small or large a map may be.
A top view of a very simple layout ( grid spacing 512
units) - bricks on the right, playerstart in the middle of the green thing on
the left.
The player's view is automatically oriented along the positive X-axis, thus bricks must always be placed to the right of the playerstart, as shown in the picture above.
The depth (X-Axis) of the map is determined by how wide it is and what angle the player's FOV (field-of-view) is going to be. The further away the player is from the bricks, the narrower the FOV must be and the less distorted the bricks will appear towards the edge of the screen, at the expense of apparent 3D depth. FOV can be set in the default properties of the paddle once it has been placed in the map. I would suggest a value not outside the range 70-90 degrees.
Next, the map must contain one paddle and one ball. Load the package 'NaliBricks.u' into the actor browser. Both can then be found under 'NBObject' (you may have to deselect 'Placeable classes only' before they are visible in the browser). The ball can go anywhere in the map, but the paddle should be placed in the position it will appear when playing, usually some distance below where the lowest brick will be. The paddle can only move along the Y-axis.
Here you can see the paddle placed in the map, in the
centre of the screenshot. The playerstart is above that, on top of the
hemisphere thingy. The ball has been placed just above the paddle although it
can go anywhere if you want.
The map must also contain one and only one playerstart. The player will always be fixed at the same location as the playerstart, facing exactly along the X-axis when playing. Because the player can see their character when the game has finished, it is a good idea to put something underneath the playerstart so it doesn't look like the pawn is floating in the air. It should be approximately 40 units below the centre of the playerstart. Anything you use for this must not have any collision (that means making it non-solid if it is BSP, or switching all the collision settings to 'false' if it is a static mesh), or it may cause the playerstart to move when the map is rebuilt. Note that an error will be displayed when you rebuild saying that the playerstart is not on a valid base. Ignore it.
The ball needs a solid boundary to prevent it from leaving the playing area. In the above screenshot this is simply a hollow square shaped static mesh. This must be lined up with the paddle and in the Z-Y plane. The boundary can be any shape, but if it is very complex you may want to use blocking volumes to smooth it out and keep the ball bouncing predictably.
At the bottom of the map, below the paddle, there should be a PhysicsVolume with 'bPainCausing' set to true. When the ball enters this zone it will be reset. Again, this must be lined up with the paddle in the Z-Y plane and should extend a little way to either side.
Lastly, some bricks are needed. They can be found in the actor browser, under 'StaticMeshActor'. As with everything else, these should be lined up with the paddle in the Z-Y plane. Just a few bricks will do at first, to test the layout.
Save the map with a prefix of 'NB' so it will show up in the map list.
That is enough for the map to be playable so you should run it and check that the paddle appears in an appropriate location (just above the lower part of the HUD is best) and the edges of the playing area are within the player's field-of-view. If the playing area appears too big, you can either move the playerstart further away or increase the FOV setting (in the paddle's default properties). Do the opposite if the playing area appears too small.
Because the player's position is fixed, the map can be nothing more than a facade. You can stuff the visible part with much larger numbers of polygons and special effects than a normal map. Note that because the paddle uses cylinder collision for world geometry, the area around where the paddle will move must be clear of anything solid. The area should extend to at least twice the collision-radius/height away because it increases in size with the 'Paddle Extension' power-up.
Ball Properties:
StaticMesh, Skin(s), bUnlit and AmbientGlow can all be set per-map and will work as expected. Other properties may not work correctly with the multi-ball power-ups. Note that if you use a static mesh that is not the same size as the standard ball some special ball effects may appear the wrong size.
In the 'NBBall' section are two settings: InitialSpeed is how fast the ball will be when it is first launched. This value should be increased depending on how large the map is and how difficult you want it to be; BounceSound is the sound played when the ball bounces.
Paddle Properties:
As with the ball, StaticMesh, Skin(s), bUnlit, AmbientGlow and additionally DrawScale can all be set per-map. If the width of the paddle is not the same as the default, you must adjust the 'CollisionRadius' to match, or it will not collide with world geometry correctly.
In the 'NBPaddle' section is one setting: LevelFovSetting which is the FOV of the player, as already described above.
Brick Properties:
There are many configurable properties for the bricks:
Furthermore, StaticMesh, Skin(s) and DrawScale can all be selected individually for each brick.
Exploding Brick Properties:
Exploding bricks are a subclass of normal bricks. They behave the same except they explode when destroyed, damaging surrounding bricks. They have two extra properties: Damage and DamageRadius.
Other Stuff:
When all bricks are destroyed, the event 'GameWon' is triggered. When the player loses all their lives, the event 'GameLost' is triggered.
Bricks trigger their own event when destroyed.
The ball triggers its event when dropped.
Creating a ladder:
If you have several maps you can link them together to form a ladder. This is simply a matter of writing a short .int file, which will look something like this:
The 'Name' field contains the name of the ladder first, then a list of maps in the ladder and finally an end sequence, all separated by '|'. If you don't have an end sequence then terminate the string with a '|'. The Description field is, as you would expect, a description which is displayed when the player selects the ladder in-game. This can be anything you want. The other fields must be exactly as in the example. The .int file can have any name you want, as long as it is unique (i.e. don't use a generic name like 'ladder.int').
Although there is no hard-coded limit to the number of maps that a ladder can contain, more than about 18 will probably not fit on the screen.