Cauldin Kyle

Duration: 2 Months Planned (Current: 2 weeks completed)

Team: None

Size: Solo Project

Tools: Unreal Engine, Photoshop

Game Overview 

Lord of the Grave is a isometric cast and blast dungeon crawl style game, where the player controls a lich wizard trying to escape from the graveyard he's been confined in. Using magical spells to defeat zombies, ghouls, skeletons and more, collects the souls of your enemies to power and and grow, and find a way to escape the grave that binds you.

What I've Done

• Fireball Attacks
• Trigger Events
• Player Movement and Abilities
• Enemy Abilities, Movement and Animation Graphs
• Enemy AI
• Item Pickups
• Doors opening, text popups, etc.

Technical Work

So far on Lord of the Grave, there are a few key abilities that I've worked on for players to engage with.

     Fireball

• Summoned via right click
• Rotates around player, following them wherever they go
• Damages enemies they contact
• On left click, fires from current location in direction of mouse, maintaining height while travelling off screen
• Explodes on contact with surfaces, damages enemies
• Self Regulating (new fireballs will not spawn until previous ones are used up)

     Enemy AI

Planning for 3 boss fights, each with different sets of attacks and abilities. One boss (ghoul) is nearing completion.

The enemies use an AI tree and blackboard (the Unreal toolset) to to select from events to do based on conditions in the game. I have also set up animation graphs for them to select animations based on in game states.

Ghoul

• Approaches player if it is far away
• Checks if abilities are on cooldown. If they are, it will attack the player in melee (arm swing)
• If the boss's ability is off cooldown, it will create a large explosion around itself, giving the player a few seconds to move away.
• When defeated, drops an important item for the player to progress

Further AI coming Soon

     Health Bars

The game features health bars that are in the world rather than as part of the HUD. The player health bar follows the player behind them, always facing the camera and sitting near the ground. Small enemies do not need healthbars as they die in a couple of hits. Boss enemies have health bars that are circles under their feet, depleting and flashing red as they empty.

Duration: 4 Months

Team Size: 6

Tools: Unreal Engine, Photoshop, Illustrator

Roles: Project Manager, Gameplay Designer/Scripter, UI-UX Designer/Scripter

NOTE: All Pictures and Videos Represent the Works of all Members of the Team, Including Artists, Level Designers, Programmers and Sound Designers.

Iron Casket is a third person mech combat game in a western mech style, with slower paced, ground based combat. It features a large amount of environmental destruction, with most buildings and props being destructible using a mixture of Unreal destructible meshes combined with Houdini data to improve the effect

Role/Game Overview

Iron Casket was a project at VFS. When we began this project, I volunteered to be the Project Manager and take care of a lot of the team needs with scheduling. Besides that, I took on the role of Gameplay Designer, with that being my primary interest in game development. Starting out, this was a hefty workload, but i felt confidant in managing what I had assigned myself for work. Shortly into preproduction, the team realized we had overlooked a very important part design for this project; the UI. At the time, each member of team already had a lot of work on their plate, and so I stepped in to take on this role that nobody on our team had any experience with, and found that I really enjoyed working with these systems. I was also primarily in chart of maintaining all of our documentation, including Game Design Document, and task lists.

     What I Did:

     - All Visual Scripting (Events, Timers, Movement, Enemy AI, UI, Material Graph)

     - Document Maintenance

     -Design For All Mechanics (Everything Players Do, not including level and scenery. Includes Movement, Shooting, Gameplay Level Events, Etc.)

     -  Project Management

     - Narrative

     - User Interface, Including HUD, Dialogue Text Boxes, Enemy Health bars, Etc.

     -Enemy AI Design (Designed Logic Tree for Mech Enemies, but didn't implement. Designed and Implemented Soldier AI)

Gameplay Design

On Iron Casket, as a designer I had a few goals that I laid out at the beginning for the game in order to make a successful title:

1. Create weapon systems that promote different playstyles between players, as well as having meaningful tradeoffs for using each weapon
2.  AI that provides necessary decision making and threatening combat to the player
3.  Movement that supports active involvement with the weapon systems and the AI, creating a dynamic triangle of continuous movement through the level while keeping combat activity high.
4. Systems to promote player awareness of the battlefield and give sufficient information on enemies to confidently engage in combat without breaking player engagement and making them feel like they are a player in a game

Weapon Systems

Iron Casket three weapons; a machine gun, a rocket launcher, and a gauss cannon. These weapons were designed with two important aspects in mind; combat and destruction. Designing all three weapons to fit into both categories equally was hard, typically balancing in one field would unbalance another. I spent a lot of time in testing bouncing back and forth on the usefulness of the rocket launcher. It often felt like the rocket launcher was not useful in combat, but very interesting for destruction. After some time playing with weapon stat balance on all three guns to bring them into line with each other, I've decided to move along with the fun. Player testers have enjoyed having a weapon that they use primarily to destroy the environment, and I'm happy to give them that option.

The Cannon and machine gun have been far easier to work with, creating a natural dynamic of long range/slow/powerful to short range/fast/weak, which most players inherently understand and are used to. The cannon has a camera zoom to shoulder to increase the feeling of largeness and power during shooting, which compliments the destruction well, increasing the player view of the destruction they are causing. The only major change the machine gun has gone through is a switch from ray cast based to projectile based, which allows us to edit the bullet speed travelling through air.

Character Movement

Player movement hasn't been the most difficult aspect of balance in terms of combat. Instead, it presents a primarily visual/thematic problem. Maintaining a large, destruction machine feeling during combat while still having enough mobility to create interesting combat scenarios has been interesting. I first introduced the idea of destruction in order to solve this problem,  allowing players to create their own paths to navigate combat zones and move around enemies to create better combat scenarios for themselves.

Controls

A worthwhile thing to address would also be the controls of the game. In the beginning was dedicated to maintaining true tank controls, where holding a sideways directional movement key would turn the legs of the mech, and pressing the forward movement would move the player in the direction of the legs facing, rather than the direction they were holding. While the mech enthusiast in me struggled with change here, eventually I was convinced through player testing to move true tank controls to an optional setting, and simplifying the controls. Currently, the controls allow the mech to move in the held direction, but with a minimum turning radius to continue to make players have to plan their path carefully.

UI/UX Design

Designing UI has been an interesting side passion I've found throughout this project. Much of the UI is very straight forward, albeit necessary for a mech game. These include a reticle, ammo counters, cooldown timers, health bars, vignettes, and a few more. The most interesting ones for this project I think were the ammo counter and the radar ping. 

                                 Final UI Format

     Ammo Counter

The ammo counter was by far the thing I've struggled the most with on this project. I had barely looked at user interface elements before this project, and had some fairly difficult problems on  my plate right off the bat. Namely, how to indicate all of the combat necessity information to the player without eating too much into the player view space, and the most dominant aspect in this regard was the ammo. Starting out, it was simple words and numbers on the left of the screen, but it was quickly apparent that this simply wasn't good enough. It looked bad and caused players to move their eyes away from where they were aiming to track necessary information

                                                                                           Ammo Counter First Pass

I took some inspiration from indicators from the MechWarrior franchise, who solved this problem quite nicely for me already. Ring the reticle with some simple but informative images that give the information without directly giving numbers. After a few passes and a lot of figuring out math to create it, I ended up at something that look somewhat like a computer based graphic to fit the theme, with differently shaped icons to indicate each gun, but no numbers to make the player read. The images fill and deplete with color to indicate ammo usage and reload.

                                                                                              Ammo Counter Concept Pass

With the machine gun indicated on the left and rockets available on the right, players no longer had any difficulties tracking their ammunition usage in the heat of combat.

This would later evolve to the first picture displayed, with the more simplistic yellow bars further away from the reticle.

     Radar Ping

The radar ping was nearly as difficult for me as the ammo counter, but with this one I had the experience of the counter under my belt. This was first designed to counter player unawareness of enemies they had not seen entering the battle zone, and it creates a 5 second highlight of enemies through walls up to a maximum distance.

                                                                                   Radar Ping First Pass, Functional

                                                             Radar Ping Final Form

The AI was a piece that none of our team had any experience with beforehand, and so I had to work closely with our programmer to meet our visions of interesting, thought driven combat. This is still a field we struggle with currently, constantly improving enemy reactions to player actions.

AI Design

At this moment, our AI utilizes angles and player heading to improvise group work, where they are all checking distance from the player and choosing movement patters based on if they are closest, second closest, third closest, etc.

We started with the basics during prototype: an enemy that moves towards the player and shoots them. This quickly evolved into an enemy that circles around buildings to find the player first. Given the nature of our game being in a city, this was a necessary step. This is also very boring to fight.

After a few iterations, we made our way towards enemies that seek the player, but they weren't engaging with the environment in any meaningful way, and that was a problem. It made them feel like robots, not people in robots. To solve this, we created delays in the firing patterns of the enemies, so that after players run behind buildings, the enemies would continue to fire for a few seconds, and will take a few seconds after the player emerges to regain vision, simulating a human margin of error in tracking. We also created a second AI for enemies that primarily use the cannon, with cannon enemies now acting as snipers, waiting for the player to come out of hiding, and machine gun enemies flanking the player to drive them out of cover.

Project Takeaways

I still feel like there's so much more I could learn with this project if I took it further, but already I have taken away a lot about Unreal Engine as a whole. The project has made me learn a lot about material creation, widget construction and shaders. It has greatly widened by visual scripting skills and understanding of animation graphs and animation events.

More broadly, it has increased my awareness of the difficulties in dealing with AI programming, how difficult it can be to break down what seem like simple tasks into useable information in code.

Throughout the project, I have had to address ever increasing numbers of problems, and it has forced me to improve my problem solving and design capabilities to match.

Most importantly, my understanding of other roles in the games industry has improved greatly, having had to work with programmers, artists, sound designers, and concept artists to make this project work. I've learned enough to realize that there's so much more to learn, and I'll never be finished with being shown how little I actually know.

Project Collaborators

Eric Boucher (Level Designer) linkedin.com/in/eric-boucher-80b114255 

Arseniy Skodaev (Programmer) https://www.linkedin.com/in/arseniy-skudaev-655338255/ 

Nicholas Drew (Character Artist) linkedin.com/in/nicolas-drew-3a2961246 

Marcus So (Environmental Artist) https://www.linkedin.com/in/marcus-so-5b835621a/ 

James Ingram (VFX Artist)  linkedin.com/in/ingram-james 

     Secondary Collaboration

     Diego Medina-Cabral   (Sound Design)  https://www.linkedin.com/in/diegomedina-cabral

     Pablo Palomino Gómez  (Sound Designer) www.linkedin.com/in/pablo-palomino-g%C3%B3mez-2490a817a 

Nadia Coronel Contreras  (Sound Designer)  https://www.linkedin.com/in/nadia-coronel-a39818195 

     Samuel Buday (Concept Art) https://www.linkedin.com/in/sam-buday-b62783254/