Updates - 07/12/2014

Today I have been adding in path nodes and player starts in an effort to make AI bots utilise all areas of the map, I have also modified the doors to open horizontally.
I have inserted the 16 player starts into my map appropriately spaced and positioned far enough apart to make sure deaths are not too frequent but not infrequent either, improving the pacing of a regular deathmatch. This may not yet be perfect and I will continue working on the pacing until it is appropriate with not just bots but human users also. The player starts in turn require more Path Nodes to be inserted.
Having modified the door to open horizontally, I feel it will improve both pacing and bring the chance of exploitation of choke points down, stopping people hiding behind doors even more so than previously.

I have now successfully integrated the use of doors with regards the AI. I originally had issues caused by the breaking of the link between path nodes when meshes were placed in between them acting as the door mover.
To rectify this issue, I modified three things, the mesh location, animation and the trigger, the meshes now start apart and upon the map loading, animate to come together. This allows me to link two path nodes through the open door in the editor viewport, making sure the line between nodes is green signalling an active link.
After the link was made the meshes were animated and linked to the 'level loaded' trigger, a touch trigger was added, when touched, the animation is set to reverse which opens the doors, and when untouched the animation will play again, closing the doors afterward.

Multiplayer Map Design - Overview 1

Through development of my multiplayer map to my current point, I have learned multiple new processes and tools to aid me in map creation and have a prototype multiplayer map functioning for play in both Deathmatch and Team Deathmatch.

I have constructed a two-tier map, consisting of 3 rooms and a set of corridors with a walkway above, the rooms containing various pickups and the walkway giving access to a rocket launcher.

Through peer feedback I have noticed some issues with waypointing, notably AI ignoring certain path nodes and in one case an AI attempting to scale a non-scalable mesh repeatedly, rendering them useless to the game mode, providing less than desirable competition from any difficulty AI.

I have taken into consideration many features of a standard multiplayer map and will continue to develop my map taking inspiration from already existent multiplayer maps and building my knowledge as applicable.

Things I still need to consider:

• I need to fit in more player starts, the standard number for a DM map is 16 as to vary the spawn locations of all users upon death, this will require shifting some nodes and/or player starts, taking into account positioning of spawns to decrease the likelihood of 'spawn-killing'.
• I have experimented with teleports in my level, but have not yet finalised implementation in the map, as I feel there is currently no use for them, the map is fairly small and can be navigated within a short time frame, I feel as though a teleporter would simply loop the paths which users would take, slowing down pacing and more importantly breaking the architectural flow.
• I am looking to include some jump pads in my map to make the upper level more accessible, this could also possibly assist me in the fixing of some AI based issues I am currently facing although I would like to fix these without using extra nodes where possible.
• I will continue to look at peer reviews and analyse them throughout development, I will change my map as appropriate and the gameplay will adapt to the new map and scripting as a result.

Multiplayer Map Design - Jump Pads

Originally I wasn't planning on utilising jump pads within my level, as I thought the ramps in each corner would be navigated by bots in order for them to gain the Rocket Launcher atop my map, this however has turned out differently due to AI constraints and I am most likely going to be implementing jump pads again, giving AI the ability to access the rocket launcher faster and possibly creating firefights on the upper level of my map, between AI or players using jump pads and AI or players navigating using the ramps.

I am aware this may render the ramps almost useless to AI, as they may only select the quicker route to the rocket launcher, this will be taken into consideration as the jump pads are implemented to keep as many concept ideas in place, meaning less or more jump pads may be used.

Intended changes will be documented on action at a later date.

Multiplayer Map Design - Choke Points & Pacing

Throughout the blockout process I have paid attention to choke points and pacing, attempting to keep the pace of the game as fast as necessary, keeping a player on their toes and not letting them sit in one space too long without getting either pressured into moving by suppressive fire or killed by an AI.

This in turn encompasses choke points, in the layout of the map I have incorporated animated cover objects which I am hoping will lessen the effect of players hiding around the corner waiting for people to come past them, instead causing firefights in the corridors with the cover objects providing both advantages and disadvantages, allowing players to both take cover and escape under cover if on low health.

I have also animated my doors to open quite quickly in comparison to a regular door opening speed, this does however fit in with my overall concept and is designed to stop players from sitting behind a door whilst it slowly opens, waiting for the other user on the other side to be revealed and easily shot in the legs/torso as the door rises and the opposing player is unable to see who is shooting at them.

These may yet change, but I am aiming to keep the gameplay and pacing as fluid as possible and feel that with quick door animations and moving cover it helps me to keep the pacing feeling right, this again will only come full circle when I get a larger number of peers on my map at one time with or without AI bots, I will be more able to fully analyse it then.

Multiplayer Map Design - Animated Cover

In the starting blockout process of my map, I considered how a firefight in a corridor could be improved, I then implemented cover objects within my map, made of a basic T shape, identical to that of a Tetris block but with one difference, the single piece on top was to be animated, it would slide along the lower row of three blocks infinitely back and forth throughout the game.
This would allow users to both take cover and return fire, and escape a firefight if necessary utilising cover, to take another route and engage in the firefight from another perspective is necessary.
The design can also be scaled by a user, using as double jump to get over the lower layer of the cover, this can also speed up a firefight as a player can make use of the cover, then scale it, putting an opposing player under pressure.
With the animation in mind the top piece was moved from the centre to one side to aid the animation process.

I have also modelled a rough 3D mesh which may take its place further in the development cycle, the texturing is still subject to change but will be weathered to fit in with the theme regardless, it may also be destructible, though that may prove negative, taking away the cover aspect in corridors, it will definitely be split into two separate meshes so that I can animate the wooden portion to move side to side.

They were animated using the exact same procedure as an elevator, only triggered with an event instead of when mounted, the event chosen was "level loaded". When given the event node in Kismet I linked the 'loaded and visible' option to the start of the animation and selected the loop option, forcing the animation to loop and play infinitely as imagined.

This has had a good effect on AI gameplay so far but due to the pathing 'line of sight' system I will only see how this feature truly works when I have a full team of my peers in control, as players are vastly different to AI controllers.
Any updates on animation or changes in design will be documented upon action at a later date.

Multiplayer Map Design - Volumes

I have been experimenting with implementation of various types of volumes, including trigger volumes and water volumes within my map, cutting away pieces of floor using the brushes and adding in surface actors to show water or other such fluids like slime or lava.

Within my concept I'm not too sure to whether or not fluid volumes will be suitable to the theme of the level and will be experimenting some more to see what I can produce which may fit the level.

I have also been experimenting with some post processing volumes which can be seen when the second water volume is entered in the video below, making use of motion blur, the options available to me within post processing volumes will likely be modified at points in the future.

I am still yet to possibly design another floor to the map, contemplating a lower, underground level to again expand the playable area, whilst keeping the map size at a format which isn't too open or vast. Some water volumes and other volumes may be implemented in either the existing levels or an underground portion, any changes to volumes will be detailed in a later post.

Multiplayer Map Design - Peer Review stage 2

I have performed a second review session with my peers to gain feedback on my DM map, my questions asked and feedback provided was as follows.

Peer Review 2 questions to be answered:

Q1. How do you feel the layout of the map itself affects gameplay? Suggest ways to make it better.

Q2. Do you feel the waypointing and placement of path nodes is true to the architecture of flow, sticking to a figure of eight? Even if yes, suggest ways to improve the waypointing.

Q3. Do you feel the placement of weapons and other pickups like ammo, armor and jump boots helps assist users in navigating the map, bearing in mind the architecture of flow once again.

Peer 1 answers:

1. The layout of the map works well, the bots seem well spread out and interact well with doors, pathways and pickups. To improve your map I would say maybe place hazards such as slime or lava volumes on both sides of the map were the ramps are, or at least a water volume to slow down the players with perhaps a pickup in the centre. (Just adds another aspect, keeps the player interested)

2. The layout and way pointing is spot on really, there's not much room for improvement. My only suggestion would be make the second level more accessible for bots and other players, whilst playing I found that the bots remained on the ground floor, very rarely would they venture up and even then when they saw someone below they would jump off instantly. You should maybe place jump pads to help with this.

3.The weapon, ammo, health pickups work well within your map, the jump boots especially helped me navigate up towards the higher levels and I found health easily when I was low. I would maybe place something inside the areas boxed off by the one block high walls in two of the four corners, place maybe two towers leading to vantage points one or two levels higher up? 

Peer 2 answers:

1. Easy to navigate due to the amount of space in the map. Door are not easy to identify in combat however while not in combat they are easy to identify.

2. Generally most of the path nodes are working apart from one of the corners of the map with a ramp.

3. Pickups help in navigation however I feel like the jump boots have to many uses per pickup. Weapons are placed well around the map creating firefights to get to some of them adding to the flow.


Outcome:
Building on the information given by my peers I will be making modifications to my map in the coming days including alterations to my path nodes and waypointing, door animations and AI usage will also be looked into, as the AI's door usage is reliant on path nodes being altered.
I have found issues myself on top of any highlighted by my peers, and will continue to work on these also to provide a more fluid experience for all users.

Multiplayer Map Design - Doors

Implementing doors into a DM map is much similar to implementing elevators, as they are animated in the exact same way with one difference, a trigger volume used to animate the door.
The process starts again with conversion of a mesh into a mover and the re-application of collision values, followed by the opening if Kismet and the customisation of the animation values, length, start and end keyframes.

The differences in animation come in after the keyframes have been set and the animation completed, the Max Trigger Count, found within the node attached to each matinee, must be set to 0, this orders the animation to run infinitely when triggered, so the door opens every time the trigger volume is activated.
The second difference are trigger nodes themselves, created using the builder brush and assigned in the volume drop down menu, they appear in the viewport as a different coloured cube, trigger volumes show as green.

I have implemented multiple fully functional doors in my DM map used to access rooms and aid navigation. As of right now they open directly upward but I may yet change these to open horizontally, opening from the middle. The reason for the proposed change is that when opening vertically, the doors interfere somewhat with the geometry above, initially cutting through the walkways above the lower level, the walkway was reshaped to cut around these, however the idea to animate a double door sliding open horizontally is now a much more attractive prospect.
This change will be detailed at a later date.

Multiplayer Map Design - Elevators

Today I began basic animation techniques within my deathmatch map, looking at both lifts and doors, starting with elevators, I converted a chosen mesh to a mover, making sure it could be mounted with ease in-game and re-applied the collision values ready for animation.

Kismet was then opened and a 'New Interp Actor' chosen, this granted me access to UDK Matinee and with that the ability to animate the mesh. I created two keyframes, one at the beginning and one at the end of the animation window and at the meshes end point, moved it to where I wanted the animation to finish and then return, the matinee window was then closed and the elevator tested.

I have experimented with adding a lift into my level, although due to the use of multiple tiers and constraints with the AI I am not yet set on including them within my level. the AI will sometimes not use lifts unless forced to, and as such would not be able to access the upper tier of my map which contains a single rocket launcher for use against opponents, due to the positioning and distance away from the potential lifts in opposing corners the AI is unlikely to use one.
This may change throughout the developmental process, with the implementation of more user controlled characters and less AI present. The addition of extra users will alter the gameplay experience for all involved, with characters wanting to use lifts to access the rocket launcher on the walkways above.

Multiplayer Map Design - Path nodes & spawn locations.

Following the first batch of peer review feedback, I was happy with the base look of my deathmatch map, this then is where the basic AI implementation begins in the form of 'player starts' and 'path nodes'.
Player Starts are in-game spawn points which AI characters and end users will access and respawn on every time they are killed in-game and are found located in various places around any map. These are shown as joysticks within the viewport.

Following placement of a player start in the viewport, player nodes are added then duplicated [Using Alt + Move], in the pathing process player start points, pickups and navigational aids all act as nodes to lessen the amount of nodes necessary, even if only by a few, marginally bringing down the file size and shortening the load times of a map for an end user.
I have implemented many path nodes and pickups within my map and the result so far can be seen below.

There is still a lot of experimental work to be done in terms of pathing, due to interaction issues with animated software, some corridors must also be widened if possible, as the AI will ignore certain coloured path lines, I am hoping to fix these with addition or altering of path nodes and possible pickup placement, however I will also have to take into account the architectural flow of the map at the same time, so the map stays true to the figure of eight, whilst becoming fully functional with no AI issues.

Multiplayer Map Design - Peer Review stage 1

To start the peer review session, prior to peer testing I had to analyse three elements of my DM map, they were as follows.

1. The map's Architecture of Flow
2. Why is your map blocked off?
3. Splash Damage Building position in map

1. The Map is to flow through multiple rooms and corridors, encompassing the figure of 8 theory within, rooms have multiple entrances/exits to avoid ‘camping’ and cover has staggered height blocks, to enable characters to obtain both full body cover and  half body cover, giving them the ability to return fire from cover.
The flow of my map also extends to the walkways above the main combat area, this gives a multi-tiered layout with the ability to gain a height-based advantage over other players, this must be paid attention to, however, as the player with the vantage point must not have a large cover advantage for balancing reasons, for this reason I may put simple railing or no rail at all on the walkway, giving the user the ability to fall off, back down into the main battle area.

2. To fit with the theme of my overall splash damage project (post-war), the idea behind my DM Map is a combat training area. With possible wooden panel structures and cover objects, this in turn is the reason my map is blocked off from external contact.

3. My Splash Damage building will be situated outside of the map, and can be seen when looking through windows located on one of the four containing walls of my combat training area, my overall game idea was to have the Splash Damage building act as a laboratory in a post-war environment, and the combat training area will be situated in the near vicinity.

Peer Review

I received feedback on my DM map from two of my peers, both of which gave very similar feedback.

Peer Review:

1.  Layout works well, placement of cover is operational, but also scalable for fast paced, fluid movement during gunplay.

2. Reason for map being blocked off from outside contact makes sense due to having one specific area for training.

3. Reason for Splash Damage building being located outside makes logical sense, being in close proximity to combat training area.



[I am happy with the feedback at this point, as my visualisation of my concept feels as though it works fairly well as a bare asset not just to myself but to a small number of peers also, however much more work will be done yet to improve this map and create a DM map with a functional flow, interactive AI, pickups to aid the Deathmatch progression, interactive surroundings/scenery and more.]

Multiplayer Map Design - Map Blockout

I began the blockout of my level with a 4096x4096 floor, created with a cube brush.
Building from the ground up I used the provided modpack to generate a general layout for my level referencing my top down layout regularly to maintain a large degree of the concept for the maps design. The design was made symmetrically identical, taking into account the ease with which potential players would be able to familiarise themselves with the map and its layout.

Upon finishing the first layer of the map, including the rooms, potential target ranges and intended cover objects, I expanded on the possible access to a higher tier by blocking out a walkway above the lower floor, with a view to putting a valuable pickup above the lower battle area, making people navigate to the upper level to gain an advantage necessary to winning the game.
When designing the walkway above I implemented a simple cross design, kept narrow in width all the way around, keeping it simple enough to navigate whilst the narrow width of the platform add the risk of falling off and having to restart navigation to the pickup. Bearing the width of the platform in mind, the walkways also have no barrier or rail, meaning no cover to hide behind, in turn making it again harder to gain the upper hand by grabbing the special pickup.

The layout may yet be subject to change through development and will likely be modified in various ways dependent on feedback from peer review sessions, another layer may also be added at a later date but for the moment I am happy with my base map.

Multiplayer Map Design - Top Down Layouts

Following my mind mapping I created a couple of quick top down layout ideas using minimal detail, plotting out a map which would flow in a figure of eight, plotting out any building/room locations which could be used for general navigation and user familiarity, any points of cover or access points to a higher tier of the map itself.
From here I will develop a prototype blockout of my map, using the Ublock package provided, going from my top down layout drawings and building upward.

Multiplayer Map Design - Mind Mapping

Working from the brief given I quickly developed a mind map, breaking down each aspect of the multiplayer map to be created, elements like gameplay, visuals and theme.
Many gameplay aspects were taken into consideration, including in-game pickups (health, armour, ammo, weapons etc.), possible cover mechanics and most importantly the architectural flow of the map itself.
The layout of the map itself was also discussed, in terms of necessary spawn locations, dictating the pacing of the game from the start, the effects of multiple tiered layouts on gameplay itself and also how camping directly affects the core gameplay of a map and ideas on how to prevent it.

Multiplayer Map Design - The Brief

For this project I have been tasked with designing a multiplayer map inside UDK, following the given brief.
The final product restrictions given were as follows;

•  The reason behind the area must be realised.
• The Splash Damage building created last year must be included somewhere in the field of vision.
• The map must follow an architectural flow, flowing in a figure of eight.

In the following posts I will be documenting each of my steps from breakdown of deathmatch maps, to the final production procedures, through aspects like Gameplay, Sounds, Visuals and Theme.