Since our last DEVBLOG from April, our primary focus went into refactoring our engine codebase. After over a year of tweaking and patching the engine, lots of things have been scrapped or redone which ultimately led to unused and obsolete code, or previously implemented features that could use more polish and optimization.

This is why we decided to move from our “Client” codebase, to a new and shiny one that we named “Core”.

There has been no consequence as a result of this change, and this is what this article will primarily be about. In our longest DEVBLOG as of yet, we’ll go through a lot of technical changes and improvements, what they mean for us, the team behind the project, and for you the future players. As usual, we will talk about plenty of other changes, whether it be arsenal replacements, interface redesigns, or visual improvements.


On the development side of things, Core allows us to better manage our workflow as we can easily pipeline all of the in-progress assets in a confined space, isolated from the rest of the base files.

The first step to this change was to completely redo the filesystem structure: Every single element and file from the game has been re-organized and tidied up in a way that makes sense. The integrity of the game’s code has been organized, redone and polished. All of the different modules got tidied up in a way that makes sense, which allows us to work more efficiently instead of doing things on the get-go. Taking the time and effort to keep it “simple” and orderly might sound like a waste of time for most, when in reality this attention to detail and scope only helps and accelerates development in the long run.

The whole engine refactoring also helped to pinpoint some issues we had and work on some of them more efficiently. For example, independent Weapon Field of View was causing issues. Some in-game effects such as muzzle flashes or lasers, were not displayed correctly; they were shown relative to the World’s FOV rather than the Weapon’s, which resulted in these effects being offset. This only got worse as the world-to-weapon FOV difference increased. Now, this example might not be the end of the world for some people, and for crying out loud, a-very-popular-game-that-released-in-late-2021 has this very problem to this day. But as we commit to release the game in the best state it can be, having a pristine codebase helps tremendously to fix these kinds of errors, and to work as efficiently as we possibly can.

Another big issue that has been fixed with Core is related to the menu system. We will go through menus and how they really work further down this article, but we discovered a severe memory leak issue caused by the menus themselves. Due to the gargantuan changes that have been made to the UI, we had to figure out a solution quite early on. No less than 12 months back, the old codebase has already received a temporary fix to reduce the frequency of these memory leaks. However, we have finally found a true, permanent fix to the issue, alongside the development of Core. Again, having a cleaner codebase allowed us to easily go through this issue again in order to find a permanent solution.

Now, all of these changes are things that don’t ultimately matter for you, the future players. But as Core evolves, so do the features that are actually relevant inside the game, and here’s a peek of what it has to offer so far.



As explained in our very first DEVBLOG, IW4 (aka the MW2 engine) is a 32-bit application, which means that it can only allocate and use 4GB of RAM. This is why a lot of the work goes into optimizing everything the best we can, to minimize the memory usage and “keep the engine cool” at all times, which results in a smoother and much more stable experience. This is done in a lot of different ways:

  • Our Dynamic Attachments system, dubbed “DYNAT”, has received a massive overhaul with Core.
    ⠀⠀- You can find more details about the fundamentals of DYNAT in our very first DEVBLOG, but there’s more in this article!
  • Minimizing assets usage by removing every unused asset, which also helps with the game’s size.
    ⠀⠀- Call of Duty games are known for having leftovers from previous games, intentional or not.
  • Dynamically loading & unloading components, to avoid unnecessarily re-allocating things that are already in the memory pool.
    ⠀⠀- Doing so reduces memory stress and improves stability.
  • Texture Streaming: In the same fashion, this allows the game to only use textures that are currently necessary and free them over time.
    ⠀⠀– More in-depth explanation below.

Our Dynamic Attachments system has been further improved, in a way that allows much faster and efficient loading, as well as adding more parameters for us to tweak depending on the attachments used.

When preparing the Gun Game gameplay that we revealed a few months ago, we noticed stutters during “promotions” due to the extreme frequency at which weapons could be generated back to back. This was due to the fact that the attachments were handled on a per-weapon basis: A weapon would have its own “base” entry, and its very own catalog of attachments with all the changes they provide, such as stats, extra models or animation changes. In the third and new establishment of DYNAT, all attachments are now shared between all weapons, which lowers the amount of attachment entries even more, thus drastically shortening the time it takes to build your weapon. This also helps with stats consistency: Now that all the attachments are shared, we don’t have to worry about them being inconsistent from one weapon to another. A change made to an attachment will apply globally, to all weapons that can use said attachment.

Another improvement made to DYNAT has to do with the level of complexity it can offer. It is this change that allowed us to make much more advanced attachments, such as Explosive Tips on the Crossbow; What was doomed to be a throwing-knife-launcher from a technical standpoint now has proper explosive arrows that sticks to walls and players, with a delayed explosion (and its ill-famed beeping) after impact, and can visually be changed from the eyes of players with the proper perk… and this is all done through a single attachment rather than a whole new weapon which is what we’d previously have to resort to.


The refactoring of the codebase also brought forth a complete re-work of the controller code. On release, the game will support Xbox 360 and Xbox One controllers, as well as DualShock 4 and DualSense models. All of these devices will be supported natively without the use of third party programs. Bluetooth connectivity is of course supported.

Talking about PlayStation controllers, we’ve taken advantage of their light bar; It will now glow according to your main menu color scheme, and will fade from green to red depending of your health when in-game.

The Aim Assist code has received an overhaul too, and has been redone in a way that makes it feel more responsive and natural, as well as being able to control settings per individual weapon. This is particularly useful from a balance perspective as it allows us to tweak certain weapons more in-depth. Most tweaks however, are based on the weapon’s category rather than the weapon itself, so Aim Assist won’t be disorienting from one weapon to another. Still, being able to make very minor adjustments for weapon balancing is a big step in the right direction.

Another big feature of controller support is menu navigation. No less than 900 lines of engine code has been written from scratch for UI flow alone! Said code ranges from actual input control, to UI element patches that absolutely did not support controllers in any shape of form: For example, “Feeders” – which could be described as scrollable lists – can now be navigated with a controller only.

As a minor side note: If you’re the type of person to have both an Xbox and PlayStation controller set up on your computer, both turned on at the same time, the Xbox model will take priority. This is not a biased choice, it’s just that the XInput API will be called first in the game’s code!

The reason we went diving into controller support code again was to ensure that the game is as easy and straightforward as possible for controller players. Since sm² is a PC game only, it’s only right to make it friendly to the controller users who might be “too afraid” to cross the gap – especially for DualShock and DualSense that can be notoriously painful to setup, even on more modern games. Ultimately, the objective is to be able to start the game, grab your favorite controller, and be able to use it as your sole source of input from start to finish without having to deal with anything even remotely technical.


Another roadblock we (almost) hit has to do with texture usage. Compared to the original Modern Warfare 2 (2009), sm² uses far more textures, most being at a higher resolution too. Shocker, I know.

To get the lingo out of the way, here’s a quick brief on some technical terms to avoid confusion later on:

  • Images: They’re the actual texture files, or what’s commonly called “textures”.
  • Materials: They contain all the information necessary to use the images correctly, such as how they need to be displayed: sorting methods, the rendering technique it needs to use, etc… Anything and everything that uses an image in the game has a material, whether it be a 2D icon, a weapon or an explosion. The last two can use multiple materials as well.
  • Zones: They’re essentially big chunks of data that can contain all types of assets, materials included. They are also called “fastfiles”, hence the .ff file extension.

The way the original game operates, albeit rustic, is quite simple:

  • Every image is loaded on startup, in a way that ensures the game won’t miss anything later on. They’re all saved in the game’s memory.
  • When the game starts loading zones that contains materials, it’ll be able to fetch the texture it needs from the images pool, which contains everything.

The issue here lies in the fact that every texture is always loaded, at all times, which is very problematic in our case. Even after trimming our files and getting rid of as many useless textures as possible, the overall memory usage skyrockets even before the game has fully started, not to mention possible crashes due to simply running out of memory. Just as a reminder, IW4 (which is MW2’s engine) can only allocate 4GB of RAM, as it is a 32bit application.

This is why we worked on streaming the textures over time instead of loading all of them at once. Basically, texture streaming functions the exact opposite way as the original game.

  • When the game starts loading zones that contains materials, the game pre-loads the material to know which images it will eventually need.
  • Once the game needs to render an image on-screen from a material that’s already been loaded, it fetches it so it can be shown properly. When an image stops being used, it will be freed from memory, but the material remains in case the game needs to reuse it later, for example when a weapon stops being used during a match but might be used again at any moment.
  • When a zone is unloaded because it isn’t used anymore (e.g. a map’s zone after a match has ended), so are the materials associated with it. No need to keep materials from a map that’s not in play anymore.

Not only does this help for memory management and performance overall, but it also helps us on a development standpoint. Thanks to texture streaming, we can still run the game with missing images and add them on-the-fly, and the game will load them once they’re found. It allows us to directly monitor the memory impact of certain images and further optimize and improve them.


It wouldn’t be appropriate to keep some of the annoying phenomenons that the engine comes up with, and here’s one that most PC players encountered at some point, especially those running with high FPS: The stuttery stairs collision.

Basically, there’s two ways to handle stairs in videogames: Either with a “ramp-like” collision, or to let the game’s engine handle the climbing movement, the latter being favored in the original Modern Warfare 2 in general. There are engine functions to handle that kind of case already, which allows the player to “go over” a very small geometry-made obstacle, like a curb or a stair’s step. If such functions did not exist, the player would get stuck at anything that’s even a unit higher than the surface they’re currently on.

Now, it’s safe to say that most stairs are composed of two things:

  • The flat, horizontal area where the player actually steps on. It’s the elevation between these surfaces that make functional stairs.
  • The vertical part, that we consider on a technical level as a wall (this will be important later).

Like all past COD games, this kind of behavior is tied to the client’s framerate. That means that the higher your framerate is, the more time it gives to the game to catch up on the state/flag of the surface you’re walking on. You can tell where this is going, so guess what happens? Well… nothing, if you’re running the game on a console, a decade old computer, or with a 60 FPS cap. But with a higher framerate, there’s the possibility that the game will catch you clipping-through or walking on a surface flagged as “non-walkable”, which will ignore all inputted movement for that frame. This will either make you bounce up due to the upwards, diagonal momentum if you’re climbing the stairs, or completely stop you if you’re going downstairs.

This is why this issue stayed under the radar for so long, until recently when people started playing on machines that more-than-quadruples the game’s requirements. The higher your framerate, the more blatant the issue is; in fact, using the “timescale” command to slow down time will make it even worse.


Another smaller issue that the original Modern Warfare 2 had has to do with how akimbo weapons worked. When it comes to dual wield weapons, Treyarch and Infinity Ward had two very different approaches to the problem. While Treyarch opted for a way to completely distinguish the left and right weapons (which sounds the most logical), Infinity Ward had a more “stitched out” but simpler approach: Technically, akimbos are one weapon, but with a duplicate ammo pool and two different “firing methods”, to lay it down very simply. In MW2’s case, when a weapon was flagged as Dual Wield, the entire hands and weapon models were duplicated, and were assigned left and right animations. That means akimbo-able weapons had three sets of animations: Standard, Left and Right.


– Billy, 2022

But with this comes a bigger issue on the game engine side of things; If something that looks like two weapons is actually just one, it means that the status of the weapon depends on one of the two guns, right? And yeah, that’s exactly the case.

Weapons in the game rely on something we commonly call “weapon states”, which indicates to the engine what the weapon is currently doing for that frame. Weapon states can describe different things, is the weapon currently firing? Or is it locked out from firing because the player is sprinting or reloading? Is the weapon currently being inspected? All these questions can be answered by the current weapon state, which returns a certain value depending on one or more conditions.

The one issue we particularly had was magazine ammo, especially when it was empty. Indeed, when the weapon is dry, a different set of animations is supposed to play, that’s not a surprise to anyone. But because of what we described above, the weapon state that involves this behavior can be invalid in the exact situation where your right weapon is empty, but the left weapon still has ammo. Since the right weapon is technically considered “the actual weapon”, its weapon state is authoritative on what the left weapon is supposed to do, which resulted in the left weapon using the same set of animations as the right one, because it was incorrectly flagged as empty.

This is not the case on all the animations though, as reloading was kind of patched out in the original game – probably because it would have been painfully obvious something was wrong. But for example, pulling out and putting away weapon animations remained wrong, which we have taken the time to iron out.


This is not an “engine quirk” per se, but people who play older COD games on PC know the pain of starting them for the first time: With the weird 640×480 or 1024×768 resolution in fullscreen, stretched to infinity and beyond. Well, this is no more! The default display settings now is your actual screen resolution, in a Windowed Borderless configuration. Of course, Fullscreen and Windowed modes are still available in the options, and Windowed Borderless will ALWAYS fill your entire screen, since it uses your native resolution: No more messing around with files to get your borderless game right!


It’s that time again! A few weapon switcheroos and tweaks have been made yet again to the weapons roster; As much as we try to not drift away from our initial weapons list, some changes constantly need to be made, for multiple reasons. But don’t worry, the changes (hopefully) aren’t as brutal as it was in the last DEVBLOG! Here’s the list of the changes with an explaination as to why they’ve been made:

  • The Modern Warfare Remastered MP5 has been switched back the the Modern Warfare 3 version. The MW3 variant was the one we original had (c.f. our first Gameplay Reveal) but switched to a better-looking one shortly after. However, it was better-looking on paper, but not in-game! After multiple attempts of polishing to give the gun justice, we decided to roll back to the MW3 version, which we know works flawlessly.
  • The Modern Warfare 2 Campaign Remastered M14 is now the Modern Warfare 3 MK14. Ditto about this one: What we thought would be an upgrade ended up being more troublesome than we initially thought. It turns out the the MW2:CR version of that gun has baked-in camos – It’s not a difficult thing to fix at all, but this combined to the weird proportions of the weapon and the mediocre animations, we decided to fall back to a more reliable version of the same weapon. We also added the Sniper Scope to the MW3 MK14 as an attachment, which was only present in the Campaign.
  • The Black Ops 2 MK48 has been replaced by the Modern Warfare 2 Campaign Remastered L86 LSW. As far as LMGs go, we felt like a bit more variety was long due. We’re always trying to get a roster of weapons that all feel at home, yet different. The MK48 – while being a good weapon overall – is as “basic LMG” as it gets. Even though the L86 might not be the most popular machine gun you could think of, it definitely has its own look and feeling, which ultimately helps against monotony; Having a vast array of different choices is always good to combat an “all weapons feel the same” scenario, which is very easy to fall into.
  • The Black Ops 3 Kuda has been replaced by the Black Ops 2 Peacekeeper. We think this is a change that everyone will be on board with. The Peacekeeper is an all-star weapon that made a big name for itself, and probably one of the most iconic weapons of the entire franchise. However, Black Ops 2 weapons can be a bit painful to port due to “holes” in the models, that are normally patched up in-engine. But these holes are a thing of the past, so we can welcome this beauty to the SMG list. The reason the Kuda was picked as a replacement was because the SMG list was already pretty stuffed, so we didn’t feel like adding another one, and we saw the Kuda as a “modernized” UMP45, which we already have.
  • The Black Ops 3 PPSH now has a drum mag by default. This weapon uses a curved magazine as default, but after thinking about it we realized that the drum magazine was represented as part of the whole gun’s design more often than not. It does not change anything on a gameplay perspective, it’s just that the default magazine model has been swapped with the one that was used as Extended Magazines by BO3. Needless to say that the animations got updated to fit the new magazine as well. Another small change worth mentioning is the removal of the red tritium sight, as we judged that it was not fitting the “antique” look of the weapon at all.
  • The Black Ops 3 Drakon has been replaced by the Black Ops 4 Vendetta. The Drakon has been following us since the start, however we didn’t feel like we were able to bring the materials up to the scratch which is especially difficult in such an old game, so we decided to try replace it with something new and arguably a bit obscure… and this is how we landed on the Vendetta. Fairly unknown by most as it’s a BO4 DLC Weapon, but definitely a PTSD-inducing weapon for veteran BO4 players. Not to worry though, the Vendetta will not be as overpowered as it originally was, but will still remain a good choice for long-range plays, as all semi-autos should be.
  • The Black Ops 3 Galil got its Tritium sight removed. The initial thought about picking the BO3 Galil instead of the BO1 one was because of the newer game’s overall quality, although everybody – including us – remembers and considers the Galil as a BO1 weapon. The weapons themselves look the same, except for one thing: The BO3 Galil had a green glowing sight that the original gun didn’t have. This has been removed in order to keep the “upgraded” version of the Galil as close as its original version as possible.
  • The COD: Online Desert Eagle has been switched to the Modern Warfare 2 Campaign Remastered version. Right after our first gameplay reveal last year, we quickly noticed that the COD: Online Desert Eagle resulted in a very polarizing opinion from the community. While a good portion of people thought it was an interesting choice, the majority was a bit thrown off by its unusual design. This is why we decided to go back to basics. Our first move was to try the MWR take on the weapon, but the reflections caused by the chrome finish was insanely difficult to get right: It ended up looking like someone found it in the mud, and even after some attempts at a cleaner retexturing job, we still weren’t satisfied. At the end of the day, we went back to the classic Two-Tone look from MW2:CR.
  • The COD: Online G37H has been changed to the World War II Gewehr 43. One thing that can be attributed to COD: Online is its overall “exotic” weapon designs, and even though we looked fondly to it, the G37H looked really weird and felt very clunky to use. The weapon looked awfully thin (if that even makes sense) and really did not feel great once in hands. However, since a normal G36-platform weapon wouldn’t fit in the Tactical Rifles category, we decided to look away and went to Gewehr 43 instead. World at War players probably have a good memory of that weapon, although this is not the version we used due to the outdated model and textures, so we picked the World War II version instead, which feels equally as good and viable.
  • The COD: Online Type-95 has been swapped with its Modern Warfare 3 counterpart. Pretty much like the G37H, COD: Online weapons can be very hit-or-miss in terms of design. Shortly after being implemented, we quickly realized how poor the texturing job was, and how the iron sights are otherworldly bad. Moreover, we thought that the MW3 version of the gun was a much more logical and nostalgic choice.
  • The COD: Online L115A3 now uses Ghosts animations and models. Well, to put it simply… while we love the look of the L115A3, the COD: Online version is using the OG Intervention’s animations; They aren’t bad per se, but one can see how they weren’t fitting the weapon. We even fixed the bolt pull animation which was incorrect: the weapon is supposed to be a straight-pull bolt-action rifle, while the Intervention that gave its animations to the weapon was not. But despite that, we still weren’t fond of using this animation set. On the other side, the Ghosts L115A3, which looks identical and has much better animations, suffers heavily from low-polygon models due to the Sub-division tech that the game was using (as explained in DEVBLOG 2). So, to make this short, we took the best of both worlds, and the Online L115A3 now became the Ghosts version, with a few fixes applied to the original COD:Online model and materials that were present in the original game.
  • The Black Ops Stakeout has been replaced by the Black Ops 4 Zombies Trench Gun. Our current lineup of shotguns needed some refreshing, and the Stakeout caught our attention again. We thought about replacing it with something of the same style, but more memorable; That’s when the Trench Gun came in mind. The reasoning behind the BO4 version instead of the World at War one is the same as to why we picked the Gewehr from WWII: Much better looking weapon and animations overall. Note that the “pump action” animation has been remade to be more in line to the World at War one, in a way to pay homage to its roots.
  • The Advanced Warfare M1 Garand has been swapped with its Infinite Warfare counterpart. The only reason for this change is the more modern look of the Infinite Warfare version. While it might not be as “realistic” as the old one, we felt like it was much better looking in general and has a cleaner, more open iron sight.

Another part of the weapons job now is reworking, creating and replacing some of their animations. There are four notable changes and in-progress work worth mentionning:

  • Better sprint animations on some weapons: An issue we had with some weapons – especially MW:R and MW2:CR ones – were very stiff and unnatural sprint animations, that either did not reflect the “feel” of their original version very well, or were straight-up bad looking. In the case of remastered weapons, we tried our best to get their original sprinting animations. As for the poorly animated ones, we went with a custom sprint, based on Infinite Warfare, which looks very smooth and natural. The changes include, but are not limited to:
    • The MW:R M40A3, the MW2:CR Barrett.50, and the MW2:CR Intervention now use their original sprinting animations
    • The AW MP40, the MW2:CR AUG, the Ghosts L115A3, and more use custom sprinting animations.
  • Weapon movement animations have also been changed. Always in the objective of modernizing the game overall, work has been put in order to replace all the different movement animations by something a bit more sophisticated and pleasing to the eyes.

    We achieved that through the use of Additive animations, which can essentially be described as an animation overlay that effects the positioning of the weapon. This is what the game uses for ADS: Aiming in and out is just additive animations that places the weapon in a new position. But, even if it was “technically” in the game, these new animations still required quite a good amount of engine modification. Here’s a list of the changes that have been made:
    • The old viewmodel “bobbing” when walking has been replaced with actual animations instead.
    • Jumping, landing, and going prone has proper viewmodel animations.
    • Sprinting while in the air will slow down the sprint animation until you’re back on your feet.
    • Crawling now has its very own animation as well, instead of just disappearing like in the original game.
  • Support for unique animations when reloading empty rechamber-based weapons has been added: This was difficult to read wasn’t it? Well, for the history books, this feature goes back to the Call of Duty 4 Alpha, but has never seen the light of day until several games later. When reloading an empty weapon that used rechambers – like a pump-action shotgun or bolt-action rifle – the game would play a different reload animation for the first bullet or shell, and would then continue with its usual reloading animation. This is a feature we added back, although the SPAS-12 is the only weapon to take advantage of it as of today. Regardless, having this functionality restored will open up possibilities for the rest of the weapons in the future.
  • Finally, we worked on a minor yet cool weapon detail: When the weapon is empty, the sprinting animations are also affected, which wasn’t the case in the original Modern Warfare 2: Open bolts, pushed back slides, and empty chambers are now visible during sprints.

We have started to rework the brass eject effects. The original game’s effects are due a good makeover. Some of you might remember the 2D-esque looking casings and shells that were ejected from your weapon, and those of you even more attentive might also remember how a new casing model just spawned on the floor, out of nowhere, when the casing finally “reached” the ground. This is not the case (no pun intended) anymore, as we replaced these clunky looking effects by physics-based ones: You will now be able to see proper models ejecting from the weapon, as well as seeing them bounce on the floor when they touch the ground… if looking at the floor is your thing. In all seriousness though, it’s these little details that go a long way to enhancing the look of the game when all put together, and while it might sound nitpicky to some, we saw it as a necessary change.

The weapon categories have been simplified, as we got rid of the “Marksman Rifles” category (not the weapons!). It was used by semi-automatic weapons that are considered as the “weaker, spam-friendly sniper rifles” such as the SVU or Dragunov, as well as very high damage Tactical rifles. For the sake of simplicity, weapons from this category have been dispatched back to Tactical and Snipers rifles categories accordingly.


Another thing that went through an entire overhaul is the interface, both in and out of a match. The UI is something we’re constantly exploring; The overall style of the game plays a huge part in its identity, and we want to make sure to provide something that feels “at home” visually and functionally, while being unique in its own way.


One struggle we had during the making of the User Interface as a whole was the support of different aspect ratios. While Ultrawide (21:9 and 32:9) resolutions never were an issue since they give more real-estate, 16:10 and 4:3 can become problematic when trying to fit everything in a more confined and tighter space.

What’s so difficult about this problem is the technology used by the UI: The game uses what we call “.menu files”, a practically prehistoric tech that was first used with Quake III, whose engine is what later became the “Call of Duty engine”. Believe it or not, but the whole science behind this haven’t changed at all since then, to the point that Quake III documentation about the subject is 95% applicable to Call of Duty games up to Modern Warfare 3, after which it was (finally) thrown into oblivion for more modern solutions. And, in case you need a reminder, Quake III came out more than 20 years ago, in 1999

With that in mind, it becomes pretty obvious how this can become problematic for a game in this day and age. Earlier during the development of the project, we even tried to ditch .menu-based UI by implementing our own custom-made UI engine, which started good but ended up being a much bigger challenge than we could ever have expected. So we’re going to work with whatever the game gives us in the meantime.

Back to the aspect ratio problem, the way the original Modern Warfare 2 game handled it was to basically duplicate UI elements (sometimes quadruple, because splitscreen), and show them based on what the game considered a “widescreen”, purely by reading the resolution it ran on. Now, the idea of basically having two versions of the same UI is nuts; this is what we ran with for a while, but adapting the UI and scaling based on the resolution is not a bad idea on paper.

Not so long ago while working on Core, we started experimenting on automatic HUD scaling based on the game’s aspect ratio, in order to force the UI viewport to a standard 16:9, atleast for the out-of-game menus which are the most problematic in terms of usability. It still requires more work as it creates cursor pointer anomalies, but ultimately this would allow us to not make the same error that Modern Warfare 2 did and duplicate everything, as well as to not constraint ourselves on a creative standpoint for the sake of 4:3 monitor users, who will then benefit from a complete and fresh UI compared to a minimalistic and objectively ugly one.


As far as in-game UI goes, most of the work has been put towards the health bar and the weapons widget in order to enhance their usability based on community feedback. But we’ve made a few other changes worth noting too:


The idea behind the split health bar – other than for style – is to give a better idea of your current health by separating them into “zones”.

That way, you can instinctively count the number of “zones” you have left, instead of making an approximate guess between what health you have left relative to the total length of the health bar.

Similarly to the latest COD games, a small animation has been added upon receiving damage, to provide a subtle visual queue.


The weapons widget has been redesigned to offer better visibility, by increasing the ammo counters’ font size and weight, as well as changing its placement.

We also re-styled how the attachments are displayed, so they’re a bit less intrusive while giving the information when you need it, whether it be switching or picking up a weapon.


The map intro text that was first seen in our Gun Game gameplay reveal has finally reached its final form!

It is now much less intrusive and better placed in the bottom-left corner of the screen, and has some sweet sweet animations. It also features some subtle sound effects to go along with it.


Who doesn’t love a cool killcam? While we’re still working out the details, we thought about redesigning them from the ground up, and clean them up a bit.

A massive improvement to the feeling of final killcams are sounds: Similarly to the original Black Ops, some of the sound effects will be distorted during the slow-motion part. It gives much more impact and power to the effect and has a very satisfying feeling.


Though the default classes are never really looked at unless you have to, we still decided to give them justice and saw the opportunity to do something very unique with them.

Default classes now have this exclusive layout that features them under their best light. Custom classes also received a bit of an overhaul, which will be showcased further down.


Core was a good occasion to inaugurate a brand new Interface overhaul, even for everything you see outside of your matches.

Like we previously mentioned, UI as a whole is a huge deal when it comes to identity, so we want to make sure to get this right. Even though most of the new interface is still under construction as we speak, we still wanted to show the new Create-a-Class layout.

A batch of new icons have been made for equipment, attachments, melee weapons and perks. We also tried our best to make one of the most important menus in the game to be as clear and straightforward as possible, while having its very own style.

Since most of the new interface is still to be done and polished, we will save it for another occasion, when we will able to showcase it in all its glory!


The same things about uniqueness can be said about loading screens! Without realizing, we spend a significant amount of time looking at them.

Having these videos as loading screens has always been in our DNA. However, the loading screen themselves were due a redesign, to go with the rest of the interface that’s in preparation. We removed the black bars and opted for a cleaner aesthetic. We also restyled the text to be more in-line with the rest of the UI and the loading bar will be dependent on your color scheme.

Stay up to date with sm² on Discord, Twitter, and YouTube!