23 de abril de 2019
Explore En Garde! a 17th century, action-packed UE4 student game
En Garde! is a swashbuckling action game prototype made with UE4. In a fantasized vision of the 17th century, the player embodies Adalia de Volador, an impetuous swordswoman who must fight with panache to defend her family’s honor.
Visit https://engarde-game.com/ to download the game and read on to learn more about it!
How the project started
En Garde! was a game concept submitted for our graduation project that went to the final selection.Prior to developing gameplay, our very first intention was to create “a swashbuckling video game.” We wanted to draw inspiration from the tropes of various works from literature and cinema, and to reinterpret those tropes in a game. The inspiration came from works like Zorro, The Three Musketeers, the Errol Flynn movies from Hollywood’s golden age, and even more contemporary works like Pirates of the Caribbean. We didn’t know much about the genre before starting this project, however, we quickly learned that the spirit of swashbuckling deeply resonates with many people’s collective imaginations. This genre has a long heritage, especially in France.
There are a variety of pirate games, but we realized there are no proper swashbuckling action games — at least not in a classic “musketeer” kind of universe. For some reason, this genre has been underserved in video games, so we felt this endeavour had much potential.
Design
En Garde! is designed around the notion of player fantasy. We want players to embody a heroic, resourceful swordmaster - to make them feel like a real swashbuckler. In order to stay true to that spirit throughout the development process, we needed some guidelines. We had to put our vision into words. We built the game around three main pillars: sword mastery, improvisation, and panache.The “sword mastery” pillar speaks for itself. It’s the idea that our game should heavily rely on swordplay. Though with the mood and vision of our game, we knew we had to do more than just create classic sword fights. We ignored the complexity of real-life fencing and prefered something more straightforward and choreographed, with a lot of stylish moves, dodges, and acrobatics.
This notion of sword mastery is also about the opponents you will encounter. In our game, there are numerous basic guards, but they are clumsy and meant to be humiliated by the heroine's superior skills. The Captains, on the other hand, are unique opponents who each make a different approach of combat. The proud one will challenge you to single duel, the traitor will call reinforcements, while the coward will make you run after him in a sort of hide-and-seek chase.
Our second pillar, improvisation, covers the heroin’s resourcefulness, the discovery of the environment, and the need to constantly adapt to new combat situations. It’s also about the experiments you can make with all the environmental interactions you can do in the game. This extends to the idea of unpredictability — as we are fond of systemic games, we wanted to create sets of systemic elements that can combine to create surprising outcomes and emergent situations. It felt like the best way to transcribe the unbounded creativity of some movies’ fight scenes into an interactive form.
The third pillar, panache, is about fighting with pride, style, and manners in an effortless entertaining way. It is about making fights feel like spectacles. The idea of panache was mostly transcribed through the mood of the game, but we also wanted Adalia’s wittiness to shine through gameplay with punchlines and taunts, so we implemented the “Repartee” mechanic.
Each idea we had for the game held this vision in mind. We gave priority to the ideas that would strengthen our fantasy, or expand it in new ways.
You can read more about the design and creative direction of En Garde! in our Gamasutra interview.
Art and style direction
The art direction had to convey a spirit of adventure and a sense of spectacle, with the light-hearted tone of classic swashbuckler stories.The Spanish golden age seemed like a great setting for a story full of expansive characters, conspiracies and sword fights. It was a time of wealth and ostentatious luxury, but also of inequalities and corruption — perfect for a noblewoman to fight villains in the name of honor and justice. The environment design is inspired from the Mudejar style, a unique blend of European Renaissance and Moorish influence, which can be found in Andalusia.
Though, our game is about swashbuckling adventure, not history. So while historical reference makes for a solid base, our world is seen throughout the romantic lens of literature, theater, and cinema. To reflect that, we chose dramatic lighting and dream-like colors. We were inspired by the golden age of illustration and artists like N.C. Wyeth, as well as more contemporary creators like Dreamwork’s Richard Daskas.
Traditional Mudejar architecture and decoration is very rich so we decided to streamline it. The environment and props are subtly stylized in order to have clear recognizable shapes. The textures are likewise discreet, just visible enough to ground our world and suggest the different materials. The environment should sell the setting while staying readable in the middle of a chaotic battle.
This process of simplification and slight caricature was also applied to our characters. We would simplify the basic shapes to the bare minimum, then build them back up from there. Faces went through an opposite process of extremely cartoonish caricature to find a personality, later brought back to the degree of semi-realism we went for.
Adalia, in particular, had to personify the swashbuckler archetype, but we really wanted to make her more than that. Giving her a strong and consistent personality was a crucial point to help us define her costume design, her animations, and her catch phrases. We also wanted to show that she had a past life of adventure, so we made sure to give her practical clothing that are inspired by both masculine and feminine historical fashion.
Tech Art
There were only three artists on our team with no one fully dedicated to environment art, so we had to find workflows that would allow us to save time and to iterate quickly. As a student game, our project was always changing because we had a lot of feedback from teachers, playtesters, and other students.Material Layering
For the environment materials, we decided to use a material layering system. We were heavily inspired by what was made in Paragon. We created a library of material functions, each one with some generic material (stone, marble, wood) with some very basic options (like tiling or tint). They were blended in a master material with a low resolution mask texture (usually 128*128 or 64*64).
We also used a scratch, grime and AO mask in one texture, to add some weathering effects on some props (once again, very similar to what was made in Paragon). Vertex paint was used for effects specific per assets (like dust, small displacement) to break repetitivity. We used decals for more specific effects (like leaks or cracks).
This workflow also improved our iteration time: with this system we could change one material throughout the entire game in just one click. As the project went on, it was constantly evolving and sometimes we had to remake some early assets.
For the characters, we decided to use custom shaders to have more control because they needed much more specific functions related to gameplay (like highlight, hair, and cloth shader).
The Public
To support the game’s theme of spectacle, we wanted to add an in-game public. In every room, some guests at the balconies are watching the fights and react to the player’s actions.We initially used simple skeletal meshes for them, but it was hitting the performances too hard. Since they were quite far from the player, we decided to go with some animated flipbooks. To give them a sense of 3D, we were inspired by a technique used in Battlefield 1 — depending on the viewing angle, we play a different row of the flipbook, taken from a different angle on the 3D model.
We used some motion vectors to enhance the interpolation so we could reduce the overall number of frames and the texture size. In the end, the shader cost was a bit high but the public was just instantiated quads, so the overall cost was minimal for a large number of characters. It was a suitable solution for us since we had the same character model with only one animation. For a more complex crowd, we would go with a 3D shader animation or intanciated skeletal meshes.
Lighting
The lighting was also a big challenge. We wanted the warm atmosphere of southern Spain and the fairy tale-like mood of adventure stories.Using the environment is a big element of combat. Since most of the props are movable, most of the lights also needed to be movable. Of course, for performance reasons, full dynamic lighting was out of the question. After some tweaking, distance fields and indirect shadows did an excellent job. This gave the environment a soft shadow effect — exactly what we wanted for our soft lighting and dream-like atmosphere.
One big difficulty we didn’t anticipate is that we had to mix outdoor and indoor lighting in one level. It was very hard to have some lighting settings that gave satisfying results everywhere. To achieve the result we wanted, we set up the directional light and skylight for the outdoors and heavily relied on post processing to achieve each room’s unique look. Changing the eye adaptation and ambient occlusion settings also helped us define the mood between the grandiose main hall and the gloomy library.
We had to make a lot of adjustments while working on the lighting. One important lesson we learned was “do not hesitate to fake.” In other words, a lot of light comes from nowhere or is placed to exaggerate bounce light to guide the player to key elements. For example, sun shafts come from all directions in some rooms of the game or the key element of the training area (the shadow from the ceiling) does not match the true shadow of the 3D model.
Animations
The animations were a big challenge because we needed to create a combat game with a climbing and jumping system in just a few months. We initially created the animation Blueprint with all the basic features that were related to gameplay. Very early on, we had some place holder animations for every move that the character could perform. After that, we could progressively add the polished animations and add some procedural animations (like leans and accelerations) when needed.By having everything working early on, we could see which features needed to be prioritized. The designers could use the placeholder animations in montages to tweak the timings; when they were satisfied, they would give the exact timing to the animator who would then create the final animation.
Because we didn’t have time to create animations for each character, all the characters share the same skeleton with the same proportions. The animator was animating with a generic character, then some procedural animations were added in Unreal for characters’ specific elements like hair and cloth. For example, Adalia’s hair includes three bones in the ponytail to create the global structure, a custom displacement material driven with a Blueprint to give a more bouncy feel, and some cloth simulation on the strands to provide a more natural and unpredictable look.
Blueprints, challenges, & solutions
Our game was made almost entirely in Blueprints, the only exception being the character movement component, which we extended to give us more control over root motion. Blueprint scripting is amazing and a lot can be done with it. The only issue we had to address was the inability to merge Blueprints in the same way you can merge two pieces of code. To make working together viable, we relied on inheritance, and we put a lot of our gameplay logics inside components or function libraries. This way, we could easily work on several tasks in parallel.
Parkour system
To allow the player to do a series of acrobatic tricks without difficulty, we created an automatized parkour system. When sprinting, characters are able to vault on obstacles and jump between ledges automatically. We used blend spaces to create adaptive jumps animations (depending on the size of the gaps), and animation notifies to have alternating feet for each consecutive jump.
Our AI characters can use the parkour system, too. Making AI characters understand the paths they can take while using parkour was a bit tricky. To overcome this, we increased the Agent Max Step Height in the navmesh generation settings above one meter. This is why on the screenshot below you can see tables are not cutting the navmesh. In other words, this makes the AI compute their path as if the way was clear of any obstacles.
The only caveat with this trick is that the enemies would never go around a table and always climb on it. Since this was inefficient and made them look less intelligent than necessary, we added NavModifiers on climbable obstacles. This is indicated by this orange navmesh color on the screenshot. This is a way to tell the AI that entering and moving through this volume has a higher cost in distance. With the NavModifiers, the AI would only climb on the table when it was actually more efficient than going around.
Finally, we hand-placed navlinks around the map, so the enemies knew where they could make long jumps between different parts of the navmesh.
Unreal Engine’s ability to recompute the navmesh at runtime was a blessing, because we have a lot of obstacles that can be moved around by the player.
Making objects that would simulate physics and move around while allowing characters to move and fight on was also quite challenging. Anyone who has played a bit with physics knows that walking on simulated objects will just start throwing stuff around the map at crazy speed, characters included.
To solve this, we doubled every collision on simulated objects, putting one as a child of the other. The parent collision was the one simulating physics, and was not colliding with any pawn. The child collision, on the other hand, was colliding with just the pawns, but because it was not simulating physics and just following the parent collision, we had the result we were looking for.
From the character's perspective, it was just like any other moving platform, but from our perspective, we can see all the complex movement and sways that result from physics simulation.
Camera, Character & Controls
We built various systems to make the controls as user-friendly and accessible as possible. For example, we made an obstacle avoidance system for the character, that redirect the player's inputs. On the following GIF, the movement L-stick is always pushed forward. The inputs are redirected in a way that tries to avoid being blocked by walls, but also avoids jumping off gaps by accident.
As the game expanded, we started to have a lot of character states to keep track of. To make our life easier, we created the function displayed below. This function handles any request for a new state. First, it will check if the character is allowed to go into that state, otherwise it’s discarded. Then it will check if that state should be overridden by another one depending on several conditions. The function is recursive so it can override itself multiple times.
One example of using this function can be seen at the end of any attack. In other parts of the code, we simply request to go back to the idle Guard state, without checking anything else. Thanks to this function, if there is no enemy remaining, the Guard state will be automatically overridden by the Jog state. If the player is holding the Sprint key, Jog is overridden with Sprint. Finally, because sprinting allows for parkour, if a climbable obstacle is detected, the Sprint state is overridden by Climb. All of this happens in one frame and allows us to always call default idle states, such as Guard of Jog, anywhere in the script. This function replaces the requested state with a more appropriate one.
AI behaviors
For AI scripting, we naturally used the UE4 behavior tree system. To make our combat experience satisfying, we worked a lot on the guards’ combat behavior as a group. The maximum number of enemies fighting Adalia is capped to prevent the player from triggering all of the level’s guards.Enemies fighting the player switch roles dynamically. Active enemies are closer to Adalia and are the only ones to attack her, while passive enemies are further away and only watch the fight. Their attack decisions are coordinated to never feel unfair to the player. Enemies will more likely attack Adalia if they are in front than in the back, so that the fights feel more fair and readable.
The enemies try to reach a spot on a virtual circle around the player, thus following the famous “kung fu circle” principle. This can sometimes look cheap in other games, but we deliberately did it to reinforce the feeling of a cheesy, choreographed swashbuckler action scene.
We used one of UE4’s experimental features, the Environment Query System, to tell the enemies where they should position during fights. The potential spots to reach have more weight in front of Adalia or on her sides, and less in her back. We try to avoid positioning them on spots that would feel weird. For example, in the image above, the guards can technically navigate on the balcony rail, but we ask them to avoid the spot given the situation. Finally, we also put more weight on spots close to interactive objects, so the enemies can fall into environmental traps more easily.
Gameplay Elements
While fighting, the player can improvise with many objects from their surroundings. Our initial goal was to make every object of the environment interactive in an intuitive and organic way. With this in mind, we made shape and size templates for the objects, to create an overall coherence. Our objects all inherit from a few generic Blueprint classes. For example, objects from the “knockable” class are all the tall objects that can be knocked over. Then, they come in two categories: thin and large, and have even smaller variations and tweaks for each individual object.
We also made those elements react as systems to create chain reactions and emergent situations. This reinforces our combat intentions by creating a lot of unexpected outcomes. We standardized the trigger events through interfaces - for example, kicking and dodging into an obstacle will always call the Push event, but we made a lot of custom resulting effects (table will slide and enemies will stagger). Some interactions are quite hidden, for example you can throw enemies over guardrails by kicking them, or make them trip on the stairs if you force them to dodge into it.
We made those into homing projectiles as we didn’t want this interaction to involve any complicated aiming mechanic. This kind of stuff must feel easy to do for a swashbuckling hero.
The trick was to find an easy way to make the projectiles follow a nice curvy trajectory, while always landing on the enemy’s head, even if he is moving. You can see below how we achieved this in Blueprints with a timeline and a curve.
Audio
We built various audio systems that needed to support the game’s systemic and non-linear nature.We have “dynamic music” that alternates between a calm ambience track when there are no enemies, a normal combat track when there are one to four enemies engaged, and an “epic” combat track when there are more of them. The music can transition only at specific timecodes to create a smooth transition that doesn’t break the rhythm. To achieve this, we used Blueprint Timelines that are very precise to keep track of time. The timeline is playing in sync with the audio file, with several event keys on the timeline to know where it’s allowed to make the transition. By the way, you can listen to En Garde!’s original soundtrack here.
The characters talk a lot in this game, so we also built voice managers to ensure a character can never “say” several things at the same time. When we want a character to say something, we make a request to its voice manager. The manager checks if the character is already talking, and either interrupts the voice currently playing, or prevents the new voice from being played, depending on a priority value. Of course, story dialogues have priority over everything, so a character will never be interrupted when saying important things. On the other hand, the less important commentaries from the enemies will be interrupted by their “ouch” screams when you beat them up!
Finally, alongside the voice managers, we made a dialogue system that is used for both in-game dialogues and during cinematics. Our dialogues are using a custom “dialogue line” structure that contains various parameters; parameters like the voice sound to play, the subtitle text, the dialogue priority, the character speaking (so we can spatialize the voice), or even an optional “public reaction” that can ask the crowds at balconies to react to dialogue lines in various ways (like “gasping” or “cheering”).
What did you love about working in UE4?
Working with UE4 has been a blast. A great aspect was collaborative work, as we’ve been able to integrate our version control solution (SVN) directly into the engine, and we used the Level Layering feature to work simultaneously on different aspects of our main map.
We loved working on En Garde!. For most of us, it was our most ambitious project yet. Though we only made a vertical slice, we learned a lot in the process. A lot of things could be improved. If we ever get to work on it again, we would probably restart from scratch (on the programming side at least), to build something cleaner and better. But we definitely would use UE4 again!
Team Credits
engarde-game.com
Adrien Poncet - Game director, producer & sound designer
Valentin Capitaine - Game designer & AI designer
Corentin Mangé - Level designer & level builder
Sylvain Schmück - Technical Designer & 3C Designer
Pierre Chapelet - Gameplay & AI programmer
Tim Guthmann - Animator, technical artist & level artist
Anaïs Simonnet - Character artist & level artist
Julien Fenoglio - Art director, concept artist & level artist
Ludwig Wu - Music composer (from MAAAV Lyon 2)
Ilse Zamarripa - Adalia's voice performance
For additional help on assets, special thanks to Ilse Zamarripa, Jordan Jaminet, Valentin Picard, Maxime Conquy, Thibaut Moitel, Loup Druet, Guillaume Faguet.