AGS and Microsoft OneDrive (or how to share a project with several people)?

[JLM_82]

I have started to think, what would be a best way to share an ongoing AGS game project with several developers?

Is it possible, for example, to put the game files to a shared folder in Microsoft OneDrive? Then each of the developers could install AGS engine on their own computers and open the project files from that shared OneDrive -folder. Maybe then each of them could test the game easily, and make updates to the codebase, without the need to send game files separately?

It would be nice, if a musician, for example, could access the latest version of the game directly on his computer, and test the new music pieces on fly?

Has anyone used OneDrive with AGS project?

[Retro Wolf]

Could cause problems if people are working the same time. Person A loads up project then person B loads up but finishes before person A, person A then finishes overwriting person B's changes. I could be wrong.

[morganw]

Writing scripts/code doesn't really fit well with this approach, and AGS makes it worse in the way it handles game assets. You can do it by carefully arranging who is responsible for changing individual scripts but for tasks such as importing sprites there is only one file, so each person must work with placeholder sprites or their own sprite number range until they can safely get their new sprites imported.

Could cause problems if people are working the same time. Person A loads up project then person B loads up but finishes before person A, person A then finishes overwriting person B's changes.

Yes, you are likely to lose data and/or create conflicting files which refuse to sync.

Maybe then each of them could test the game easily, and make updates to the codebase, without the need to send game files separately?

This is really a job for version control software, although you still need to arrange how you manage the game assets (potentially these are version controlled too).
https://en.wikipedia.org/wiki/List_of_version-control_software

[Snarky]

Yeah, I wouldn't recommend working in a shared folder. It could easily corrupt the project if people edit in parallel. Like morganw says, the best thing is to use a version control system, like git. However, yes, the problem is that these don't handle large binary files (such as AGS's sprite cache) very well: every time you make a change, it stores a copy of the entire file, so the repository can grow very quickly.

I think in the latest version of AGS you can regenerate the sprite cache from the original image files, so as long as you keep those in a shared OneDrive directory, you could just exclude the sprite cache from version control and have people regenerate it each time they update the project from the repo. (You should then never delete any image files from the images directory, or you won't be able to restore earlier versions; and if you edit or overwrite the files, that will affect earlier versions of your game as well, if you try to restore them through version control. It's not perfect, but if you take some complete backups of your project at regular intervals as well, you should be pretty safe.)

[JLM_82]

Thanks for responses.

Yes, you're right, it seems that Microsoft OneDrive is not the best possible tool to share an AGS project with several people.

Have you had experiences, then, what would be the best possible way/tool to share the project with several people? In my project, for example, I'm the main writer and programmer, but the musician lives in a different area and has never used AGS before. However it would be good if he could be able to test project on fly, when composing background music for different game rooms and situations after they are scripted.

How have you solved this kind of problems, when developing an AGS game in a group?

[morganw]

I think in the latest version of AGS you can regenerate the sprite cache from the original image files, so as long as you keep those in a shared OneDrive directory, you could just exclude the sprite cache from version control and have people regenerate it each time they update the project from the repo.

Unfortunately because of the way the import process works it couldn't be done, since the imported sprites are stored in RAM until you hit the save button and potentially you have more sprite data than RAM that is accessible to the Editor.

[Snarky]

If he's just doing the music, I'd keep all the development on your end, and just share a copy of the game project, or simply an updated build of the game, with him regularly. (You can certainly do that over OneDrive if you like.) Then he makes the music, potentially tests it out in his copy of the project, and sends it to you to import into the "real" version of the project.

[Crimson Wizard]

I think in the latest version of AGS you can regenerate the sprite cache from the original image files, so as long as you keep those in a shared OneDrive directory, you could just exclude the sprite cache from version control and have people regenerate it each time they update the project from the repo.

Unfortunately because of the way the import process works it couldn't be done, since the imported sprites are stored in RAM until you hit the save button and potentially you have more sprite data than RAM that is accessible to the Editor.

Does not this mean that it can be done, if you dont edit sprites simultaneously?

[morganw]

Does not this mean that it can be done, if you dont edit sprites simultaneously?

I think most people probably would just commit to the sprite file after checking it was OK to do so with any collaborators (and if the version control system is OK to take the file size). It is an automated restore from the source files that is problematic, I think I still have a branch with it done as a proof of concept, but it can get pretty crashy.

[Crimson Wizard]

Oh, right, the problem was that it has to read everything into computer memory first, and may crash doing that.

Also clipboard pastes do not have source files and cannot be restored.

[morganw]

Also clipboard pastes do not have source files and cannot be restored.

The bulk export did get put in, so I think you should be able to export everything from the root sprite folder and then keep it as a source reference.