Armored Tussle
Game Design, Programming, Art, Marketing, Music, Sound, UI Design, Production
Roguelike Twin-Stick Shooter
What is Armored Tussle
Armored Tussle (AT for short) is a singleplayer roguelike top-down twin-stick shooter (bingo!). You play as a tank called the Tomcat, dropped behind enemy lines facing down waves of opposing forces single handedly. This is a solo project developed by me, and published by my studio SkyPyre Studios. It was created in Unreal Engine 5, using almost all blueprint code, and all other assets were created from scratch by me.
The game loop would see the player start an Operation: a collection of missions with differing objectives, threats and modifiers. They would then choose a tank pilot to bring on the mission, and had to complete a certain number of objectives to evacuate. All the while the player would collect upgrades and addons to enhance that pilot’s tank. If the tank died, all upgrades and experience it had would be lost, and the mission would end. Thus giving the player a limited number of tanks, and a limited number of missions in which to complete enough objectives to win.
This project is still in development, but due to a series of events, and a severe case of burnout, it has been shelved for the time being. I plan to return to it and release it eventually, but for the time being this writeup acts as representation of the work done - all features or products mentioned have been completed at this point in development.
Player
AT features a top down twin stick shooter style player controller, with a fixed camera position. The game was first designed with a mouse and keyboard in mind, using WASD for movement and the mouse for aiming, and a reticle below the mouse to keep track of the pointer’s position. Gamepad was also implemented, initially it saw the left stick used for axial movement, and the right stick for axial aiming. This proved challenging to balance for game feel, and thus it was changed to a positional aim point which was locked to the radius of the player (ie replicating the aim of a mouse). I found this to be much more natural, and in the future I’d love to see how players react to it.
One consideration for the player controller was locking the camera to the character, rather than the reticle. I experimented with both, and found the latter to be uncomfortable and unreliable for aim. Down the line I may have offered it as a gameplay option.
The other notable player element was the use of a laser pointer for aiming, since it helped make sure the player knew what they would hit and what was offering cover. This color was customizable in the options.
Map Generation
The maps are partially generated, allowing for a constantly changing game experience. The first component of the map generation is that they are grid based, composed of tiles that evenly fit together from all sides to allow for the construction of a number of layouts. Generated at runtime, the map reads a data table of integers which correlate to a series of tile groups, within each a variable spawn change for a smaller selection of tiles. These data tables are CSV files imported from a custom python app created by SkyPyre’s Andrew Smith for map making, called Tussle Tiler. Once the core layout was created, each tile then checks its neighbors and adjusted connective components depending on the relationship; such as water on a cliff edge turning into a waterfall.
Once the data was set in place, the biome and weather subsystem would do its work, changing all the materials to one of the master biome materials. These used a collection of colors and high performance noise maps to great grass, dirt, sand, snow and rock, and applied it to all the ground meshes with specific masking information. It would also change all tree models and water materials to match the biome data. Finally, the weather would be set, including any global particle effects like ash, snow, or rain, along with a time of day changing the fog, directional light and ambient sky light color and direction.
The result is map generation offering loads of variations on hand designed layouts, with hundreds of combinations of biome, weather and time of day for varied visual appeal.
Enemies
Created later in development than they should have been, enemies offered a number of archetypes against which to test the player’s mettle. They were built on Unreal’s Behavior Tree and AI Perception systems. I won’t go into too much detail about each one, but I’ll cover the rough archetypes and implementations.
-
Soldiers are basic fodder enemies that tickle the player with machine guns.
-
Rocket soldiers are stronger fodder, that telegraph and fire a non-tracking rocket the player must dodge.
-
C4 soldiers are suicide enemies that telegraph and charge after the player, exploding on contact.
-
Javelin troopers are like rocket soldiers, but have exo suits they can use to jump out of the way, and fire a tracking missile that moves straight at the player, meaning they can be guided into walls.
-
Jeeps are pest enemies that move faster than and circle the player, doing chip damage with guns.
-
Tanks are basic enemy brawlers, they can take beating but are not smart opponents.
-
Artillery maintain distance from the player, deploy and fire telegraphed shells in their direction. When approached, they pack up and run, activating a defensive shield.
-
APCs are your classic spawner enemy, they can deploy up to 3 infantry squads, and attack from a distance.
-
Destroyers act as the snipers, telegraphing a precise line that tracks the player until fired, dodgeable, but better to find cover.
-
Healers would heal or revive enemy vehicles.
-
Disruptors would hang around in the backlines, and use a debuffing beam to slow player movement and disable abilities.
Art Pipeline
The artstyle for the game is obviously retro, aiming for that late 90s Half-Life inspired low fidelity. Not only was this chosen for artistic reasons, but it also would play nice with the distance of the camera, and would allow me to produce more content in a shorter time.
All meshes and rigs were modeled in Blender, using very low poly design methods. One example is that any cannon or gun barrel (of which there are a lot) is just a cube with rounded shading on the edges, giving it that illusion. If required, the mesh was also rigged in Blender, either manually or using Blender’s Metarig system.
Once the mesh was complete, it was brought into a new app for me for this project, 3DCoatTextura. There, it was hand painted on several separate layers, each exported for dynamic use in the engine. These textures were of course, low fidelity, at 128x128 (takes me right back to my Unreal Gold mapping days). Even the noise textures used for world aligned environment materials were downscaled to 128x128 or 256x256.
Once in the engine, the master material for that object was used. All materials in AT are fully rough and flat, with the exception of light sources which had emission. Many of the materials offered dynamic coloration, such as enemies having a faction color mask. The Tomcat tank itself had a whole suite of customization options, various patterns across a number of colors, and player ‘faction’ color for the main turret.
All bespoke animation was also done in Blender, using keyframe animation techniques. It was then exported for use in Unreal’s Animation Blueprint system. There were also several layers of procedural animation, such as turret aiming, which was programmed in the Animation Graph.
User Interface
AT featured a full menu system, painstakingly implemented using Widgets and UMG. By design the menu was meant to evoke a computer console, like a command line. Injecting some contemporary design overlaid for visual appeal helped improve the user experience though, such as modern fonts, gradients and transition animations. The latest version of the pre-alpha has a full operation screen, customization, lore codex, achievement list, settings menu and several prompts for warnings, pickups and upgrades.
On the backend, the menu system fully supports mouse and keyboard, and gamepad, including hotswitching depending on which device is detected being in use. Whenever I revisit this, I will convert it to use the new Common UI system in Unreal, but using just UMG made this process much harder than I thought it would. I ended up inventing a custom widget referencing table which used focus to allow for smooth gamepad use without losing focus or getting unwanted jumping.
I also created dozens of widget elements that are reused all over the project, from buttons and pages to drop downs, multi-select lines, sliders and text fields.
Audio
Finally, the humble audio. I hadn’t made it to the point of custom sound for actions or the environment, but I had composed a number of musical pieces for the game to help build the theme. This was my first project using FL Studio, but overall I’m proud of how the pieces came out. A selection of them are playable below.
Conclusion
While I wish the game had made it to the finish line, I needed to prioritize my mental and physical health first. A choice, while painful, I don’t regret in the least. This project taught me an immeasurable amount about Unreal Engine, game development, data architecture, AI programming, 3D asset creation, music production, and UI design. These are lessons I carry into every future project, and will eventually, I’m sure, end up benefiting the final version of this game once I return to it.
If you want to see more about this game, check out the SkyPyre page for it, and if you want you can wishlist it on Steam - though, that might be a while.