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 startedEn 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.
DesignEn 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 directionThe 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 ArtThere 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 LayeringFor 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 was a bit complex in the beginning for the artists because we needed to create a new master material for each new combination. This process can take a long time, especially when anticipating the final result. Nevertheless, it was worth it to take the time to implement this workflow since it helped us reduce the amount of textures and their size. Most objects only use the generic materials and only few of them need a special mask.
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 PublicTo 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.
The flipbook was created in 3ds Max but with experience it could be directly created in Unreal. We also used some normal maps, ambient occlusion, masks, and low-resolution maps to enhance the 3D feel and to root them in the scene to add some variations.
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.
LightingThe 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.
AnimationsThe 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, & solutionsOur 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 systemTo 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.
To let the characters know where they can jump or not, we placed splines on the level elements. Those splines are detected by various traces and the character reacts accordingly to what gets detected. Using splines like this gave us more control in the execution of the behaviors that simply make the characters search for any solid surface.
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 & ControlsWe 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.
We worked on an obstacle avoidance system for the camera, too. By detecting the player direction of movement and the incoming wall corners and obstacles in the foreground, we are able to position the camera automatically so the player never loses sight of the character. On the following GIF, the camera R-stick is left untouched, and the camera rotates on its own.
The camera also orientates in the direction of movement if the player is going to the left or to the right. On top of this, we have the camera focusing automatically on the enemies you’re attacking so you never lose track of the action. Of course, the player's input always has priority, but such a system makes the game more accessible to less experienced players who are not at ease with dual-stick controls.
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 behaviorsFor 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 ElementsWhile 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.
For moving objects, we don’t solely rely on physics because the results would be too chaotic. We actually control the physics a lot, so that the objects always behave in the way we designed them. Controlling object behaviors also lets us do custom reactions to specific contexts. A bookshelf object in the middle of a room will simply fall in the direction you push it. But when placed against a wall, that same bookshelf object is scripted to sway for a second before falling in the opposite direction. This also provides additional time for some enemies to conveniently get in position to be crushed.
At some point, we started to add smaller objects to populate the level. Following our intentions, we knew we had to make them interactive too. Allowing the main character to throw them toward the enemies with a kick turned out to be one of the funniest swashbuckling tropes in our game. It first started with water jugs, then we added fallen guards’ helmets, and even roasted turkeys that can get stuck on the enemies’ heads.
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.
AudioWe 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.
The engine is really user-friendly, and Epic’s documentation as well as the community’s tutorials are quite extensive, making it easy for everyone on the team to participate in a lot of aspects of the project. It’s incredible that we’ve been able to create all of our systems almost entirely in Blueprints! Some tools really made our life simpler, like the Animation Blueprints, Sequencer for cinematics, the Material Editor, and the lighting tools. The fact that we have access to all of these tools for free is amazing too.
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!
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.