Hello again! This is the second part in our series about setting up source control in GameMaker Studio 2. If you haven't read part one yet, I suggest you do so by clicking here.

In this post, we will cover how to deal with merge conflicts. The article is divided into the following sections:

• Quick reminder
• Setting your diff/merge tool
• Solving common merge conflicts
• Reverting to a previous version
• Useful external tools to consider

Disclaimer about screenshots: I am using a custom skin in GMS2. The windows may look different from yours, but the options are all the same.

Quick reminder

As mentioned in the first post, the basic loop when using source control is as follows:

Make Changes --> Save --> Commit --> Pull --> Merge --> Commit Merge --> Push

If you are working alone, the Merge and Commit Merge sections will most likely never happen (unless you are committing from a revision that is not the head). However, if multiple people are working on the same project, it is very hard not to modify the same file at one point or another, so you will encounter these merge conflicts. This article will explain how to identify and solve the most common ones.

Setting your diff/merge tool

GameMaker Studio 2 doesn't come with a built-in diff/merge tool, so you will need to download your own and set it up. There are many tools that achieve this purpose. I will cover how to set up KDiff3, but you can use your favorite tool.

First, go to http://kdiff3.sourceforge.net/ and download the latest version of KDiff3. Install it and remember the local path.

In GameMaker, go to Preferences > Plugins > Source Control (Git). You need to locate your diff/merge tool (it may differ from mine), and the parameters to send the program when it is called. This is what it should look like:

Here are the lines in question, to make it easier to copy/paste into your editor:

Merge

${scm_theirs} ${scm_mine} -o ${scm_merged}

Diff

${scm_base} ${scm_theirs}

We are asking the program to open three files when merging: the local file (mine), the file on the repository (theirs), and the output (merged). To diff, you only need two files, base, which is the version before the conflict occurred, and theirs.

With the diff/merge tool configured, let's take a look at how to resolve the most common merge conflicts.

Solving common merge conflicts

It would be impossible to cover every single possible merge conflict you may encounter while working on a project with other people. Identifying and fixing merge issues requires experience and running into these cases, but once you understand the basics behind the solutions, you will be on your way to solve any issue. The following are the most common conflicts you will come across.

After you commit your changes and pull from the repository, GameMaker will compare all the files and check for conflicts. If there is a conflict, you will get a window that looks like this:

In the big box, you will see all the files and events where conflicts have occurred. You now have three options:

1. Use Theirs. Ignore your local changes and use whatever is in the repository.
2. Use Mine. Ignore the changes in the repository and use your local ones instead.
3. Merge. Open the merge tool and address the conflict.

If you see a conflict on a file you don't remember changing, or you know the changes on the server are the most up-to-date ones, then Use Theirs. If you believe your changes are more recent than the ones in the repository, Use Mine. If you are not confident in what the most up-to-date changes are, Merge. This will open the merge tool and show you three files: The file in the repository, your local file, and an output file, which is the one that will be changed.

This is what it looks in each situation:

Updated a binary file (image, sound file, font, etc).

You can only merge text files (code, views, scripts, objects, etc). So, if the conflict happened in a binary file (image, sound, font, etc) then you need to either select Theirs or Mine. Merging binary files is not a valid operation.

Changed the same line

The highlighted lines are the ones where the conflict lies. If you right-click the conflict in the output file, can select the lines from file A, file B, or both. Once you are done, Save the output file (Ctrl + S or the save icon at the top) and close the diff tool and confirm if the merge was successful or not in GameMaker.

If you select No, the conflict will remain in the conflicts window. Else, it will be removed. You need to solve every conflict before you can push your changes.

Added two different sections at the same location in a file

In this situation, we have added two different pieces of code at the same place in a file. If you want to keep only one change, then do so. However, if you want to keep both, then select "files from A" and "files from B" in each of the conflict locations, and you will get an output similar to the one in the image above. Remember that you can modify the output file if you need (to change spacing, line breaks, swap statements, etc).

Added a different event to the same file

This one is tricky because the diff tool will count the number of events in your object and notice you have the same amount of events, but then it will think you changed one of them into another type of event. In reality, you added two different events to the same file which means you will want to add BOTH events to the file. In this situation, I recommend selecting lines from file A in both conflict sections (id and eventtype), copying the event from file B, and appending it to the end of the last event in the output file. Don't forget to add a comma between both events. This is what the output should look like:

This one is a good example of weird merge conflicts you will get which you may not know how to solve at first, but after you've seen it once, you have the experience and knowledge to fix it in the future without too much trouble.

After merging

When all files are successfully merged, you will need to commit again to reflect the new version with all the merges. GameMaker will generate a Commit Message for you this time around, which is useful. You can still modify it, but it's up to you. The message points out the resolved conflicts, like so:

Revert to a previous version

One of the most important features of source control is that you can revert (or roll-back) to a previous version of your project. Do this by going to Source Control > View History.

A window will pop up with three sections:

• Commit History: Shows you basic information about the commit, such as the date and time, the person who made the commit and the first line of the commit message. There, you can select the commit you want to explore and the bottom two sections will display the changes.
• Message for Commit: Here you will have a more detailed look at the commit message in case it was too long and got truncated.
• Files Modified in Commit: This shows you every file that was changed, added or removed in this commit.

There are a few things we can do from here. First, you can revert to a specific revision by right-clicking the revision in the top section and selecting Revert to this Revision. This will revert every file to be the same as what it was in that revision. Watch out, as this will discard any uncommitted. You can also double-click any of the modified files in the third section, to open a diff window, showing you the differences that file went through in that revision. Last, you can right-click any of the files in the third section to revert only that specific file, or files, to that version, instead of the entire commit.

Useful external tools to consider

There are several external tools you can use to get even more functionality out of your source control. Almost every GameMaker file is a text file, which makes it great for source control. The internal Git plugin is great, but it has limitations, such as not allowing members from forking from the main branch. It is viable to work on a project with only one branch, and it has its benefits (more frequent, but smaller merge conflicts, the project is always the most current one on everyone's computer, etc). However, working with multiple branches also has a ton of benefits, especially if some people in your team are working on incomplete features or sections of the game that break it for everyone else in the team. In these cases, they can either work by only doing local commits until they are confident they can push it to the server, or they can create their own branch and work there interrupting no one else. To get this functionality, you can use external tools and set up source control on the GameMaker project folder instead of using the Git Plugin. This is what I did when working on HackyZack and INK and the process was nice. The tools I recommend, if you want to follow this approach, are:

• For Git Repositories: GitKraken or SourceTree.
• For Mercurial Repositories: TortoiseHG.

I am always willing to help out if you run into any issues with the material covered in the article, or something else related to GMS2. You can contact me on Twitter.

Alejandro Hitti is a videogame Programmer and Designer from Venezuela. Although his background is in C++ and using custom-made game engines, his two commercial games, INK and HackyZack, were made using GameMaker Studio 1.4. With the release of GameMaker Studio 2, that became his engine of choice. The novelty of GMS2, paired with his knowledge of the previous version, ignited his interest to create tutorials that focus on this new engine.