I've been playing around with git and AGS today, and so far I find no reason it shouldn't work, however, due to AGS-restrictions, we need to lay down some rules and conventions to get a seamless multi-user collaboration.
What's so cool about git is how you can make separate branches of the project, making a branch a separate environment a user can toy around in, not affecting the master build. However, any user can work in any branch, including the master branch, and this opens a world of potential problems.
Considering we're going for the open source route, we'll want to give permission to anyone who has something to offer, but if we were to stumble upon the common internet troll or someone had an accident, suddenly everything would on sourceforge would be wiped away. Removing all of the hard work anyone were currently doing, and also the latest edition of the master build, which is what everyone should always be working on at all times as a foundation.
Now I assume Robert has the foresight to back up the latest edition on his local computer, but this would leave everyone in his power, having to sit idly until the master build gets loaded back up again.
Googling some common practices gave me a rough idea on how this could be fixed as fluently as possibly.
- Have a local master build with read only permission, only admin can edit it.
- Have a remote master build with write access to developers. Sourceforge supports having multiple git projects in one sourceforge project, so this shouldn't be problem.
Now how this would work, is that everyone is free to work on the remote build, and if anything majorly cocks up, we're at any time free to extract the local build and start over at a relatively updated build. Whenever anyone is finished implementing something to the remote master, admin can check the changes, give feedback if he doesn't the implementation, or if he thinks it's good, put in in the local master build, finalizing it.
That would take care of one problem, however we'll need to discuss branches next, as multiple users working on one project, writing code and what not, could give interesting conflicts when they work on the same files, at the same time. git is built to work great with files that can be represented in text, which is what you normally do under a pure programming project, however AGS compresses and archive resources on the go, instead of on compile.
The idea I've come up with to reduce this problem down to the most minimal, is to utilize branches, a ton of 'em, let's use the recently implemented options menu as an example.
The Options menu had several issues, it didn't show up on the title screen, it had functions we don't want or desire on the title screen, it had no GUI implementation to be called in-game, some of the functions in it didn't even work.
Mapping out these issues and reducing them as tasks(ticket system in sourceforge, ka-ching!) could allow multiple users to work on the same stuff and not override each other. Say we make a branch of the remote master build, and call it "optionsmenu", every task that is associated with options menu could be a sub-branch of the branch "options-menu".
When a task would be completed, the assigned worker can ask for some feedback, from the others working on the same master branch, and if it's good, merge it with the master branch. When all sub-branches of the main branch is done, and the of course if the main branch is running and functional, it is ready to be merged with the remote master build. From there the admin would again merge the local master with the remote master. And finally overwrite the remote master with the data from the local master, to enforce that is the most updated and current version people are working on.
Things to be aware of:
- I'm still not sure of how a git system would affect sprites and other stuff that is made into a binary file the moment they are added to the project. One solution would be to just ignore that stuff on git, and implement it like we did before.
- Anyone that would wish to contribute should show to some results they can contribute with, let's avoid a random person entering the project and wiping everything out as much as possible.
- http://www.adventuregamestudio.co.uk/wi ... ce_Control
- git can be tedious if you're new to it, but the more people that is working on one project, the more it's worth it. Especially on a project like this where people live so far away from each other.
I've attached a diagram that I hope explains visually what I'm trying to convey. I know all of this may sound extremely tedious and micro-managemently, but I believe it's worth the effort, as it can give a very streamlined work flow and always access to the latest build.
PS: Sorry for the wall of text
