Steelhunters

I worked on Steelhunters as a level designer in UE5. It’s a third-person shooter mech-based game made by Wargaming. Unfortunately, shortly after release, the decision was made to sunset the game due to a lack of an player base.

See below for some of my work on Steelhunters.

Please note that, due to the NDA and the fact that it has been sunset, I am not allowed to post pictures of my work that had yet to be released to the playerbase.

Level Designer - Roles and Responsibilities

Here is a short summary of my responsibilities during my 2+ years working on Steelhunters. To see more details and images, please look further down this page.

• Feature owner of the tutorial and gamemode training. Under a tight deadline, I created the documentation, blockout and designed the flow of the tutorial. This required a vast amount of cross-compartmental communication, such as regular communication with gameplay programmers, artists, narrative designers, QA and the creative director.

• Responsible for creating a significant portion of the snowy-themed map, which was released to players, but unfortunately wasn’t fully completed. In the planning stage, I helped create the top-down documentation and gather research for the map pitch. In the blockout stage, due to most of the other LD’s being busy or on leave, I created with another LD the initial blockout, including general placement of the POI’s and extraction zones and the flow. As more LD’s became free, I took less responsibility towards the end of the process due to other outstanding work, such as the tutorial.

• I used blueprints to create gameplay prototypes to help the maps seem more alive and interesting. For example, creating a trap prototype, such as falling rocks or destroyable bridges. I also designed a lift prototype/jump pad prototype to be used in maps so that there were more options for players to get to high areas. These never got past the prototype stage due to the sunset of the project.

• I pitched a design to improve the Drone’s interactability in-game, which got accepted, but again got stopped due to the sunset of the project. Drone AI improvements included creating more hotspots and ‘mini POIs’ such as drone nests to improve the PVE experience, rather then the roaming drones that were currently implemented. I also pitched for there to be tools for LD’s to modify the drones in game, such as being able to decide their behaviour, difficulty and patrol paths so that we could create more exciting encounters.

• I also worked on another map and was responsible for a significant portion all the way up until the first completed blockout. It was in the testing phase before the game got sunset. Again I helped create and design the initial top-down map and documents, as well as being responsible for creating a vast portion of the map (maps were 2.5km x 2.5km). Due to NDA I can’t post images of this.

  
  
  
  

Tutorial Work

To see a video of the tutorial, please follow this link and view minutes 1:02 to 9:10.

https://www.youtube.com/watch?v=ESCEhx7h5Kk

Please note I don’t take credit for this video.

The onboarding flow for players was in 2 parts; the first was through the tutorial that taught players the basics of the hunter/mech. The second part was gamemode training and was optional for players. The gamemode training was featured on a portion of an existing map to save time and resources.

Originally on Steelhunters there was a tutorial already created, but the leadership decided it wasn’t fit for purpose and asked if we could make another tutorial. The main requirements of the new tutorial included:

• Players needed to be able to complete both parts in under 10 minutes; the quicker the better. (The onboarding at the time was very long, and there were worries about it affecting the retention rate.)

• The tutorial needed to feature more destruction and show the mech’s towering height and powerful feeling.

• Needed Voiceover with subtitles

• Integrate more of the lore

• More exciting.

• It was primarily a duo game, so the player needed an AI partner to help them through it.

• Teach more about how to play the game

Process

Below are details on how I tackled some of these requirements and the problems that were encountered.

Teaching the player

Due to how close to release we were creating a new onboarding flow for the players, there wasn’t much time to create this. As it also heavily involved lots of different departments, (from narrative, to sound, to artists etc) it needed to be small and basic. There were a lot of exciting plans initially (such as the tutorial being a simulator and you travel through different ‘biomes’) but it realistically couldn’t be created in the time period given. Also part of the planned design I had wrote into the documentation had to be cut due to there not being enough time to create this. With that said, a modular approach was agreed on to save time. However this meant trying to squish introducing the mech’s controls and progression to the player in 4 rooms (as well as some lore).

In the end I had to prioritise what to introduce to the player in the tutorial and what I thought the player could pick up as they played the game more. For example, initially I wanted there to be a separate ‘beat’ to explain the starter mech’s abilities but this had to be cut. Instead, I mention that the player can use abilities in the help text and via the VO in the tutorial, hoping that they would discover them. I chose to do this as I thought that players would see their partner, or the enemy ai use abilities and ask how they would do it and then try to use their ability. There is also a dedicated UI section on the HUD that becomes highlighted when the abilities are available (E.g you level up and it says ‘Ability unlocked’).

The good thing about not being able to create more ‘beats’ and rooms for the player is that naturally it meant that it became a shorter and snappier tutorial.

Voiceover/Lore

There was a limited time that the VO (Voiceover) speaks and part of the requirements was to introduce lore to the player as part of the tutorial. However, this also meant a balance of lore VO vs player information VO. It was important that the player is given the instructions and they learn the game. In the end some of the narrative VO had to be cut as it got in the way of giving instructions/information to the player. To add to this as we wanted to create quite a ‘free’ tutorial where they aren’t waiting for the VO to finish before proceeding, it had to be balanced so that there was minimal VO clipping. What I mean by that is in the very beginning they are asked to jump up to the initial ledge. The length of the VO line couldn't be much longer than the time it would take to do this.

Destruction

In terms of destruction, this was more on the art team’s side to include objects related to the theme of the map that could be destroyed. As the LD I had to ensure it didn’t impact LOS of objectives or general gameplay. There was initial confusion on first iterations where a destructible building was placed near and in front of where the player spawned. But a player isn’t going to know they can destroy buildings on their first load in on the game. So the spawn was moved to a place that they had a clear direct route to the first objective but still close to the building so there’s a chance that it will be destroyed. With the implementation of the AI buddy there was a chance that the player would see them destroy it too.

Exciting moments

In terms of adding big moments and more excitement, in the end it wasn’t deemed as necessary as long as the tutorial is in a good state. This was very much moved to the backlog as there were more pressing matters in the project. However there were plans to polish this more which included more life and moving parts, such as drop pods falling overhead, enemy AI having a much better entrance and dropping in from the sky rather then just ‘being there’.

AI Partner

We didn’t have much functionality on the project regarding the AI partner, as essentially we wanted the partner as a tool to help them learn so his movements on the map were important. The AI teammate usually follow the player and in this case it was no different - so the implementation wasn’t reflective of the design document and was to be added at a later time. Essentially the plan for the AI was to go ahead of the player and lead the way and feel much more alive. The partner was to not necessary take control, the pace would still be decided by the player. But if players were ever lost for example, the plan was to have the AI locate near to the next objective.

© [2025] Wargaming.net. All rights reserved.

Snow map

The snow map was the first map to be released after the initial Early access launch. Due to the sunset of the game, it actually didn’t get an official name but was released to the remaining players.

Process

I was part of the creation process of this map from the very start. A summary of the workflow looked a little like this:

1. Create initial documentation, detailing the purpose of the map (Unique map mechanics, how its different to other maps in the map pool etc).

2. Gather references and create high-level top-down for the pitch to the leadership team of the project

3. Present the map to leadership

4. Depending on how step 3 went, either amend the pitch from the given feedback or proceed

5. Discuss and finalise Top down with other LD’s

6. As they were large maps (2.5km x 2.5km), responsibility was usually shared between 2-3 LDs, depending on availability.

7. Create the initial blockout, big shapes, and general flow of the map.

8. Test

9. Iterate, add more detail and repeat step 7 until the blockout was finalised.

10. Environment Art support phase

This was an extraction-based shooter, so we aimed for 6 extraction points that were equally apart. Each extraction point would be a POI in itself. For this map, before the creation process begun, we had feedback from players regarding the other maps and relied on this to make gameplay improvements for the level. The general feedback was that players got lost easily and the areas looked quite similar.

With the above in mind, we tried to think about how each POI would stand out on the map and ensure that you were always able to see another POI wherever you are on the map. I came up with the idea of having a large central POI which stood out amongst the rest, and acted as a waypoint wherever you were on the map.

A traintrack was also implemented in helping players reach other POI’s quicker. This also had the second purpose of guiding players to each POI - follow the railway and you would be guided to near another POI.

Originally, at the beginning, it was a busy period so only 2 LDs (including myself) were working on this whilst handling other responsibilities. We more or less split the map into two and created the first iteration of this. Eventually, as other LD’s became free and other tasks needed doing, the areas were separated further for more detailing. Towards the end I was mainly responsible for the Nuclear waste POI and the Central town POI as well as the traversal areas between.

See images below for work on my areas:

© [2025] Wargaming.net. All rights reserved.