DEV Community: Diversion

The compounding effect of version control performance

Sasha Medvedovsky — Thu, 11 Sep 2025 14:18:20 +0000

By: Pablo Santos Luaces

As software developers we tend to focus on the latest, shiniest new feature and often take for granted the core value of our product.

I remember the surprise when visiting a customer and asking their team what they liked better about the product: every morning it syncs much faster than the previous version control. It wasn’t the latest change in the UI, the super advanced merge feature we just added. It was the speed. I took it for granted. I considered it something that of course was important but that has been there for years. And it was the real key thing.

And something often overlooked about speed is how it compounds and impacts productivity in ways that are initially not considered.

‍

Diversion performance boost

During the last few months the team at Diversion has dramatically improved the speed of the product. They swarmed together to respond to the requirements of much larger customers. When you have to handle millions and millions of files in the head of the repo, the rivets start to pop.

To some extent, these teams need some performance to just operate. But in Diversion they have not only matched but vastly outperformed the version control they are replacing. And this creates new opportunities.

‍

The compounding effect of speed

An improvement in the speed of your daily version control operations, sync or submit, for instance, makes you wait less.

Every operation that takes more than just a few seconds makes you switch context, go to X or Insta or whatever, then ruin your flow.

So, if an operation goes down from, let’s say, 30 seconds to 10, the impact is not only 20 seconds times the number of operations per day, it is much more. The threshold between less than 10 seconds and more than 20 provokes minutes of time wasted browsing the internet, going to Slack to chat while you wait, etc.

But there is more: when an operation is not painfully slow, it creates new opportunities that go beyond saving time and into real workflow changes.

‍

Fast branching changes the game

Take the branching example. One of the most used version control systems in the gaming industry can’t branch in a performant way as soon as the depots grow too large. Taking 5-20 minutes to create a branch makes it an event, something to be planned, considered, feared. It is not something you do lightly. And then entire workflows are shaped around that limitation (which is something very, very common in the gaming industry).

Now, suddenly your branching time goes from 5 minutes to 20 ms like it happens with Diversion. The naïve way to think about it is: ok, we create 1 branch a month, so we’re only saving 5 minutes a month, it is definitely not worth the change.

Obviously the impact is way different: suddenly the team can create as many branches as they want. If you want to work on a new ticket, you can go and create a branch for it, lightly, no planning, no approvals, because branches suddenly become an instrument of productivity, not a release event. You can use branches to develop tasks and they can be timely merged, but the review process will be driven by the branch (something Git users take for granted but many game teams do not because Git can’t handle the sizes of their binaries fluently).

Same can happen with release branches, experiment branches, ideas, etc. Fast branching opens up improvements that go beyond the current workflow.

‍

Art and code in a single repo erases artificial complexity

And branching is just one example, but the same happens with the ability to handle code and art, no matter the size, in the same repo. Do you simply accept the extra complexity of dealing with code in one repo and art in a second one because the system that manages code is not good with big assets, and the one that deals with large binaries doesn’t offer the features programmers demand?

‍

Wrapping up

Like a friend of mine always says for their data analytics platform: speed matters. It matters a lot. It does not just remove blockers, it creates whole new opportunities when you can suddenly perform operations that you accepted to be costly in almost no time.

‍

About the Author

Pablo Santos Luaces is the founder and former CTO of Plastic SCM, SemanticMerge, and Gmaster. An accomplished programmer specializing in version control and merge technologies, he now shares his insights on these topics through writing and speaking, including on his Medium page.

A step-by-step guide to versioning a Godot game project with Diversion

Mina Pêcheux — Tue, 19 Dec 2023 09:17:14 +0000

Whether you’re a long-time open-source game dev or an enthusiastic Godot newcomer, you probably know that getting used to a sound and robust workflow is an essential skill for any kind of software developer.

And, in particular, having a way of keeping track of your project’s progress is a really cool and often necessary thing to set up early on. Which is why, over the years, the game dev community has become more and more interested in version control for game projects.

In fact, in Godot, there are some built-in tools using one of the go-to VCS solutions, Git…

But, as we’ve discussed in several articles before, some of those “old timers” in the VCS worlds aren’t really the best fit for games, because those are complex multimedia projects. And so, as time went by, various alternative projects started to grow to offer new and more suited version control tools to game devs.

Among which: Diversion, a cloud-native VCS that is meant to enable game creators to work quickly, with nice real-time collaborative dev, and an easy-to-use interface.

So, in this tutorial, we’ll explore the basics of using Diversion to version a Godot project, from setting up an account to actually committing updated work, tracking your progress in the online web app, and even doing more advanced tasks like creating branches.

Exploring the Diversion version control tool

A quick note on Diversion’s pricing system

Like most of the cloud-based versioning tools, Diversion’s pricing works with tiers, and you can keep with the free one until you’ve reached the thresholds… which here, are actually pretty sweet!

Indeed, as shown on the pricing page, with a completely Free tier account, you can have 10 repositories, 100GB of storage and 10 collaborators - and you can use virtually all features of the tool:

After that, if you need to scale up, you can switch to the Team or the Enterprise tier, depending on your needs.

Note: Also, it’s important to remember that Diversion is still in beta. So, it’s already quite promising - and there’s even more coming! In particular, integrations with CI/CD solutions or Git are on their way, to make it even easier to integrate Diversion in your usual workflow.

Creating your account

Alright so - let’s say for now you want to explore the tool, and you’re fine with the (loose) limitations of the Free tier. Then, first things first, to get started using Diversion, you’ll need to create a new account :)

It’s actually very easy! All you need to do is go to Diversion’s website and, in the top-right corner, click on the Login button:

This will bring you to the login form, where you can also sign up for a new account by using the Sign up call-to-action at the bottom:

That’s where you’ll be able to enter your new Diversion account info (username, email, password) or choose to sign up using a Google account, and then you’ll simply need to confirm with the unique code sent to your email address:

And that’s it! At this point, you’ll have your Diversion account, and you’ll be auto-redirected to the welcome page with a step-by-step onboarding wizard (the following screenshot shows just the first step of this wizard):

This wizard walks you through the base steps for installing the Diversion command-line tool (dv), configuring it to use your new account, and using it to initialise or update a Diversion version control repository.

So, now that we have access to the tool, let’s see how to actually set it up on our computer and use it for our own projects…

A quick peek at the Diversion CLI tool

Before talking about mixing Diversion with Godot, we need to start by installing and preparing our Diversion CLI. To do this, we simply have to use the CURL download URL provided on the welcome page.

This depends a bit on your OS. You’ll find all the necessary details in the quickstarting guide - but typically, for my Mac, I can use the following:

curl -sL https://get.diversion.dev/unix | bash

Once it’s done, we can simply open a new terminal (or re-source the current one to take the changes into account), and we’ll have a brand new dv tool we can use to init or inspect a Diversion repo.

For example, to check that all went well, just call dv help - you should get a detailed list of all the available commands, with neat (and even coloured!) instructions that show you a lot of nice tricks for using this CLI tool:

You’ll notice that there are actually a good deal of commands you can play with to create, update, reset or share your repo contents.

By the way a nice thing is that you can use all of those in interactive mode by first typing dv in your console to enter a new Diversion CLI context, and then use those commands without the dv prefix at the beginning. Plus, this gives you really cool bonus helpers like a command menu, and autocomplete!

And if you’re a bit familiar with the famous Git VCS, you’ll also see that many of those commands are super similar. So, basically, if in doubt, you can usually start by “mimicking” your git [X] command with dv [X], and there is a good chance that it will work directly :)

Though, because Diversion is first-and-foremost a collab dev cloud-based version control tool, there’s also many additional utilities for working with other teammates, such as:

dv status -sync-only or dv status -wait: Compared to the simple git status command, Diversion lets you enforce the sync has happened if you want by using dv status -wait. This way, you’re sure that you’re seeing the latest changes in your repo at any moment!
dv invite: It allows you to invite a new collaborator to the repo by passing in their email. Note that you can also specify the level of access you want to give them by adding an additional <access> option:
- dv invite <email> –-access WRITE
- dv invite <email> –-access READ
- dv invite <email> –-access ADMIN
dv share: It shares your repo with one or more other Diversion usernames, either in read-only mode (default) or in read/write mode if you add the –-rw option at the end. The users are referenced by their usernames, and you can pass a list of space-separated usernames if you want: dv share <user1> <user2> –-rw.

Moreover, the dv login, dv logout and dv view are commands to directly sign in or out of your Diversion account, and to use the web interface instead of the CLI if you prefer to manage your repo.

Typically, if you want to login into your account from the CLI, you can just run dv login. Your browser will automatically open an OAuth authentication page and, assuming you’ve logged in your Diversion account earlier, you’ll directly be signed in, and you’ll be able to instantly come back to your shell.

Ok - now, with all this in mind, let’s see how to use the code>dv CLI to version a simple Godot project, and discover the Diversion web app.

Versioning a Godot game with Diversion

Preparing the Godot demo project

For this tutorial, I’m going to use Godot’s “Dodge the creeps” official demo project, which you can get for free on the official Github. It’s a basic 2D game where you control an avatar with the arrow keys and you have to avoid the enemies that are spawning randomly around you:

Note: Although the Github branch is marked as 3.5X, the project also works directly in Godot 4 :)

To get the project, you can download the whole repo as a zip, or clone it locally on your computer using Git; then, open your Godot app and, in the startup project browser, click the Scan option:

Then, go to your local copy of the dodge-the-creeps/ demo folder, and click Select Current Folder - this will auto-add the project to your Godot projects list, and you’ll be able to double-click on it to open it as usual:

Inside, you’ll find a simple 2D scene that looks like this - and that you can run to try out the demo game yourself :)

Initialising the Diversion repo

**_Important note: This part of the guide assumes you’ve logged into your Diversion account from the CLI, using the dv login command, as discussed before :)

Now that we have a Godot project to version, let’s see how to use Diversion for it.

To start up, we can just open a shell, go to this folder and run the dv init command. We need to pass in the path of the folder to create a repo for, so here it’s just our current folder (dv init .):

This will do several things:

It will create a new Diversion repo linked to this specific directory.
It will auto-add a .dvignore file in the folder, which is the equivalent of the .gitignore file for a Git-versioned project.
It will register this repository in your Diversion account to make it accessible from anywhere on the web app.

Note that the base contents .dvignore file are improved regularly by the Diversion team and now contains some goodies for Godot game devs (like the .godot/ folder that is auto-generated by any Godot 4 project, and contains some cache files that don’t require versioning). So although you can always edit it to fit your own specific architecture, it should usually be fine as-is for your game projects :)

So, now, let’s have a look at what files in our Godot demo project are ready for versioning by running the dv status command:

That’s nice!

You see that our Diversion versioning only takes into account the “real” assets in our project. Moreover, we can notice something at the very bottom of the screenshot: Diversion shows us a Sync complete message.

That’s because, as we said before, Diversion being a cloud-native tool, your repositories are always synced to the online version available via the web app…

Exploring the Diversion web app

To get a direct link to the online version of this repo, we’ll simply run the dv view command. This opens a new browser page in the Diversion app (as usual, you’ll need to be logged in to see it) that is dedicated to this specific project:

At the very top, we see the name of the repo and the branch we’re currently viewing - here it’s dodge-the-creeps, and main.

Then, below, we have a list of files corresponding to our current workspace that perfectly reflects the results from our last dv status command, and a list of the latest commits. You see that we can also commit files from this interface using the left sidebar.

Typically, let’s say that we want to add all of those files, and create a new commit about adding the Godot demo project. Then we could click on the checkbox at the very top of the workspace view to select all files, enter our commit message in the input field at the bottom, and click the Commit button:

As soon as we click on the Commit button, we get a confirm window, and then a quick spinner while Diversion actually does the commit… and here we go!

Our new commit now appears in the list of recent commits on the right, and we see our workspace has no modified files anymore :)

By the way, if you have a longer history in your Diversion repo and you want to keep track of some older modifications, you can also go to the left sidebar and switch over to the History tab to see the full evolution of your project, or search for a specific commit:

Of course, we could also come back to our shell and, inside our Diversion-versioned repo, run the dv log command - and sure enough, our new commit is already synced locally, too!

Now that we know the basics, let’s see how to use branches in Diversion to help organise collaborative development, handle important features, or just follow common DevOps workflows like Trunk-based Development.

Working with branches

As most (if not all) VCS tools, Diversion has branch-related features that let us easily create, switch between and delete branches.

So in this last part, we’re going to quickly recall why using branches when versioning a project can be beneficial, and we’ll see how to apply this to our Diversion/Godot demo project.

Why should I use branches when working with a versioning tool?

Using branches in version control systems is an efficient way to manage code changes, collaborate with team members, experiment with new features, and maintain a stable and organised codebase.

Most notably, branches provide the following advantages:

Isolating new features or big changes: Branches allow you to work on specific features or changes without affecting the main or stable codebase. This is crucial in preventing unfinished or potentially unstable code from impacting the rest of the project.
Supporting parallel development: Multiple developers can work on different features simultaneously by creating separate branches. This parallel development can significantly speed up the overall progress of a project - and it’s totally aligned with the main objectives of Diversion, and its cloud-native nature :)
Testing or experimenting: Branches are also a safe space for tinkering with new ideas or implementing potentially disruptive changes. Developers can create feature branches, test new code, and easily discard or merge it back into the main branch if successful.
Collaborating & doing code reviews: Branches help with the code review process, too. After they’ve created their branch and committed changes on them, developers can initiate a pull request for team members to review before merging into the main branch. This ensures that changes meet quality standards and follow the team's coding conventions.
Managing releases: Branches are often used to manage releases. This can help plan, verify and execute a nice release schedule while always maintaining a stable main branch.
Doing hotfixes: If critical issues are discovered in the released version, branches can be used for quick hotfixes. This is a sort of “practical application” of the parallel development mentioned before: thanks to branches, you can address urgent problems without affecting the ongoing development work in the main branch.

So having branch-related features is a must-have for version control solutions - and Diversion has got some to make it easy to work in parallel.

Using branches in Diversion

If we take a look at the dv branch documentation in the CLI tool, by running the dv help branch command, we get the following:

To test the branch features, what we’re going to do is change the Godot demo a little to have enemies move more slowly; we’ll suppose this is some experimental changes that we want to test to make the game easier, but we’re not too sure it will be perfect - so we’d rather use a branch to isolate our new development.

To create our new branch, we can use dv branch -c <name>. Then, if we run the dv status command, we’ll see that the CLI auto-switched us to our new branch (contrary to Git, for example, that doesn’t auto-check you out on your new branch):

If you want, you can also have a look at the browser and you’ll see that this new branch will have appeared in the project online dashboard, and you’ll be switched on it:

We’re now on our new branch, ready to work. The next step is to actually do our change in the code, to reduce the enemies’ speed.

To do this, let’s go to the Main.gd script, in the _on_MobTimer_timeout() function, and replace:

# Choose the velocity for the mob.
var velocity = Vector2(randf_range(150.0, 250.0), 0.0)

With:

# Choose the velocity for the mob.
var velocity = Vector2(randf_range(50.0, 150.0), 0.0)

If you run the game again, you’ll notice that the enemies now move more slowly, making it slightly easier to dodge them and last longer. The modified file is also visible if we do a new dv status:

And, in the web app, you can click on the modified file in the Workspace tab, and select the split view at the top to compare the modified version to the previous one:

Ok so - now, let’s commit our changes in the branch, so that everyone in the team can use this branch to try out our modification and give some feedback.

You could also use the shell to commit the file by running the following command:

dv commit -m "test(core): reduce enemies speed" Main.gd

Plus, if you want, you can always compare two branches by selecting them in the dropdown at the top, and then selecting the commits to compare:

Finally, suppose the team decides to keep this change and wants to integrate it in the production version of the game. Then, to re-merge this new commit in the main branch, we just need to switch back to this branch (with dv checkout main), and use the dv merge command with our test branch name:

It’s important to remember that merging a branch doesn’t automatically destroy it (because you might want to keep working on it afterwards, depending on the situation). So to really clean up our work session here, we should also remove our test branch.

This screenshot shows the state of the branches before deletion (the first run of dv branch), the deletion of the branch (dv branch -d test/enemies-slower) and the state of the branches after deletion (the second run of dv branch):

And, as usual, you can come back to the web app to check the repo is perfectly reflected, and the test branch has indeed disappeared:

Conclusion

So there you go: you now know how to initialise, configure and update a Diversion repository for a Godot project. And you even know how to work with branches to get a more organised workflow and support your collaborative dev!

Of course, this was just a quick intro to using Diversion for version control, and more specifically for a Godot project. But of course, if you’re curious, you should definitely have a go by going to the official website, or joining their Discord to ask all your questions directly :)

Choosing your weapon: SaaS or self-hosted version control?

Mina Pêcheux — Fri, 03 Nov 2023 11:13:02 +0000

In the fast-paced video game industry, being able to efficiently manage, track, and collaborate on complex multimedia projects is essential. You need to have a way of iterating quickly, of checking everything works with every release, and of merging together all the code and the assets the team produces.

That’s why today, many game studios, large or small, use version control tools.

Of course, as we discussed in other articles, finding the right version control solution for your team might not always be easy, especially taking into account the specific needs of developers and artists. But luckily, there are now more and more available, and several projects aim at providing good versioning utilities specifically in the context of video games.

However, there is still a question that you will need to answer when picking the best version control tool for your team, which is: “should I go for a SaaS or a self-hosted solution?”.

Well, in this article, we’re going to briefly go over the advantages and the drawbacks of each system so that you can get a better idea of which one best suits your own situation :)

A quick recap: SaaS VS self-hosted

Just before we dive in, let’s briefly sum up what a SaaS or a self-hosted VCS solution is.

SaaS version control is a system where code, assets, and project data are stored and managed on servers hosted by third-party cloud providers. Generally speaking, this approach allows for real-time collaboration and easy access from anywhere with an Internet connection.
Self-hosted version control is a system where the code and project data are stored and managed by the team itself. This approach grants full control and ownership of the infrastructure, but it requires in-house hardware and/or software maintenance.

It’s important to note though that this crude distinction is quite basic, and we’re simplifying the comparison by grouping together some variants. SaaS VCS could also extend to private servers managed by a third-party provider; and self-hosting can consider both self-hosted private servers, and self-hosted on-prem(ise) servers.

Basically, here, we’re mostly focusing on the difference between “having someone else handle the VCS in terms of hardware and software” (SaaS) or “taking care of everything on your own, from install to maintenance” (self-hosted) :)

Alright so - now, with this in mind, let’s see what are the main differences between those two systems, and which one may be more adapted to certain team structures.

The powers - and risks! - of SaaS version control tools

Benefiting from easy access & collaboration

One of the most obvious advantages of SaaS version control systems is that they’re more easily accessible for real-time collaboration (this service being managed by the SaaS provider itself). So usually, even if your teammates are spread across the globe, they can still work simultaneously on the same project and share their results instantly.

Because every designer, artist and developer can easily access the latest version of the game assets and code at any time, it’s also easier to stay consistent throughout the development process and iterate on the project in an interesting way.

All this leads to improved efficiency, faster decision-making, and a more streamlined workflow.

Moreover, since the data is centralised in one place, some SaaS solutions offer really nice features such as automatic conflict prevention, to help teams avoid infuriating afternoon-long merge conflict resolution sessions - ‘cause the system can check continuously whether a file is currently being edited and ensure everyone’s in sync, without people having to manually lock and unlock files.

(Note that this can also be true of a self-hosted VCS, if the version control doesn’t use a Git-like distributed architecture ;))

Taking advantage of scalability & flexibility

Video games are strange beasts that mix a lot of different fields of expertise - be it in terms of people’s skills, or in terms of file types and sizes! Handling complex binary assets, and large multimedia files like images, sounds, 3D models or even movies is always difficult.

Nowadays, some VCS solutions are very much focused on managing these large files and allowing game creators to keep all their assets in the same place, whether they are small light scripts or big heavy 4k textures.

And, truth is - a SaaS system is often a nice answer here :)

Indeed, a SaaS tool is inherently scalable: it’s based on technologies that can be boosted by upgrading the hardware and the infrastructure seamlessly. And, of course, because this is handled by the SaaS VCS provider, the game team is free to continue working on their project without all these maintenance headaches.

This “auto-scaling” is also often supported by a lot of other nice-to-haves or auxiliary tools that help facilitate the overall versioning workflow. Usually, SaaS version control doesn’t exist in isolation; rather, it’s part of a broader ecosystem of cloud services. This complete “all-in-one” pack can be a real game-changer for video game creators, because it can simplify the day-to-day project management by keeping everything centralised in one place.

For example, having task management tools, continuous integration, deployment pipelines and review features can be an amazing time-saver and further power team collaboration.

The goal, as always, is to reduce menial manual tasks and automate them to improve the development process itself - and by taking advantage of cloud-based services, game developers can delegate a lot of the boring maintenance issues and, instead, focus on efficiently realising their own dream and making games for all of us.

Going to the cloud… for data protection & security?

The third big advantage of a SaaS version control system is often said to be data protection and security. And even if it’s true that there are a lot of super neat and reassuring utilities when using this kind of solution, perhaps there’s also some side-stuff worth remembering when diving into a SaaS VCS.

So, on the plus side, using SaaS version control is obviously excellent as far as data redundancy goes. Since you literally have a remote backup of all your data online, and this data is often also backed up again by the VCS service provider, as part of the reliability they are committed to provide. So, you really run less risk of seeing all your week’s work disappear because of a wrong move! (Typically, cloud providers invest a lot on robust redundancy mechanisms, and they distribute the data across multiple data centres or regions to make sure your project data remains safe and accessible at any time, with as little risk of outage or downtime as possible.)

A SaaS VCS is also considered really secure because, unless they want to go out of business, cloud providers basically need to put a lot of money in installing heavy security measures and guarding everyone’s assets. Of course, any system can be hacked… but at least, they put a lot of effort and capital into making sure it happens as rarely as possible here.

That being said… some people have also pointed out that, while your cloud data is indeed secured from the outside, you also are forced to entrust the cloud provider itself with it! Meaning that, in a world of secrets and dark trades like the one of video games, you might be giving your private data to another company that then just promises it will be cool and not backstab you in any way.

No, let’s be honest - I’m painting a rather dark picture of it and, in fact, most SaaS providers aren’t just terrible sharks lurking and waiting to feed off your data. They’re sincerely concerned about obeying the various regulations and laws regarding data privacy, they comply with all legislations about data storage and sensitive data management, and they respect intellectual property.

I just thought it was worth mentioning this issue so that you also see some of the risks of storing and distributing your data online via a cloud provider, if not every actor in the chain is doing their best to up the quality of the service ;)

What if you can’t access the cloud service?

Actually, another smaller but notable drawback of SaaS VCS is that, because everything’s online, you need to have the Internet to connect to them and get access to your data. Oftentimes, a SaaS version control tool will have very limited functionalities when used locally on your machine offline - if it has any.

Game studios that want to go for a SaaS VCS therefore need to consider this failure point, especially in regions with unreliable or slow internet infrastructure.

And, also, there’s always the possibility that it’s the service itself that is out. In other words, even though you are connected, the cloud VCS is offline and down for some reason. Although the cloud providers have many failsafes to avoid this scenario, it can still happen and, in that case, you need to have some contingencies in place to address potential downtime and ensure the work can continue offline.

However, you should also keep in mind that a self-hosted system, even if it’s completely on-prem, can fail too - there might be a connectivity problem, some downtime on your data centre, or a maintenance issue that your IT team is working on and prevents you from accessing the data…

Addressing the cost issue

Finally, last but not least, there’s the question of price.

SaaS version control systems typically operate on a subscription-based or a pay-as-you-go pricing model. So, while this model provides flexibility by allowing teams to pay only for what they use, it also means you’ll have ongoing expenses. Over time, subscription costs can add up, and perhaps be more expensive than the initial investment of a self-hosted version control solution.

Smaller indie studios or startups with limited budgets may find it challenging to manage these recurring costs - in particular if they can’t accurately predict the thresholds they’ll meet… although, to be fair, most SaaS VCS offer a free base package, and there are some thresholds before you’re required to pay anything :)

For larger game development teams, the problem is a bit different. On the one hand, those companies usually have more money, so they can handle the price of a SaaS version control tool. But on the other hand, the subscription costs of SaaS version control can become substantial. As the team size grows, there will be more and more people in need of access to the service, and you’ll have to pay more and more subscriptions.

This cost scaling can make SaaS solutions less cost-effective for large studios compared to self-hosted alternatives, which may have just a one-time cost upon install. However, it is not always a clear-cut decision since, as we’ll discuss in a second, many self-hosted version control systems have per-seat cost or annual subscriptions, too, and they always require resources on your part…

To recap?

So ok: SaaS VCS offer a lot of good perks that are really well-aligned with the unique specificities of modern video game creation. They don’t require any set-up or maintenance, give teams instant access from anywhere in the world, they allow for easy sharing and collaboration (sometimes with auto-merge conflicts prevention), they provide seamless scalability, and they usually have a lot of security measures in place to ensure your data stays safe and backed-up.

However, they also introduce some concerns about data privacy, and they may go offline and stop your production if you don’t have a backup plan - plus the ongoing subscription fees (or the pay-as-you-go models) can slowly start to cost a lot in your overall budget.

That’s why some people prefer to turn to self-hosted solutions…

Should you rather pick a self-hosted solution?

Managing & “securing” your data

Obviously, as a counterpoint to SaaS solutions, one of the best things with a self-hosted VCS is that you’re totally in control of your data and their management. You don’t store your secrets on a third-party server - you keep everything at home, within your own secured infrastructure (of course - assuming you make sure it’s secured - see next section).

This level of control is really important when you’re dealing with highly confidential intellectual property or proprietary tools, assets or even game mechanics. By keeping the data on a private server, or even on-prem, you ensure that your game’s source code and assets remain completely private.

This complete control of the data also means that you are free to choose how you store it. You can tailor the system to your own needs, even if it means experimenting with some custom workflows. And you can perfectly link the version control system to the rest of your internal tools to craft an end-to-end superbly adapted game development pipeline.

The importance & difficulties of operating your system

But of course… on the down side, there’s the problem of maintaining and securing all of this by yourself. ‘Cause this “phenomenal data privacy perk” only stands as long as you can guarantee that your system is well-setup and protected.

Maintaining a self-hosted version control system, whether it is on a remote server or directly at your studio, means you have to manage both the hardware and the software infrastructure. This includes buying, setting up and preserving servers, storage devices, and the version control tool itself. In particular, regular updates, fixes and upgrades are often necessary to ensure the system is reliable and secure.

So, contrary to a SaaS version solution where all this is handled by your SaaS provider and your team is 100% focused on creating games, when using self-hosted version control, you’ll almost certainly need to have some IT people dedicated to taking care of it!

By the way, this IT team will also be in charge of handling data backups. It will need to put in place data redundancy mechanisms and it will be responsible for disaster recovery if there is ever any problem - all of which takes time and skills. And any lapses in this area can lead to data loss and big project setbacks, so better be careful…

Working on a local network… a gift or a curse?

As we said before, video games often rely on massive assets such as high-resolution textures, 3D models, and complex animations. These big files are heavy on the storage… and also long to transfer!

In that case, on-premise version control is actually a great way to have high-performance access to these large files from within a local office. Teams can retrieve and update assets swiftly, minimising the waiting time and optimising productivity. And even a self-hosted private server, if it is well-located and linked to your studio, can be a real step-up from using some SaaS solution.

(‘Cause yeah, comparatively, using SaaS VCS can be slower and have bottlenecks at various points of the file exchanges, which can be risky if your production is on a tight schedule. Plus, if everyone is downloading the same huge asset at the same time, it will probably bog down the entire studio…!)

On the other hand, being constrained to a local network also means that collaboration is more limited - at least, geographically speaking. If the company is really harsh on security measures, you might not be able to work somewhere else that on the company’s premises (though this is evolving as we enter a new era of post-Covid remote work-friendly setups). Of course, VPN is a common tool for dodging these issues and allowing people to access the private network from anywhere, but it does require some cumbersome setup steps whenever you want to collaborate with the rest of the team.

Depending on how the infrastructure is built, and how the version control tool is made available to the team, cross-team collaboration can also be hindered and therefore slow down the overall process. In a really large studio with multiple teams working on different aspects of a project, coordination can become complex - teams can struggle to share assets seamlessly and maintain consistent project versions, which then leads to potential conflicts and delays. The only solution is then meticulous planning and communication… but this also takes time and skills ;)

Predicting & lowering the costs

Now, though maintaining your infrastructure can be hard, there’s a nice silver-lining in having it all in-house: you can predict and reduce the cost dedicated to this part of your activity.

Indeed, while installing the whole system can be a bit expensive at first, this initial investment can become very cost-effective in the long run, especially for large studios.

Also, you’re not subject to the same unpredictable variations of VCS-related costs as with a SaaS solution. When using on-prem version control, you can get fairly reasonable expectations of the budget needed, and you can allocate the rest of resources with more confidence.

But.

First, as we said before, the costs of SaaS solutions may actually be quite low for a while - if there are even any.

Second, although on-prem VCS doesn’t directly scale the costs when your team expands, it’s not always that clear. Typically, if your IT team grows, then your personnel costs will as well. And actually, some solutions like Perforce or even Github and Gitlab when used on-prem price their service by the number of users - so you’re not necessarily getting the better bargain…

And third, being fully on-prem only works as long as you’re sure you can maintain all of this. So even though it’s technically possible… it can be a big risk to go fully on-prem, and it can actually create a lot of difficulties. You can of course consider those a risk worth taking, but it’s crucial to remember that the initial investment and the subsequent savings cost-wise are just one chunk of the equation; and there are a lot more things to consider before going this route.

Typically - your system might suddenly be endangered if some unexpected twist forces you to adapt to rapid growth or re-provision your pipeline… because a self-hosted solution, especially if it’s on-prem, is way harder to scale properly than a SaaS one.

Understanding the challenges of self-hosted version control scaling

Game development studios live in a strange industry, where a small studio can suddenly boom and grow wild, especially after releasing a very successful title. (That’s a very-well known phenomenon in the indie community, where two people in their garage can make a completely revolutionary artwork that becomes a milestone for an entire genre! Yes, The Binding of Isaac, I’m thinking of you…)

However, self-hosted version control systems may struggle to adapt seamlessly to these changes. Scaling up the infrastructure to accommodate more people and more data can be tricky - it can be time-consuming and costly. So studios must be really careful when they plan for growth and find where best to direct resources to support this change and avoid bottlenecks.

Even outside of those unique events, more common scaling challenges can be over- or underprovisioning your hardware and infrastructure. Because overestimating the system may result in unnecessary expenses… but underestimating can just lead to roadblocks. It’s essential to find the right balance and analyse your entire studio’s past, present and future state to scale everything as well as possible.

To recap?

Self-hosted version control systems can offer a high degree of control and customisation. They are interesting in terms of data security and fast local access, or even in terms of budgeting because they make for lower and more predictable costs. But the trade-off to all that is that your studio is in charge of its entire infrastructure and hardware - so you’ll need to deal with data backup, maintenance, and even scaling difficulties.

So… what should you pick?

At this point, you see that there is no perfect answer to this question. It all depends on the situation, such as the size of your team and projects, the security requirements you have, the budget you can afford to spend or your scaling ambitions.

Still, it’s worth noting that, in all generality:

SaaS VCS solutions are a good choice for small and mid-sized studios, startups, or indie developers who prioritise agility, remote collaboration, and cost-efficient scaling. They are particularly interesting when a team is spread around the globe, and they need quick deployment without the overhead of managing infrastructure, because with scalability, data backups and integration capabilities, they provide an “all-in-one” and “care-free” solution. \ But, of course, it also implies taking the related subscription or pay-as-you-go fees into account when budgeting your projects (though a lot of solutions remain free for quite a while…), and you put your IP in the hands of a third party - although you’re getting their guarantee for privacy :)
Self-hosted VCS solutions can be better for large studios with substantial resources, sensitive IP, or a history of on-premise infrastructure. They’re valuable for studios who want to keep full control over their data, need high-performance (local!) access to large assets, or who can benefit from economies of scale… \ Still, all this requires in-house maintenance - meaning, usually, a dedicated IT team - and good planning to cope with scaling challenges, so this “efficient cost” can actually sometimes scale up, too!

Conclusion

To sum up, picking between a SaaS version control system and a self-hosted solution is an important decision that will have an impact on the entire workflow of the game studio.

Ultimately, there is no one-size-fits-all solution, and each type of VCS has its own advantages and drawbacks. The key is to find the one that suits your team and your project, and to not have your version control tools slow down your creators, but rather empower them to do what they like.

That being said, nowadays, there are a lot of interesting tools for you to explore - and not just the old-timers like Git, PlasticSCM or Perforce.

For example, if you’re a game dev looking for a free VCS SaaS option, then you might want to explore diversion.dev, which is a really cool project with a lot of interesting features that, though it is in-development, is already very promising!

Can artists benefit from version control, too?

Mina Pêcheux — Fri, 15 Sep 2023 08:21:35 +0000

Over the years, the little game studios have slowly turned into a big industry with a lot of high budget products. And despite some infamous AAA titles day-one patches and ridiculous bugs (yes, Cyberpunk, I’m looking at you), it’s impressive to see how much of this software works really well.

Because video games are demanding and complex artworks that involve bringing together coders and artists. You have to ship a robust project, that is maintainable and upgradable while working on as many platforms as possible; you have to write whole stories, prepare hundreds of scenes, code complex behaviours for your AIs or create stunning visuals that can run on six-years old consoles.

All of that requires some minimal level of organisation. And, most notably, a tool to clearly track the progression and history of your game, step-by-step, and file by file.

That’s usually where version control comes in; after all, the whole goal is to keep an eye on the evolution of files, compare differences, help with teamwork by handling branches and merges, and get a backup of your latest working release. (Yes, you know: the one from before you added this new boss that crashes the entire level.)

Except that there’s a catch. For now, most of those versioning tools are mostly made for code. Meaning that they’re good at tracking basic text files like scripts, but they struggle with large assets; and that they don’t always have the most user-friendly interface.

So… what about artists? How can they keep track of their work on assets?

Why “coder-oriented” versioning tools rarely work for artists

These days, there are a fair amount of version control systems - but the most famous ones come from the dev community, and are thus primarily designed for code versioning.

The well-known Git, the old SVN, or the quite popular PlasticSCM and Perforce - those are all common tools for versioning. Yet artists are often having a hard time using them, because of various common problems.

Complexity & user-unfriendliness

The first culprit is the complexity of those tools.

Git and SVN are probably the worst in that regard. Although they both offer a few GUI clients, they’re filled with big concepts that aren’t that easy to grasp, and make versioning a real challenge in itself. Using branches properly can be very complex, and solving merge conflicts is nearly impossible when dealing with binary files like images or 3D models.

Now, to be fair: PlasticSCM or Perforce offer way clearer interfaces, and GUI clients that make them fairly easy to use.

Still, the moment you start to dive into more advanced stuff, you’re gonna have to know the tool really well in order to not inadvertently overwrite your colleague’s work, or erase last week’s progress.

In particular, there is virtually no visual differencing in those tools. At best, the system will tell you that “your image file has changed”, which is far from informative. In other words, artists can’t really see what’s changed between the two versions, and they’ll basically need to keep both copies on their computer and open them side-by-side if they want to compare.

Another thorn in the side of game artists who want to use these versioning tools is that the traditional game art workflows don’t often combine well; you then need to force artists to comply to the VCS’s rules, or develop in-house ad-hoc intermediary solutions to bridge everyone’s comfort zones… which is time-consuming and not very scalable!

Handling large asset files

Of course, another major problem of those “coder-oriented” systems is that they’re not designed to manage massive files like art assets. By comparison, scripts are extremely small files.

So most of those tools don’t expect files to weigh more than a few hundred KBs - while this is just on the low-end for images, audio files or movies!

PlasticSCM and Perforce are currently the best solution in this domain: they are both able to handle mid- and large-sized assets, and that’s why they’re now the standard solution for many game studios. But the pretty steep storage cost of PlasticSCM, or the licence fees and server maintenance requirements of Perforce, can discourage little teams, and because they’re not as famous as Git for example, they have a smaller user-base and less documentation.

Git has a well-known command-line extension called Git LFS (for “Git Large File Storage”) to manage large files better, but it’s complex to set up and can severely hinder the day-to-day usage of the VCS, in particular for small projects.

Limited metadata editing

Moreover, game assets often require additional metadata such as tags, descriptions, or other information to help artists and developers update and integrate them effectively.

However, common versioning tools don’t have much in terms of metadata. Usually, you have your files on one side and your commit history on the other - and these commits hold metadata on the tasks and the updates, rather than the files themselves.

This means that unless all your metadata is embedded in the assets, it might be “lost in translation” when sharing the file with the rest of the team via a typical version control system.

Merge conflicts management

Art assets are typically files that are edited by several members of the team - more often than not, a main game asset like a character or a big environment requires several people to combine their skills and create a model, a rig, an animation, materials and textures, hair and cloth simulation…

This naturally implies that one asset file might be edited by two people at once and, if this file is versioned, you’ll then have to merge both results into a logical single output.

This is the problem of merge conflict and, again, a lot of “coder-oriented” VCS don’t do it well for binary files. Basically, that’s because tools like Git or SVN for example are designed for text files that can be compared line by line; but, in a JPEG image, it’s not possible to do such a comparison.

That being said, SVN and Perforce for example have a “lock” mechanic that lets you take over the file during your work session and prevent any other changes, which is a basic way of avoiding conflicts. That’s already very cool, and it solves a lot of daily issues - but it can be tricky because you need to remember to lock the file before starting your work, and unlock it afterwards so that other teammates can edit it further.

Ideally, this conflict prevention should be handled automatically by the system, especially if it’s cloud-based and therefore has access to previous and current data at the same time.

Are there versioning tools for artists?

All of this highlights how, at the moment, the classic VCS tools like Git, SVN or even Perforce aren’t totally suited for game artists.

Still, you need to track those art assets so that you know what was made when, by who, and for what - so you have to find tools to version those files as well as code.

But - can’t we use Google Drive? Or Dropbox? Or emails?

That’s actually a very common solution to this problem. As discussed in this study we conducted a while back, many game teams decide to use some external storage system for their non-code assets.

The problem is that those tools are not real versioning systems: you often end up sending your team files with “_v2”, “_v3”, “_final” suffixes. Plus, you have to spend a lot of time managing shared folders that get cluttered with backup or temporary files, because art software (such as Photoshop, Maya, Blender…) are very good at creating plenty of files “around” your main one.

To put it simply - using Google Drive or emails is easy but also risky, because you don’t have a reliable single source of truth, you don’t have a centralised history of changes and you don’t have any specific security for your data. Most notably, separating your code from your assets by maintaining two storage/versioning systems is really cumbersome - especially for video games that intimately tie the two!

Picking a versioning tool made for artists

Solutions like Alienbrain, PlasticSCM or Perforce’s designer-oriented Helix Sync are trying to shift the mindset on version control and integrate artists better. Be it by creating more accessible interfaces to the tool, simplifying the options to get a more approachable system or ensuring direct connections with typical art creation software, they aim at giving artists adapted tools to keep track of their files.

For example, Alienbrain offers a visual differentiation tool that directly highlights the modifications on the file:

(Screenshot from: https://www.alienbrain.com/)

And it also integrates seamlessly with many game creation tools (Unreal Engine, Maya, Photoshop…), so that you can access your version control system from within each of those applications without having to switch windows.

Sounds great, right?

Well - that actually comes at a high price that basically blocks any indie studio from using it. It's a minimum €120 per year per team member… and that’s for a coder! ‘Cause yeah, Alienbrain has a fairly strange pricing system where you can have a coder subscription, an artist subscription or an “advanced” subscription that combines the two. For example, someone with a coder account won’t be able to get image previews, or track progress and manage the project at all.

This highlights how, because of the challenges of versioning large binary files, current solutions have to make their products expensive to cover their storage costs, and how this directly impacts users.

Moreover, the “easy integrations” that Alienbrain advertises on its homepage are mostly for art software… the only code editor they support natively is Microsoft Visual Studio, which is just one of the solutions used by devs. Overall, the steep learning curve and high complexity of the software put a huge overhead on the coders’ daily workflow.

(Plus, while the code-centric features such as branches, merging and conflict solving have improved, some reviews still say that the check-in/check-out and code merge features aren’t as well-designed as in other tools…)

So… does this mean that we have to pick either coder-oriented and perhaps free VCS that don’t work well for artists, or buy very pricey artist-oriented VCS that are unusable by coders? Or are we condemned to maintain two version control systems at the same time on every game project to combine the best of both worlds… which also means painfully re-merging those two worlds afterwards to get our final game?

Exploring modern versioning tools

This industry-wide question is becoming more and more of a problem, because video game studios are growing fast and exploring ever new workflows. To try and solve this conundrum, many people have started to work on more modern and multi-usage version control systems.

Diversion is one of those new versioning solutions. It is a cloud-native tool, currently in beta, that aims at bridging the gap and providing a VCS built both for developers and artists.

One of their main goals is to handle large binary files and small code sources alike, in a seamless and user-friendly workflow that everyone can understand. So they’re looking for the best trade-off between providing many features and a scalable solution, and keeping it easy-to-use with a clear interface.

And another very cool thing is that Diversion is actively working on an automatic conflict prevention tool to help teams collaborate on large projects safely - without risking unwanted overwrites, and also without having to “lock/unlock” files manually.

To do this, they take advantage of their cloud setup to continuously keep local files in sync with the remote version, and then notify users working on the same file at the same time that it is already being edited. You even have some info on the other teammates who are currently changing the file, and when was the last modification.

Of course, Diversion is still in beta and there are a lot of features that need to be added; but as is, this solution already looks interesting, and it’s definitely dedicated to creating a good user experience for both coders and artists.

Conclusion

In the complex world of video game creation, finding the perfect version control system is hard. Having something that is tailored for the needs of coders and artists is difficult, because they typically rely on very different workflows and software. And yet, having tools that accommodate both and can thus be shared across an entire game studio (instead of juxtaposing several profile-specific solutions) could be extremely nice in terms of setup, maintenance and team collaboration.

Traditional versioning tools like Git and SVN, while robust for source code management, often struggle with handling large game assets - plus, artists are often blocked by the complexity of those coder-oriented VCS. Conversely, artist-friendly systems are often very expensive, and they might not be suited for developers.

That being said, the industry is witnessing a wave of innovative solutions that are meant to solve this exact problem. Tools like PlasticSCM and Perforce have recognized the need for artist-friendly version control and have implemented interesting features such as visual diffs and large binary asset support.

Diversion is another solution that tackles this challenge. It aims at providing creators with a scalable and easy-to-use tool - and it might not be as pricey and difficult to manage as PlasticSCM and Perforce! Plus, they’re currently developing a conflict prevention feature to simplify collaborative work and make the best out of their cloud-based solution. So if you’re curious about this alternative solution and you want to learn more, check out Diversion here!

Version control for your Godot game projects

Mina Pêcheux — Wed, 26 Jul 2023 13:02:52 +0000

Any game developer knows that versioning the code and the assets of a game project is no piece of cake - whereas web apps are mostly big bundles of text files, games require both text and complex binary files. So you need to have a tool that does both version control and asset management!

However, even to this day, the game dev community is fairly sceptical when it comes to using the usual SCM tools for keeping track of the project’s history, and collaborating with the other teammates.

We’ve already talked about these issues for versioning a Unity project with Git, the standard SCM solution; but, of course, the same questions arise for other game engines, such as Godot.

So, today, let’s put on our Godot DevOps hat, and see how we can version a Godot project, what are the differences from a Unity one, and what issues still remain no matter what.

Godot: a VCS-friendly game engine...

Compared to Unity or Unreal Engine, Godot is a somewhat new and small game engine - the real first out-of-beta version dates back to only 2014, and it began as the brainchild of two developers: Juan Linietsky and Ariel Manzur.

However, it does stand out from its competitors with its community-first philosophy, and the fact that it’s been open-source since the very start. This idea of bringing in the community on the development has allowed the engine to grow quite rapidly, in particular thanks to various plugins that can extend the tool in various ways.

And, among all those features, there are some specifically meant to help with versioning and SCM...

Enabling version control for a Godot project

Although there is no SCM tool built-in Godot directly, any Godot project offers an easy way to integrate versioning, just by going to the Project | Version Control menu:

Except that if you click on that button... you’ll probably get an error popup telling you that you don’t have any VCS plugins enabled:

That’s because, parallel to enabling version control for your project, you also have to make sure Godot actually has a tool to use to do this versioning!

Now, from what I’ve seen, at the moment, the only plugins that are available in Godot’s asset library for versioning are Git integrations. In fact, the Godot team has even released an official Git versioning plugin to directly connect your Godot project to a Git SCM.

Ok, I know: there are dozens of SCM tools, so you may be thinking that Godot is just limiting our options here, and that this quick VCS setup is just a joke that nobody should use. But, in this specific case, there are actually a few reasons why Git is a nice choice, and may be the right fit:

First of all, Git is open-source. And given Godot’s whole “sharing to the community” mindset, it makes sense to stick with open-source software for versioning.
Git is also among the most popular SCM tools, so many developers are familiar with it and use it “by default” (as a survey we’ve conducted has shown).
Github and Gitlab are also extremely popular, and they provide another set of tools for automation, and CI/CD.
A lot of files in a Godot project are text-based (we’ll talk more about this in a second), so they are totally “understandable” and usable by Git.

So, in truth, going for a Godot-Git combo is not that unreasonable :)

Note: By the way, if you’re curious, some of the most famous versioning tools for game development and their specificities are discussed in more detail in this article ;)

Anyway - if you follow the install instructions of this plugin and add it to your Godot project, you’ll then be able to click the Set Up Version Control item of the menu and get this new popup, where you can enter your various Git-related credentials and info:

Once it’s configured, you’ll be able to examine your Git repo from inside your Godot project editor, and benefit from various tools like:

File differences (in unified or split view):

Direct staging/unstaging:

Direct commit, and a list of all the current commits in the repo:

And even more tools for branch management, remote repository configuration, etc.

Ok, that’s great - thanks to this little add-on, we can very easily handle all of our project’s versioning inside the editor, and we have all the basic Git options we need right at our fingertips. So we should be able to version all of our codebase directly, without even needing an external shell.

But this does beg the question: what about our complex project files? You know, all the project settings and resource assets like shader graphs, material properties or even entire scenes?

Godot’s text-based settings file

To me, that’s where Godot really shines!

‘Cause, as we said before, many Godot project files are text-based. Basically, as stated in the game engine’s official docs: “Godot aims to be VCS friendly and generate mostly readable and mergeable files”. So the creators have made their best to use human-readable and easy-to-version files for the project configuration and the resource metadata, by writing those files in a TOML-like format.

This makes those project files way easier to version and track than Unity’s - actually, let’s do a quick comparison to better understand the difference ;)

In Unity, even if you force the editor to serialise the assets as text files to help with Git versioning, you still end up with pretty cryptic config files, filled with a long list of mysterious properties:

%YAML 1.1
%TAG !u! tag:unity3d.com,2011:
--- !u!129 &1
PlayerSettings:
  m_ObjectHideFlags: 0
  serializedVersion: 23
  productGUID: 969ea8fe4c8a54236a202247833a2b06
  AndroidProfiler: 0
  AndroidFilterTouchesWhenObscured: 0
  AndroidEnableSustainedPerformanceMode: 0
  defaultScreenOrientation: 4
  targetDevice: 2
  useOnDemandResources: 0
  accelerometerFrequency: 60
  companyName: DefaultCompany
  productName: Tutorials
  defaultCursor: {fileID: 0}

On the other hand, here’s the beginning of a project.godot file, which contains the project’s global settings:

; Engine configuration file.
; It's best edited using the editor UI and not directly,
; since the parameters that go here are not all obvious.
;
; Format:
;   [section] ; section goes between []
;   param=value ; assign values to parameters
config_version=4
[MonoCustomResourceRegistry]
ClassPrefix=""
SearchType=0
ResourceScriptDirectories=[ "res://" ]
[application]
config/name="Tutorials"
run/main_scene="res://05-MouseFollow/scenes/05-MouseFollow.tscn"
config/icon="res://icon.png"
[display]
window/size/width=1920
window/size/height=1080
[editor_plugins]
enabled=PoolStringArray( "res://addons/MonoCustomResourceRegistry/plugin.cfg" )

And similarly, any Godot resource is stored in this TOML format. So, for example, you can just open and read through your scene hierarchies in any text editor (here’s the top of a .tscn asset in one of my Godot projects):

[gd_scene load_steps=6 format=2]

[ext_resource path="res://04-RTSUnitNavigation/scripts/Unit.cs" type="Script" id=2]
[ext_resource path="res://04-RTSUnitNavigation/art/models/craft_speederA.fbx" type="PackedScene" id=3]

[sub_resource type="BoxShape" id=1]
extents = Vector3( 0.5, 0.55, 0.35 )

[node name="Unit" type="KinematicBody"]
script = ExtResource( 2 )

[node name="Model" parent="." instance=ExtResource( 3 )]
transform = Transform( -0.5, 0, -4.37114e-08, 0, 0.5, 0, 4.37114e-08, 0, -0.5, -1, 0.2, -0.7 )

[node name="CollisionShape" type="CollisionShape" parent="."]
transform = Transform( 1, 0, 0, 0, -4.37114e-08, -1, 0, 1, -4.37114e-08, 0, 0.35, 0.05 )
shape = SubResource( 1 )

What’s great is that a file like this:

allows us to quickly peek at our scenes and remember what nodes we’ve put in them, plus all the components and linked resources they use
is fully compatible with a Git versioning since it’s just text
can be explored and compared throughout the commits history easily
is way easier to merge in case of conflicts than an incomprehensible soup of properties like in Unity’s scene description

Actually, to a certain extent, an artist that is a bit curious about coding could probably read those files and get the overall gist, or even help fix merge conflicts!

All of this means that Godot offers a quick tool for integrating Git, and relies on text-files that are totally human-readable, and that Git can handle without any issues. Perfect, right? :)

Well, sadly, not quite.

Because there is still one type of files that poses a problem - it’s those heavy images, movies, audio clips or 3D models that your Github has trouble displaying, and that always ends up as an unreadable mess of binary characters.

... but not for large asset files!

Yep - large binary files are always the problem when versioning a game project, especially when you’re using a tool like Git, that was primarily designed to handle text files.

Your SCM will try its best to help, but if you ask a Git repo to show you the diff on an image or a movie clip, you won’t get very far. All those “special multimedia files” that are crucial to a game project - the images, movies, 3D models, audio files... - are just not meant to be tracked with Git.

In other words, despite Godot’s really nice Git integration, it is still limited by this everlasting versioning issue when working on game projects. So you’ll be able to commit all your metadata files into your Git repository without a hitch, but when the time comes to actually add the file itself, you’ll need to blindly push the binary contents of the asset and hope it works.

As time goes by and you continue to add more resources, pulling back your Git repository will become longer and longer because the tool will have to try and retrieve all of this complex data.

And yes: all of this will be a real nightmare for the (non-dev) artists in your team... who should actually be the ones authoring and keeping track of these final asset files!

This might be fine for small Godot projects. But for big ones, long story short: versioning large asset files is, as it’s always been, a pain - and this time, Godot doesn’t have a ready-made solution.

So, does all that mean we should give up and manage with this less-than-ideal situation? Is Git the doomed-but-only option? Or could we connect Godot with another SCM tool to dodge some of those problems?

An alternative to Git with better asset management?

Because the usual version control solution, Git, has proven somewhat limited for game projects time and time again, many people have turned to other SCM solutions.

Most notably, Perforce and PlasticSCM are two common versioning tools that are used by the game creation community.

Perforce is an interesting solution for big companies, because it handles large assets well and it’s good with code and complex assets. It’s also centralised, which means you won’t have to worry about re-merging local versions... but also that you are completely dependent on the remote server. Plus, compared to Git, Perforce is free for a little bit, but then it quickly adopts the pay-as-you-go strategy. And finally - you have to host and manage the remote server...

PlasticSCM shares many of Perforce’s advantages. However, since it’s been acquired by Unity in 2021, it’s slowly been tuned for this game engine - so it’s now mostly valuable for Unity dev teams that want an all-in-one solution. (And who aren’t too scared by the price, since PlasticSCM is a pay-as-you-go tool as well, but with fairly high prices.)

And then, of course, a few other teams around the world have started to dream of easier game dev versioning tools, too - which is why, today, various new SCM solutions with a special focus on game development are in the works.

For example, Diversion is a cloud-native version control system, still in beta but very promising, that aims at providing a versioning tool that is easy-to-use for everyone (meaning, developers and artists alike) and highly scalable.

Its goal is to facilitate versioning for multimedia projects like games by natively managing small text files and large assets, and by offering a centralised history of everything in your project, trouble-free. Plus, because they have a simple GUI, non-dev members of the team can use it too, and help with the integration and merges :)

The Diversion team is also working on a conflict-prevention feature to notify you whenever you’re updating the same file as somebody else, and you might be creating a conflict (thanks to its continuous sync system of local changes with the remote repository in the cloud).

Combine this with Godot’s easy-to-read text-based configuration files, and you’ll get a pretty neat version system that makes it easy to browse the entire history of your project, and lets you do collaborative work without too many risks of merge conflicts!

Conclusion

Godot is a rising game engine that is attracting more and more followers and that already offers quite a variety of features thanks to its open-source nature and its community-made plugins.

Some of those plugins make it very easy to integrate Git versioning in a Godot project, simply by downloading an add-on and turning on a few options. We then have everything we need to inspect and update our Git repo inside our Godot project editor. Plus, because Godot uses a plain text TOML-like format for all of its settings and metadata files, we can read through the config and version it with Git without the big merge conflict issues we’d have in a similar Unity project, for example.

However, this solution is not perfect, because Git is not meant to handle large asset files, and those are an essential part of many games. For big and complex Godot projects, keeping track of images, 3D models or audio sources alongside the codebase is hard, and taming all the subtleties of Git is often too complex for non-dev members of the team to be brought in on it.

But nowadays, new SCM solutions are popping here and there to serve as alternatives to Git, such as Diversion. This cloud-native versioning tool handles both basic text files and large binary asset files, and it is accessible to developers and artists thanks to its visual interface. A conflict prevention feature is even in development, that could nicely complement Godot’s VCS-friendly configuration files and reduce the frustration of detecting and avoiding potential conflicts :)

If you want to learn more about Diversion, go ahead and check the website!

The Agile, The Fragile, And The Iron Fist Of Branching Strategies

Sasha Medvedovsky — Wed, 19 Jul 2023 07:08:58 +0000

Whether you love it or hate it, Git has proven to be the nearly ubiquitous method engineering organizations employ to ship code today. However, when you’re just getting started and building your team, you may be thinking about which strategy is the right one for you to choose based on your current and future needs.

‍

We recently wrote a longer post about effective branching strategies, and the considerations involved when selecting your branching strategy of choice. However, we still believe it could be useful to dive in more deeply into the underlying philosophy for each branching strategy, to help you decide what code shipping strategy is the right one for your engineering team.

‍To make a very rough generalization, we can largely split branching strategies into those that are more agile in nature and those that are more structured. Each is employed to provide either more rapid delivery or greater control, if we were to think about them in a very generic way. Below we’ll dive into the most common strategies, from the structured to the agile, their benefits and what they’re best suited for. Hopefully this will help make the decisions regarding what can work best for you and your teams, and whether you need to rethink your branching strategy altogether.

‍

Structured Strategies

‍

Release Branching

‍This strategy is well-suited for large teams and projects that require long-term support for multiple versions. It’s no surprise then that both Microsoft and the Apache Software Foundation often employ release branching as their strategy of choice. (For those who aren’t familiar, the Apache Software Foundation is best known for hosting numerous open-source projects. The way they work is: each major release has a dedicated branch where bug fixes and patches are applied while development continues on separate branches).

TL;DR:

In this strategy, a separate branch is created for each major release version, where bug fixes and patches are applied to the release branch.
New features are developed in separate branches. ‍

When to Use It

Release branching is best suited for projects that require stable release maintenance while continuing development on other branches. This is because it offers a controlled and structured approach to managing releases, along with greater stability. Another situation where this strategy is used is in large projects with frequent releases (e.g. games) - the release branches isolate features scheduled for the upcoming release from ones that are not.

‍Advantages: The release branching strategy’s greatest advantage is that it provides strong isolation between releases, allowing clarity in multiple versions support, and scheduling and coordination of release cycles in large scale projects.

‍Disadvantages: This strategy creates numerous long lived branches, which complicates code management - it creates a need for complex merges to make sure code written in one branch (e.g., a bug fix) propagates into the other branches correctly. Use this strategy only where needed.

‍

GitFlow

GitFlow is a variation on the release branching strategy, that also defines additional long lived branches for different purposes. It was conceived in 2010 by Vincent Driessen.

TL;DR:
It consists of a "develop" branch for ongoing development and a "master" branch for stable releases (we’ll call it ‘main’ from this point on to align with the more modern terminology).
Additional branches are used for feature development, bug fixing, and release preparation. These branches are deleted once they are merged to “develop” and “main”.
‍
The Way it Works
Gitflow uses a central repository approach with two long lived branches: 'main' for production and 'develop' for integrating features. Additional temporary branches are created for isolating new feature developments and for preparing production releases. After a feature is developed on a feature branch, it's merged into the 'develop' branch.

‍When a release is ready, a release branch is created off 'develop', which is then merged into the 'main' and 'develop' branches, when the release is complete.
‍
When To Use It
GitFlow was commonly used (and still is, in some places) in projects with a scheduled release cycle. Teams working on software that has major scheduled releases, like operating system distributions, often use this strategy to add greater control and stability to the project.

Advantages: Clear separation of under-development code and production; streamlined release management.

Disadvantages: Bad fit for CI/CD processes; a complex workflow with multiple branch types and merging strategies.

‍

The Agile Strategies

Feature Branching

‍

‍Feature branching enables parallel development, isolation, and collaboration among developers. It places the emphasis on agility, collaboration, and shorter feedback loops, which is why it is one of the more popular branching strategies employed with many development teams, including well-known engineering organizations like Atlassian.

‍

TL;DR:

In the Feature Branching Workflow, developers create a branch for each new feature.
The 'main' branch contains the official project history, and feature branches are used to develop new features outside of the main project.
When a feature is complete, it's merged back into the main branch.
Different instances of this flow are known as ‘Github Flow’ where code is pushed to production upon its merge and ‘Gitlab Flow’ which schedules code for release across one or more staging branches. ‍

When To Use It

Due to its flexibility this strategy is suitable for teams of all sizes, although it should be noted that it can become complex for larger teams if branch management is not done properly. This is oftentimes the go-to strategy of choice for those who want both agility with some semblance of control and isolation.
‍
Advantages: This strategy is great for collaboration as each feature branch allows developers to work on new features without disturbing or impacting the main branch, which is kept production ready. Yet on the collaboration side, changes can be shared and discussed before being merged into the main code base.

‍Disadvantages: Probably its biggest downside is that it can lead to "merge hell" if not managed properly. This tends to happen when many branches are created and worked on concurrently, making the merging process a complicated and time-consuming task.

‍

Trunk-Based Development

‍

Trunk-Based Development allows agility, large-scale collaboration and fast-paced development. This strategy is common in organizations that practice continuous integration and deployment, and is used in conjunction with feature flags (with tools like LaunchDarkly). It is often used by large consumer-facing companies such as Google, Meta and Netflix.

‍

TL;DR:

Trunk-Based Development is a branching strategy where all developers work on a single branch, usually the main branch or "trunk."
Short-lived feature branches are created, but they're merged into 'main' as soon as possible - usually before the developed feature is complete.
Continuous integration tests are run to ensure 'main' is always in a releasable state.
Feature flags or toggles are used to enable or disable unfinished or experimental features. ‍

When To Use It

This strategy is useful in organizations that prioritize continuous integration and deployment, over isolation or control. While enabling velocity, this does require discipline to keep the main branch always in a releasable state so that unstable code is not inadvertently pushed to production. In large companies like Meta and Google, this is the only viable strategy - as any branch that splits off main falls hopelessly behind extremely quickly, making merging back an impossible task.

‍

Advantages: This strategy encourages regular code integration, decreases the complexity of merging changes, and supports continuous integration and deployment practices.

Disadvantages: The constant integration can lead to problems if not done carefully. This format requires strong release engineering to support it, and additional feature flags / toggles tooling to ensure experimental and unfinished features aren’t released at large without proper controls.

‍

While it may appear that the more “agile” approaches have similar principles, they prioritize different aspects of the engineering workflow. The Feature Branch workflow allows more flexibility in terms of when deployments happen; Trunk-Based Development emphasizes regular code integration and continuous delivery.

‍

How to Choose Your Strategy

Some of the key factors to consider when selecting or changing the branch strategy for your engineering organization are:

Release frequency
Risk tolerance
Project complexity
Team size

Regardless of the strategy you employ, the version control system you choose should provide the following:

Fast branching and updates
Flexibility
Ease of resolving conflicts
Real-time collaboration

The next generation of cloud native version control systems should focus on all of these elements to ensure that modern engineering can deliver fast and stay safe. There is also a need for better automation of processes like merges and conflict resolution; these may be greatly improved in the near-term by leveraging new generative AI tools, which promise to free us from mundane and frustrating tasks - but this deserves a separate post.

How to Version Your Unity project with Git

Mina Pêcheux — Wed, 05 Jul 2023 15:46:35 +0000

If you have a bit of Unity experience, then you know that game projects are complex beasts that contain a wide variety of files - from source code to graphical assets, a Unity folder hierarchy is divided in quite a lot of subfolders with a plethora of file types.

Yet those files need to remain structured and organised, otherwise it’s a recipe for disaster!

That’s why, in video game development as in other domains, we have to follow good practices and version our code thanks to Source Code Management (SCM) solutions - also known as Version Control. And one of the best-known tools for this is Git which is still, to this day, a favourite among developers (as shown in a previous survey we conducted)... although as we’ll see in this article, it’s not always suited for versioning game projects, and it requires some adjustments in your Unity settings.

Tuning your project’s settings for Git versioning

Versioning a Unity project with Git is not exactly plug-and-play; indeed, it’s essential to understand how to properly specify the SCM which files are relevant and which should be ignored - and to ensure you really commit all your project’s data, in particular the relationships between your assets.

Using the right `.gitignore` model

Now, if you’re ever faced with versioning your first Unity project, you might be a bit frightened by all the files you’ll need to commit and update... but fear not, there are actually some good practices to keep in mind when versioning a Unity project hierarchy with Git to reduce the amount of versioned files!

As is the case for most Git repositories, it’s crucial to properly tell the tool which files or folders it can safely ignore without losing any data in the process, thanks to a .gitignore file. For Unity, this .gitignore typically includes at least the following:

/[Ll]ibrary/: Luckily, Unity projects don’t need to be shipped with all of their dependencies directly! For versioning, you can just share the Packages/ folder that contains the manifest.json and packages-lock.json files: those files are simple metadata lists that detail all the required lib dependencies and will allow another Unity instance to retrieve all the needed packages in the right version.
/[Oo]bj/, /[Bb]uild/, /[Bb]uilds/...: All the files that are auto-generated by Unity during compilation, or at runtime, can of course be ignored since another Unity instance will re-generate them when the time comes.
*.tmp, /[Tt]emp/ and /[Ll]ogs/: The temporary files can obviously be ignored since they’re worksession-related (they’re created dynamically when you start up Unity and destroyed when you close it, and they depend on the machine you open the project on).
/[Rr]ecordings/ and /[Mm]emoryCaptures/: Those files can quickly grow in size and hurt your storage usage - plus, they can contain sensitive data.

This list is far from comprehensive - to get a full example .gitignore file, you can either:

check out this official sample, and copy it in your own Git repo
or, if you’re just creating your project and you’re using Github or Gitlab for example, reference this template in the UI to add directly to your project:

Of course, if you have any types of credentials in your Unity folder (such as keys for publishing to the Apple Store or Google Play, or a unique Unity Pro id), you should definitely add these to your .gitignore too. Because don’t forget that even removing these files with a new commit won’t erase them from the repo’s history :)

Checking a few editor settings for even cleaner repositories

In addition to excluding the unnecessary files and folders with your .gitignore, it’s also important to tell Unity how to properly store and reference the files that you do wish to commit and version.

Keeping the references

First of all, you have to remember that a game project is not just a bunch of code snippets and assets tossed together in a big pile; all of these pieces of data have to be linked and referenced the right way so that you eventually get the expected interactions and an actual playable thing!

In a Unity project, these connections and references are handled by the famous .meta files - the Editor automatically creates one for every folder and file in your project. And yet, if you explore the hierarchy of one of your game projects outside of the Editor, by default, you won’t see any of these .meta files.

Similarly, by default, Git versioning won’t be able to see these .meta files and it will thus lose all these references in commits.

To avoid this and actually keep the connections, you need to go to the Project Settings panel and, in the Version Control section, set the Mode option to Visible Meta Files:

If you take another look at your project in your OS file explorer, you should now see .meta files next to each folder and asset:

Versioning the assets more easily

Another interesting setting is the asset serialisation mode. If you want your project to be more adapted to Git versioning (which is a text-based SCM tool), then you can force Unity to serialise the assets as text.

Once again, go to your Project Settings and, in the Editor section, make sure that, in the Asset Serialization block, the Mode is set to Force Text:

This will make your Unity assets easier to version for Git... but, sadly, it doesn’t solve everything!

Important note: After any of these changes, don’t forget to save them explicitly by going to the File | Save Project menu ;)

Handling large assets

Asset management is a big topic (as we’ve already discussed in this other article), and anyone who’s tried to use version control on multimedia projects like video games or animation movies knows that the common SCM tools can’t always cut it. Especially when it comes to versioning large and complex files such as images, movies, 3D models or audio clips.

The problems with multimedia files

Large binary assets are always the pain point when using Git - and for several reasons:

First and foremost, Git was not designed to deal with these types of files. Its text-based philosophy is excellent for versioning code or, to a certain extent, project configuration files, but it really lacks some features for multimedia assets.
Even if you manage to commit and store your files, don’t hope to get easy-to-read version comparisons for your images or your videos: while Git providers like Github or Gitlab offer pretty impressive tooling for browsing your code history and studying the changes made by your peers in the codebase, they don’t have anything remotely as efficient for binary assets. \ And if your file is too large, you won’t even get a preview - that’s typically the case for audio files:

Moreover, those large assets are often resources created by artists - and Git is by no means easy-to-apprehend for non-coders. Versioning these assets therefore either implies that the artists take time to learn how to use Git (or at least a UI Git client), or that you devote a team member to integration.

These issues shouldn’t be ignored because Git is still the go-to versioning tool for a lot of developers, so many will just use it as a reflex when they set up the project. But if you’ve not properly assessed whether it’s fit for your team, you might run into quite a number of difficulties later on, when you bring in your actual assets.

Of course, the Unity team and community are well aware of these problems, and there are a few tricks you can learn to mitigate them...

Improving the management of your large files

Now that we know large files are the most common issue for Unity Git versioning, let’s discuss some interesting techniques for better configuring and storing them.

Testing and limiting the size of your images

An obvious but important thing to keep in mind is that your files shouldn’t be larger than needed. This is particularly valuable for images since, by picking the right format and the right resolution, you can greatly reduce the file’s size and thus improve your storage consumption.

When you’re working with bitmap images, there’s always this concern that the asset might be scaled up somewhere, and that it will end up blurry if you, as an artist, haven’t prepared a file with a high enough resolution.

However, all in all, games aren’t that responsive - sure, you’ll want to accommodate for various platforms and screen sizes, but you don’t necessarily have to prepare each and every image in your project for a 4k display. So a good process is to keep a high-resolution source file archived somewhere out of version control, and only include the final exported assets in the versioning, while making sure those exports suit the project’s needs - no less, and no more.

In order to check if a given image size works for your game, it’s possible to actually test it out inside Unity by defining a maximum resolution for the image asset in the Editor at import time, and then verifying it’s okay in-game:

This import setting doesn’t modify the image file itself, it simply limits the max resolution inside Unity - so you can use this setting to check down to which resolution the image is still legible in your game, and then re-apply those settings to your export to actually reduce the file size.

Re-using instead of duplicating

Another nice trick is to try and anticipate your asset variations, and produce some base that can then be transformed automatically into the other alternatives, without duplicating this file over and over again.

For example, consider a 2D platformer game with some little characters jumping around, each for one player. Each avatar has the exact same shape, but the colours have to be different to distinguish between each player:

Now, suppose that these sprites are defined in a spritesheet, so as to have all the animations and poses. Then, a naive solution could be to prepare one spritesheet per player, and vary the colours on each, right?

The problem is that this is very risky in terms of maintainability (since changing a chunk of one spritesheet requires the artist to update all the others the same way, and this is very error prone), and it is absolutely not efficient in terms of storage. A better solution is thus to use some colour-swap shader to create per-player colour variations, and switch the colour palette of the spritesheet accordingly.

And it’s the same for materials, which can be customised at runtime using a MaterialPropertyBlock instance; or sounds which can be re-pitched and even chopped down to create other audio clips; or 3D models that can be combined to form unique sets.

Using Git LFS... or not?

Finally, it’s worth talking a bit about the Git Large File Storage system, also known as Git LFS.

In short, Git LFS is a Git command-line extension that is meant to simplify the versioning of large files. As explained on the tool’s main page, the goal is to better deal with heavy resources (up to several GB), keep your main Git repo manageable by externalising these large assets and benefit from faster push and pulls on these big objects, all the while working with a Git-like solution.

That’s very nice and this page also shows you how quick it is to start using Git LFS... unfortunately, from my own experience and the experience of many users, Git LFS becomes a real thorn in your side the minute you install it in your pipeline.

From my own experience, it’s true that Git LFS does make the push and pulls faster. However, it also requires you to list all your “asset types” (meaning the file extensions you consider like large files, and want to include in this alternate system). And that you maintain this list. And that you migrate your previous assets that fall under this list, if any, to the Git LFS system. And you can’t really use SSH easily, so you’re bound to fall back to HTTPS transfers, whereas your main Git repo may be using SSH.

Oh and, yes - if you’re mixing Git LFS with Github or Gitlab, the moment you begin to really store some fair amount of assets, you’ll need to buy additional LFS data storage, and this can quickly grow to a significant amount of money.

That’s an awful lot of trouble - even though, to date, Git LFS is about the only Git-solution for managing your large files. So, does that mean despite its wide usage among developers, Git is not suited for versioning video games? Should we try and find another SCM tool that’s better at handling our heavy assets?

Switching to a SCM with native large file management?

At this point, it’s clear that although Git is the de facto SCM tool in many domains, it’s not the perfect fit for game projects versioning. In particular, its lack of support for large files severely complicates the management of a Unity project for example. So: wouldn’t it be cool to find an alternative that both coders and artists can use, and that handles large binary files better?

Well, actually - there is one worth taking a look at: a cloud-native SCM tool, currently in beta, called Diversion.

Diversion is working hard on integrating large assets management in the normal versioning pipeline, no addons required, and with an easy-to-use interface for devs and artists alike. So it lets you version your source code and your big assets next to each other in one unified way, no matter their size:

This way, your team can keep together all the project files and rely on just a single tool, rather than extending the SCM solution with command-line plugins specifically for one kind of asset!

Conclusion

Git is still one of the most used versioning tools nowadays, and in lots of domains, it’s great for the job. However, with video games, there are some challenges that Git just wasn’t designed to solve - most notably, the management of large multimedia assets like images, movies or audio clips. So if you use Git for versioning a Unity project, there are a few guidelines to follow to make your workflow more manageable and streamlined.

When you want to store and version your heavy assets, you can rely on a command-line extension called Git LFS. It makes your push and pulls way faster, and it provides better examination tools for those big binary files. And yet, this tool is far from perfect, in particular because it’s not that easy-to-use, and you have to keep track of which file types should be handled by this alternate system.

On the other hand, other SCM solutions such as Diversion take this fact into account and aim at providing creators (both artists and developers) with a user-friendly scalable tool, capable of handling small code snippets and large asset files. So if you’re not satisfied with your Unity Git versioning, or if you’re curious about this alternative solution and you want to learn more, check out Diversion here!

3 Reasons Game Developers are Looking for Perforce Alternatives

Yuki Arbel — Mon, 29 May 2023 12:31:10 +0000

Version control is key to software development of any kind and games are not different in that sense - any serious game developer (from indies to AAA) use some shape or form of version control as part of their development infrastructure.

Nevertheless, Game development requirements are somewhat unique so version control tools stack up slightly differently than the way they do for “generic” software development. Perforce (or more accurately HelixCore from Perforce Software) is known to address many of these unique requirements pretty well. In a survey that we conducted among game developers, we learned that Perforce was used by 28% of respondents - a huge market share compared to its foothold in other software market segments. Perforce themselves report that they are in use by 19 of 20 top AAA game vendors.

Speaking to many game developers as part of our exploration of the domain - we learned that even game developers that are heavily invested in Perforce as a version control system have “one eye open” for a Perforce alternative. Some assign the search to a special task force, and for others this is only a wishlist item for the infra team… but it is always present - and here’s why:

‍

Why It’s Attractive

Perforce has been around for many years and many of the competitors it had in the 90’s are no longer with us. When Perforce started, Git was not even conceptualized. During that time, it has built robust software and a broad set of features, but if you look at its current focus, it is game development companies, and other vendors that have to manage versions for very large projects and very large files. This is because Perforce is known for its scalability - the ability to handle very large files and repositories.

Another key feature that is attractive to game developers is the ability to integrate perforce into the IDE’s of the two leading game engines - Unreal Engine from Epic Games and Unity. Interestingly enough, Unity has recently acquired a version control tool Plastic SCM (now rebranded as Unity Version Control), so it remains to be seen to what extent this integration will still be maintained.

‍

And - What the Challenges Are

One major complaint about Perforce is the complex setup and maintenance it requires. As a tool developed back in the 1990’s, and not undergoing an architectural overhaul since, Perforce server is software that needs to be installed on a dedicated server. Being in the era of SaaS (with version control tools like Github, Gitlab and Bitbucket available as SaaS), developers are reluctant to invest excess IT resources running legacy infrastructure and the fact that Perforce still requires them to do so is considered as a drawback.

Another related disadvantage is the smaller set of modern integrations it has compared to other cloud native version control tools. Perforce did start pivoting towards a cloud offering, however it’s more or less the same software, installed on a server provisioned in the cloud - and still requires complex maintenance and configuration.

Finally, probably the key reason game developers are looking for Perforce alternatives is its cost. Perforce pricing (per-seat) is considered to be very high compared to alternatives, and combined with the cost of setup and maintenance you end up with a pretty high Total Cost of Ownership (TCO) making it prohibitive for smaller players, and a noticeable expense for the larger ones.

‍

What to Consider when Looking for a Perforce Alternative

When looking for alternatives, there are a few evaluation criteria that are unique to the game development industry. First and foremost: scalability. Game projects tend to be large and include many large binary files. Version control tools have to cater for that and apparently not all of them do this all that well. Git, for example, has a limit on its file and repo size, and game developers typically have to use Git-LFS to be able to use Git reasonably (but even that doesn’t work all that well).

Another key criteria is the simplicity of use: game development companies typically have game designers and artists as part of their staff, and they typically prefer simpler interfaces than those offered by version control tools.

The main alternatives game developers have to choose from are Git, SVN and Unity Version Control (which is how Unity packaged their acquired Plastic SCM). A recent article in The New Stack provides a good roundup comparing between the various alternatives. Spoiler: no tool is perfect and something’s got to give…

We at Diversion are looking closely at the needs of the game development community and are building a modern, cloud native version control tool to make their life easier. If you’re looking for a Perforce alternative, be sure to check it out here.

The Key To Proper Asset Management In Game Development

Yuki Arbel — Tue, 21 Mar 2023 20:11:11 +0000

The world of software development has changed and evolved significantly over the last two decades from when Git was introduced. The world of cloud and microservices, CI/CD and automation have introduced scale, efficiency and velocity made possible through as-a-service models for both software and infrastructure. However, there is an entire industry that could not derive the same benefits that traditional software has seen, due to its own unique complexities. Much in the world of game development has not significantly or sufficiently evolved, due to its inherent limitations of size, performance, and collaboration that look quite different in the game development world.

A core piece in the complexity is a byproduct of how gaming assets are created, managed and versioned in game development, which is quite different from typical software engineering disciplines. From 3D models to audio files, textures, and other media, game assets are critical components of any game development project. This is why managing game assets efficiently is essential for creating high-quality games, and source control systems can play a significant role in this process––both in managing the assets and from a collaboration perspective.

‍

With much of the modern software delivery world relying heavily on Git and the SaaS tooling that makes git source control available at scale (from Github to Gitlab and Bitbucket), the world of game development requires different capabilities, as noted in previous posts––leaving game developers to work with a different set of SCM tools. As a byproduct, there is often much less community and ecosystem support and help that focuses specifically on these unique complexities.

‍

In this blogpost we’d like to focus on this specific area and explore the different source control systems that are optimized for game development, alongside best practices for how to manage game assets effectively. We'll cover the benefits of using source control systems. We’ll focus on the basics of asset management, version control for asset management, and how this applies to your source control of choice.

What is Asset Management?

Assets are a core component in games, and asset management is a crucial aspect of game development that involves organizing and tracking all digital resources used in the game.

‍
Asset management is typically comprised of several steps in the process, as follows:

‍

Asset Creation.

‍Asset creation involves creating digital resources such as 3D models, textures, animations, audio files, code, and other resources that are what constitutes the game elements. This process can be done by in-house artists, sound designers, and developers, or outsourced to external contractors. Depending on the type of asset, it may require close collaboration between asset creators and engineering.

Asset Organization.

‍After assets are created, they need to be organized and stored in a central repository for collaborative work. This repository could be a version control system, a cloud-based service, or a local file server. A good practice is to organize assets based on their type, such as 3D models, textures, or audio files, and should be easy to locate and access by team members.

Asset Integration.

Once assets are created and organized, they need to be integrated into the game engine. This involves importing the assets into the engine, optimizing them, and testing them in the game engine to ensure that they work as intended. Integration can be done by artists, designers, or developers depending on the asset type.

Asset Tracking.

‍As assets are integrated into the game, it's essential to keep track of changes made to them. This is typically done using version control software, which allows teams to track changes made to assets over time, collaborate on asset creation, and revert to previous versions if needed.

Asset Reuse.

‍Like other software development disciplines that leverage boilerplate code, and reuse types and other objects, game developers often reuse assets across multiple projects to save time and reduce costs. Asset reuse requires proper documentation and organization of assets to ensure that they can be easily located and used across projects.
‍
With all of this in mind it is really critical to have a strong version control and source management solution that is optimized for the diversity of collaborators and stakeholders in the game development world. This is where the right SCM comes into play, and has a huge impact on the speed, quality, and productivity of game development teams.

‍

Why Your SCM is Important for Asset Management in Game Development‍

Version control software (AKA source control management––SCM) is the backbone of modern engineering practices, and it provides essential features for efficient asset management critical in today’s engineering processes. A good place to get started is this post, on the current state of the SCM union for the game development world (read: Unleashing Git for the Game Development Industry).

‍This begins with structured workflows that all of the collaborators and stakeholders in the organization can align with, making it possible for teams to manage their assets in a more organized and efficient way. Another mission critical capability that version control will provide is backup and recovery: Using a version control system allows teams to back up and recover binary files, which can be especially important for these large and complex files that would take a significant amount of time to recreate.

‍As the name implies, version control also provides much-needed versioning and change history of binary files, which can be used to track progress, understand changes made, and document the development process. While merging is not possible for binary files, version control software still enables collaboration by allowing multiple team members to access and work with the same file. Some version management tools also allow checking-out/locking a file so that it is not modified by two people in parallel to avoid conflicts. One way this comes in handy with version control software is branching. This allows teams to create separate branches of a binary file, which can be useful for experimenting with different versions or testing new features without affecting the main branch of the file.

‍Finally no piece of software is complete without verifying its quality, through reviewing and approval processes. Your SCM will enable you to review changes made to binary files and approve them before they are implemented in the game engine. This can help to ensure that all assets meet quality standards and are error-free.

Choosing the Right SCM for Game Development

The first step though, and likely the most important is choosing the right system for your needs. This is an entire blog post unto itself (and we plan to release one soon on this topic - so subscribe if you’d like more on this topic), but just to touch on this briefly––this should be based on factors such as the size of your project, the number of assets you're managing, and the type of assets you're working with, as well as other SW development practices and processes you apply across your company. The popular tools leveraged for game development include Git, Perforce, SVN and Unity PlasticSCM.

There really is a lot that can be said about each of these, but the most critical pieces you would need to explore is large binary file support, performance with large repositories, branching and merging capabilities, as well as collaboration through permissions and access control to files and repositories. Each of the popular tools in the ecosystem plays to different strengths and use cases, and we’ll be sure to dedicate a post to this in the coming weeks.

Once you've chosen a source control system (check this post out for some stats on version control for game developers), you can start applying best practices for asset management, which we’ll dive into below.

Asset Management Best Practices

Once you have proper version management in place for assets, you are halfway to having an efficient process for asset management, as basic aspects, regular backup, are covered for you.

‍Let’s dive into some good practices around asset management processes and workflows that are built around how you leverage your SCM and play to its strengths.

‍Like software pipelines, assets should be handled in a similar fashion. It’s a good practice to establish a clear and well-defined asset pipeline to manage the flow of assets from creation to implementation. This will also ensure that all team members are aware of the process.

Another good practice that contributes to effective teamwork and workflows is defining a consistent naming convention for assets. This makes it easier to locate and manage files that multiple collaborators need to work on. Suggested methods are to include information such as the type of asset and the date it was created. Once you have good processes, and naming conventions, knowing where to find these key assets is important.

‍This is where your SCM or cloud storage comes in to provide a central repository where all assets should be stored that is easily accessible to all team members. This helps to prevent duplicate files and reduces the risk of lost or misplaced assets. When these types of files are stored in a centralized location, their size can impact cost and performance, and this is where asset optimization comes into play.

‍Optimizing assets such as textures and models can reduce file size and improve performance. This can be achieved by reducing polygon counts, compressing textures, and using LODs. Storage is also expensive, so the additional value of reducing file size is that you can also derive cost benefits.

‍After all is said and done, one of the backbones of great collaboration that is often underestimated is documentation. By taking the time to create great documentation regarding the creation, modification, and usage of assets you can ensure that all team members are on the same page and can easily refer to previous decisions and iterations.

‍Finally we come to actually making use of your assets, and no engineering assets should be pushed to production without proper testing. Make sure to take the proper time to test your assets in the game engine to help identify issues early in the development process, and ensure that assets are working as intended.

‍SCM & Proper Game Asset Management

Eventually game development is not much different than other software engineering disciplines. There are mission critical assets that need to be properly maintained, backed up, versioned, and managed for productive teamwork and operational best practices.

‍Choosing an SCM that is optimized for game development will help you overcome some of the unique challenges in the game development world when it comes to asset management and collaborative work. Once you have a good SCM to help with the version control, backup and collaboration, you can then set out to apply best practices for processes and workflows to ensure you manage assets properly in the long term.

‍In our next posts we will dig deeper into the game development world, and provide more insights into unique challenges for gaming engineers.

Version Control for Game Devs: Survey Results

Sasha Medvedovsky — Tue, 24 Jan 2023 15:10:51 +0000

Yuki Arbel, January 24, 2023

"Listening to your customers is the key to building great products"

Anonymous

At Diversion, we are building a next generation Version Control tool, with a strong emphasis on addressing the unique challenges faced by game developers. It’s no secret that the games industry is underserved by existing solutions (see here), but we wanted to hear first hand from game developers about the tools they are using, how they use them, and what challenges they encounter.

With that in mind, we ran a survey among professional game developers. Obviously, people are busy, and you need to show your gratitude for their willingness to contribute, so we added a raffle for VR goggles. We ended up with more than a 100 respondents before closing the poll.

‍

Who responded to our survey?

We asked people what size of organization they are currently working for. We thought this could be important in order to look at usage patterns and challenges also from that angle. It is one thing to be an indie developer or work with handful of colleagues, and another to work in a large enterprise split across continents. 45% of our respondents work in small companies (up to 100 employees), 40% work in midsize companies (up to 1000 employees), 15% work in large companies (larger than 1000 employees). We’ll get to some analysis using this information later on.

‍‍

So, which version control tools are game developers currently using?

Our main goal was to find out the distribution of version control tools among game developers.

Git is by far the most common version control solution reported by game devs (used by 82% of respondents). However, approximately 25% of those who use Git also use another version control tool in addition to it.

Other version control products used by survey participants:

Perforce (28% of respondents)
SVN (6% of respondents)
Plastic SCM (4% of respondents)

There were also 2 respondents reporting using an internally built version control system (which might indicate a lack of adequate solutions, and is probably less than ideal for a game development company).

Differences by company size

We looked further into the tools usage patterns, to see if they depended on organization size. Perforce is much more common in larger companies than in the smaller ones. More than 38% of respondents working for mid to large companies (companies larger than 100 employees) use Perforce, compared to 11% in smaller companies (under 100 employees).

Graphical assets

Binary files, and especially graphical assets, are a huge problem (pun not intended) in game development. We wanted to check how game developers deal with this problem.

First, we wanted to check whether designers use version control to store the assets that they create. It turned out that nearly half of respondents (45%) say that designers in their company use cloud storage to store the assets that they create. We assume that part of the reason is the complexity of using version control (which we were able to correlate from other responses they provided), as well as large storage volume required to store versioned assets (as version control products don’t have a way to manage that).

‍

Then, we wanted to check how common it is to keep graphical assets in version control (at least the end result of artists’ work). 78% of respondents who use Git and were familiar with the topic reported that graphical assets are also versioned. We’ve got a few more detailed responses explaining that only the final assets are versioned, which makes us believe this may be a typical scenario.

‍
Since large files don’t work well in Git, we wanted to cross correlate this with the use of Git LFS. 59% of Git users reported they are also using Git LFS to handle large files (some of them reported about problems with it, but this deserves a separate article).

From direct interviews we know that some companies who use Git to version code, are also using SVN or Perforce in conjunction with Git to store large assets. This of course is not optimal, as it complicates the toolchain and reduces the team’s ability to collaborate effectively. This might explain the high percentage of cross-usage between Git and SVN/Perforce.

‍

Hosting

While the global trend is to move hosting to the cloud via SaaS, all prominent Git vendors also offer their product as software that can be installed and maintained by the customer himself. We wanted to understand to what extent this trend is applicable to game developers. First, we wanted to learn how many of our respondents consume their remote Git as a cloud service vs. install the software on-prem. Approximately 22% of our respondents were not sure about this, but from those who did know where their Git is hosted, approximately 2/3 are using the cloud, and 1/3 are hosting Git on prem.

‍

Next, we wanted to understand the split between the different Git offerings in the market. The majority of companies are using Github (41%), followed by Gitlab (30%) and Bitbucket (22%).

‍

Challenges

Finally, we wanted to explicitly ask about challenges. After all, we are building Diversion in order to better address existing challenges with version control products, so we’d better know what they are.

Many respondents that use git reported on challenges they are having with the solution. Here are the top 3:

38% of respondents who use git indicated it is too complex for use by non-developers
25% of respondents who use git indicated it has poor support for graphical assets
21% of respondents who use git indicated it is slow ‍

We also asked about challenges with Perforce. One of the challenges that was highlighted by users for Perforce was complexity of use by non-developers (seems to be a common theme). Another challenge that stood out in the responses was a poor branching experience.

Finally, we asked about the existence of a dedicated team handling the version control tool. While this does not necessarily translate to a challenge for the end users, it does impose costs and an operational burden on the organizations. To this question, 64% of respondents who were familiar with the subject, indicated that such a team exists in their organization.

‍

File conflicts

One common challenge that we haven’t included in the survey, but that has surfaced in interviews we conducted, is file conflicts. One company we talked about told us they have a slack channel where artists ask each other if someone’s working on a specific art file (of course, sometime this workflow fails). Others have reported frequent and impossible to solve merge conflicts in Unity or Unreal Engine’s files (scene files, prefabs, etc.). Some version control tools offer an ability to lock files (not Git); but this introduces other problems (people forgetting to unlock files). None of the companies we’ve talked to uses file locking - clearly, a better solution is needed.

‍

What’s next?

As we can see, version control remains a significant challenge in game development. The most probable reason is that the popular version control tools were not built with game development in mind, or are just very old and were not built for today’s scale.

We continue to work hard to get Diversion to you. It’s currently in private beta to our early subscribers, and we plan a wider release in the coming weeks. Stay tuned!

Secure By-Design Storage for Your SCM

avi-mastov — Mon, 08 Aug 2022 09:37:36 +0000

The widely adopted SCM tools we use today, Github and Gitlab, are built on the dated architecture and design of git. I recently happened upon this thread on HackerNews that talked about a lot of the pains we’ve spoken about in our article On Git and Cognitive Load. These aren’t the only issues with Git, many of them are just really simple missing features that are no longer aligned to our current engineering practices, take this post on Folder (Non)Tracking, and today I want to talk about common workarounds (AKA hacks) for secure storage with today’s SCMs.

When we build applications, from mobile to desktop, across industries we often have many configurations in order to connect our applications to external services. Some of these services are required at runtime (e.g. ad networks, configuration servers, analytics), and others at build time (e.g. code signing). We’ll dive into some of the challenges third-party services and imports introduce into our development processes.

Common Challenges with Securing Credentials in SCMs

With security taking center stage over the past few years, from the code to the build processes - shift left to DevSecOps, many best practices have been formalized for handling the credentials to our third-party services and supply chain. For example, for good security reasons, credentials to the services described above are usually not stored inside the SCM. What is usually done is that each developer has their own local ‘.env’ files that store their environment variables for quick access in development processes. These files are set to be ignored from commit processes by the SCM so that they do not propagate to your git repository and remain there for all of posterity.

However, in order for these services to run properly, these credentials do need to be accessible to the running service in production or at build time, and so the way this works is that the CI/CD platform of choice then has its own copy of these secure variables. These are then either injected into the code at build time or used at build time to sign the app itself.

While this is important for defending our systems, and ensuring our secrets and environment variables are not exposed to would-be hackers, this does add a lot of complexity to the management and maintenance of our environments and systems, and can be tedious to keep up with.

This, to us, is yet another area that git and similar SCMs have not kept up pace with modern engineering and the attack landscape. With the amount of data and services running in the cloud, that require remote access, and are interdependent as chained services - the communication between these services is critical, while security cannot be compromised either.

There are products who have tried to address this known challenge, such as Fastlane’s Match, that stores code signing certificates for iOS in a dedicated git repo. This makes it possible to use just one setup for both your local development environment and for the CI/CD to access the same credentials. The drawback is the git repo itself. Over time, the files it contains grow so big, that the cloning starts to take so long that it becomes the most significant part of the build time.

This isn’t scalable, and ultimately is a huge time sink on our most valuable asset - our developers’ time. Recently Match started supporting alternative storage - Amazon S3 and Google Cloud, which is great progress. No point in keeping revoked certificates in version control, taking up space and increasing clone time, right? However, it just replaces one problem with another of the same type. Now you need to store access credentials to S3 / GC. The documentation reads:

When running fastlane match init the first time, the setup process will give you the option to create your gc_keys.json file. This file contains the authentication credentials needed to access your Google Cloud storage bucket. Make sure to keep that file secret and never add it to version control. We recommend adding gc_keys.json to your .gitignore

Back to square one, then. Each developer and the CI/CD need their own credentials file, so additional setup needs to be done between cloning the repo and being able to run or distribute the code. The same thing applies to using a git repo to store the certificates, because it’s a different repo than the one that contains the codebase, and usually requires another SSH key for access. Oh, and I forgot to mention you also need a passphrase to decrypt the Match repo, which is another secret to worry about.

This is a good resource to reference on code signing, and the complexity involved. I’ll also add that currently Match is the only solution trying to overcome this challenge without compromising your credentials to the Apple Developer Portal - so it’s a good effort on their part, and a useful utility, despite some of its drawbacks.

Scaling Secret Management - Truly as Code

For this to truly be scalable these important variables need to be stored inside the native workflow and context, and be easily maintained. What if you could just store all this data inside your regular repo, but somehow mark the relevant files as sensitive and/or volatile? What’s more, what if we could have them secured and replaced with different versions at will (per environment or per user)?

A post about security and DevOps wouldn’t be complete without some reference to GitOps. So let’s talk about roles and policies, and how all this could come together. We’ve established that it would be really great to have a “secrets” folder inside our regular ol’ repo. Once that happens, we would be able to leverage this repo, manage and apply policies like we would any other repository in our organization. We would be able to define who has access to these folders, and make that possible only for certain roles, and in our favorite way–as code (e.g. with separation for dev and prod).

From a cost optimization perspective (as we head into a bear market), this would not only save us the setup and troubleshooting time, but also the added cost of additional tools in our stack just for secret management.

From Git to Developer Experience - It is Possible

When it comes to git, it’s clear that it wasn’t built with developer experience in mind. However, this could also be a byproduct of the times. Perhaps that’s what developer experience looked like historically with little external services, no CI/CD, less security in mind, and the features were sufficient then.

With the constant evolution in engineering processes - from the speed and velocity that code needs to be delivered to production, the many and multiple services that each application is broken down into, the evolving attack landscape, and even our processes and culture with global, distributed teams—the way we work together and collaborate on code is becoming a core piece of our developer experience, without compromising security.

At Diversion, as a team that dogfoods its own products, and wants to improve our very own git developer experience––we’re trying to find the many points of friction and ruthlessly remove these unnecessary obstacles from our development processes. What else is bugging you about git? Let us know in the comments.

Git and Folder (Non)Tracking

avi-mastov — Mon, 20 Jun 2022 14:16:23 +0000

We talk about Git a lot, because it’s simply the de facto way of collaborative engineering today. However, aside from the complexities with using git as a source code version control tool (you can read this post about it), there are other aspects with the way that git works that still require workarounds and hacks, even as they are known issues for many years.

One such pain remains in the lack of folder tracking in git. There are plenty of good posts on best practices with tracking folders (such as using .gitkeep or .gitignore files to track empty folders), and in this post, I just want to outline why this is important at all.

The Git Tracking Oversight

Git is a system built to track files only, but files –– as we all know –– are hosted in folders. This means that if you want to do an operation as simple as renaming or moving a folder, this will affect all the files hosted in that folder, and your repo status will show as though all the files under the folder (and its subfolders) were changed, when really only one folder name or path has changed.

Why does this matter?

There are a few reasons this is something you should pay attention to if you are just getting started with git, and we’ll dive into them below.

Real-World Scenarios and Recommended Workarounds

Let’s start with tools you may be using in your repository. Some of these tools (take the example of DBT), when integrating with your repository, will build a directory tree including folders that are required for the tool when it runs. Upon initialization though, these folders start empty and some of them will stay empty at the time of a new commit. Because DBT is a great tool, it uses the aforementioned practice to create dummy files (.gitkeep) inside the empty folders, in order to make the folders “trackable.”

In the event that folders are created in a repository with no such dummy file, they won’t be tracked and pushed to the remote, so if someone chooses to fork or clone your repository as-is, these untracked folders will not be present in the cloned repository. If a tool requires certain folders to exist to properly run and store future files, this tool’s operation will fail.

Tip #1: If you require a certain hierarchy to your repository, whether it’s for specific tools that require certain directories or even automation processes in your CI/CD, make sure to create a dummy file inside these folders so they aren’t lost when collaborating and sharing with teammates.

Another common scenario where tracking only files can cause a lot of pain is when moving or renaming folders. Content changes are often made in the same commit that the rename or move has occurred (refactoring). When this happens, git will treat all the changed files in the moved folder as completely new objects (because both the path and contents are different), and you will essentially lose their entire change history. On the flip side, if a teammate has not yet pulled or updated their local copy, and they happen to update any of those files pre-move or name change, this can create the type of merge conflicts from our worst nightmares.

This one is particularly painful, as it requires the entire engineering organization to hold its breath until this update is propagated to the entire engineering team. Depending on the internal processes, a pull request like this might require the same checks and balances as any other code changes, with peer reviews and merges, and the entire engineering team will be blocked from continuing work until this change is merged.

Tip #2: A good practice when planning on moving or changing a folder name is to complete this operation as a standalone and separate commit to any other code or file content changes. Push and then merge this change.

Once you have done so - be sure to update the entire engineering organization to the change and have them rebase their local copies before making any further code or file content changes. (Yes, you literally have to do all this, to not have any breaking changes due to the lack of folder tracking in git).

Important caveat: If engineers from the team are working on their own branches, they will not automatically sync with the main branch, so be sure to have them pull the main branch into their working branches.

However, the good news is, that if you do follow this process, you will maintain your entire folder and file content history after the move or rename, so make sure to follow this closely.

Knowledge is Power with Git

When it comes to working with our developer tools, knowledge is power, and can be the difference between painful mistakes like losing our entire folder or file history because we weren’t aware of the underlying fundamentals of our tools. Before you complete any potentially irreversible operation (rm -rf anyone?), make sure to read the fine print and know what you’re doing beforehand.

We need our tools to support our work and the pace of our engineering, and sometimes when we take the time to do things in the proper canonical order recommended, we will actually move faster, and not have to clean up unnecessary messes that will only slow us down.

We’ll continue to share good practices with version control, and how to work through its challenges, so stay tuned.

DEV Community: Diversion

The compounding effect of version control performance

Diversion performance boost

The compounding effect of speed

Fast branching changes the game

Art and code in a single repo erases artificial complexity

Wrapping up

About the Author

A step-by-step guide to versioning a Godot game project with Diversion

Exploring the Diversion version control tool

A quick note on Diversion’s pricing system

Creating your account

A quick peek at the Diversion CLI tool

Versioning a Godot game with Diversion

Preparing the Godot demo project

Initialising the Diversion repo

Exploring the Diversion web app

Working with branches

Why should I use branches when working with a versioning tool?

Using branches in Diversion

Conclusion

Choosing your weapon: SaaS or self-hosted version control?

A quick recap: SaaS VS self-hosted

The powers - and risks! - of SaaS version control tools

Benefiting from easy access & collaboration

Taking advantage of scalability & flexibility

Going to the cloud… for data protection & security?

What if you can’t access the cloud service?

Addressing the cost issue

To recap?

Should you rather pick a self-hosted solution?

Managing & “securing” your data

The importance & difficulties of operating your system

Working on a local network… a gift or a curse?

Predicting & lowering the costs

Understanding the challenges of self-hosted version control scaling

To recap?

So… what should you pick?

Conclusion

Can artists benefit from version control, too?

Why “coder-oriented” versioning tools rarely work for artists

Complexity & user-unfriendliness

Handling large asset files

Limited metadata editing

Merge conflicts management

Are there versioning tools for artists?

But - can’t we use Google Drive? Or Dropbox? Or emails?

Picking a versioning tool made for artists

Exploring modern versioning tools

Conclusion

Version control for your Godot game projects

Godot: a VCS-friendly game engine...

Enabling version control for a Godot project

Godot’s text-based settings file

... but not for large asset files!

An alternative to Git with better asset management?

Conclusion

The Agile, The Fragile, And The Iron Fist Of Branching Strategies

Structured Strategies

Release Branching

GitFlow

The Agile Strategies

Feature Branching

Trunk-Based Development

How to Choose Your Strategy

How to Version Your Unity project with Git

Tuning your project’s settings for Git versioning

Using the right .gitignore model

Checking a few editor settings for even cleaner repositories

Keeping the references

Versioning the assets more easily

Handling large assets

The problems with multimedia files

Improving the management of your large files

Testing and limiting the size of your images

Re-using instead of duplicating

Using Git LFS... or not?

Switching to a SCM with native large file management?

Conclusion

3 Reasons Game Developers are Looking for Perforce Alternatives

Using the right `.gitignore` model