How Naming Conventions Can Boost Your Game Dev Workflow!

‍

If you’ve ever had to work on a big game project, either as an indie or as part of a larger studio team, you’ve probably noticed that having a structured and consistent workflow is essential for keeping everything on track.

And one of the most underrated but crucial parts of that process? Naming conventions.

In the fast-paced world of game development, where assets, code and builds pile up quickly, maintaining clarity is key. Without a clear naming system, things can spiral into chaos fast—just imagine trying to find the “final_version_v2_actual-final_last-prod” file among a folder of dozens of versions!

That’s where good naming conventions come in, providing a simple yet powerful way to keep your files, commits and builds organised and easy to automate.

Indeed, over the years, game developers have realized that these conventions do much more than just make things neat. They can become part of your version control strategy, improving workflows for both individual projects and team collaboration. And when tied into CI/CD pipelines, they can help automate repetitive tasks like builds, testing, or deployments, speeding up your workflow and reducing human error.

In this article, we’ll dive into how setting up strong naming conventions for your files, assets, and commits can supercharge your game dev workflow—from versioning to automation, to keeping your entire team on the same page.

‍

What are naming conventions?

The basics

At its core, a naming convention is simply a set of rules for how to name things—whether that’s files, folders, assets, code branches, or even entire versions of your game. Think of it like a labelling system that keeps everything neat, predictable, and, most importantly, easy to navigate. Instead of giving things random names on the fly, you create a standardised approach that everyone on your team can follow.

For example, instead of saving a texture file as "blue_character_v4.png," you might decide on something like "hero_sprint_001_diffuse.png." Now, anyone looking at the file can immediately tell it’s a diffuse texture for the sprinting animation of the main hero character. Plus, the number system allows room for iterations without confusion.

Why it matters for games

In game development, where assets can range from textures and models to audio files and scripts, the sheer volume of content grows rapidly. Without a solid naming system, tracking down specific assets—especially as they go through iterations—can quickly become a frustrating, time-consuming task.

And it’s not just about convenience. Games are complex, multi-disciplinary projects involving designers, programmers and artists, all collaborating at once. A chaotic file system can lead to accidental overwrites, lost files, or duplicated work, which can derail progress and slow down the entire development process.

A well-established naming convention ensures that everyone can find the right assets at the right time, reduces miscommunication between departments, and keeps the project moving forward smoothly.

Some naming conventions for better asset management

Of course, naming conventions can vary a lot from team to team, and the important thing is to find one that everyone on your team agrees with and finds logical. (No need to stick to some “supposedly perfect rules” if no one in your studio understands how it works!)

‍

That being said, here are still some examples of how you can name your game assets to manage them more easily:

• Adding asset type prefixes: To help identify what each file is at a glance, you can add specific prefixes for each type (e.g. TEX_ for textures, S_ for sounds, MAT_ for materials, M_ for meshes…). This can be particularly useful if your engine uses the same extension for types of assets, like Godot which basically saves any kind of resource as a .tres or a .res file.
  
  Sometimes, for images and textures, you can also add a suffix to make it clear how this texture should be used. For example: _C for the colour map, _N for the normal map, _R for the roughness map, _MT for the metallic map…
  
  
• Tagging characters or locations: You can use extra tags or prefixes to define what character, environment or object the asset belongs to (e.g.: CH-Mage-TEX_Staff_003_C.jpg, ENV-Village-S_Ambiance_001.mp3…).
  
  
• Adding version numbers: Some devs include a version number in their asset file names - while making sure it uses enough digits to avoid conflicts later on or weird reordering in lists. This can prevent the common mistake of overwriting the wrong version, and it’s a nice first step on the road of versioning!
  
  (Typically, something like “M_Skeleton_001.fbx” will be easy to iterate on as “M_Skeleton_002.fbx”, or “M_Skeleton_341.fbx” in the future.)

That being said… maintaining this version system can be a pain, and knowing exactly what different modifications the file went through along the versions isn’t always possible. So using naming conventions with numbers for versioning only goes so far. A way better alternative to these incremental numbers is to use a dedicated tool: a VCS, just like Diversion!

This way, you’ll get a full history of the updates for every file, you’ll be able to easily go back to a previous version if need be (to check what it would like or to revert some problematic changes), and you’ll even get to store some metadata along with the changes, to make it more explicit what you did for a specific version :)

• Optionally using extra suffixes: Sometimes, it can be nice to add a sort of extra short description at the end. For example, for character animations or actions, you’ll most likely want to suffix your file with _idle, _run or _attack to clearly identify which animation you’re talking about.

Again, these are just some basic ideas - feel free to adapt those to your own pipeline and discuss with your team to see which ones make the most sense for your specific project :)

‍

Improving your workflow thanks to good naming!

Now - as we said before, a solid naming convention isn’t just for tidying up—it’s an essential part of creating a workflow that scales and adapts as your game grows. Here’s how thoughtful naming conventions can make a big difference in your day-to-day development.

Semantic versioning, aka “How to update your game’s version properly”

Ever released a patch only to find a bugfix introduced a whole new set of problems? It happens way too often!

But with semantic versioning, you can keep things organised and easily track what changes have been made. The system typically follows the format MAJOR.MINOR.PATCH - think of it as a way to communicate the impact of your changes at a glance.

• Major updates change core elements of the game or break backward compatibility (e.g. upgrading your game engine, or completely refactoring a big system).
• Minor updates introduce new features or significant changes but don’t break the game’s existing functionality.
• Patch updates fix bugs or add small, backward-compatible improvements.

This simple naming system gives you (and your players) a clear roadmap of how the game has evolved and can help automate processes like build creation and version tagging in your CI/CD pipeline.

Plus, during the early access or playtest phases of your game, it can be an easy way to sort the feedback you get from your players to know which bug reports or feature ideas apply to which version of the game :)

‍

Typical naming conventions for commits & branches

When you’re working with version control, especially on a team, good commit and branch naming conventions are a lifesaver. Instead of piling up commits like “fixes” or “updates,” having a set structure ensures everyone knows exactly what each commit or branch does. It’s once again about readability and predictability.

For commits, a popular convention is to prefix the message with the type of change, like:

• feat: for new features
• fix: for bug fixes
• refactor: for code restructuring without feature changes
• chore: for small maintenance tasks or dependencies

Then, you often indicate the topic of the commit in braces. For example, if you’ve just implemented a new feature for your hero’s levelling up system, you could prefix your commit with feat(hero) or feat(level-up).

For branches, the convention could include a short description or even a ticket number (if you’ve got an issue ticket tracker), such as:

• feat/inventory-system
• fix/bug-123

Of course, you could also reuse the same kind of prefixes as for the commits, and have some refactor/hero-powerups branch if you reworking the player’s bonuses system, or a chore/deploy branch if you’re preparing your build and export settings :)

Using clear, descriptive names means anyone on the team (or even future-you!) can easily understand what’s happening and what has happened in the repository, which further improves collaboration and helps prevent mistakes like merging untested code into production.

Integrating with CI/CD pipelines

Good naming practices also come in handy when you’re setting up continuous integration and deployment. With structured branch names and semantic versioning, your CI/CD pipeline can be set to trigger specific workflows—like automatically building and testing feature branches or deploying patches straight to QA.

For example, your pipeline could be configured to:

• Trigger automated builds for any branch starting with feat/
• Run full test suites only for commits with fix/
• Deploy to staging automatically when a new version tag following semantic versioning is pushed

This level of automation frees up developers to focus on more creative tasks while ensuring your project stays in a healthy state at all times.

By the way - at the moment, Diversion supports integration with some CI/CD tools that can help with automatic triggers and versioning hooks… but they’re planning on adding even more utilities for that in the future, with plugins and user-made automation scripts that could call webhooks and allow you to customise your CI/CD even further! So stay tuned for more Diversion automation power :)

Reducing human error through consistency

Let’s face it: no one’s perfect, and in the whirlwind of game development, it’s easy to make mistakes. (Besides, the video game industry has sadly been known for encouraging pretty stressful situations and crunches that often make wonders in terms of disorganisation and instability…)

But good naming conventions act like guardrails, helping reduce human error. When everyone follows the same structure, there’s less ambiguity, fewer miscommunications, and a higher chance you’ll catch potential issues early on. Whether it's making sure your branches are properly named or ensuring your assets are versioned correctly, consistency minimises the chances of something slipping through the cracks.

And it also makes team collaboration and communication easier, since your teammates will know what kind of asset you’re talking about when you say its name, and so who should be in charge of dealing with it.

In the end, good naming conventions contribute to a development environment that’s not only more efficient but also more resilient to errors, allowing you to focus on what matters most - building an awesome game!

‍

To go further

We’ve said it multiple times in this article: conventions should fit your team and your project, first and foremost. That being said, some game engines or tools have a few guidelines, or common practices, that you can draw inspiration from if you want :)

Typically:

• For Unity: The docs suggest some nice pointers to get you started over here, and there are also GitHub repos like this one where people suggest their own best practices for organising your Unity game projects.
• For Unreal Engine: The Epic team has published this little doc where they list the conventions that they themselves use for their demo projects.

For Godot: This time, the suggested conventions are mostly for scripting, as you can see in the official docs.

‍

Conclusion

To the non-specialist, naming conventions might seem like a small detail in the grand scheme of game development. But as your project grows, you’ll quickly realise that having a consistent and thoughtful approach to naming can be a game-changer for your workflow. From versioning your game updates to organising commits and branches, clear naming practices help keep things running smoothly. And when paired with automation in your CI/CD pipeline, they can save you valuable time and prevent costly errors.

In short, good naming conventions provide structure and clarity, making it easier for your team to collaborate, automate repetitive tasks, and stay focused on the creative side of development. By adopting these conventions early, you’re setting yourself up for a smoother, more efficient development process—one that can scale with your game as it grows.

So, whether you’re polishing that final build or pushing out quick bug fixes, remember that every name you choose contributes to a more reliable, and, ultimately, successful game dev workflow :)

‍