/
next project One Life

Combat Sim

DESCRIPTION

Combat Sim is a third person shooter that I briefly worked on at VFS, working using only the given assets; for this project I created a level with two stealth sections and two combat ones. This was my first experience working on a third person shooter, working on this project was very challenging because the camera was very close to the character and fixed on its right side. I tried to create some interesting geometry, but sometimes this made hard to read the pattern of camera scans and lasers because of the position of the camera.

Even thought I had a second take on the map, there are still some issues on this level: that’s why I would like to point out some of them in the following paragraphs. I am going to take some screenshots from the video walkthrough: if someone wants to examine more in depth the issue, watching the video should be way more explanatory.

A very interesting lecture that inspired me during this project is “Creating Satisfying Combat Experiences at Insomniac Games“: even thought it is about FPS, a lot of rules can be applied to TPS as well.

DETAILS

Catg

PROD.

ENGINE

REL.

TYPE

TERM

I. Level Design breakdown

~0.55

In this first image you can see the camera issue that I was talking about: as you can see… you can’t see. This situation lasts for a few frames, then it gets better, but it happens during a very important moment, when the player is jumping in order to avoid a laser.

The wisest solution would probability be changing the camera angle, but in this project the challenge was working without changing any asset. In this situation, avoiding to have narrow paths with walls on the right side, would have been a better design solution.

Camera issues

~ 01.06

I applied a post processing effect to the camera, changing colors of some elements in order to enhance the visual feedback and the atmosphere. This crated two issues:

– when the player looks at the laser from some angles, the laser disappears and with it, all the visual feedback.

– when the player get caught, the cameras and lasers don’t change anymore color.

Having more care for issues like these is very important, they might look like small things but it is very important to be sure that players understand why they fail. They should think “ok, my bad” not “this game is wrong“.

Invisible laser

~01.47

In this other screenshot I show another situation where the prospective of the camera can create some big issues. A laser is right behind the player, that doesn’t have enough awareness of the danger behind him, because is totally focused on following the movements of the other equipment in front of him.

In this case, shortening the range of the laser on the left would surely help to not put the player in dangerous situations, without him even noticing it. Danger is fine, challenge is fine, but situations like this create quite a bit of frustration.

Camera issues

~01.58

Here the most frustrating spot of the level; I tried to sneak it at least 15 times before succeeding. Here we can see at least 3 issues:

– no feedback from the laser.

– the danger is on the left, the camera shows the right.

– the light that comes from the security camera doesn’t give enough feedback, because its boundaries are very blurred. Supposedly, players must be totally outside of the ray, but playing it is easy to notice that this assumption is not always true, there is some tolerance that gives a confusing feedback. It would be way better to have a more clear and defined line.

Lack of visual feedback

~02.39

This picture shows something very important that players must always be aware of: the relationship between cause and effect. In this short cinematic I show that the door closes because the camera on its left caught the player. Even thought this might look like a good idea, it is actually a bad one because the behavior of this camera has not consistence with how other cameras work. I taught to the player that he has to stay outside the yellow ring in order to be safe, but this camera got him even if it no yellow ring was shown. The basic idea was good, but in this case I should have found another system to trigger the closing of the door.

Cause-effect feedback

~02.50

Apparently the AI it is not able to understand if there is an efficient cover between the controlled enemy and the player. Fixing the AI would be the best solution, but in this case I didn’t try to do my job as level designer.

In this case, having cover without breaks and restricting the navmesh in order to force the AI to stay behind the wall would have been a better solution. Surely less visually interesting, but better than clearly showing that something is broken.

AI issues

~02.58

Here something positive to show. I made a short cinematic in order to show some enemies spawning outside of the line of sight of the player. Dying is always frustrating, but it is normal the sometimes happens; however, it should never happen because an enemy that we didn’t see flanking us. This rule is totally applicable also to multiplayer matches, but with an important difference: if someone is behind us, probability someone didn’t check appropriately his area. It is important to provide interesting flanking opportunities in order to keep the pacing high and reward players for risky actions. This creates the most interesting dynamic in shooters, when players are battling each others trying to read the enemy and to guess his next move.

New enemies entry

~03.19

The idea of having AI flanking the player is good, gives variations to combats and forces him to move. Player have a natural tendency to stick to places where they feel safe: once they get the perfect spot is impossible to move them, that’s why I think that it is very important to  find an effective way to push players to constantly move. I tried to do so, but in this case the AI wasn’t vary helpful, because it doesn’t check that the soldier was in cover before recharging. Seeing this kind of episodes totally throw players off from the experience: I think that in order to solve this issue, I should have renounced to the flanking opportunity and forced the AI to stay under cover. 

AI issues

~03.46

In this screen you can see the outcome of me struggling to create an interesting combat encounter. I wanted to have the enemies on a higher ground, but they did’t have the ability to shoot from over the short protective wall that I created for them: then, I decided to remove it. As you can see, now they are standing without even trying to cover, no they are a way to easy target for the player, also because the AI is not able to understand when to stand up or when to kneel instead. In this case, having them on a lower level and placing a protective short wall would have been a better choice.

AI issues

~04.26

This is a very bad ammunition placement: I think that it is fine to push the player to move around in order to recharge his weapon, but in this case he is forced to jump to a wall which is just a little bit lower of the highest high that the character can jump to. This means that probability the player will fail the jump at least once, while the enemies are shooting at him. Having difficult places where to jump to is fine, but having them during combat encounters can create a lot of frustration.

Bad ammunitions placement

~04.52

This is another example of bad placement of a pickup: it is very close to the critical path but at the same time nothing is pushing the player to focus on it. Some light or particles should have been placed on the ammunition, because this is not a rare collectible, but a vital gameplay actor.

Bad ammunitions placement

~06.26

The idea of moving under the floor is not revolutionary, the Batman series uses it with a lot of success, but with a big difference: the placement of the camera. In this case my camera is inside of the ground, when it should be outside, in order to increase the awareness of the player. If you check the video, you will see how difficult is for him to understand what is going on outside the hole and how punishing can be moving outside of the hole with a bad timing. Having a dynamic camera that moves back during this situations, would be an interesting solution, but I was not allowed to touch this feature, then I should have had found a different solution in order to provide a different but fair challenge to the player.

Bad camera angle

~06.43

Again, another problem related to the camera and to a mistake that I made creating the geometry. The player has a perfect visual on his right, which is totally useless because the camera is behind him: having the camera a little bit further away and centered would help, but here my mistake was placing a difficult jump inside of a stressful area. The player has to jump on a tall block and he has also to time the jump depending on the position of the camera. To be honest, I got stuck on that block many times, feeling a lot of pressure because I knew that the camera was coming. 

Bad obstacles placement

II. Conclusions

The lesson that I learn working on this project is that there are different levels of priorities: it would be amazing to have all the gameplay issues fixed and have the opportunity to create amazing levels without struggling with some features, but this is not always possible. Probability, never.

Everybody wants to do a nice job, but sometimes it is not possible to fix some issues: I think that is very important for me to learn how to hide issues and still create interesting levels for players.