This section pertains to my work in the group “The Most Oldest People” in our senior school project Merry Mayhem. My role in the group was lead and sole programmer. All my work on the project is Coding/logic (Blueprints) and setting up and managing source control. The art and design that you will see in any gifs and images of the project are not my work but the work of my amazing teammates! Nevertheless, let us look at my work in a project I’m very proud to be a part of.
I’m going to start with Source control, because it is one of the first things I did in our project, and there is a lot less for me to say about it than the rest of my work on the project. We used an AWS server which has 30 gigs of space (really 13ish windows takes up the rest) and Perforce as our source control. We didn’t run into too many issues on the user side other than windows being a little crazy to two of our group and we did run out of space at one point, but that was easily remedied by going into the server and deleting old files. I’ve learned check the size of the server daily and to keep an eye on the number revisions with big files.
To start let’s look at the most used and important blueprint in Merry Mayhem, our character controller script for our protagonist Pax called “HeroCharacter”. It should be noted all the character scripts are children of a C++ script called “BaseCharacter” that does a simple health calculation. Even though the game’s scripting is done 99% in blueprints I wanted the project and the group to be open to having C++ scripting available in case we were limited by blueprints. Lucky that was not the case. Other than a simple C++ sound script that allows a sound node resume instead of restart the rest of the project was possible with blueprints. Anyway here’s “HeroCharacter” blueprint zoomed out
As you can see it’s a big blueprint so instead of zooming into every section I figured I would focus on the important parts and use gifs to show the functionality. I want to note that I spent the most hours in this blueprint, this is because it’s the most interacted with script, and almost all the other blueprints interact with the player in some way. The “HeroCharacter” blueprint currently has 108 revisions and while some of those revisions were simple fixes, the evolution of this script has been a big part in making this project functional and stable.
Pax, our main character has 8 main functions: movement, rotation, shooting her gun, slashing her sword, dashing, gravity trap, sword tornado, and flame on. These functions are of course all managed in the “HeroCharacter” blueprint.
The way the movement works is pretty simple, the left stick on a controller controls the movement and the right stick controls the rotation. What was interesting to get working was the camera. I followed a tutorial on how to use a simple TInterp(Transform interp) which smooths the camera’s movement as it goes from one location to another when the player is moving, but later on I also added due to feedback a self-made function that smoothly pushes the camera forwards in the direction of the players movement so the player can see a better area in front of them.
Here’s a small example in action
Below are the gifs for the rest of Pax’s abilities
Gravity trap – is dropped right under the player and can be triggered at any time. Once triggered it sucks all non-large enemies into the center.
Sword tornado – when activated Pax becomes invincible and spins, any enemy within her swords range takes a major amount of damage.
Flame On – drops on Pax when quick casted or on a selected area if the button if held down. Deals damage to normal enemies or melts their shields opening them up to be attacked.
While the “Hero Character” blueprint handles a lot of other stuff like death, placing the menus on screen and functions to stop Pax during scenes those aspects aren’t as interesting so I’ll move on. I will say I’m very happy that I got to work on another character controller script in a third person environment, because I really got to improve the skills I learned from creating the character controller for my earlier group project Kaguya.
I really enjoyed working on the enemies, I’m a big fan of A.I. and get excited working with programs I can put behaviors on. Speaking of Behaviors this was the first time I was scripting A.I. in unreal and using behavior trees
I will say the whole task was a bit scary at first, to get A.I. to work you have to connect four different blueprints EnemyCharacter>AIcontroller>BlackBoard>Behavior tree. Once I got through the tutorial I used and a week of fiddling around I got a hang of it. I used two AIcontroller’s and Behavior trees for Merry Mayhem one for melee and one for ranged, the only real difference is the range in which they attack though. Here’s an example of the A.I. system I used. Three enemies are running back to their location they need to guard, but once Pax gets in range they turn an attack.
The project had three different sizes of enemies and each size had at least three unique differences, so I had quite a few blueprints to deal with. If I was to do it again I would try to fit them into less blueprints. I think I could combine each size into one blueprint with booleans controlling it, so the designers would choose the enemy type they wanted from a details panel. Getting the enemies where I wanted them took time, but I’m very happy with the result and hope to build on my knowledge of A.I. Systems in the future
One of the Enemy blueprints
When I wasn’t fighting with Perforce, acting as Unreal tech support(I would kill to have a Unreal tech on campus 24/7) or getting Pax and the Enemies working correctly I was building the backbone of our project, the Game Mode and the Game Instance blueprints. The Game Instance blueprint is pretty simple it just holds all of my global variables. The Game Mode blueprint is what controls the interaction between these variables and the rest of the game(that includes holding the skill point variable which the player and skill tree UI use, shown above) as well as sends the current variables to the Save Game blueprint at the end of a level. The blueprints themselves are simple but getting the interacting variables to work correctly can take some brain power. I’ve spent quite a few hours trying to tie down every variable that needs to be saved or global working as intended.
The Glue and dressing
Past all the big and important blueprints are the hundreds of little blueprints that can take up to a night of hair pulling or less then a minute to create. These blueprints are what make the project come to life, from UI and triggers to pick ups, I spent a lot of time on these blueprints. Some of these simple blueprints just act as hungers for whatever the artiest want to place within the project or others act as environmental interactions the designers can easily place, whatever the reason there’s a good deal of scripting to be done outside of the major blueprints. I’ll leave this section with an image of the skill three blueprint
Last major thing I’ve done in this project is interact with the rest of the group. Yes this may sound ridiculous but interacting with your fellow team members is a huge part of a group project. In truth, a major reason why I’m placing this here is to thank my teammates, it’s been a great semester thanks to them and I hope to work with them in the future. Our game has fantastic art, wondrous maps, great sound, and a lot of personality. I encourage you if you’re looking at my stuff you should also be looking at theirs. Here’s the link to our sound and creative director’s portfolio for this project which has the links to the rest of the team.