BA2B - Game Project - Week 3

BA2B Collaborative Game Project

Week 3

This week my task was to continue working on the environment and also implement a lot of the vegetation. The next thing I needed to put together in the level from Billy's concept art was a large elven bridge. The story about this bridge was that a long time ago, elves had lived in the area and they constructed a beautiful large bridge. The goblins however, ruined the bridge to later realise that they actually needed it to walk across; so they built a small hanging bridge. The bridge has a very interesting shape and because it was a massive structure, it would be on of the main focal points of the game for the player. I really like the sense of scale, as it will be a 'big reveal' for the player when they first see it.

Normally a large bridge like this would not be built by individual rocks, but since we only have 6 weeks. this was the solution for now. By the time I had come this far with the bridge, Nat and Charlotte had been able to create a couple of different plant and ground textures. So up next was for me to create the tilted plants in Maya. The process for this was very easy since plants are just a few polygons each. It was important for me to not go too overboard with the polygons when it comes to this since there will be a lot of them in the scene.

Here is an example of how the fern looks in Maya.

Fernplant in Maya, Texture made by Natalia Rojek and Model created by me.

Wireframe

After doing this with all the plant textures I got provided, it was time to get them in game. Here is an image showing them within the level.

This week I also played around with the lighting settings in Unreal Engine 4 and tried to add some more ambiance to the level. It was quite difficult because the time of day really effects the scene and all of its textures. In our meeting this week we talked about it and eventually decided to set the level at around noon and sunny, as this would show off the textures well and would be bright enough for the player to see. If we had a sunset, all textures would end up very orange and it takes away from the texturing of the assets. Also since the map has a rather dense forest this would result in the players path to be mostly covered in shadow which is a bit dull. Billy had the idea of adding a blue tint to the level which could act as a way to indicate that it was night, but again we thought that it would be best to have a game we could potentially show in our portfolios with the assets clearly visible.

Week 3 Summary

Week 3 was a bit of a slower week but the bridge scene took a very long time to create and place every rock manually. Now that I've gotten the hang of it, it should become a lot quicker in the future. We did get some critique from the tutors that the vegetation is currently too dense which we all agree with, and that the ground should be shown more.

It is great seeing the game come together though and everyone in the team is very excited to work on it. Since most of us will be going home over holidays we don't expect much progress to be done next week. We have said that if someone want's to they can do work on the game, but we don't expect anyone to have been doing work over the Easter break. 

BA2B - Game Project - Week 2

BA2B Collaborative Game Project

Week 2

This week started off by having a team meeting so we all could nail down what tasks everyone should focus on the following week. My tasks for this week will be to further work on the blueprints and look into the animation system. I will also start working on the environment for the game so we can get an idea of how our art style will look in Unreal Engine 4. 

Animations

As I mentioned in the last blog post, I discovered an issue with the current animation system we were using. Since the original First Person character animations are driven by "Animation Blendspaces", an issue occurred when I was playing animations directly from the blueprint. Since we are using a mix between the original blend space animations and the blueprint ones, the blendspace stopped working as soon as an animation was triggered from the blueprints. To solve this I looked up how Blendspace animations actually work. Thankfully Epic Games have made an excellent tutorial series about how Animations work in Unreal Engine, so by watching this tutorial I got a greater understanding of blendspaces and was able to replace all the animations to work using the blendspace system.

Tutorial by Epic Games

Video Link: https://www.youtube.com/watch?v=pfKdr0FRC5g

And here is a video showing off how it works in our game.

Video Link: https://www.youtube.com/watch?v=qNo6QuU8m44

To explain a little bit what is going on in the video, blendspaces work in a way where I can have two different animations that blend together. I can activate the animations by using different methods. As you can see in the video, with raising the shield I just used an "On/Off" button which I gave the name "Shield Rise". In the character blueprint I have assigned it so that when the player presses Space, it tells the blendspace to check this box which makes the character raise their shield. For the run animation I attached a number which basically means that the quicker the player runs, the more the hands bob up and down. I also added that when the shield gets hit, the "Shield Hit" variable will be turned on and off which will create a greater impact when the shield get's penetrated by a bolt or firespell.

After implementing this, the animations work a lot more fluently and now there are no bugs what so ever with them. Blendspaces was a great thing to learn and now I will definitely use it for future animations.

World Building

With the Animations sorted and most of the blueprints done, it was time to create some of the world itself. Billy had been drawing really good Environment Concept's which were very useful when doing this and I also asked him to create me a top down view of how he imagined the level. 

Environment Concepts Created by Billy Machin

 Top down view of the level, created by Billy Machin

(Click to enlarge)

The only model I had to work with at the time were 5 different rock models, created by Jack, I then tried to replicate the starting zone from Billy's concept with only the rocks, which was a bit tricky but it definitely helped to get started with the environment. Jack modelled the rocks so I could rotate them and scale them however I wanted, so that the player won't notice that it's just the same 5 rocks everywhere and this proved to be super useful.

I used post processing effects such as "Ambient Occlusion" to make the rocks look more visually appealing even though they did not have any textures yet, except Normals. We definitely started to get the "Firewatch" vibes from the rocks, which was one of the games we took inspiration from when it comes to the art style.

Speed Tree

Now with some of the rocks in place, I decided to start looking into vegetation. UE4 has Speed Tree support, which is a software that allows you to auto generate trees of different kinds. I figured this would save us a lot of time instead of modelling them ourselves. The idea was that we could create a tree which we were satisfied with and then just swap out the textures to a hand painted one created by one of our artists. We decided to quickly test this, so Nat created a quick birch texture which I then applied to a tree and it worked perfectly!

Screenshots of Speedtree with Nat's birch texture applied

Now that we knew it was working, Nat then created textures for the tree that we were actually going to be using in the game which was a pine tree. The needles on this right now are just a quick placeholder texture created by me for experimenting in UE4. I later replaced it with Nat's new and much better needle texture.

Pine tree with Nat's handpainted texture applied (Placeholder needles).

(Click to enlarge)

Since Unreal Engine 4 and Speed Tree support each other, importing it to UE4 was a very easy process. All I had to do was to export it from Speedtree and then import it in UE4 where all the different LOD's (Levels of detail) were automatically applied. Here are a few images of the trees in game.

I did have some lighting issues that I was struggling with in the beginning, because how Unreal Engines shadows work is that you bake them into a separate texture map. This means that the UVW's  cannot overlap, because if they do then the shadows will overlap. This results in shadows that fit in one place will show up on a different location on the model, which will end up looking odd. The issue with these tree models was that Speed Tree didn't take this into consideration and had some overlapping, as well as some bits of the UVW's being tiny. This also meant that some parts of the trees ended up with black spots. I solved these issues by looking up a tutorial for how to properly set-up vegetation in Unreal Engine. 

Vegetation Material Tutorial

With the shadow issues taken care off it was now time to replace the needle textures, as well as the grass textures with the new ones Nat had created. This really changed the scene and now we could start seeing our art style emerge in the engine.

I also got the wind to affect the trees so we got slight wind swaying, it's not much but it definitely made a change to the scene and feeling more alive. To demonstrate this I created a short video.

Week 2 Summary

We made some great progress on the game this week and it is definitely nice for everyone on the team to start seeing the game come to life in the Engine. It's pretty difficult to get an art style nailed down until you can see it in the engine, since the shaders and such in the engine will affect your art style as well. What we wanted was a mix between Firewatch, League of Legends and World of Warcraft and we are definitely already getting those vibes. Next week I will continue to work on the environment and also more vegetation in the game such as standing grass and flowers.

BA2B - Game Project - Week 1

BA2B Collaborative Game Production

Week 1

For this brief we have 6 weeks to create a fully playable game using Unreal Engine 4. Since this is another collaboration project, we were asked to divide ourselves into our own groups. The group I am in is very similar to the one I had during the week long Game Jam, which is because we worked very well during this and wanted to see what we could achieve in 6 weeks instead of 4 days.

My Group:

Billy Machin (Concept & Texture Artist)

Charlotte Lawrence (Concept & Texture Artist)

Myself, Johan Lagesson (3D Artist, Programmer (Blueprints), Level Designer & Animator)

Jack Edwards (Team Leader & 3D Artist)

Natalia Rojek (Concept & Texture Artist)

The only restrictions that we have when creating our game is to follow the theme of it being "One-Button". I will mostly be working within Unreal Engine 4 and do the Blueprinting & Environment Design, this is because I have the most experience when it comes to Games Engines and also enjoy it! However, I will also help out with some of the 3D assets, but most will be created by Jack. I will also be working on some of the animations for the game, since I have experience with Animating in Unreal from my earlier game projects.

We were also provided with a timetable which shows how we should progress in the following weeks.

Idea Generation

We had a meetup where we tried to figure out what we wanted our game to be. Jack had two really great ideas that we started to develop. The first idea took place in a haunted mansion where the player wields a lantern. Since the theme is "One-Button", the game would be an "On rails" experience where the player cannot move the character and a path is set for them. The player would also use a lantern to scare away ghosts which come closer to the player if the lantern was not on. When the player pressed the button to turn on the lantern it would drain a resource such as Oil, so preserving the oil and use it carefully would be the main game loop.

For the second idea it would be another "On rails" experience which was literally on rails. You would sit in an Minecart and avoid different objects that approach you. This is inspired by the famous Indiana Jones scene where they escape a mine using a minecart.

After much discussion we decided to go with the Horror idea, although we did plenty of changes to the main concept. Since the game would be an on rails experience, we needed a reason for why the character was constantly moving, as well as a way to introduce what was happening in the game. So Jack had an idea that the player could be an Actor on a movie set, and to introduce you to the level a Director would tell you what you were going to do. We thought this was a good idea and since the game would take place in a movie environment it allowed us to experiment with different themes and not only just Horror. 

We then thought of different themes we could design our level around, with our team favourites being Fantasy, Egyptian and Pirates. Not only this, but we also had a discussion about making 3 levels with different horror tropes, but since our game would be in a hand painted art style we figured if the point of the game was not to scare the player then 3 horror themed levels weren't the best idea. We also decided that since we only have 6 weeks to create this game, we should stick to one theme. After thinking of different game play mechanics for the different environments, for example using a flashlight or pressing a button to jump over obstacles we decided to choose the most solid one. Eventually, we concluded that the level would be fantasy themed and the player would be equipped with a shield using the space button to block incoming projectiles (which relates to the one-button aspect of our game).

Short description of our game:

- On rails experience.

- The player is an actor who performs a shoot, thus the on rails experience makes sense since you would be directed by someone else and performing to a script.

- The genre we choose for our first level is Fantasy.

- The "One-Button Game" limitation will be the player action, in this case using a shield to block incoming projectiles such as arrows by pressing the space button.

- We will add more levels with different genres if we have the time.

Here is an image created by Jack that describes the Game Concept well.

Created by Jack

Art Style

Since I would focus more on the technical side during this project, I was not very involved in the decision of the Art Style. Because there are 3 concept artists in the team we wanted to go with a more hand-painted approach, which would also help them with their own painting development. If we went with a realistic art-style then Jack would have to create most of the textures using PBR but because we have 3 concept artists, they can create the textures while Jack can work on multiple models without having to worry about it. As a team, we also all enjoy hand-painted art styles and it fits very well within a fantasy setting. 

Charlotte created this great image showing the different art styles we will try to pursue.

Created by Charlotte

Since we now had a great idea of what our game would be, we gave everyone different tasks.

Charlotte, Nat and Billy were tasked with just brainstorming and start concepting different ideas. These concepts could be mood paintings, asset concepts etc. 

Jack was tasked with doing research on particle effects and thinking about the assets we would need in the game.

I was tasked with blueprinting the mechanics of the game as well as finishing a small prototype level, so we could try out different iterations of our game mechanics to see what feels the best. 

Work I've done this week.

For our game I decided to go with the first person template in UE4 since I have most experience with it and it suits our game perfectly. To start off with I began to look up how you can create an "On-rail" experience in Unreal. I found out that there were several different approaches you could take, but I decided to follow this tutorial since it showed everything step by step as well as it being just pure blueprint, which meant I could tailor it to our needs and add to it. 

Tutorial Link: http://www.unrealenginetutorials.com/character-follow-a-spline-component-unreal-engine-4/

On-Rails Blueprint

The way this blueprint works is that you are using UE4's own "Spline Tool" to create a path through the level. You then create a blueprint where it searches for this path and makes the player character follow it. A great thing with this is that it only controls where the player moves and not the rotation the player is looking, which makes this a good Blueprint for "On-Rail" experiences. 

UE4 Spline Tool

To decide the speed of the player character, all I had to do was create a "Float" variable which I set to public, instead of making it a set number. Because we set it to public we can now modify this number whenever we want and therefore change the player speed easily. This will be very useful to create a varied flow in the gameplay and be able to slow the player down in tight areas, however in larger areas make the character run so the player doesn't get bored.

Movement Speed value marked in Red.

Things we can do to add to the movement is adding features such as Head-bobbing and footstep sounds but this will be done in a later stage.

Up next was to create the first iteration of the shield block mechanic. There were different ways I could approach this, for example I could add the shield to the hand mesh and just create new animations with the shield, or I could create the shield as a separate part of the body like most games do. The benefit of the latter is that if we want the player to be able to swap to other shields or maybe  a new weapon etc, it would be possible. If we go with the first option, this would limit us to only use one shield and not be able to change. After discussing this issue with the group we decided to go with the second approach. I found a tutorial showing how to implement a weapon by attaching it to bone sockets, by following this tutorial and doing slight changes such as not making it an actual weapon; it turned out really well. It also taught me about bone sockets which might be useful in the future.

Tutorial Link: http://creategamesfromscratch.blogspot.co.uk/2014/05/prototype-adding-hands-and-weapon.html

As for the shield model, I just created a quick place holder shield for the prototype!

Image showing the new "Shield" socket.

The way this works is that by adding a new socket to the bone called "Shield", I will be able to add any model I want to that location of the arm. When I add animations to the arms, the "Shield" socket will follow the animation and thus the Shield will follow the arm. I tested this by using my knowledge with animation in UE4 from BA2a's game prototype and applied new animations to the  arm model.

Arms with the new Shield and the block animation.

Block Type Iteration 1

The way I will create the shields block feature is by making it similar to the player using a "Spell" in MMO's, such as World of Warcraft. When you tap the "Spacebar",  the character will then raise their  shield for a few seconds and then lower it. This way of blocking will be more about timing than anything else.

First iteration of the Block type.

How this Blueprint works is very simple as when the player presses Spacebar, an animation will play that will rise the shield and after a few seconds it will lower it. To know if the shield is up or not when the player gets hit by an arrow, we included a Boolean called "Shield Up" that get's activated as soon as the shield rises and de-activates when it's lowered.

Here is a video showing the path system and the first iteration of blocking type.

Video Link: https://www.youtube.com/watch?v=HQmxJKzA5a8

Creating the Goblins

Now with the first Shield iteration done it was time to make the enemies, which in this case will be Goblins. I tried to find the best way of creating them and came to the conclusion of making them into "Turrets" would be the best for our game. This means that they are now actual AI but just driven by blueprints to shoot at a specific spot when the player enters a trigger box. There was no tutorials for this but it wasn't a problem since I could come up with this Blueprint by myself. 

Goblin Blueprint

To start off with, the Goblin will check if the player is in a trigger box or not, if he's not then the rotation will just follow the player as he walks. 

If the player has entered the trigger box, then the Goblin will first look at a target point which is where the goblin will end up shooting. After that, the goblin will spawn a projectile (which is the bolt in this case), play the sound effect of a crossbow shot and then return to look at the player again. This blueprint is a modified version of the base character blueprint, I used this since it already had the projectile blueprint in there and I just had to modify it.

The reason why I had to use "Target Points" to specify where the goblin will shoot the bolt instead of just taking the character position, was because the player character is in constant movement. I did try this at first but it just resulted in the goblins missing the character because by the time it took the bolt to travel to the player position, he had already moved. It did work in some angles but I felt that we needed a better system that allowed us to guarantee that the goblins hit's the player every time, and thus I decided to use target points. 

Here is a video showing the goblins in action.

Video Link: https://www.youtube.com/watch?v=FvQhqVQf-7U

Block Type Iteration 2

Iteration 2 of the block mechanic would be using a "Stamina" system. The player will now have to hold the Spacebar to have his shield raised, but when it's up it will drain from a stamina bar. If the stamina bar reaches 0 then the shield will lower again. This version of blocking will be more about resource management instead of "Timing". This mechanic was very much inspired by games such as From Software's "Dark Souls" series which uses a Stamina system for their blocking. However, the stamina only drains if the player get's hit, but here it will drain just by holding it up so we are doing some slight modifications to the system. 

Dark Souls

To get this to work I started off by creating a health and stamina system using previous knowledge from BA2a's game prototype. When that was done it was a matter of creating a new blueprint for the new block feature. 

Block Type 2 Blueprint (Click to Enlarge)

How this blueprint works is that it first checks if the player has enough Stamina to raise the shield. If he does then it first allows the stamina bar to stop refilling and start draining instead. After that I made sure  that the Shield was set to "Up", so I know if the player should receive damage from the goblins or not, and then plays an animation to raise the shield and hold it. When the player then releases the Spacebar, the shield is lowered and starts regaining Stamina again. To make sure that the player can not hold the shield up forever we use the "Event Tick" to check on the stamina, and as soon as it goes below 2 (Not 0 because then when the player regains stamina it glitched out) and if the player has lower than 2 it fires off the lower shield blueprint. 

Here is another video to show it in action: 

Video Link: https://www.youtube.com/watch?v=QaFF9AYmU-w

As you can see in the video, I have also added another type of Goblin which are Fire mages, these were done by just modifying the original Goblin blueprint and replacing the bolt with a particle effect instead and changing the sounds. I have also added so that bolt's will now penetrate the shield. This was done by just adding a socket for the each bolt and making them invisible, to later become visible one by one using a sequence node if the character manages to block a bolt. 

Game Testing

We had a team gathering to try out the two different block mechanics, to make this as easy as possible I made it so just by a button press we can switch between the two different block types. We all agreed that the second iteration felt a lot better than the first one and the resource management was more fun than just having to time the button press right. So we all agreed rather quickly that the second one was the one I should continue to work on.

Week 1 Summary

This concludes the first week, overall I think we managed to do a lot this week and most of the game mechanics are now blueprinted. Now it's mostly just a matter of adding to them and polishing. I have plans to take another approach to the animation system since the way I do it now it doesn't play well with the blendspace animations. If I force an animation in blueprint,  the blendspace animations "Which are used for the walking animation etc." will stop working. It was an issue I had with my previous game prototype from BA2a as well but never got around to fix the issue. Now since we have 5 weeks left I should be able to look into it and hopefully be able to solve it.