• Hello [name]! Thanks for joining the GMC. Before making any posts in the Tech Support forum, can we suggest you read the forum rules? These are simple guidelines that we ask you to follow so that you can get the best help possible for your issue.

 Make GMS 2's project format more SCM friendly


Are there any plans for making GMS 2's project format more compatible with source control software?

So far with the beta, the source control integration has never been publicly tested. Like with GMS 1.x, the lack of such testing resulted in a project format that behaves badly with both SVN and Git. This hindered the adoption of source control as a standard in GM development, and led to a number of incidents when people lost projects in ways that SVN, Git or a comparable source control system could have easily prevented.

If using Tortoise instead of the built-in mechanism was enough, I wouldn't mind. But it still isn't enough because of views, both in their random naming scheme and the way they are enumerated inside the main project file. Conflicts between branches or working copies would be next to impossible to reconciliate.

With a strictly linear flow and only 1 developer, the current format works. But start branching or working in teams, and the whole approach falls apart. This is no way to move forward with a more professional audience.

With GMS 1.x, I think you've heard enough of my year-long whining about its SCM. I hope I don't have to whine like that again with GMS 2.x to make it done right.


YoYo Games Staff
YYG Staff
Are you finding specific problems or do you just want to whine?

Let us know if you have issues - source control will be in the next public update which is in test (and should be out pre-Christmas)



Are you finding specific problems or do you just want to whine?

Let us know if you have issues - source control will be in the next public update which is in test (and should be out pre-Christmas)

Here are the issues I'm finding with the project format and its effects on source control:
  • UUID view names don't safely resolve resource creation conflicts. For example, if developers A and B both commit a new obj_something to the project, the resolution doesn't make it obvious that they are fighting over the same resource.
  • Duplicate entries in the main project file. For example, a room is listed twice, once under resources and another time under room_order. With two or more divergent development flows, automatic merging is almost guaranteed to fail and be an illegible mess to fix.
  • Simply viewing a resource can register a change in the main project file. For example, when I imported the Angry Cats Space demo, simply re-opening the project for a second time caused the three scripts to shift position in script_order.
  • Idempotent changes can create new UUIDs that don't match. This can happen when manually undoing a small D&D or sprite frame change from a previous session that is too small to warrant a commit on its own.
And by the way, I'm making this post because gnysek has reported more or less the same findings, and he said he's being ignored. By you and Mike specifically, to boot.


Thanks for mentioning my post ( https://forum.yoyogames.com/index.p...s-into-the-folder-structure.13928/#post-91415 ).

I'm working with SVN/GIT/Mercurial for 8+ years now. Of course for PHP, JS & HTML work with VCS is very easy, for XML it's also not bad (as long as output isn't random, like it was in GM:S 1.0 for rooms) but I've also used it for C# projects, where are some required binary files in source, and also they are made in a way, which makes them not too hard to merge in case of conflicts (or they can be ignored in VCS and will be recreated on compile time).

I see a ways to make changes, that make current projects compatible with newer version of GM:S 2.x, but may make them little uncompatible when downloading older IDE (but we're in beta, and GM:S2 wouldn't allow you to use older version in some cases, forcing to download new one, so this shouldn't be a big problem, and may even not happen at all).

We're one month from final release, so it's not too late to fix those problems, as radical changes may be still made (and fixes in structure made on project load), and I even have some ideas, but without cooperation from YYG side, we won't do this.

I may dedicate some of my time to write a complete long list of propositions, and we may find a solution together - but I don't want to waste it if answer will be "Sorry, but this won't change...".
  • Like
Reactions: Yal


nobody important
GMC Elder
Okay, so the GUIDs being used ended up being a requirement. As we started to move resources around, renaming them etc. having stuff named after things was horrible and caused too many "saves" and pauses. So swapping to GUIDs meant we can maintain internal lists and its all just works better. We knew at the time that this would make it harder to look at files and know what was what, but it just made the UI much nicer to use. The extreme example was that we had a test 1000 frame animation which was all numbered from 0.png to 999.png. Really easy to look at and know what was what, but if you inserted a frame, we suddenly had to rename 999 files before you could do anything. This just wasn't acceptable. So this won't change.

The room order and script order can now be removed, they are no longer required.

Just viewing a resource should never change the order, that sounds like a bug. If you wan to file this, we'll fix it.

If you're adding and deleting new resources, each will get a new GUID on creation, there aren't GUIDs set aside for particular slots of things. So delete one, then add one; they will be different. That's just the way it is, this isn't going to change.

Ideally, working on scripts or images should not change the project file unless you change a setting that is stored there, if it does, that'll be a bug.


I am waiting for first update with VCS to see what changes you made during those two months, since maybe there are improvements, but I'll sure get back to this topic.