• 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.

Question - IDE GMS2 not playing well with source control for game jam, what to do?

  • Thread starter SayBaconOneMoreTime
  • Start date
S

SayBaconOneMoreTime

Guest
I'm in the GMTK game jam with a couple others, and we're trying to handle source control with Git, and everything is going awry very quickly. Every time we try to merge branches or do something similar, we get conflicts that seem impossible to solve in the main .yyp file. If I, for example, add a new sprite, and my friend adds a new object, it will count both of those being added together as a conflict, and if we try to renegotiate the file so it includes them both, the project fails to load. Is there a potential fix for this? We're kind of at a loss here.
 

FrostyCat

Redemption Seeker
This is a problem that I've reported before. Either minimize your use of branches, or delegate resource creation to just one user and pull off that user's copy.

I've dealt with YoYo long enough to know that source control friendliness is seldom on top of their agenda, and the nebulous promise of the fix coming in 2.3 (found in the last reply to my Mantis ticket) probably won't save your jam experience. But at least I've done my best helping affected users and screaming as loud as I can.
 
S

SayBaconOneMoreTime

Guest
This is a problem that I've reported before. Either minimize your use of branches, or delegate resource creation to just one user and pull off that user's copy.

I've dealt with YoYo long enough to know that source control friendliness is seldom on top of their agenda, and the nebulous promise of the fix coming in 2.3 (found in the last reply to my Mantis ticket) probably won't save your jam experience. But at least I've done my best helping affected users and screaming as loud as I can.
So you mean to tell me that this same issue, which has been thoroughly detailed in a thread from 2 whole years ago, is the thing that's messing me and my team up now and still hasn't been adressed?
 

FrostyCat

Redemption Seeker
So you mean to tell me that this same issue, which has been thoroughly detailed in a thread from 2 whole years ago, is the thing that's messing me and my team up now and still hasn't been adressed?
Damn right. And if you're pissed off about it, be assured I'm with you on that front, and I'll keep voicing up about it until YoYo takes it seriously.
 
S

SayBaconOneMoreTime

Guest
Damn right. And if you're pissed off about it, be assured I'm with you on that front, and I'll keep voicing up about it until YoYo takes it seriously.
Dear Lord. That's impressively ill-managed. Well, we're going to try to cope as best we can for the rest of the jam, but I hope they get off their butts and fix that. That's crazy.
 

Carbon

Member
Hi @FrostyCat, what do you think the temporary solution for us working as teams? Is it as long as we create resources on one person and the others pull and edit only would be fine? We use github desktop, not GM's built in scm system.

I remember this was a thing back in 2017 but even until now I'm still searching and still can't find the solution yet.

Perhaps what we need is someone creating a simple 'guide' that references people how to work with multiple people using source control with GM, as in what works and what doesn't, since (I tried again earlier today) project corruption is still sooo frequent when merging...
 

FrostyCat

Redemption Seeker
Hi @FrostyCat, what do you think the temporary solution for us working as teams? Is it as long as we create resources on one person and the others pull and edit only would be fine? We use github desktop, not GM's built in scm system.

I remember this was a thing back in 2017 but even until now I'm still searching and still can't find the solution yet.

Perhaps what we need is someone creating a simple 'guide' that references people how to work with multiple people using source control with GM, as in what works and what doesn't, since (I tried again earlier today) project corruption is still sooo frequent when merging...
The issue is this: I don't have a real answer for that myself.

The "one creating user" suggestion is just a hypothesis given my observations of the current file format behaviour, I have not tested it live to date. But if you are willing to try it out on your team and let me know how it pans out, I would be happy to listen in.

It really doesn't matter what Git client you use, the main problem is at the file level, not the interface level. You can reduce the incidence of with-versus-without-comma conflicts by installing this command line tool, but the issue with UUIDs and created-versus-not-created conflicts remains. As long as you can commit, create branches, stash and pull correctly with the GitHub client, you are more or less the most prepared you can be. Though I would recommend learning some command-line Git for cases where visual GUIs often don't cut it.

Perhaps what we need is someone creating a simple 'guide' that references people how to work with multiple people using source control with GM, as in what works and what doesn't, since (I tried again earlier today) project corruption is still sooo frequent when merging...
I would love to write such a guide, and it's not like I haven't written similar documentation before. But given what happened during the GMS 1.x timeline, I have qualms about that approach.

The first issue was when I started creating workarounds for making the integration usable again. This isn't a best practice, but I know it'll happen for the guide to be actually applicable. Not only did it give YoYo room to be complacent and turn their priorities elsewhere, it also ended up being an informal "official" workaround solution. That impeded YoYo from implementing a proper fix, since that would break the workaround for community members who rely on it.

The second issue is how improvements on the source control front only work when YoYo's development direction isn't undergoing upheaval. I did once collaborate directly with YoYo in GMS 1.x's timeline, when I was invited to report 20-something source control bugs directly from in-house builds. The developer assigned to me during this blitz session did a stellar job. The source control compatibility of the GMS 1.x format and built-in integration skyrocketed. But later when I uncovered other incompatibilities, YoYo had no time for it anymore. GMS 2 development was ramping up, and I never got any attention on the source control front again.

The third issue is that I'm mainly a solo hobbyist/extension developer. If I write such a guide, my experiences and usual practices will differ significantly from my audience's. Everything you see from me, including that Mantis ticket, is just me creating small-scale hypothetical simulations in a basement. While that has some reference value, it is a far cry from genuine production-level experience, and it also arguably compromised the efficacy of my blitz session with YoYo. My best intentions would be to have no "let them eat cake" instructions in such a guide (e.g. manually checking UUIDs to make sure they line up is feasible in my small sample, but perhaps not in your project), but I know it'll fall short.

If this is to happen again, I definitely won't be doing it solo again. It will have to be done via community testing and consensus, and YoYo has to be on board with it.
 
Top