How Does 2-3 Computer Developer Team Works?

I just wonder how can teams work? I mean: making a game with 2+ computers. How? How are they connected. I'm 14 and really wonder how to. Answer is critical *maybe*

 

Are you referring to multiple computers working from the same code base? Or are you talking about multiple computers communicating with each other for a multi-player title?

 

It's the same as developing any type of application in a team environment. The basic idea is you'd use some type of source control / code repository that all appropriate team members have access to. There are more complicated parts, like managing scene files so you're not overwriting each other, but this is the direction you'll eventually go.

If you're just starting out, though, and barely comfortable with code, let alone source control, you may want to just have your team lead manage the actual project files, and he handles assigning code files to various members and merge them back into the project upon completion.

 

To @Schneider21 and @RichardKain
Is there any programs that redirects multiple computers to the same code base. Think a folder and first a programmer adds a script from another computer and than another programmer changes that code or adds a script from another different computer. Ethernet cable? What?

 

https://en.wikipedia.org/wiki/Revision_control
https://en.wikipedia.org/wiki/List_of_revision_control_software

 

Ah yes, you are definitely thinking of version control software.

This sort of thing is usually handled by hosting a version control server somewhere, and connecting to that server from those multiple computers. This can be done locally on a LAN, or remotely over the internet.

You better get ready to do a little homework. There are numerous different version control solutions. (see the list steego is linking you to) And most of them have their own permutations. I personally use a LAN-focused SVN server that I set up in my own house. I mainly work alone, so I just need it to access my code base from different computers.

Version control is all about communication, be sure to put comments whenever committing changes. You want anyone who comes after you to be able to know what you did.

 

Well, if you think about what you're actually describing, it sounds pretty terrible. Imagine two developers working on a script simultaneously, a la Google Docs. You're writing a function to so something basic like set an object's parent, and another developer is working on a more complicated feature. As you're trying to test your code, it keeps failing because he's not finished with his portion yet.

Instead, what real-world teams do is use version control, like I said. Git and Subversion are the most common ones I've seen, and I have a strong preference for Git. With version control, (or revision control?! Is that the proper name?), both developers would have a local version of the same file. Both can freely edit the file as they like. When one person is ready, they merge their changes into the remote version of that file. It's kind of complicated, and I don't have the mental faculties to explain it right now, but you should definitely look into it if you plan on working with multiple developers.

 

I'm gonna say it now: I've had the best experience with Github repos. Just publish a Unity Project as a repository, then have your partners clone the repo on their computers. Next, add them as collaborators to the repository, and then you can sync your project whenever you want. Github combined with Unity Cloud Build has saved an incredible amount of time for me. Here's the .gitignore file I use with Unity:

Code (CSharp):

1. # =============== #
2. # Unity generated #
3. # =============== #
4. [Tt]emp/
5. [Oo]bj/
6. [Bb]uild
7. [Ll]ibrary/
8. sysinfo.txt
9. # ===================================== #
10. # Visual Studio / MonoDevelop generated #
11. # ===================================== #
12. [Ee]xported[Oo]bj/
13. /*.userprefs
14. /*.csproj
15. /*.pidb
16. /*.suo
17. /*.sln*
18. /*.user
19. /*.unityproj
20. /*.booproj
21. # ============ #
22. # OS generated #
23. # ============ #
24. .DS_Store*
25. ._*
26. .Spotlight-V100
27. .Trashes
28. Icon?
29. ehthumbs.db
30. [Tt]humbs.db

I'd recommend reading up on how Git/Version control works, then setting up a repository for you and your team.

 

Guys I'm trying Git. Thanks for all those comments.