Discover Top Posts Tagged with #unit49

Evaluation of Unit 49

I really enjoyed Unit 49 specifically learning how cameras can be used to guide the player but also purposefully raise tension in the player such as forcing them at a difficult angle when doing jumps, puzzles or avoiding enemies. I enjoyed researching games and how their use of cameras and controls have changed or stayed the same over the years. When doing research into the origins of the Warcraft franchise I found that when they were considering going from RTS (top down view) games to a third person MMO they brought one of their Gnoll models and just tried to make it work with the camera angle they wanted to go for.

"Basically, what happened was that one of the artists on the team just took the Gnoll character from Warcraft III and made it look good at the camera angle that we were using. He kept the same proportions, the same bright colours, the same silhouette with the exaggerated features - and we all looked at that and said, yes, this is what World of Warcraft is going to look like.

"Then he proceeded and did the Kobold, and from then on, that was... Well, it was like, why are we trying to reinvent this thing? Everyone loves Warcraft - let's just make this Warcraft. We don't need any futuristic spin on it, or scary versions of this character, compared to the Warcraft III one. Just make it Warcraft III - that's what the fans are going to love." – Samwise Didier

https://www.eurogamer.net/articles/the-making-of-world-of-warcraft-article?page=2

They were considering changing their art style to be grittier or have a different setting all together but they decided after opening up their Warcraft 3 assets and placing them in a third person angle they still liked the cartoony exaggerated style and stayed true to it. This ended up becoming a staple in future Blizzard games as they never really aim towards true realism that other games do.

I’ll keep how camera angles can manipulate a player’s perception of the environment and characters in mind when creating my game next year. Over the summer I want to begin experimenting with level layouts and creating floorplans for certain sections such as puzzles or boss fights. I’ll also try to block out what cameras I want to go for and how it relates to the character’s controls.

I already know I want the player’s camera to zoom from third person to over the shoulder when taking aim with their weapon. This will be automatic to not clutter the controls but also puts some pressure on me as the player can basically zoom in on certain models, characters or sections of my game. I’ll have to make sure to put higher detail in anything the player is able to get up close to and less detail in stuff that’s far out the way and inaccessible. This is so the game and environment still look detailed but is not as demanding on the PC.

If I was to do Unit 49 again I’d spend more time developing my controls and attempt to add some attacks. I’ll work over the summer to begin blocking out the control layout I have planned in UE4 but also connecting up my playstation or xbox controller as that’s what I feel will play smoother on.

#unit49

Game Walkthrough (Unit 49)

The game test begins with the player simply starting in the default persistant level. This is filled with various cameras that I’ve used in the game as this is where I originally tested and placed the blueprints. The player can mess around with the different labeled cameras and enter the game through the “Enter Game” Trigger Box. This loads up Level 1.

Level 1 consists of a simple maze which the player must escape.

Here is the blueprint for the level. I’ll go into more detail and break down the blueprint and what purpose it serves now.

Upon loading Level 1 the players controls are disabled and a small matinee shows the camera panning across the maze towards the exit and then pans back to the player. A UI widget also is displayed with the prompt text “Escape the Maze!” This is to give the player clear direction and also a hint at what corner the exit is in.

Here the blueprint starts at the “Event BeginPlay” and disables the control input. It also brings up the widget to the player viewport.

Here the players camera is switched to the matinee camera and the matinee is also played. It then holds at the exit for a delay then reverses the matinee.

after switching back to the player camera the player movement is restored back to default and they are able to move again. The “Escape the Maze!” prompt is also removed from the viewport.

At the very beginning of the maze a text render informs the player they can switch between 3rd and 1st person perspective with the T key. This is done with my camera toggle which I made in the third person character blueprint.

Pressing 1 also switches the camera to an over the shoulder view if the player prefers that view. I kept it up to the player as they can use whatever camera they find controlling easier.

In front of the player is also a live CCTV feed which shows a birds eye view of the maze.

These screens are placed throughout the maze at various dead ends to help guide the player towards the exit. When I let people playtest my game a lot of them stopped at one of these screens and simply counted how many lefts or rights they had to make to get to the exit.

To make this I placed a 2D texture capture camera and made a material from it.

I also made sure to set the “Capture Source” to “SceneColor HDR” as it stopped graphical issues I was having with the material.

After building the lighting I found the maze was too bright and the walls were casting large shadows making some parts of the maze pitch black. To even out the lighting I placed a roof on top of the building and added lights to the interior. This helped by removing the natural sunlight from the skybox. I still wanted the birds eye camera though to be able to see through the roof. I set the roof to “Owner No See” and “Hidden Shadow” so it still cast a shadow over the maze even though it was invisible.

After completing the maze and finding the exit the player enters a triggerbox that loads level 2!

Level 2 is a small obstacle course made up of floating cubes the player must jump across.

Here is the levels blueprint. I’ll break down and go into each section seperately.

One of the main features of the Level is the player dying and respawning if they fall. A deathbox waits for the player and destroys the actor.

The player is then respawned at the location of two different target points (Depending if they’ve hit the checkpoint yet).

I created the checkpoint after Alex’s feedback as he found it frustrating having to restart the entire obstacle course when he was over halfway. The checkpoint also motivates the player to keep trying as there’s less punishment from dying.

The Level has a similar beginning to the maze. Player movement is disabled (to stop them from killing themselves straight away) as a camera overlooks the course following the correct path. It also shows the switch and pans over to the door it opens.

This not only shows the hazards of the area but also shows the player what direction they should take and hints what actions they should take to open the door.

After the camera matinee is finished and the player camera is returned to default they are free to move. The player can jump across the course in either 1st, 3rd or over the shoulder depending on what they find easier.

The first major hazard are three balls moving at different times threatening to knock off the player from a narrow walkway. A fixed camera switches the view to a far up top down perspective.

This camera was at first a side on view however players were getting confused with the controls and accidently strafing over the side. I thought of maybe disabling the movements keys except forward and back. Adding invisible walls on either side of the walkway and just having the balls insta-kill the player upon contact. I however prefered the player simply being pushed off as it’s scarier watching them fall. I instead simply adjusted the camera angle. If I was to keep the side on view however I would use blocking volumes to trap the player on a narrow path and disable the player keys (except W & S) in a similar way to how I disable the player movement at the beginning of each level.

After getting past the three balls the player must jump across three cubes. The centre cube has a large obstacle which moves up and down periodically threatening to crush the player.

This was really quick and easy to do. I simply set the matinee to play and reverse with a slight delay between it. This gives the player 3 seconds to jump before the cube comes down and stays down for another 3 seconds.

After getting across the player has the option to go either left or right. The camera matinee from the beginning of the level however guided the player to go right towards a switch. After walking across a narrow walkway the player is prompted to press E and the switch is activated.

This informs them with a text render that they’ve reached a check point and also opens up the exit.

The players camera is switched to a camera facing the door and the way towards the finish of the obstacle course is opened up.

This makes it clear to the player that they can now progress towards the exit. Upon opening the door however the narrow walkway that the player took is now set to rotate every 1.5 seconds. This makes the return trip considerably harder.

It rotates quite quickly and requires good use of timing and jumps to get across. This kills players quite a lot if they’re not used to the jumping. I placed this right after the checkpoint to make it less punishing.

Upon reaching the end of the game a simple switch prompts the player to press E. A congratulations message appears and after a few seconds the player is returned back to the persistant level where they can stop playing.

Here’s a short video showing a quick walkthrough of my level.

#unit49

Peer Review

Blog Review

Very well detailed blog. However, you could expand more about the animations and what programs we used (fuse, mixamo.) And you could also talk about how we got everything into unreal and made the blueprint work and how you created the blueprint and what it does. Also, maybe show each of the cameras perspective when you enter the trigger box. (camera experimentation.)

-Alex

Your camera set-up is great. I like that you can watch the character going up the stairs – the character moving to the higher platform gives it something a bit more interesting to look at. Maybe talk about what cameras and controls you plan to use in Arkade. You could use it for an enemy.

-Silke

UE4 Game Review

1: What Cameras worked well?

The matinee cameras worked and showed exactly what and where you need to go. Also the toggle between 3rd and 1st person perspective worked really well and was smooth.

2: What Cameras could be improved?

I would say to add some sort of fixed camera either on the maze or on the collision course. Maybe add one on the big balls of death on the collision course. So you attempt to get past them with a side on camera. Maybe even add CCTV cameras in the maze.

3: Did you ever feel lost or needed more direction?

No I felt the maze was the perfect size to get through without being lost. However, on the collision course I would suggest adding a checkpoint when you get to the switch to save the player from physically dying.

4: What did you think of the controls?

I felt the controls where fine. However, I would lower the jump distance to make it a bit easier on the collision course.

-Alex

1: What Cameras worked well?

The camera worked mostly well, aside from the fixed camera section.

2: What Cameras could be improved?

The fixed camera section could be improved if movement was changed relative to the camera, rather than the character.

3: Did you ever feel lost or needed more direction?

No. the stage was clear and concise.

4: What did you think of the controls?

The jumping felt rather floaty and somewhat tricky to control.

-James

With my feedback from my peers I decided to go back and makes changes based off my feedback. I added a checkpoint to the collision course once the switch has been pressed so the player does not have to repeat the whole course each time they die.

I also added some additional cameras to the maze to make it more interesting and some visual queues which showed the player that they could switch camera perspective from 3rd to 1st. I also added some fixed cameras to the collision course to give a forced perspective.

With James’ feedback I went into the CharacterMovement (Inherited) as it was using the same movement of the default UE4 mannequin and changed the Jump Velocity and move speed.

By reducing both of these values the character is a lot easier to control and does not overshoot the platform section of the level.

I also changed the forced camera section of the obstacle course so the player is able to navigate past the moving balls section.

-Adam

#unit49

Controls Experimentation

Character Possession

We looked into spawning new characters and possessing them. This can be used to spawn any type of actor such as items or enemies but we’re using a character with a skeletal mesh and so we’re able to take control of them.

I placed a box trigger (made visible for testing purposes) and created an BeginOverlap event for it.

I then was able use the SpawnActor node and select the character from the drop down list. The “GetActorLocation” finds the target points location in the viewport and sets that as the spawn point for this new character. You can also use either a delay or a retriggerable delay so the DoOnce resets. This is in place so the player can’t continuously spam new characters and flood the level with the old ones. If you for some reason want the player to be able to do this you can simply remove the DoOnce. The delay can also be placed at different parts of the code for example you can have the player needing to stand in the trigger for a certain amount of time before the possession or have it instant like I am.

Here you can see the old character is still running in place at the box trigger. This will remain here forever until told otherwise. For whatever purposes in your game you might want the character to do a different animation such as idle if you want to repossess this character later on. If however you’re finished with the old character and no longer need it is better to destroy it.

Collisions

Here’s my blueprint for destroying the old actor. I simply added the destroy actor node right a the moment of the overlap. This is a much simpler way of doing it in my opinion than trying to make every actor overlapping the box trigger to get destroyed. That method could also cause issues as later in the game you might hit the trigger and get deleted by accident.

I also added a DoOnce so this happens once and never again. I also set the DestoryActor’s target as “Get Player Character” then added “cast to actor” so only the player character activates the trigger box. This is because I only want the player character to be destroyed not every actor that might accidentally trigger the box.

You can also change how box triggers (and other triggers) work. There are different collision presets which can be used for different purposes. For example “OverlapAllDynamic” will only trigger an overlap when dynamic actors hit the trigger such as projectiles or other moving actors.

Static actors wont trigger the overlap and so they’re safe to use inside the trigger space. Dynamic collision triggers are taxing on the game however as they’re constantly keeping track of all these dynamic actors.

Different collision presets might be needed for different moments in your game. The majority of issues seen in video games are collision problems so when building a game you always need to be aware of what collision you’re working on. Depending on any in game sequences, boss fights or character power ups/attacks might require different collision presets to work properly. Being aware of you’re collision and how it relates to your game will help you loads when coming across issues with your actors. It’s easy to see how complex your blueprint can get especially when needing to change collision presets or actor tags in game.

Another collision test I did was seeing if a true/false branch could identify if the correct type of actor had entered the trigger. I was having issues as my character was not already placed in the game and instead spawned at the player network. I tried referencing back to “MyNewCharacter” but it was not working so instead this new blueprint which makes use of the “Get all Actors of Class” and “ForEachLoop” has fixed my issue!

Adding Controls

By going into project settings I’m able to add action mappings such as controls for the character. I began experimenting with a Dash. I made it so the character has a short boost of speed. I also made it so a ghost is left behind of the character and vanished after a short while.

Once I’ve narrowed down exactly what kind of attacks and controls I want I’ll begin using the action mappings to place my control layout ingame. I’ll also begin looking into tutorials for creating additional movement such as double jumps, wall climbing and crouch!

#unit49

Camera Experimentation

Fixed Cameras

I set up multiple fixed cameras in the third person example level similar to how in some third person games it has different cameras you switch between automatically as you move around certain areas.

I placed three cameras and three box triggers. I then selected each camera and made references to them in the blueprint. I also made events BeginOverlap for each box.

It was very simple having the box triggers activate the different cameras. You just need to resize the box trigger for the area you want it to activate for.

Here is the first camera activating as the player begins walking up the stairs and overlaps the box trigger. An issue I found however was when you leave the box trigger the game didn’t return to the usual third person view and was instead stuck on this camera. This is because it wasn’t being told otherwise.

I threw together an EndOverlap and hoped it would switch back to the default camera view.

This however locked the camera INSIDE the player characters torso. I had a look through the player character blueprint and realized the follow camera was a set distance behind the player and I simply needed it to switch back to that camera.

A super simple fix was simply changing the EndOverlap to this:

Instead of “Get Player Controller” I used “Get Player Character” as the new view target which switches the camera view back to default third person!

I then duplicated this quickly for each camera.

This is a great for when you want fixed cameras in your third person level but also want it to switch back to the follow camera when leaving certain areas. Examples of games which used a feature similar to this was Resident Evil which had fixed wall mounted cameras in the hallways and rooms of the mansion. If resizing each individual trigger box to the size of each room is too much hassle you can instead change the “EndOverlap” to a “BeginOverlap” for a new trigger and just have that sitting at the exit of the room.

3rd/1st Person Toggle

I also implemented a basic 3rd to 1st person toggle!

I added a new camera to the viewport of my character. I placed it in the head and made a reference to it on the blueprint. I also went into the project settings > Input and added a new action mapping for when the “T” key is pressed.

Here is the blueprint for switching between the two camera perspectives.

Now when pressing the “T” key it lets you move and look around in 1st person! I also had to toggle on some features in the character variables and the camera variables so the 1st person has the full range of movement that you’d expect in a 1st person game!

An interesting thing to think about as a developer is if you want this feature to be up to the player or to happen automatically? Games like Skyrim or Fallout 4 allow the player to freely choose between 1st or 3rd. However some developers might not want to clutter the players with more controls and instead have it switch automatically in certain game sequences or when certain actions are taken.

A good example of this is in third person games which follow the player from a distance but switch to over the shoulder when the player takes aim with a weapon. This lets the player have full view of their character as they move in the game world but have a closer and more accurate aim when in combat. This can be done by linking the “ready weapon” or aim action with the “Toggle Perspective” action map. This makes the game feel more intuitive and immersive without overwhelming the player with loads of controls. They don’t have to remember to switch to the different camera every time they want to aim their weapon because the blueprint does it for them!

I also added an over the shoulder camera option if the player prefers.

Matinee Camera

Here’s the blueprint for a simple camera matinee that gives a brief overview of the level similar to Tomb Raider. This is great at giving the player direction towards the level goal.

Live Feed Camera

Here I used a SceneCapture2D camera to create a material that acts as an in game security camera!

It works in real time and could be used as a CCTV camera set up.

I had issues with antialiasing not working properly in game on the camera feed material. After some research I learnt that the “Capture Source” in the cameras detail panel needs to be set as Final Color to fix this issue.

#unit49

Animations

Using the adobe Fuse program you are able to create a character and send to mixamo to download and also find animations. It’s a great tool as it also create your face maps for animating different facial expressions. This is great for saving game developers time.

Here’s a test character I created with Fuse. An issue I came across were the textures being transparent. A quick fix was to simply go through each texture and change the settings back to Opaque.

I then followed the guide to setting up the IdleRun animations.

#unit49

In-game Cameras

Cameras can be used to direct the players by giving them a brief overview of the area. This subconsciously hints the player what direction/actions they’ll need to complete without relying on in game prompts such as text.

Tomb Raider (Core Design, 1996)

The Tomb Raider series often has the camera pan to interactable objects and puzzles when entering an area for the first time. This is so the player does not feel lost and without direction. It’s also a great system for if you take a break from playing and return. By restarting that area, you are reminded of what you need to do instead of having to rely on memory.

A system I really like is in “Final Fantasy Crystal Chronicles” (Square Enix Co. 2003). At the beginning of each zone there is a brief narration which sets the atmosphere and progresses the story. It also has the camera pan over the various locations and monsters so the player knows what to expect and can get excited for what they’re about to explore.

The use of narration and camera really solidifies the atmosphere whilst making each area feel distinct and different to each other.

I find “LittleBigPlanet 3” (Sumo Digital, 2014) use of the sidescroller camera really strong especially when dealing with multiplayer. When playing online each player can move as far away from each other as they want as they’re on their own PlayStation however when playing together the characters need to stay on the screen at the same time. The camera follows the group as a whole zooming out slightly to give enough space whilst zooming in closer when the group stand closer together.

It also chooses a player to follow when others fall behind (usually the one who is further ahead) so the level can progress and people who fall behind can die and respawn.

Here is a great example of four players (the maximum amount for multiplayer) playing on one console and the camera adjusting itself accordingly as they move further and closer together. The camera often fixes itself into a locked position like in boss fights or certain puzzles however there is always a slight give to it when players push on the edge of the screen.

Cameras can also be used to raise tension and fear in the player.

“Siren: Blood Curse” (Sony, 2008) is a Japanese survival horror game which uses a mix of third and first person cameras to scare the players.

The players play a variety of different characters some who possess the ability to “sight jack” which basically allows them to see through the eyes of the enemy. This lets players keep the normal third person perspective whilst also splitting the screen and having the enemies first person view.

This view can be used to spy on enemies and watch their movement to properly choose a time to make a move. The zombie enemies often follow paths so it’s a great feature for scouting the area and forming a plan on how to sneak past them. This feature also leaves you at the disadvantage of blocking off some of your screen which makes you feel vulnerable.

Here the player character is running in third person whilst watching a first person view perspective of the enemy chasing them. This gives you the advantage of knowing how far back they are without having to manually turn your camera around however it does often make you feel panicked.

Here the undetected player is using the “sightjack” ability and has found the switch they need to pull. This enemy has intentionally been placed here by the developers because it gives the player an obstacle to overcome but also helps guide them on what they need to do. The room is quite cluttered and so the switch alone could have easily been overlooked by the player.

When I was playing through the game I found the ability to see from the enemy perspective to be essential to surviving the game however not being able to control their camera especially during chases scenes when they’re running after you to be really disorientating. I do however think it’s a really unique and fun feature and I like how it was also a magical ability in the game world’s lore.

I found the scariest part was being forced to play as a child who although great at stealth was completely defenceless. Fighting enemies was absolutely not an option so relying on your sightjack ability was needed to determine if you’d been spotted.

#unit49

Controller Types

A brief look into different input devices!

Console controllers typically share similar button bindings depending on the genre of game.

The left analog stick usually controls character movements and the right controls camera (unless the game type binds the character movements and camera together)

Analog sticks can usually be clicked in to toggle camera types, character crouching/sneaking and other toggle like features.

The letter/shape buttons usually activate attacks or toggle abilities whilst the D-Pad controls other features for example holding down on the D-Pad whilst pressing X will do something different rather than just tapping X alone.

The Centre buttons (Start/Select Touchpad etc.) usually pause games and open up additional menus such as options/exit game.

The left bumper/trigger usually activates a basic attack such as firing a gun in an FPS or grabbing an item in a platformer.

The right bumper/trigger is used less often and activates abilities that you can’t spam such as throwing grenades or a similar limited resource.

Keyboard & Mouse control systems are naturally designed for PC games.

WASD or Directional Arrow Keys usually control movement. The mouse cursor might however control the movement like in Topdown games where you hold down or click where you want to move your character.

Moving the mouse usually controls the camera like in 1st/3rd person games. Sidescrollers and platformers don’t have this feature.

Shift/Caps Lock often control toggle features such as crouching/sneaking.

On occasion the right mouse button or shift controls is held down to aim through a scope.

The left thumb rests on the space bar when using the WASD layout so this usually controls jumping or another often used ability.

ESC pauses games and opens menus

Touch screen games are built with the mobile phone in mind so they’re usually a lot smaller and simpler compared to console or PC games. The controls reflect this with amount of controls being a lot less and user friendly.

Character movement (if there even is a character to control) can be done by sliding your finger in the direction you want, tapping an area of the screen, or tilting your phone in the direction.

If the character is always running (like in most platform games) you simply have to tap the screen and time your jumps correctly.

The rest of controls are notifications alerting the player with windows such as “Menu!” or “Dodge!”

#unit49