3D Computer Game Engines - Original plan comparisons, Rule of the Loop and Overall conclusion.

Original plan comparisons:

Through this unit, I have been following through with plans from the previous unit, which was to lay the ground work to create a map within the Unreal Tournament Editor.

Though I was tasked with only creating a blockout variant of the map, I am fairly confident I have stuck to my initial plan fairly well, which was to create an industrial styled steel mill, with an environmental hazard in the centre.

When comparing with my mood boards, I am reasonably happy with my outcome to this point.
(Mood board located at: https://uk.pinterest.com/plissken1989/unit-75-ctf_mill-moodboard/)

The idea was to have the BSPs within the boundaries of the map be placeholders for groups of pipes, with the possibility of their own tunnelled sections at a later point in the design process.
The implementation of my environmental hazard is almost exactly as I had planned it out in my head, there were only two alterations from my initial plan is that three molten steel containers are involved, I did not have a pre-determined number of containers planned for the interactive portion of my map and I originally intended the hazard to be activated on a button press, this was of course edited out through the rule of the loop, allowing the hazard to be triggered autonomously.

Dundoc & Trello usage:

Whilst I have continuously updated my Trello board throughout this unit, moving items between categories as appropriate, due to how closely I have followed my original plan, I do not feel my Dundoc needs any alterations making to successfully show the progression I have made from the beginning of the project to my current position.

Both my Dundoc and Trello boards can be viewed via the links below;

https://trello.com/b/mkTzLuNb/ctf-mill-development-board

https://www.dundoc.com/project/1046/3zlyioul6

The Rule of the Loop:

To implement and utilise industry standard techniques within this project, I have been working by the rule of the loop, essentially trying something, play-testing, gathering opinions and tweaking any elements which either don't work properly or could be improved upon. This can factor into anything, things such as map size, layout, functionality and flow of the map too. Once an issue has been fixed, the map is generally saved out under another version number to keep development history log and so that I can personally see my own progression through the process or map creation.

Through a total of 11 iterations or my multiplayer map, using my peers for feedback with every progressive build, I have developed what I believe to be a fairly competent Capture the Flag map, which acts as a basic Team Deathmatch map also, the Team Deathmatch variant of my map does however need a good amount of tweaking to things such as amount of and placement of weapons, armour, ammo and health pickups. I also need to modify the environmental hazard to reflect that which occurs within the Capture the Flag variant.
Whilst these are changes which can be made at a later date, it proves my map as least functions for both CTF and TDM game mode variants.

Below are screen captures of my CTF and TDM maps in action.

Capture the Flag:

Capture the Flag (Environmental Hazard Active):

Team Deathmatch current functional build:

Overall Conclusion:

Through this unit I have utilised industry standard techniques to produce through iterative measures, a multiplayer map for use in Unreal Tournament 2015. The map is built mainly from BSP brushes, with some Static Meshes in place for interactive elements.

Whilst I already had some knowledge of the UE4 blueprinting system, it is somewhat different within the Unreal Tournament Editor, and feels more akin to UDK than UE4 itself, limiting some of the content I can edit with blueprints when compared to the blueprinting system in Unreal Engine 4.

Despite this, I feel as though I have built on my previous knowledge from multiplayer level creation in at least UDK which will benefit me when building further, going forward in Unreal Engine 4.
For example I now have some basic experience in adding in interactive elements, which are more complex than simple lifts or teleporters (which are now physically provided within Unreal Tournament Editor itself) from implementing my environmental hazard, aimed to affect the flow of a multiplayer game by forcing the players/bots to use alternate paths..

3D Computer Game Engines - Peer Review Cycle 5; CTF-Millv10

I have conducted one final peer review to gain feedback on the environmental hazard alone, following tweaks made to benefit play, the questions were as follows;

Q1. I have tweaked the regularity of damage dealt to the player within the limitations of Unreal Tournament. Do you feel this change has any bearing on the effect to the player, for example do you think the player would be more likely to want to escape as soon as possible.

Q2. At 10 damage per second, split into 2 hits of 5, do you still feel the damage is enough to impact the flow?

-----------------------------------------------------------

Peer 1:

1.  I think the change on the more/faster pace of damage is better and it will make players avoided or try to get out of the hazard as soon as.

2. I do think this damage is sufficient enough if it was possible to do more damage it over time this would be a better option.   

-----------------------------------------------------------

Peer 2:

1. I think the player is more likely to avoid the central path with the new damage.

2. I still think it may still be a little low? Though you cannot avoid damage by jumping, you can still use the translocator, which I guess is a risk vs reward, as you are exposed while you aim/teleport.

-----------------------------------------------------------

Peer 3:

1. Lava is much better now – workaround for two ticks per second is solid without having to tamper within blueprints needlessly. It feels more ‘realistic’ although you could work on having it dripping from the player – melting arms, legs and faces. Get on it lad.

2. Apparently I don’t read questions ahead; as answered previously – yeah I feel the damage is definitely more on par with what you’re looking for here. The whole point I made initially was that you could literally strafe around and get a handful of kills and with other incoming fire you barely noticed it at all. Now however that isn’t the case you do feel the impact and I would safely say it affects the flow.

-----------------------------------------------------------

Peer 4:

1. Definitely! Makes you want to get out and find alternative routes and avoid the lava, so it brings variation to the game and opens up.

2. No, the game feels fine. It just causes you to think more about routes to take, rather than going a direct route or standing in a fire fight too long I think.

-----------------------------------------------------------

From the feedback I have received, I can tell there are still tweaks I could ideally benefit from making, however within the limitations of Unreal Tournament Editor I'm not 100% sure how modifiable these are.
I would ideally like the Translocator removed from my game mode, but on researching that change, without modifying the core blueprint of my game mode I cannot remove it.
There is also still the possibility of adding more damage to the pain caused by the environmental hazard, whilst I personally feel 10 health per second is enough, I will look into this again and test higher damage scales in full play with bots present.

From this point going forward, whilst these may not be reflected within this unit due to time constraints, the elements I will look to continue working on are;

• Overall damage dealt by environmental hazard.
• Implementing my own game mode blueprint based on CTF, with the ability to remove the translocator.

3D Computer Game Engines - Changelog 4.0; CTF-Millv10

Items modified this changelog;

• Lapse in time between damage dealt via pain causing volume.

Details;

I have been experimenting with the time lapse between damage when the player interacts with the environmental hazard, though the damage per second still ultimately dictates the amount of damage dealt.
If the damage per second remains at 10, but the lapse between damage is set to 0.5, the damage dealt to the player will appear as 5, this is down to the damage being predetermined to "damage per second", and the length of time itself isn't editable as such.

I have changed the lapse between damage to 0.5 seconds, whilst the player is still receiving the same damage, they are receiving it more frequently and this may result in player experience changing, wanting to get out of the environmental hazard faster to minimise damage taken, this is still not set in stone and I will continue testing until I and my peers are happiest with the result.

I am also having slight issues with the implementation of friction within the environmental hazard, this was a suggestion by one of my peers, to possibly slow down the movement of players and bots when within the pain causing volume.

I am under the assumption that without making the volume a water volume, I am unable to alter the fluid friction, as I have changed the value between 1.0 and 40.0 with, producing no navigational effects on players or bots.
Changing the volume to a water volume would add unnecessary animation changes to both the player pawn and bots in-game, and would result in them appearing to swim over the molten steel which would look out of place.

Without casting effects to the pawn used in the UT Editor, I am unsure as to ways I could change this. Adding to this, as I have tried adding effects to the character previously (when trying to blueprint my own damage over time sequence) and have come to various stumbling blocks, due to the limitations of the character effects in blueprints.
These are of course counteracted by the fact there are things like pain causing volumes freely accessible to use, but there are once again, limitations to the usage.

Bearing this in mind, I will for now, be leaving the friction unchanged and moving forward into another peer review for any feedback on the regularity of the damage dealt, once this has reached a point at which I and my peers are happy with the values and functionality, I will endeavour to revisit the friction values once again.

3D Computer Game Engines - Peer Review Cycle 4; CTF-Millv09

Having applied the last change detailed in the previous changelog, the audio clip. I found the correct way of implementing the audio into the level in the form of the "Play Sound 2D" node within the level blueprint. The players are now alerted to the Environmental Hazard by both visual and audible stimuli.
Below is the finalised blueprint as it stands, this is of course subject to further tweaking following this peer review cycle.

I have once again prepared questions to be answered by my peers.

Q1. The damage dealt by the environmental hazard has been doubled, does this feel more adequate in terms of affecting the gameplay?

Q2. The environmental hazard will subside roughly half way through the round, and then make a resurgence with roughly 1:45 left on the clock, does the hazard re-emerging feel like it makes a better impact on the flow of the map?

Q3. Do you find yourself using the upper pathways any more or less with the doubling of the environmental hazard damage?

Q4. The blueprint is set so to introduce the environmental hazard twice in the first half and twice in the second, do you feel the environmental hazard lasts long enough before subsiding both times during play?

-----------------------------------------------------------

Peer 1: 

1. The damage seems sufficient and better than before

2. It showing up twice does make an effect on the game

3. Not really as I can still run through it and take only 10 damage and I can use the teleport gun to jump over it.

4. I thing the hazard last long enough in both halves.

-----------------------------------------------------------

Peer 2:

1. I think the damage value is better, though are you able to increase the rate of damage?

2. There is more of an impact though you can still run through it. You could try adding in a channel that comes up and puts a wall either side of the lava to make it harder to just walk through the middle and further force the gameplay change.

3. I do prefer to use the upper paths anyway because it’s less risky.

4. I think twice per round is a decent number of times to affect gameplay and make it interesting.

-----------------------------------------------------------

Peer 3:

1. I felt like playing the game was fast paced, I found it pretty difficult to get over to the other side of the map without dying, however that might be because I’m not good on PC game FPS.

2. Yes, I loved the idea of doing that as it makes you have to use the bridge. However, I’m not sure if you can get across it or if you are meant too, if you are not meant to get across it I did a wallride and managed to get past it without using the bridge.

3. Again, I was not too sure on what it did, I understand the idea of not being able to cross, at least I think it was the idea? When I did die on it and I got a notification telling me that I forgot to turn on the water, I started looking for a tap, not sure if there is one but if there isn’t I think you should add it!

4. Well, because of how rubbish I am at playing games I did not play the entire length of the match, But I feel like once it is activated, if you added like a Mechanism to turn it off, or maybe a fire wall which will point in the direction of an opposing team, and when the flag is captured the lava will start gradually increasing on the opposing teams map until either the flag is returned or a flag is scored, other than that, great job!

-----------------------------------------------------------

From this feedback I have gathered that there are still some slight changes I could possibly make to this, I will be be experimenting with the length between every hit of 10 damage when in the environmental hazard.

Due to mixed abilities of peers, and that of potential end users I would be hypothetically aiming my map at, I will be taking into account all points made, but I will not be adding a tap, corresponding with the "You forgot to turn on the cold water" message when the player dies in the Environmental Hazard.
With regards making it harder to get through the environmental hazard also, I may look into inserting a volume which slows player movement down a little, though with the damage extended, and enemies/bots dealing damage in tandem.

Changed I will be experimenting with are as follows:

• Length of time between each damage tick when interacting with Environmental Hazard.
• Player/Bot movement speed when interacting with the Hazard.

Any changes made to the level will once again be detailed in a changelog.

3D Computer Game Engines - Changelog 3.0: CTF-Mill_v08

Since my latest peer review cycle, I have made 3 of the 4 required tweaks suggested by my peers, with the only omission being that of the sound clip, to provide an audible alert when the steel container animation is occurring. This will be added shortly, when I figure out exactly how to add it, since the two methods I have tried in the blueprinting process so far have not worked.

I have also removed the switch to start the process, allowing the steel containers to move autonomously, and now entering the playable area twice, this allows for the flow of the game to be altered up to four times in one game of Capture The Flag as opposed to the initial one time.

The amount of damage the environmental hazard now causes has been doubled also, to hit for 10 health per second, this actually feels much much effective in playtesting, as it as least made me take note of my health more often, and left me facing the decision of whether or not I should retreat to gain health from nearer my base, or risk there being some unclaimed near the enemy base.

It took some extra tweaks to get the times just right, but overall it feels like an improvement on impact of flow, as I have also experienced some bots dying in the environmental hazard, as well as physical gameplay.  The lack of a button would take away the dependency of players competing to get to the button to trigger the hazard, and allows the flow to continue unhindered until the molten steel and with that, the pain causing volume actually appear.

I will continue playtesting this and endeavour to add the audio clip in to signal the start of the environmental hazard, I will also hold another peer review cycle once the audio clip has been added in, to gain feedback on the changes I have made to the map once again, with an eye on improving it even further.

3D Computer Game Engines - Peer Review Cycle 3; TDM-Millv08

Through peer review cycle 3, in addition to my CTF map, I converted the map, at it's core to a TDM build, taking the same map and seeing how it would cope in a straight shooter environment with no objective to fulfil other than killing the enemy to score points.

I again prepared questions to be answered;

Q1. Jump straight in and get playing, add in 15 bots and progress, when the game is five minutes in, access to the environmental hazard will become available.

Do you think this is an acceptable timing for access to the environmental hazard? As I feel leaving it til 7:30 in would be too late to have any real effect on the flow.

Q2. Do you feel the map, when played in TDM flows any differently to how it flows in CTF mode? If yes, do you feel this is this a positive or negative difference?

Q3. As with the CTF mode, do you think the health deducted by the environmental hazard is appropriate? Should it be increased or decreased and why?

Q4. Do you find yourself using the upper pathways more or less in this mode than you did in Capture the Flag?

Q5. With the objective simply being to kill opponents and gain points, do you feel the amount of weapons available is still enough to always have a reasonable amount of ammo ?

-----------------------------------------------------------

Peer 1:

1.   Alright so you’re basically planting the switch in under halfway by a couple of minutes. Honestly I’m not too sure, having tested this substantially at my end I feel that this works absolutely fine – on a more competitive level this may have more bearing but it seems fine, just don’t take my word for it on the timing here.

2.   Despite the obvious of no flag carrier to ‘hunt down’ not particularly. Your map is small, compact and flows well with it’s layout so TDM doesn’t really change anything up here as with CTF you’d either stumble into the flag carrier or you wouldn’t – whereas this just removes that but still has the general idea at hand. I think it works well.
3.   I’ll literally copy and paste my answer from the other document here:

‘The idea and role of the hazard will be absolutely fine end game but I tested this over several games and it currently feels redundant in the sense that you can practically ignore this and be at no real disadvantage. To test this, I stood in the lava and strafed up and down the length and got about 5 kills before the lava eventually finished me off.

·         The lava needs to be ramped up in terms of damage. This will work because the pouring serves as a warning that the lava will surface and thus people have plenty of time to position. Also you can pretty much avoid the damage from this entirely by jumping – arguably you’d take an incremental tick of damage which you won’t even notice anyway amidst the fast paced game type.

I feel that the lava should still be a per second damage type but perhaps triple. I’m not sure double would do it justice (but this could be your next rule of the loop testing here, double it and see how it balances). I feel like it should have more of a decision on the outcome of whether you live or die if you take ticks from this and it doesn’t feel like that currently.’

4.   If anything less due to instinctive nature of going up top allows you to see past the walls so you can spot the flag carrier easier. This is at no fault of your map and honestly it still works well because your upper pathways are connected well; offering freedom of routes.

Probably. The only thing I’d really test for this TDM iteration going forward is this – maybe carefully place a few more mid / lower range weapons as you see fit and test it as I think this ‘might’ be beneficial.

-----------------------------------------------------------

Peer 2:

1.   Because this is Team Deathmatch, the gaming is focus on mostly the combat. In my own opinion it would be better that have the hazard appear earlier, because the player will be mostly focusing on each other.
2.   I don’t see any change when the map is played in TDM. Because of the game mode the players are focusing on each other and thus it is the same experience as CTF.
3.   The environmental hazard dos not need to be changed at all in this game mode. But what you do need to add is another switch for the other team. Because there is only one of them and it is place at an opposing team are.

4.   When playing this map I did indeed use the upper pathways less. This is because the fact that most of the bots are playing on the ground. In order to find out if they get used or not it is best to test this on a LAN network.

5.   I would say that you have a good amount of weapons in the map and the amount of ammo is ok.  I have noticed that you have some weapons place close together. What you could do to get the top area used more often is to place some of the weapons on the upper level as well. This could get the bots to use that top area.

-----------------------------------------------------------

Peer 3:

1.   I think the timing for the hazard is acceptable and dosent need to be altered in the sense of timing, however I don’t think it has as much impact on the game as it potentially can in a ctf game. This could change if the damge was higher than that in ctf.

2.   I think it flows the same but as the objective is different I think more cover needs to be added as it is to open for the tdm mode as I can see the enemy team pretty much straight away and I am always fighting multiplayers on my own which can sometimes get annoying in a death match mode.

3. I didn't find myself using them at all but I thing that is partly down to all the bots being on the ground as well and them not going up there either.

4. In my opinion there need to be less or they need to be relocated as things like health and armour are too easy to access and need to be more scarce as this is vital on keeping players moving in a death match mode.

-----------------------------------------------------------

From these answers, it is quite clear my map isn't quite ready for the transition into a straight TDM map yet, mainly as there are cover issues with too many open spaces and the pickups are placed in an ineffective manner.
There will also be changes made mirroring the CTF mode changes, making the environmental hazard appear more often, for bursts at a time.
I will be looking into making these changes, but they will take second place to the changes made for my primary game mode, Capture the Flag.

These changes will be detailed in a changelog following experimentation.

3D Computer Game Engines - Peer Review Cycle 3; CTF-Millv07

For this peer review, I implemented the Team Deathmatch game type as opposed to Capture the flag, allowing myself to expand on the quality of my map with a second style of play.

My map was in part designed to be capable of handling both TDM and CTF game modes, somewhat similar to some of the most successful maps on shooters like Call of Duty's 'Scrapyard' and 'Highrise'.

For this peer review, I had implemented the steel containers on a matinee for base functionality, triggering the appearance of lava and a pain causing volume for realistic gameplay feedback.

I once again formed a set of questions, this time four, more detailed questions, as I am progressing through this unit I feel more detail is necessary to gain proper feedback, the questions were as follows;

-----------------------------------------------------------

Q1. Without adding bots in, play the map and wait ‘til 3:30, the switch to activate the environmental hazard should appear, press the button and let the animation play out.
Do you feel the animation is the right sort of length? Or would you say it is too short or too long?

Q2. Back out then restart the game, add in 15 bots and play with a focus on making sure you activate the environmental hazard.
How do you feel the hazard impacts play? Is it balanced in terms or health deductions? Too much? Too little?

Q3. Do you feel half way through the round is an adequate time to enable access to the environmental hazard? Or would you bring the time forward or push it back slightly? If you would make any changes, why?

Q4. How do you feel the environmental hazard impacts the flow of the game, do you notice any slow down to the pacing or any other negative effects on gameplay structuring?

-----------------------------------------------------------

The feedback was fairly positive in terms of functionality, with suggestions of tweaks I could make to the environmental hazard itself.

Peer 1:

1.       The animation itself is fine, not that it’s relevant to functionality but I like the added touch of the block out pouring the lava. It just feels correct and it serves as a pre-emptive warning that the lava will be coming up.

2.       The idea and role of the hazard will be absolutely fine end game but I tested this over several games and it currently feels redundant in the sense that you can practically ignore this and be at no real disadvantage. To test this, I stood in the lava and strafed up and down the length and got about 5 kills before the lava eventually finished me off.

·         The lava needs to be ramped up in terms of damage. This will work because the pouring serves as a warning that the lava will surface and thus people have plenty of time to position. Also you can pretty much avoid the damage from this entirely by jumping – arguably you’d take an incremental tick of damage which you won’t even notice anyway amidst the fast paced game type.

·         I feel that the lava should still be a per second damage type but perhaps triple. I’m not sure double would do it justice (but this could be your next rule of the loop testing here, double it and see how it balances). I feel like it should have more of a decision on the outcome of whether you live or die if you take ticks from this and it doesn’t feel like that currently.

3.       I can’t help but feel like it should slowly sink and disappear. I like the idea that it surfaces half way but when this no longer disappears it feels a bit off to me. Quickly thinking of something you could into your next test what about quarters? So 3.5 / 2 = 1.75. So you could have the lava surface 1.75 in and then have it vanish at 3.5 – at 5.25 it resurfaces and stays until end of round at 7 minutes.

4.       No issue whatsoever really, the lava is jumpable – and assumable on final blockout it will be encased by a small raised section (so it makes sense) which will either automatically be a part players step over depending on the height you set this or a simple jump. I don’t feel this really adds or takes away from the flow at all, the map is practically the same. Another point here regarding the CTF map type inparticular is that this shouldn’t be affected in either way either – even for the flag carrier for the reasons described above.However I would look into what happens with pain volume scaling (if it even exists) when flag carrier opposing team has advantage.
Final Comments:
Adding to what I said in 3:
Because the switch surfaces and may not always get used instantly the timings could be off, now you could either keep it working in quarters regardless of when the button is pressed (ideally wanting players to hit it close to as soon as it spawns) or you could ditch the switch entirely and have the lava automatic. This will possibly add to the idea of your map – automated machinery on timing systems pouring the lava and the lava draining over time etc.

-----------------------------------------------------------

Peer 2:

1.  Animation is fine to be honest and a really nice touch.

2.  I found with the hazard, it forces you to go through alternative routes.  So by the hazard being there and causing health problems and potentially death, you are creating choke points else where in the level and not having as open, although there are several options to back and forth across the map.  It’s a nice touch.

3.  It seems fine.  Possibly bring it in slightly earlier, but when you’re killing bots you don’t notice the time being an issue for the hazard.  The map covers all the bases I feel.  There is a lot of variation, its large enough, plus the hazard, its fast but not too fast.

4.  Doesn’t slow it at all. Just forces the player to take alternative routes.  It’s a quality map!

-----------------------------------------------------------

Peer 3:

1.       I think the animations length is fine however if possible try extending the damage over time so that players can just stand in it for too long.

2.       The hazard doesn’t seem to hinder gameplay to much however if you do increase the damge over time I would added a few more vertical floors near the middle to avoid hindering your map flow once it is active.

3.       I don’t think the timing of when the hazard can be activated needs to be altered at all and is set nicely.

4.       Currently as the hazard doesn’t kill players that fast it doesn’t have that much impact on the flow of your map however if you altered this then some changes would need to be made.

-----------------------------------------------------------

Peer 4:

1.       The animation feels about the right length as the objects themselves are enough of a warning that the hazard is being activated.

2.       I think to have more of an impact on the gameplay, the damage should be higher to make it more of a risk/reward type element.

3.       I’m not sure if this is something you already have in mind, but if I were to implement this hazard myself, I would make it first accessible around 1 minute into the round, then the hazard area itself should stay for around 30 seconds, then it should clear up and after another minute the event is accessible again. Making it a repeatable event, and not just one that stays will keep the gameplay fresh and have the players always using different routes through the map. Possibly putting the button in the middle of the upper gantry will make that a strategic area for gameplay, fairer on both teams, and I think this would make more sense thematically.

4.       I think the hazard needs to have more of an impact on gameplay, as I didn’t notice much of a change. I think the repeatable event and higher damage would help with this. I think it would be interesting to have the level flow change multiple times through the game. 

-----------------------------------------------------------

Peer 5:

1.       I would say that the animation is indeed the right time. By putting it at the halfway point it adds a nice twist to the gameplay.

2.       With the addition of the lava in the middle of the map, it will make the player take the higher level. This will also put the players at a disadvantage, so it is up to them wherever to take that risk or not. I like the idea you have put there, but I have noticed once it is activated it stays there. You could make this so it can pop up for a certain amount of time and then it falls back to the ground again. But if you do what it to stay up there, I would say the damage over time is fine.

3.       I liked the idea of having the hazards at the halfway point. It makes a great game changer and it could also turn the table for the team players. If one team is using that bottom part a lot, then activate that switch to stop that from happening.

4.       I do not see any changes to the gameplay when the hazard is activated. The bots still take the hazard route anyway, so the best way to find out is the gameplay slows down or not is to test with human players. In my opinion I nice twist for the hazard is to have the damage over time increase at the time passes. It would make the game more interesting.

-----------------------------------------------------------

From this peer review cycle, having gathered feedback from five of my peers has allowed me to pinpoint some experimental things to try out with the next build, I will be experimenting with;

• Environmental Hazard damage values (Currently 5 health per second, looking at 10)
• Environmental Hazard presence (Possibility of making it subside and resurface)
• Remove interaction to begin Environmental Hazard sequence.
• Insert sound clip for audible warning

These experimental changes will be documented in the next changelog.

3D Computer Game Engines - Changelog 2.0, CTF-Mill_v06/v07

To begin the changes which needed to be made for this changelog, I adopted a couple of Unreal meshes and copied them out into a folder of pieces for this level, this included a standard button and the lava material which had been copied out in previous builds.

Initially, unaware of the "Pain Causing Volume" accessible through the menus in the Unreal Tournament Editor, I began blueprinting a 'damage-over-time' type piece, with the idea being that as long as the player stays within the volume (placed directly on top of the molten steel following tipping) they would receive a pre-determined amount of damage per second.

As I was having some troubles with this, in comparison to the creation of blueprints in the base Unreal Engine 4, I consulted with a peer who brought to my attention the pain causing volumes, this turned out to be exactly what I needed and was put in place immediately.

For basic functionality purposes, the creation of my environmental hazard required me to make static meshes out of a few of the BSP's I had used for placeholders, once converted I began the process.

I place the switch blueprint, the environmental hazard itself and the pain volume underneath the floor for ease of use and ease of transition.
I created a matinee for each respective piece of the environmental hazard, laying out and animating them as necessary, with the steel containers being placed in one of the side corridors branching centrally from the playable area.

As can be seen below, the matinee for the button itself is triggered after a 210 second delay from the event begin play, this is the half way point of the first half in a Capture The Flag game.

When approaching the button, the user will see a "Press E" prompt and when E is pressed, Unreal will make a call to the "Matinee Steel Container" event.
Again seen below, this event subsequently plays five matinees, one for each steel container, one for the environmental hazard itself and one for the pain causing volume. At the same time is reverses the matinee for the switch, sinking it back into the ground and removing it from play so as to avoid occurrences of eventual players spamming the environmental hazard.

This could possibly have been built within blueprints as I initially intended, but for quick functionality purposes, this works as my original idea was intended and could possibly be cheaper on CPU usage.

Going forward, I will be putting forward another set of questions for my peers to accompany the new build, and will be once again making any tweaks with the feedback in mind, these could be regarding timing of the access to the environmental hazard, the length of the animation itself, the damage dealth by the pain volume and more. Any feedback will be added and built upon.

Going further forward I will be tweaking this map for either the DM or TDM game modes, I feel TDM may be a more likely alternate path based on the sizing of the map, but will experiment none the less, this will likely demand a tweak to the environmental hazard timing, as I think DM and TDM respectively have different time limits assigned to the 7 minutes a half of CTF.

3D Computer Game Engines - Peer Review Cycle 2

Since I made changes after my first peer review cycle, I have asked three of my peers to once again review my level and provide me with feedback I can use to build further on my level.

I once again proposed three questions;

Q1. The lower floor access has been taken away, how do you feel the game flows (With regards pacing, bot navigation etc)?

Q2. Do you feel the map would benefit at all from being larger or smaller now after the lower floor has been removed and if so, why?

Q3. Are there any general improvements you think I could make to the functionality of the map? Absolutely any suggestions welcome to improve the level.

Peer 1

1. Nice flow – definitely a positive change in my opinion.

2. Map is spacious and flows well enough without the need for a lower floor. If you were to pursue this idea you’d probably have to universally scale the map or something along those lines.

3. Realistic lava hurts. Really straight forward, works – fun. Happy days?

Peer 2

1.  Everything seems smooth, everything’s perfect, lots of different routes to take to get to the other teams flag, weapons placements, cover.  Looking forward to the lavar and the element with the beam going active! J

2.  The map size seems pretty spot on, possibly make it larger.  That’s entirely up to yourself.  Its fine the way it is.

3.  Get the lavar working! Haha!

Peer 3

1. The flow of the map seems completely fine and smooth and dosent need to be changed at all.

2. I don’t think the map size needs to be altered at all and is nice and complements the game mode nicely.

3. Get the lava functioning.

------------------------------------------------------------------------------

There is one overwhelmingly popular opinion which runs parallel in each reply, the molten steel/lava item I intend to have functioning in my level needs to come next.

The flow of the map seems fine from peer feedback, with the varying route options still remaining, with no excess paths which bots refuse to navigate.

The map size in general seems fine from feedback, with one slight suggestion of possibly making it bigger, but that being down to my own design decisions.

My next changes to be made revolve around the environmental hazard, in which the molten steel containers move into the playable area from the side, tipping some molten steel out as they go, this causes the lava-type effect on the strip in the centre of the map, which is intended to damage players over time, and kill on impact if a player is struck by the molten steel.

This is a functional addition and will be added within the next changelog.

3D Computer Game Engines - Changelog 1.0, CTF-Mill_v05.

I have made my first set of changes within my level and as a result, I have two versions of my map to test, Changelog is as follows.

CTF-Mill_v05-BIGCTF;

• Spawn points doubled for BIGCTF (Now standing at 32 on main floor).
• 6 Spawn points added to lower floor to fix pathing errors to pickups on lower floor.
• Access to middle side corridor blocked with blocking volume (allows all but pawn to pass through).

CTF-Mill_v05-Standard;

• Lifts removed to bring map size down vertically, only two tiers remain (ground and staggered walkways)
• Access to middle side corridor blocked with blocking volume (allows all but pawn to pass through).
• Lower tier not yet removed, in case of further alterations being made, if none are made, these will be removed at a later date.

Some pathing errors remain in both iterations when viewed via viewport toggling, teleporters are being considered in place of elevators as I feel these may work more efficiently, as a bot would only need to enter the teleporter whilst needing to exit a lift.

I will be playtesting these two builds and gaining peer feedback on the two, then experimenting based on the feedback and also trying out teleporters within my level, going forward I will be continuing to follow the rule of the loop, I will be saving these builds out and playtesting/peer reviewing v06 of CTF-Mill.

3D Computer Game Engines - First Peer Review Cycle

Since the initial playtest I have approached four of my peers and asked for feedback on my level in its current state, I prepared three questions and set the map to play.

The questions were based around map size, flow and overall gameplay, they were;

Q1. Explore the map without bots top start, what are your opinions on the size of the map? Too small? Too large? How could this be improved?

Q2. Add in 15 bots, do you feel the game runs fast enough for a capture the flag game type? Should it run faster or slower and why?

Q3. Do you feel the amount of weapons/health and armour pickups is adequate? Should there be more or less and why?

Peer 1:

1.      The map is well proportioned and generally feels fine, it’s definitely a little spacious and there’s bound to be moments of uneventful combat as a result. Although obviously not a UT veteran I understand the concept of upping the map size to 32 and how that most likely address this issue. If this persists as a problem you could grab everything and try universally scaling things – perhaps knock 25% off if 50% is too much. This will ultimately depend on if corridor sizes still work but nonetheless.

2.      Game runs well enough – due to bots not heading to the lower floor though I would emphasize either a change to 32 or consider the 25/50% universal scale downs to perhaps address this. Side to side distance between flags initially seems absolutely fine.

3.      Upper floor feels fine, not sure what you plan on doing with the lower floor – if anything. Could always revisit this question in regards to the lower floor as and when. 

Peer 2:

1.       In my opinion I feel like the map is too spacious. In a matter of fact you can easily add 32 players on this map. The best way to improve this is by reducing the map size so it is suitable for 16 players. Try looking at some CTF examples from the Unreal community and comparing their size to yours.

2.      The top level of the map runs smoothly, but the lower level feels a bit slow. There is a lot of cover down there and you can easily get lost if you do not know where you are going. In my opinion you can try to reduce the amount of cover in the lower level so that can run a bit faster.

3.      The amount of weapons/health on the top level is a god amount, but the lower level has a lack of items. Since all of the action will be taken place on the surface, you good try to add some strong weapons at the lower level, so it will tempt players to go down there. You might also want to add some heath vials in some of the pathways on the surface. Most of the health is right at the player start and they can be quickly taken away from your teammates.

Peer 3:

1.       I don’t think the map is too big at all and is a nice size overall, however I do think adding some more cover to your map as some of the corridors seem a little bit empty and too open.

2.       The map has a really nice flow to it and doesn’t need anything to improve the flow just to be careful when adding more cover as it could affect the flow of the map.

3.       The amount of pickups are fine I didn’t find there to little or to many as they were always there when I need them. 

Peer 4:

1.       Nice size, Was a surprise to see the lift and then find out there is an underground part.

2.       Game is still speedy, weather that is the game or the computer in general, but it runs pretty nicely on these computer’s, which is standard, I wouldn’t say it needs to be faster or slower, the map seems large enough to have a good game and I’d leave it how it is and focus on developing it further (Textures / Ect ) once we are allowed to do that stage of-course, But no doubt, there will always be room for improvement.

3.       There is enough, I like how you have health Vials in a row which boosts your health but as soon as you turn a corner you are straight back into combat, it seems fairly fast paced which is what I like.

------------------------------------------------------------------------------

From these peer opinions, I have gathered that 3 of the 4 have no issue with the map size, the one peer who feels the map is a bit too spacious could have been taking into account the lower level also, which is currently not properly functional. As a result, I will be creating a new iteration of my map, with no lower portion to navigate.

Analysing the answers for question 2, my peers feel the lower level is currently asinine, I feel this is apparent and with this in mind, I will be packaging the map and testing it in Unreal and also cutting access to the lower floor entirely, allowing the map to be tested with less vertical expansion.

My third question, based on pickup locations and amounts seems like a positive response, as there are enough health and ammo pickups generally placed around the level, with UDamage powerups placed near to each base but timed in terms of spawn, I will however be upping the pickup count in the underground section somewhat.

I will be following the rule of the loop in that I will be creating more iterations of my level and replaying and re-testing as I go, in effort to improve the playability and functionality within my level with a typical end user experience.

3D Computer Game Engines - Initial Playtest

Upon launching my first playtest I noticed an issue straight away, all bots were spawning on one spot, however I soon noticed that as I was hitting "play from here" in the editor, that all bots would subsequently "play from here" also.

This was quickly fixed by simply hitting play in the editor instead, forcing my pawn to spawn from a 'UTTeamPlayerStart', the bots also spawned from the player starts upon addition.

Upon first glance, the bots do no seem to be using the elevators, which isn't of paramount importance right now, due to the simplicity of the bots' AI. I intend these elevators to be used as an avenue of escape for users to take when carrying a flag and being chased by other players.

I am under the impression that an objective driven AI will follow the one objective of capturing and securing the enemy flag, and as such does not see the point in taking an alternate path to the objective if carrying a flag.

Taking this into account I will be looking into possibly adding in more bots to crowd the level slightly, with the possibility of the flagbearer being then pressured into the tunnels below.

The only other method I have of testing this is to get a group of users (preferably 16 or more) across a LAN connection, and having them test it thoroughly.

3D Computer Game Engines - Initial Blockout Process

I jumped in and began my initial blockout process using static meshes, it didn't take long, building from a top down layout to gain a rough shape for my map.

Following this build, I was informed that the base blockout should be developed using BSP brushes and not static meshes, following this I began converting the blockout into BSPs.

Whilst changing out the static meshes for BSPs, I shortened the overall length of the branching corridors, allowing me to adapt my floor plan. The aim was to effectively nullify the chance of any player sitting in the corridors overlooking the enemy base, shooting enemies as they spawn, as spawn-camping is somewhat of a problem in some of today's modern shooting games and must be kept in mind with regards gameplay and functionality.

I added the walkways seen above to the map and then began to iterate upon my map design, the main change I have made through iterations is the side corridors were changed and are now vastly different.

Whereas the original blockout did not have the 3 tiers proposed in my original design plan, the iteration was created so that the three tier plan would be brought into play.

I cut off the four corner rooms from the branching side paths and place elevators in each respective resulting corridor, the elevators were place to move down to a lower tier consisting of a crossover network of tunnels.

These are in theory, to act as a navigational aid as well as a puzzle also, which means with some study of the map, any player could become used to the tunnels and utilise them to their advantage, escaping from other players with the flag in hand, boosting their chance of scoring points for their team. This ultimately achieves the game's goal, fulfilling the 'X' of the game and providing the game with a winning and losing team.

Following iteration, I have begun to add spawn points, weapons and ammo, health and armour pickups to accompany the flags in both the blue and red team's respective bases at either end of the map. From here I will be both play testing the map with 15 bots myself and also conducting my first peer review cycle of this unit to gain feedback on multiple aspects such as map size, weapon/health/armour placement and overall functionality.

3D Computer Game Engines - Unreal Tournament Creator Tutorials.

As part of this unit I have completed the basic Unreal Tournament creation tutorials which are designed to create a functional CTF map in roughly 15 minutes.

These tutorials have helped me in using BSP brushes and in refreshing my basic knowledge, as some features are implemented differently to my previous work inside UDK.

I will be returning to my previous blockout and rebuilding with BSP brushes to expand on this knowledge further.

The tutorials show a user how to;

• Add player spawn locations 
• Add weapon pickups 
• Modify jump pads 
• Navigate the viewport 
• Adding and subtracting using geometry tools 
• Adding and manipulating meshes in the level 
• Adding CTF flags 
• Mirroring a map to create opposing sides 
• Coloring simple BSP meshes.

The map can be seen below, with the red base in shot.

Following the previous tutorial outcomes, I have completed another two tutorials which cover the implementation some more intricate parts of level design, beginning with lifts.

The lifts are actually very easy to implement within UT and can be drag and dropped in, whilst these could be duplicated into my own folder of blueprints within a map I will be looking into the blueprinting itself to see how it works.

I dragged and dropped the lift actor into my level, placed it appropriately, built meshes and clicked play, it was very simple to build a lift in Unreal Tournament on the face of it.

Teleports are also a very simply implemented feature in Unreal Tournament, with the blueprint being directly accessed from the content browser,

These can be dragged and dropped in much like the lift blueprint, presenting the user with a teleport node and a target node, which can both be manipulated and moved as appropriate.

This allows Unreal Tournament functionality to be added very easily and smoothly.

The final piece added in before the level was made playable, was a Navmesh, this was implemented in the form of a volume encompassing the entire level.

This allows bots to navigate all of the surfaces within the Navmesh volume and is a huge improvement on the node system within UDK, the apple-like navigation nodes.

Through these tutorials I have learned the new methods of implementing older features from UDK, the engine has been streamlined more and as such implementation of things like lifts is far easier than it used to be.

I will of course be looking into the blueprints themselves, to see exactly how they work to expand my knowledge, though I expect the blueprints themselves will be fairly similar to previous kismet work, as well as the previous work I have done in UE4.

I will be looking to implement these features into my level, though I am unsure as of yet how they will affect overall gameplay, as a result I may go for a simpler design with minimal lifts/teleports etc, though it is important I know how they work and these tutorials have therefore served an important purpose.