Hello,
I would like to share an unfinished game with a graphic designer. He lives in another state. What is the best way to share my work in progress?
Thanks
I would recommand using one of the versionning systems, GIT and SVN are both pretty easy to use, and you can find sites that will host your projects for free.
For windows users, there are tools to integrate this directly into your right click UI in folders, making the whole thing pretty trivial (Tortoise does both GIT and SVN support for windows systems).
As for sites for the hosting, there are a few ones:
https://github.com/ The free accounts don’t allow for private projects, but you can get a some for only a few dollars a month, and stop it when you no longer need it.
https://bitbucket.org/ Free private projects for 5 users and less.
There are way too many sites that give you that kind of services, so here is a page that list a few others 14 Git Hosting Services Compared | Tower Blog
I hope it helped.
1 Like
Because sending a 1GB+ project as an email attachment makes sense… 
I would suggest creating a Dropbox/Google Drive/One Drive/SugarSync account and then sharing the zip file and/or project folder with them (or just creating an account for you to both share).
No, but asking about unrelated third party transfer software on the Unity Game Design forum makes total sense.
1 Like
+1 for the hosted version control suggestion, as long as you want to share the source so the others can work on it. I’m using a service called Unfuddle at the moment. It’s not free, but it’s fairly cheap, and I’ve found the service to be great.
I would not share a working project via Dropbox or a similar service. Here’s why.
If you only want to share a build then it’s easier, albeit a bit different depending on the target platform. For PC/Mac just build in Unity and archive (zip or whatever) the built application. Host them online somewhere you can privately link to them, and send the link to the people you want to give access to. I believe Dropbox allows you to do stuff like this.
For what it’s worth, so does Google Drive, which you’d typically access via your Gmail if you have a Google account.
2 Likes
So… www.gmail.com?
+1 to version control or else 
Version Control, You, and Why You Need It.
Google drive should do the trick. Our git project failed because assets took up a lot of our space. Github is great for plain text but storing huge files on there is not the best idea for free users.
Unity projects compress very well, so just stick the entire project on google drive.
EDIT: Post updated, that whooshing noise is the sound of the context of this statement going over my head.
1 Like
You are aware that you are on the Unity Gossip forum correct?
My apologies.
For what? The content was still both relevant and constructive.
Google Drive is ok if you only want to transfer a file. However, I’d like to take a moment to say that sharing a Unity project or any other group of interlinked files in this manner for the purpose of making and sharing changes is a really bad idea. In my opinion any time put into organizing such a system isn’t just wasted, but will in fact have a negative effect on your overall project. This is it perpetuates your consideration of a project as “just a bunch of files”, which is a very limiting point of view and one I think any serious developer should disabuse themselves of as early as possible.
Version control systems are daunting to learn, but the few hours that it costs you will be earned back in no time at all. The significant amount of time they save you once you’re in the swing of it is then time you can put into making better games. Once you’re used to it you’ll wonder how you ever lived without it.
Here’s an example. I once (and only once!) worked on a project where, once or twice a day, the code team would stop what they were doing, gather around one developer’s machine, and manually merge all of the code changes together, which then got copied back to everyone’s dev machines, sucking up about an hour a day where all coders more or less had to just… stop. After a short time of this, a VCS was employed. After lets say 10 hours of initial setup and teething issues it was saving us virtually all of that hour per day, so it paid itself off in two weeks. Plus, the new system was far less error prone (more time savings) and allowed the coders to work far more flexibly - not just because they could check in/out whenever was convenient to them, but also because where needed we could touch the same files without then needing to manually merge the changes later (even more time savings).
I too have heard industry vets tell stories of how they succeeded despite a lack of modern version control. “Back in the day, our version control was having one floppy disk per subsystem in the game. To check it out you’d take the relevant floppy to your desk, and to check it in you’d copy your changes back to the disk and put it back at the front of the room!” And yes, people did in fact make games successfully with such methods. But that doesn’t mean it’s a good idea to continue like that, any more than it’s a good idea to treat illness with bloodletting!
3 Likes
I could have elaborated a little more
We used google drive to exchange a base copy so everyone was working on the same scene, then we created modules that just plugged right into the scene and put them on google drive for whoever needed them.
I do consider my projects just a collection of files, but that’s just me. I also consider all you humans (pronounced hoomuns for dramatic effect) just a collection of atoms. On a deeper level, I consider programming a way to manifest my imagination. But humans will never be more to me than a bundle of neurons.
This totally relates to version control.
1 Like
Application wise, sure. File syncing not so much. For that I would recommend a local SVN repo on whoever has the most reliable machine.
The unrelated bit about you biological computer shells in denial was a response to something else, so of course it cannot be relevant to version control and anyone reading the entire conversation would not expect it to be
I still don’t know what that is all about.
Ok, but why would you recommend that?
That’s more or less what we moved to in the example I gave. About a decade ago. Plenty of improvements have been made in that time, why not take advantage of them?
I would at the very least recommend strongly considering a remote host of some kind, because keeping all your data at one physical location is a risk. Depending on your security requirements you could even get fully serviced hosting that ends up being a) cheaper and b) far more convenient than doing it yourself. I’d also recommend taking a look at more modern VCS tools.
Could you be more specific?
Because I’m an indie developer and in my experience, no one wants to pay for a server or a service. As a college student, when I say “local” I mean all of us are on the same network, so I doubt a modern service can do it cheaper than we can.
It’s not like if the main machine fails, we all lose our copies as well. The main machine will likely be a second or third machine owned by someone in the group, so work isn’t being done on it. You know what happens if it fails? Nothing, it’s just a backup of the work we’ve done thus far. If we screw up, we use SVN for it’s intended purpose and back up. If the machine fails, everyone in the group already has a newer project than what was on the machine hosting the repository. We’ll pick a new main machine if the previous one exploded, put any of our projects on there since they’re all newer than the previous lost one, and then continue work normally.
I doubt they can also compete with the security of a LAN SVN. The entire internet could go down and we’d still be fine
–edit
Everyone in this major is required to take system administration, so I think we can handle our own offline network and not worry about intruders. We’d catch them anyway from monitoring the logs, as anyone who got a C or better in the class might do.
Right, so you’re talking about an environment that’s already distributed in so far as your computers aren’t generally in the same place. I’m talking about a more “typical” professional type environment, where everyone is in the same place, like an office.
I also don’t have this stigma against paying for useful services. The one I’m currently using for my own projects is costing me $6 a month. That’s a lot of saved effort and improved security for a little more than a cafe coffee.
I consider them to be a history of changes, or some equivalent. The project is the sum of the work which is put into it, not just one instance of a set of bits written to a hard drive. That may sound fluffy and useless, but thinking of it this way allows you to work with the changes rather than just one current set of bits (or, worse, a bunch of current sets of bits which you try to manually herd into one baseline like so many angry cats).
The fundamental benefit of considering and treating a project this way is that, with appropriate tools (ie: any VCS worth its salt) you can freely navigate through that set of changes. Want to see what the baseline set of bits looked like last Thursday before Bob put the new scoring mechanic in? Easy, pull up the list if changes, highlight the one you want and load it. Not only that, but it can also do useful stuff like show every modification Bob made to implement that new scoring system. Not only can you navigate the changes, the system also helps you manage them. For instance, if Bob and Jane both make changes that touch common files, modern systems are good enough to almost always merge the changes without any human intervention.
It’s not the files that matter, it’s the changes to the set of files. Also think of this: if every change is a complete task, then this approach gives you a list of all code or content tasks contributed to your project, from start to finish, in order, along with who did them and exactly how they did them.