Sunday, 6 March 2016

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. 


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.


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.


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.


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: 


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.

No comments:

Post a Comment