Monday, 6 June 2016

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.

Thursday, 2 June 2016

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.

Thursday, 26 May 2016

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.

Monday, 23 May 2016

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.

Monday, 16 May 2016

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.