To begin with the health bar I first made a widget blueprint called; EnemyhealthUI.
I then added a progress bar into the designer part of the blueprint, allowing me to create a health bar that can dynamically fill and empty by changing it’s values.
I then placed the Health Bar above the Enemy model.
After successfully implementing the bar I then moved on to programming the health bar to react to the finishing move by editing the EnemyHealthUI widget blueprint.
This unfortunately doesn’t work and I haven’t found a solution to this issue. Because of this, I can’t program the morale bar either since it would follow the same programming.
Hiding the trigger box
It turns out that double clicking on the specific parts of the trigger box such as the outlines representing the trigger box location is editable after all. I was able to remove the visibility of the outlines leaving the Billboard intact.
The following entries are focused on my final week documenting my development of the Troy Finisher move project.
Interacting with in-game models
During gameplay the player models for the cutscene are visible and while the goal is to remove the blue player model I at the very least wanted them to be non interactive, I did this by keeping the models in a keep state mode.
the Skull Icon
The skull icon finally now appears when the player is outside the trigger box, unfortunately the skull icon (known as a billboard) and trigger box are linked so attempting to hide the box while keeping the billboard doesn’t work.
This week was focused on attempting the implementation of the cutscene again but with a different technique, thankfully this week was much more successful compared to last week as seen in this entry, I was able to make some other changes to the visuals to the discipline which I will briefly cover.
the Skull Icon
To begin I was able to finally add the skull icon to the trigger box. This was done by going to the rendering tab on the skull icon (on the tirggerbox this is referred to as “billboard”) and ticking the visible option.
Because of this development the message “Press “E” to preform finisher!” has been removed. The icon still doesn’t show up during gameplay, but it does in the editor so that’s something to fix soon.
Character Mesh Colours
The next improvement was to the character models. To represent which character is the player and which is the enemy I have edited the default mannequin in Unreal 4 and made a blue and red variant matching the brief. This was to simply help distinguish between the two models.
Editing the character models was done by entering the character meshes’ blueprint and changing the body colour values.
Implementing the Cutscene Into Gameplay
I was also able to implement the cutscene into the game successfully, returning to in game cutscenes rather than a pre-rendered one using the animation made in the level sequence.
As intended the player must walk up to the enemy press the “e” key and the cutscene will play.
The current issues are the following; the player is still visible and playable in the cutscene and the blue character is present in the environment during gameplay rather than appearing for the cutscene and being removed, which would simulate that the player character was in the cutscene. Both will be fixed.
I also wanted to mention that the programming for this was to go to the level blueprint, link the “press e” box to a create a level sequence player box and then to a play box which is an obviously simpler method compared to last week’s and genuinely works.
Next week will focus on attempting various improvements that were mentioned in this post such as the skull icon and hiding character models during gameplay.
This week was focused on implementing the cutscene into gameplay using Unreal Engine’s widgets.
I first had to import the finishing move animation into the current project, from there I created a media player file which converts the animation into a readable video file (media texture). Finally, I created a material from the media texture so the widget could read it.
I then created a widget called cutscene.
From what I have experimented, widgets allow for images and videos to be put over the game screen. In the examples I’ve seen it’s been utilised for menus and pre rendered cutscenes.
I added an image to the widget and put the cutscene material on to play the cutscene.
On the widget’s graph mode, I was attempted to get the video to work when pressing the “E” key, however this only resulted in the widget rendering a black screen.
This may be from attempting to use a tool that is not exactly intended for this use, when I next attempt this I will try a different way to implement the cutscene as this was clearly too convoluted.
Next week will hopefully have the issue resolved so I can move on to other aspects of the discipline.
This week was focused on me attempting to create the trigger for the finishing move. I detailed in the proposal that the player must walk up to an enemy and press a button to trigger the finishing move.
Introducing Box Triggers
This led me to working with box triggers. Box triggers allow the player to walk up to a specific area and do something in that area, in this example I programmed the box trigger to output the message [PLAY FINISHER MOVE ANIMATION]. This of course will be replaced with the animation.
I attempted to implement the skull icon into the trigger box as a billboard that appears once you enter the box but it didn’t work with the current blueprint and I have instead opted for text to appear. If I can’t get it to work this unfortunately may be left out.
To get the box trigger to work I edited the trigger box’s blueprint, this blueprint focuses particularly on the player entering the box and having text appear on the screen.
I then compiled the blueprint and moved onto the level blueprint where I mapped the E key to printing the message.
When playing this out the trigger box preformed to mixed results. Pressing E does output the message but regardless of whether the player enters the trigger box the text “Press E to preform finisher!” doesn’t appear. This will have to be fixed as it is a vital part of the mechanic’s design.
Theoretically the text should appear like this:
I also deleted the cutscene of the finishing move and will reanimate and export it in a different Unreal level where I can have more control over the models and physics, so it won’t interrupt the game itself.
This week was on further refinements, I worked specifically on the cutscene editor this week attempting to create the finisher move animation using the sequence editor and exporting the animation to an AVI file.
Developing the Animation
The sequence editor was used a lot more this week as I created the key frames for the animation. It’s rough and won’t be refined until the mechanic is fully developed and tested since that is the focus of the discipline.
When animating the cutscene I had on the editor both characters and animate their movements by moving the character from the start point and add a key frame, I would then move the character to the end point and key frame which would tween the character and make the movement. Depending on where you put both key frames changes the speed of the movement, I’ve attempted to make it move in real time but may experiment with slow motion for added effect.
I also changed the animation pose to make the transition between the attack pose and normal pose smoother however this may have caused some issues.
As you can see the exported video shows what the cutscene so far looks like. This is even for a designer is poor and I will attempt to fix this next week, this may be to the collisions of the models or as previously mentioned an issue with changing animation poses.
Next week will have me attempting to fix this and to implement the cutscene into the game.
This week features more blocking out of the mechanics in Unreal Engine 4, specifically I focused on two areas; the camera and rigging.
Cameras and Sequence editor
I made a separate camera for when the player will trigger the finishing move as the mechanic will cut to this camera so the positioning of it is very important. This involved positioning the camera inside the environment to replicate the shot I wanted the mechanic to have.
I also started using the sequence editor to start animating and positioning the camera. I may experiment with using multiple cameras for the cutscene using the sequence editor to cut camera to camera.
I have also changed my workstation to see both how the set camera will look and also see the surrounding scene so I can efficiently set up the cutscene.
I then moved on to rigging the finishing move animation which I have blocked out as a pose. This involved moving the separate bones to match the pose I wanted.
I then saved it as an animation file and applied it to a character model. After I finished the pose, I then started to set up the scene with the camera’s perspective being on the right.
Theoretically I could program this animation to trigger when the player is prompted to via the skull icon. Currently when launching the game, the game cuts to the fixed camera which I need to fix.
This week was focused on starting to block out the mechanic. I used Unreal Engine’s pre-built “Top Down Template” which has its own programmed camera and movement controls. These two screenshots below show my experiments of the template with the right screenshot showing more unique terrain to simulate how the level design in in Total War: Troy would work on this template.
For the most part it seems the template works fine for what I need it to be with the only issue being the path finding for movement. The player controls the character with the mouse as you point and click your destination with the left mouse button. Unfortunately, this is more complicated on unique terrain with noticeable limits and unique path finding where the character obnoxiously walks around the environment to get to the clicked point.
Below you can see an example of Unreal Engine 4’s built in terrain editor which I used to make this map. This will work for a simple environment to show off the mechanic.
Navigation mesh bounds
In the outliner here we can see the “NavigationMeshBoundsVolume”. This controls the space the character can explore as seen with this screenshot below. I had to alter this to fit the environment as without changing it the character suddenly stops moving when it reaches the edge of the box.
This is the camera that is positioned above the character. This camera is the player’s point of view and when implemented into the more natural terrain it doesn’t display enough information to the player to know where they’re going, so I pulled back the camera so the player could see more of the character.
This will work better anyway since the finisher move camera will be a closeup of the character, so the contrast of the visuals will be stronger.
I noticed during gameplay that many of the battlefields in Troy are made of sand and rock, so I changed the texture of the map to a rock sandstone for a more accurate look.
I also started developing the look of the finisher move icon and based its colours off a pot made during the troy era found in the British museum.
Image source for Troy pot – (https://www.theartnewspaper.com/news/tory-british-museum-martin-bailey-exhibition)
This Blog focuses on the development of my first module in industry briefs where I am tasked with creating 1 artefact in the form of DLC for the game A Total War Saga: Troy (which I will refer to as Total War: Troy for the sake of brevity), the artefact in question must be under my discipline which is game design.
The following entry details the past 3 weeks of work under this module.
Over the past 3 weeks I have been researching Total War: Troy and the surrounding game mechanics of the Total War series in general to get a better understanding of the series and what does and doesn’t fit. I specifically looked into the mechanics of the game such as battles and bartering to see where I could implement my artefact.
I found the combat to be an interesting gameplay element to focus on since it’s been the most recurring element of the Total War series with my artefact possibly giving a unique spin on the system. During this time, I was able to create a proposal for my artefact and even provide a few rough sketches:
The proposal itself details my artefact for the unit. I decided to develop a gameplay mechanic titled; the finishing move. This mechanic allows players to quickly kill an enemy unit in a quick cutscene provided that they are low in morale and health. This is to speed up the process of battles and reward good play. It also has an AoE (Area of Effect) attack where surrounding enemy units lower in morale whereas ally units gain more morale.
I also decided to develop this artefact in Unreal Engine 4 due to it’s ease and cutscene tools.