Branislav Grujic and Daniel Ebanks shared a handful of technical details and their approach to art in the game project TANKHEAD.
Hello, and thanks for checking out TANKHEAD!
Before we jump into the details, we would like to provide you some context as to who we are as developers, our history, and what we believe in.
We are both experienced AAA game developers and have over 30 years of experience combined. We strive to create experiences that will not only entertain players but resonate with them emotionally, creating a lasting and timeless impression.
Our first project is TANKHEAD.
Just a couple of important things to keep in mind before you read this article:
- TANKHEAD is in early development and what you see is pre-pre-alpha so expect stuff to change as the project develops.
- We are currently 2 people, Branislav Grujic who handles all of the programming and implementation and Daniel Ebanks who is responsible for the art and design.
- We’re not quite yet talking specifics about the game design; you’ll have to wait a bit longer for that.
Daniel: I’ve been fascinated by tanks, bulldozers, dump trucks, virtually anything with a diesel engine ever since I can remember. There is something about these machines, especially tanks that captivates me - the terse, brutal visual language of function dictating form that creates a stripped-down elegance that I am drawn to.
But there’s more to it than just visual appeal, equally as important and interesting is the history behind these weapons of war, specifically the individual history of each vehicle. The lives of the people who operate them add a soul and a vulnerability to these terrible machines. Vehicles that have seen combat and have been witness and party to the intensity of human experience in war seem haunted by an intangible weight that hangs over them, long after the guns stop. I’m fascinated by the quiet battlefield, the scared earth, the indifference of nature and the loneliness of forgotten things. These are some of the themes that we are exploring with TANKHEAD.
The work of Katsuhiro Otomo is always on the back of my mind. Akira, The Order to Stop Construction, Cannon Fodder, Domu are just some examples of the amazing work of Otomo. His industrial design, architecture and iconic imagery have been a huge influence for me as an artist.
Physical models and dioramas are also a big source of inspiration. They are self-contained works that often feature vehicles as the primary focus. Some projects feature great compositions and rich narratives told in a simple but appealing manner. I find there is a lot to learn from how these modelers approach a scene. Plus the artistry and attention to detail in some of these works are just mind-boggling.
At the moment, all of the art is done by me which includes concept design, modeling, texturing, lighting, VFX and animation. And as such, I need to be pragmatic when planning the visuals.
That being said I have a few goals/rules that keep me focused when generating art:
- Appeal. I’m an art director by trade so the visuals are a priority.
- Keep it moody, this is a world that people want to explore, look in every corner.
- Less is more, let big shapes and colors do the heavy lifting.
- Clean frame, non-busy or overly noisy textures.
- Sense of scale. It seems like an easy thing but it’s always a challenge keeping a relative consistency over models and textures…
- Not a single asset can take too long to generate. Keeps my ambition in check.
We are planning TANKHEAD as an open-world game, so our process is geared toward building dense large scale environments.
I usually start with rough sketches, just pencil drawings in a notebook to figure out what my themes are. After I find what I’m looking for I jump right into the blocking process. At this stage, it’s about establishing volume and scale, roughing in the dominant shapes.
The space is playable so I’m also wearing my LD (level-design) hat to ensure that everything flows intuitively and gameplay mechanics and metrics are being respected.
I try to establish the color pallet for the area as soon as possible, assigning the “grey-block” assets a flat color from a pre-authored texture pallet.
This process is super quick but really helps establish the big picture. The color pallet texture allows me to quickly experiment with color combinations in context.
Once I’ve got the area blocked out, I’ll take a screenshot and do a quick paint-over in Photoshop or Procreate to guide modeling and texture creation. The paint-over also generates ideas for props and smaller assets to build later.
As I mentioned earlier, time is not a luxury for us and a pragmatic approach to modeling assets for TANKHEAD must be taken. We reserve a high-poly workflow for assets where it makes the most sense like player assets, hero assets, and vegetation... Pretty much everything else is constructed around tiling textures and trim sheets.
The world of TANKHEAD is a world lost to humans. While being not post-apocalyptic, the play-space is contained within a sort of “exclusion” zone devoid of human occupation and vegetation plays a major role in conveying a sense of neglect and the passage of time.
A good normal map is needed for the base as the in-game assets will be quite simple.
All veg is modeled out as a high-poly sub-D asset. These models are baked down to texture sheets. Albedo is made in PS.
As I’m sure we are all aware, real-time vegetation is a careful balance between performance and visuals. With that in mind, I try to be as economical as possible as density is the name of the game. For larger assets like brush and shrubs, I’ll bake the normals from a target source using the NOORS normal thief script to give the geo a more full look.
General Asset Creation
For the high poly work, I use a bunch of different techniques: Sub-D, ZBrush and more recently I’ve incorporated CAD modeling into my workflow, in particular, Shapr3D on the iPad. Shapr3D has proven to be very handy for me as I can model relatively complex forms quickly, and the convenience of the iPad is great. While Shapr3D is not appropriate for all asset creation needs, it has become an important tool in my workflow.
Trim sheets and tiling textures make up the bulk of the environment texture work. I personally love trying to see how I can re-use a texture as much as possible without people noticing it.
To help with the re-use we use some simple well known but effective tricks like vertex height blended materials and decals.
We get a bit more mileage out of our painted metal textures by masking the base albedo color using the metallic blue channel as the mask. This allows us to modulate the base color of the texture with constant while keeping the underlying metal color from the original albedo without adding any new textures. Again, it’s super simple but it works.
Branislav: TANKHEAD is built from the ground up using Unreal Engine 4. During the initial conception stages of TANKHEAD, we were thinking of how to approach game development in several ways.
Since I have a lot of experience in writing custom game engines, some from scratch and extending others, we explored the idea of doing that for TankHead, but that idea was soon scrapped as we realized that both Unity and Unreal are publically available and would shorten our development time by quite a lot.
We initially spent some time prototyping TANKHEAD in Unity so that we could explore art styles and physics, but quickly discovered that without access to engine source code it would be a difficult thing to achieve. Having access to source code helps quite a lot because we are able to quickly fix any issue and also push back our changes for other Unreal Engine developers so that we can have the least amount of local changes as possible.
The mix of C++ and Blueprints has allowed us to have a very good split workflow where we do our core features in C++ and all of our tweaking and simple things inside blueprints.
Example Switch C++ implementation with Blueprint Animations:
This is a great example of the kind of flexibility you can have with blueprints where a skeletal mesh is not ticking when initially created, but after something interacts with the object, we can turn on the skeletal animation until it's finished playing and then turn it back off.
In terms of blueprints, the two big features we use quite a lot are DataTables and DataAssets. Through the use of DataBases, we are able to create many variations of items and weapons with minimal changes. Everything else uses DataAssets in order to expose things to blueprints. We follow this approach for avoiding merge conflicts in blueprints because we don’t want to have to check in a change to an entire asset for simply tweaking a value.
Example Datatable that defines a weapon:
Example DataAsset that defines a vehicle and how it’s used inside a blueprint:
Since each vehicle is essentially a DataAsset, this means we can quickly prototype different vehicle behaviors without needing to create new blueprints. You can simply create a new DataAsset and assign it to the blueprint (visual mesh).
As many others have done, we first started with our own gameplay abilities system but quickly transitioned to the UE4 implementation because it is vastly superior. While it is a bit more complex to use, the benefits of having a threaded gameplay ability system are quite nice. This page contains all the information to get you started.
Once again, we employ the use of data assets to provide gameplay abilities to vehicles and drones which makes this quite flexible. This means that we can hot-swap, upgrade and find new abilities at any time during gameplay.
In terms of C++ code, each ability is a UGameplayAbility Class:
The actual implementation of each ability is done through a AGameplayCueNotify.
Example of an ability implemented through GamePlay Ability System:
When we first started working on TANKHEAD, we explored using the currently available plugins on the marketplace and the vehicle system provided by UE4 itself, but we found those solutions not to be flexible enough because of the modularity we require in our vehicles.
As a result, we wrote an entire vehicle physics simulation from scratch to allow for maximum fun. We were greatly inspired by the physics of Rocket League, and how simple techniques can provide a great feel. I highly suggest watching the Physics of Rocket League GDC talk if you want to learn more about vehicle physics. That talk encouraged me to try and write my own vehicle system.
The vehicles are set up through DataAssets as mentioned earlier, so it is super easy to swap vehicle physics data.
Our suspension system is quite unique as we feature vehicles that have both wheels and tracks. In order to animate the movement of these along with collision, we employ a custom solution using animation blueprints to move rigid bodies around and IK the wheels accordingly.
Since we want to also support tracked vehicles, we have a custom splined-based solution for tracks. This works great since splines in UE4 are quite cheap to use and work well.
We also strongly believe that every feature requires great debug tools, so while working on the physics, we developed proper tools that allow us to hook into the debugging features of UE4 and make our development much easier.
The main focus of our interface is the connection between physicality and interaction. Since you don't play as a traditional character that has arms and legs, we still want the player to have a tactical connection to every action they perform in the game.
As a result, player feedback is extremely important. Every single interaction needs to have a satisfying visual and sound. Every action needs to have a reaction.
When we do things in everyday life, lots of actions we perform have specific weight to them, which we also wanted to emulate through our physical interface. As a result of this, secondary motion is extremely important but can be quite difficult to get perfectly correct. Lots of satisfying animations and appealing audio cues are key to delivering this experience.
In TANKHEAD, destruction plays a critical role in the feel of controlling heavy powerful vehicles and weapons. In order to deliver the experience of what happens when a heavy machine interacts with the world, destruction is our solution to that.
You also primarily play as a scout, which is a stark contrast to the heavy machines, since it is quite agile but also relatively weak. As a result, having a destruction system that reacts to an object's mass and velocity was quite interesting for us.
We developed a custom destruction system that takes in a mesh and breaks it up into multiple pieces. This allows us to have full control over how this system works and make any tweaks we want. Since we store a completely broken version of the mesh, we can detect the collision impulse and how many of these pieces overlap and propagate the forces through the correct pieces. This also means that once a portion of the object goes into a destructible state, each piece is individually simulated as any other object in the world, which allows us to have chain reactions.
Currently, we are using PhysX rigid bodies for destruction simulation, but we are looking into using the Chaos physics engine. It would allow us to use the engine tools to generate this data inside the engine without the need of any external editors, which would simplify our workflow quite a lot.
Here is also a video of the destruction system during actual gameplay:
Visually, we are super inspired by hand-drawn art, so when it came to creating our custom "technical pencil" shader, we wanted to avoid the traditional “toon-shader” look as that’s not what we are going for.
In terms of implementation, we modified the engine to support custom rendering passes in order to ensure this is integrated into the rendering pipeline directly. Previously, we maintained lots of graphics changes in our custom Unreal branch, but since the addition of the Render Graph, we were able to remove a lot of our code and use that to hook into the right place in the rendering loop.
To achieve the look we have, a few key elements had to come together. The "technical pencil" line shader runs after the lighting is complete but before the volumetric passes. This allows us to integrate the effect into the volumetric passes since in our game we are using volumetric fog and atmospheric scattering quite a lot.
I have written many line shaders before, and this one is quite special because it's per-pixel perfect and resolution-independent. Because of that, we are able to maintain sharp lines across the entire screen no matter how far the object is away from the screen.
One more special feature of our "technical-pencil" line shader is that it is average-luminance-aware. Depending on the average luminance of the screen, it will react differently and shade itself correctly. This allows us the ability to have different colors in different lighting conditions because we want some artistic control. While this is a subtle detail, it helps quite a lot when transitioning between high and low luminance areas.
Daniel: VFX is super important to the look of TANKHEAD. We are going for smoke and fire that has substance and volume, that thick toxic smoke that blots out the sun. To achieve this look, we rely heavily on opaque shadow casting geometry that gets properly lit while being quite cheap to render. The fire is a simple hand-drawn animated texture with an opaque cut-out shader. We are applying this process to all of our effects to give the world a living and dynamic look and feel.
We are still currently mostly using Cascade for particles, but we are exploring Niagara for future work.
We love the idea of the world interacting with the particles, so we implemented a custom solution for integrating the wind into both Cascade and Niagara particle systems, which adds quite a lot to the world's look and feel.
TANKHEAD is currently in pre-production, but we are always excited to share the progress on the game with all our followers, so if you are interested in keeping up to date please follow us on twitter to see all the upcoming content.