Multiplayer Map Design - Animating Materials

Since the end of Unit 70, and finishing up my basic thematic lighting, I have been tasked with implementing 3 different instances of animated light sources into my map. I have been shown examples of animated lighting, including flickering lights and animated 'sprite sheet' style lighting.

Mandatory:

Flickering Lights:

The use of flickering lights I feel will best suit my level, being set in an abandoned warehouse type building in a post war environment, there is room to add a feeling of faulty electrics within the building.
The flickering lights may be used to mark certain pickups or bonuses, for example the rocket launcher within my level which players must fight over, could have a flickering light above, drawing in players to maintain fast game progression.

Post Processing Volumes:

I have a plan for a post processing volume within my level, to be implemented simply covering the upper tier of my map, this will have a darker colour lookup table to dim the light in the upper tier, giving the effect that there is less light higher up, the users on the lower tier of the map will not be affected by the change and will still be able to easily see enemies on the walkways above.

Lens Flares:

I must add a lens flare to my level, providing another source of animated light, these consist of four parts, with the values edited to render at set distances from the player, a lens flare will be added to my level and will be set accordingly with its surroundings.

Optional:

Flipbook Textures:

Flipbook textures are an optional extra to be added into my level if I feel they will fit, at this moment in time I do not see a direct use for a flipbook texture, but this may change, if so one will be subsequently imported into my level.

Multiplayer Map Design - Lighting

The overall theme of my DM map is to be a previously disused warehouse surrounding, which has been converted into a post-war combat training facility, for this I researched warehouse lighting setups following the block out procedure.

I then took an aerial screenshot of my map, facing straight down in a bird's eye view. I created a simple black and white version of the top down image and put together the mood board containing the more specific lighting information, displaying lighting of different elements of the map.

Following the creation of these mood boards I transferred my information into UDK. I put a roof on my playable area and began laying out the lighting using point light actors in-engine. This was to communicate and relay the information shown in the second mood board into the engine itself.

Once lit, my map looked like this;

From this point I was able to work with neutral coloured lighting, lighting the regions of the map one by one, to be tested at intervals with preview lighting, my eventual result can be seen below.
I feel the doors, entrances to the higher level, pickups and target areas have been lit up efficiently, without the use of too many light nodes and using effective brightness in accordance with my original concept for my deathmatch map.

On 29/01/15 another peer review stage was reached, through this I was to gain feedback on my lighting. I asked three questions and had various peers answer different questions each.
My questions and their respective answers were as follows;

                                                                                                                                                         

Q1. Can the player navigate the map with ease using the lighting, making use of all lit elements (Doors, Pickups, Upper level access etc.)? Whether yes or no, how could this be improved for an optimal end-user experience.

Answer - The lighting is well lit and by the lightmass/radius I could automatically tell it was set inside a warehouse. The guidance for pickups, etc. was clear, maybe add more lights into certain areas that are darker?

Q2. Are the interactive elements within the map lit well enough to navigate on a regular basis, without having to think about where you are going on the map? Whether yes or no, how could this be improved for an optimal end-user experience.

Answer A -The lighting is excellent and requires very little improvement. The lighting navigation is very clear through the whole level.

Answer B - Loving the placement of the lighting on the doors, not sure how you could improve it. 

Question 3. Do you feel the map as a whole is lit enough, encompassing both upper and lower tiers, or is it too bright or too dim? How can this be altered for the best in-game experience?

Answer - The map as a whole is very well lit guiding the player through what appears to be a maze like level on the first floor, In my opinion I’d say make the lower level a little dimmer so it’s harder to navigate.

                                                                                                                                                          

Looking at my feedback I took on board both positive and negative points made, and worked on my lighting more to fit the feedback.

As according to the feedback given for question 1 ("Maybe add more lights into certain areas that are darker?") I lit some more areas. The entrances to the upper tier of my map were lacking emphasised light of their own so I added these in, I lit both corridors dividing rooms and also the corridors to the side of the target areas so that users know that both the east and west sided rooms can be accessed from both entrances/exits. This provides navigational lighting and also helps with enemy presentation, as any AI or player coming around the corner or out of one of the main corridors will be lit sufficiently enough to be seen by any other user, with a firefight ensuing.
I have still left some areas darker however, these are left darker for spawning reasons as they are in closed areas and contain player start nodes, and lighting the area may have a negative effect on possible spawn-killing patterns. If this does not appear to introduce problems as such through testing, I will be lighting the areas in question also.

In accordance with the answer given to question 3 ("Make the lower level a little dimmer so it’s harder to navigate.") I have since lowered the brightness of all lights in the level. Some lights were at brightness values as high as 4 and 6 in comparison to the drop to around 0.50-0.75 per light.
I have not lowered the lights any further as of yet as I feel the happy with the dimness of the overall level at this stage and that taking away more light may impact the end-user experience negatively, I don't want the map to be too hard to navigate as this could be detrimental to players using certain portions of my map.

These changes can be seen comparatively between both the below screen captures.

I will continue to edit the lighting as appropriate through both this process and further stages of development as it can undoubtedly yet be improved, particularly within aesthetics and visual touches yet to be added to the map, this may include another overall drop in brightness. However at this moment in time I am happy with the lighting scheme I have and am satisfied that I have lit my level appropriately with regards the layout and have built appropriately on feedback that I have been given by my peers.

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.