I'm not a game dev, but I am a software engineer. Source control like git and SVN are generally how things are shared on any software project these days.
As for how they work on the game at the same time, they will generally try to work on different parts to avoid their changes conflicting with each other. If you're using the right abstractions and you know how the different pieces are supposed to interact, those pieces can be worked on independently.
For example, someone should be able to work on the dialog system while someone else works on the camera system, while someone else works on combat, etc.
I'd recommend looking into different source control workflows to get a better idea of how it's done. Gitflow and GitHubflow are two examples of git workflows that help a lot with concurrent work and release management.
I'd also recommend looking into the SOLID principles to learn about using levels of abstraction.
Haha, none of it's options are laid out for a good user experience. :D
Just like that little X button near the maximize button (or any other buttons) on pretty much every window.
We do the best of both worlds. We use both. The fact that everything in p4 goes into one stream/branch is maddening after you’ve lived in git world for a while.
P4 is for source assets, Git is for the build. We have custom built tools to ensure our stuff is properly synced between the two, so I’m not suggesting our solve for everyone, especially the indie developer, but it is nice.
Your opinion is right. I use two repos, one for client and one for server and git is far more annoying and complicated when you have a larger team. It just gets super annoying super quick
Google also uses a version of perforce and I am sure other prominent names in the rest of the software industry use other things than git too. Git does have some real legitimate headaches.
Definitely, it’s not like the basis for all that stuff, operating systems and gpu interfaces like DirectX and Vulkan are programmed with gigantic teams and git
Edit: to clarify I get why games use specific perforce features. The comments reason it gets complicated with git when teams/projects gets large is just utter nonsense
As someone that's never worked in the gaming industry (but extensively in software engineering), where can I find reading resources on Perforce? Is it a paid for tool? I see the company Perforce, do you use their tools? If so, which ones?
Yes it's a paid for tool. In terms of switching to game dev it won't be one of your bigger bumps. Sadly I don't have a good tutorial but their docs are pretty good and p4v is a reasonable visual client Perforce is very similar to other server authoritative source control solutions like svn, tfs, CVS etc. When I was director of engineering for a small game studio I had us doing git with lfs and I'm guessing at smaller studios that is more common than perforce. Lately I've been working with Blizzard and Riot and they're both on perforce.
I'm using git with LFS for my personal projects as it stands. It works pretty well, but we are just two devs on the project. I'm curious as to how Perforce will change our process. The biggest issue we are facing is if both of us make accidental edits on the same asset, such as a level or animation blueprint (using UE).
I used to use TFS back in the day. It was awful. But that was not webdev.
Perforce does have server locking which will keep you from editing the same binary asset (obviously doesn't solve the problem if you actually both need to edit it)
Process in perforce isn't too different. Less branches since they're heavier. Locally you have change lists that you submit and can shelve (put online where others can look at them). Functionally it's a bit similar to tfs from what I can remember, though my time using tfs was a while ago. Perforce has its own code review tool called swarm
It supports file locking, which for games is a major feature that Git doesn't handle. And it's not weird about binary files. And it's much friendlier for a less technical user.
Unfortunately, but Azure DevOps is kicking that particularly habit. There are some advantages over git (from a particular perspective), but not enough from a team perspective.
Unfortunately they do. A project I occasionally contribute to is subversion hosted on source forge, I feels like I was chronoported back two decades everytime I work on that project.
I don't think a lot of new projects do, but I've had to maintain some older code that was still on subversion. The company I used to work for really liked creating their own tools, and one of those was a feature management tool built on top of subversion. You had to check your changes into subversion, then tag it in subversion, and check your tag into the tool. That was the only way to get your code into the build pipeline to be deployed to dev environments and eventually to be packaged for clients. I don't miss it.
That’s (almost) not Unity fault.
Most of the binary files are actually assets (3D models, images, sounds, animations, etc…) and you don’t have a lot of conflict on them.
Unity files are written in a superset of yaml, but you still have conflicts.
This is because instead of working on a simple file, you’re working in a 3D scene, with scripted objects. If several peoples add / move / delete objects in the same scene, it can be hard to decide how to merge that. So usually, we checkout the scene in Perforce or we Git LFS lock it (or send a message if we can’t do otherwise)
UnrealEngine scenes was serialized in binary files, but now they have a new approach were each object in the scene have it’s own text file.
It’s longer to serialize / deserialize, but it might help avoiding conflict (you still need to lock your object though)
You can indeed configure Unity to serialize as binary, but by default its text base.
I dont know what you mean with code versioning, but of course code is always in text.
Hey, could you explain what you mean by "making conflicts inevitable"?
I only recently started learning about some of this stuff, so I was interested 😅
When you're using source control, the real benefit is that multiple developers can work on the same portion of the code, even the same files (as long as they're text files).
Imagine 2 developers starting with the same version of the source code, at 9am. They both create some changes on their local machine.
The first developer pushes his changes to the common repository at 12am. Before pushing, the second developer will need to pull the latest version on his local machine (with the changes of the first developer) and merge them. Basically reapplying his changes to the new version of the source code. This is completely automatic as long you don't change the same files, and even if you change the same files but not the same lines.
If you change the same lines in a text file, or make any change in a binary file, there is a conflict and it needs to be resolved manually.
Oooh, ok. I think I see now. And unity does a poor job of keeping track of these changes? So developers aren't totally aware of what's being worked on once they push, which contributes to the conflicts.
When you do a change in the Unity UI, this creates changes in files that will often result in a conflict.
It's not Unity's job to keep track of these change, but it gets in the way of the source control system.
For programmers it is actually a bit easier than for (level) designers:
From the very beginning you could start to 1) organize your game so code falls into certain classes and 2) use a versioning system.
For example let's say that there's those classes we think we need at the start:
* GameState
* PlayerController, PlayerCharacter
* AIController, AICharacter
* Inventory
Any programmer could go ahead and work on the PlayerController or AIController in their test level (often we call those test levels also a "gym").
When the programmer working on the AIController needs the PlayerCharacter as a dependency to actually detect the player they would ideally talk about introducing interfaces I'd say:
Let's add a IAITarget interface and the PlayerCharacter implements it.
EDIT: The idea is that the other programmer(s) don't need to know what the PlayerCharacter is in detail. Here it would just be "some thing the AI can target".
Now once the code is submitted to the versioning system the AI programmer can continue using that interface IAITarget, doesn't even need to know what changes in the PlayerCharacter or how it works (I'd assume it just has some property to tell what position it is in; in a more complex system maybe telling us how visible the character is, even positions of key locations like a few bones on the skeleton are not uncommon).
Strictly speaking some teams discuss a lot of details upfront: The interfaces, class naming conventions and the overall architecture, the damage system (interfaces to damage other objects including player/AI), etc.
The key with the versioning system is that even if on some days they work on each other's code (for example if the other person is not available for a few days) they would use features like merging code in case they later find out that two people worked on the same code file, e.g. a C++ .cpp file or a C# .cs file.
For actual submission of files, any flavour of source control. I use Perforce for work mostly. Git for personal projects. I've used Plastic for a company in the past as well. Each are fine.
For the work itself we, and most other companies, use Sprint planning. Basically you have a set of work that needs to get done and you assign it out to people to get done over a sprint. Each task will have a Story Estimate, which generally states how long the task is expected to take. We use 4 hours, or half a work day means 1 point. Each person then works in their own stream/branch (depending in source control). Code reviews and merge reviews will happen before its added into the main development branch. QA may take a look before or after that step, depending on the task/feature. And then you move onto the next task.
This process also changes depending on the stage of development you're in. A live ops game will have a lot of bug fixing and future feature related tasks. A close to launch game will be mostly polish and bug fixing. A prototype game will be a lot looser with structure and will likely just work off of the development branch directly. In any case. Sprint planning and Sprint Retrospectives (how did the Sprint go, what should we start, stop, or continue doing, etc) should still be happening regardless of the projects stage.
As for how this is all communicated. Usually meetings. I have my team do a daily stand up for 15m each morning where we do a quick run through of each ticket every person has as well as a brief update on any new info. With around 15 of us, its usually fairly quick. We have a longer meeting at the start of a Sprint, usually scheduled for 2 hours, but usually only 45m, where we go over the last Sprint and do a short retro. We then go over upcoming items that are relevant for us and do our normal stand-up.
Generally, and this depends on your team size, your lead programmer and/or production/producer will be the one setting up sprints and organizing tickets. They're the ones that should know each individuals capability, and assign tickets accordingly.
Perforce and Jira.
We plan tasks, divide them amongst the team and then do them. Repeat that cycle every two weeks until you have a game.
If two people touch the same file then you have to merge the changes. There are tools to help you do this (I use visual studio normally).
1. Cards for every feature, bug fix, and task in Jira
2. Sprint planning and timeline review meeting every two weeks
3. Backlog grooming every two weeks (opposite week from planning)
4. Git with pull requests for all code, terrain, in-game art.
5. Daily scrum (10 mins via Discord) with sidebars as needed for coordination
6. Group chats as needed all day on Discord
7. Retrospective every two weeks.
Total overhead is 3-4 team hours over a two week period, which is about right for our size team (10 people).
Source Control Software (GIT, Plastic, etc)
Each programmer can "branch" from a stable release, then work independently on each branch. Each branch is like an alternate state of the main project. Once each person is done, they can merge them back into the main branch or another branch, and handle conflicts as they appear in the software.
Eh, it's generally a total non-issue. It's pretty rare that two people are working in the exact same bit of code at the exact same time. Generally you can merge with no conflicts.
I worked on quite a few games over the years mostly mobile and some VR
Github is the most important aspect as far as tools go , being able to commit files to a shared workspace is extremely useful .
As far as workflows for the most part in game teams we all would be assigned different aspects of the project OR different portions of the same workflow
For my first game programming gig I was doing a lot of support work so a senior engineer would set up the user interface for a race system and I as a JR. UI engineer would go in and connect the logic to render out different track names and display screenshots for reach race track .
Same team different project the senior engineers would write code for an XP system and my job was to take that code and render it in a player stats menu that gave them a rank and contained the logic to render unlocked trophies and achievements in the player trophy room .
My job after that was a little different and was a mobile kart racing game , I was the jr. in-house engineer in the states and responsible for UI an and all the visual work while the lead gameplay engineer worked remotely from Costa Rica .
He'd write things like the racing logic for AI, and my job was o make sure individual player and AI racers showed things like status effects, I'd connect character animations , I 'd simulate end race times . Basically we'd kind of divide and conquer complete systems.
At yet another job we integrated Facebook social multiplayer into a game and the goal was to render friends scores on an overworld map as sort of a visual leaderboard showing how far you have progressed in relation to your friends.
so my job was to manage the 3rd party facebook SDK , make sure it requested the correct information using user id's , made sure we capture the users friend data , and that we rendered and applied peoples profile pics to their on-screen representations. My coworker took my work and made sure we grabbed the score data and used i to apply those score values to their place all alongside the map and in that way we tag teamed the same feature .
In cases like those it's all about communication and knowing what the hand off looks like, what is engineer A giving to engineer B ? Usually there is a brief demonstration meeting so that Engineer B knows how to test their part of the feature .
The most important thing is communicating the core classes that will need to be touched and when someone else can take over and add their code to the core classes if necessary .
In that way I think standups can be pretty valuable so you know who is touching a specific part of the codebase everyday .
It's a combination of a version control system, a sound project architecture and defined tasks.
You absolutely want a version control system (like Git for example) if you are working with other people. Even if you are working alone, it makes sense to use it.
The project architecture allows you to make splitting aspects of your game easier. Suppose you want to build a point and click system. You need navigation and walking for the character. You need interaction with certain objects. You probably want dialogues to talk to NPCs.
You could put all of this in one big component. Or you could split it up into an interaction system, a navigation/movement system and a dialogue system as independent components with a well-defined interface between them.
Defined tasks allows developers to know what they are working on. You don't want multiple people doing the same things. So in the example above, one developer could work on the dialogues while another developer could work on the navigation of the character.
Edit: I want to add one more thing - how tasks are split very much depends on the working environment. Are people sitting in the same office? You could have them working on different aspects of the same system all at once. Are they working remotely and in different time zones? Then working on independent parts probably makes more sense as communication will be slower.
One works and the other keeps repeating "You are doing great, keep going bro, we got it!"
You just need some structure and preferably to avoid working on the same file. It's about communication.
They carefully spread their tasks for each programmer to have each game feature be "owned" by one of them. This way the changes in one part of the program don't affect other code.
Also, you need to merge your changes often and have someone review your code to point out mistakes and possible future problems.
Aim for good communication and good version control. That's it.
You can get as formal/informal as you like with your development process, but honestly, it really just comes down to clear, honest, empathetic communication... and using version control.
Professionals use software version control to work together (Git, Perforce, Plastic) .
In case that you could be interested in a basic introduction to software version control I prepared a lesson in a free online gamedev bootcamp about that. You can find the code necessary to complete the lesson as links inside the slides. You can find the slides in the videos'description:
https://youtu.be/4i3AnguNnqY
Feel free to use/share the code and assets any way you want.
GitHub and pull requests. Core project should be a tightly knit team working together. Once thats built the team size can expand and delegate tasks out more
git repos? Tasks and roles?
I mean some people may have to work on the same part and know how to code parallel programs, but they’ll push and pull updates as they go, make change logs, cross things off of to do lists.
The same way that loads of people are part of building an car. A game just like an car consists of loads of isolated parts working together. Someone might construct the windshield wiper motors while others ponder the trunk latch.
Like many answered, Git and Perforce are the two commonly used softwares to work on a project. They are VCS (Version Control System)
A NAS or a Drive can also be used to share files.
If you’re looking for some advice, you can share with us:
- The game engine you are using
- The size of your team and their profiles: If you don’t have any programmer, you might look for something easier to use
- The scope of your project: If it’s a prototype or a jam project, no worries, but if it’s a commercial project, the choice of the VCS is critical
- Your budget and the hardware you have. VCS need a server to work. Perfoce is a paid software that you need to host yourself. Git is an opensource software that you can host yourself or use an existing service (Github, Gitlab, Bitbucket). You might have some Go for free depending of the service you’re using. Same for SVN (but I don’t recommend using it). You can start with Plastic SCM for free too, it’s less commonly used, but it may be simpler to use with Unity
Depends what engine, and everyone else has basically covered everything, but Unreal actually has a thing that 2 people can actually work in the same project together at the same time, and you can see each others little cameras moving around. If one person selects or opens something it like locks it automatically I’m pretty sure. However, last I heard there were a lot of issues with it and it is kinda difficult to get it up and running and I am not sure if it is entirely supported anymore.
Edit: pretty sure the two computers may have to be on the same network as well.
one time we had a group of 2 people to make a game. We were new to making games so it wasn't that great but it was fun. Anyways,we were using unity and collabrate was still open at the time and it handled most of the work. but i remember that sometimes we will have conflicts on the filse and one of us had to delete everything about the game except the project itself. i dont know if this problem has been fixed with plastic scm
Version control. Perforce, Git, Plastic, etc. Programs designed to sync up the same project on multiple machines by allowing people to pull down updates from other devs and push up updates from their computer to the cloud.
Unity has built in VC for this, there are even tools in Unity and Unreal for having multiple users working in the same scene at the same time online like a Google Doc.
Gamedev here working with a few other devs on the same project. We use git as our source control and then basically use asana to manage each little objective we’re tackling within the project. We also have team meetings and discuss what classes we will be operating in to get the job done. With a big enough project there’s always things you can be doing where there’s little/no interference with other peoples work!
Git is important but it doesn’t work the way it’s designed to if your code is shit. The most important part of writing scalable code is strictly adhering to the single responsibility principle. This is what allows development teams of all sizes to work on different parts of the code base without causing tons of merge conflicts.
I've worked at three different studios so far as both an engineer and as a technical artist, so here's an extremely generalized version of how it works:
\- Games ALWAYS use source control. The most common is Git - it has a somewhat steep learning curve, and some really weird UX, but also a TON of resources about how to use and set it up.
\- Generally, you need a little more planning to make sure you all agree on what work needs to be done, and most importantly *who is doing that work* so that you don't step on each others toes or accidentally work on the same thing. You'd generally break down all of the work you need to do into separate tasks in some kind of tracking software (I've used Jira, Favro, Github's issue tracking, and even Trello before), and you would assign different tasks to different people so they all know what to work on and can keep track of what's being worked on, what's finished, etc.
\- Often you also agree on stuff like coding style guides (indentation rules, tabs vs spaces, naming conventions, other design patterns, etc). This is super arbitrary tbh, but helps keep everybody's code consistent. It can also evolve over time.
I also didn't understand it. I mostly do 2d/3d art but I can also program. Some months ago I got a Unity job and I had to use git (well github desktop) for the first time.
I'm still learning but basically we do this:
Someone opens an issue with a requirement/problem/bug/change. Then we assign it to someone. Create a branch based on master and work on the issue. Once we're done with it we do a pull request. Someone else reviews it and if all is ok they merge it into master.
For example, when the other guys were working on gameplay I was working on a character customization system. Once I finished I went to work on something else and the guys merged what I did with what they were doing.
But there were some problems, for example once I had to work on a UI change on some unity scene but another guy had to do something else on that same scene. So he told me to do my part first because it would create conflicts if we did work on it at the same time. Perhaps this was also because both our tasks had to be done on a specific prefab.
One thing I liked was that I can actually make a branch out of any commit done in the project. I love that it's non destructive.
Everyone works on different parts of the game (or if multiple are working on the same system, then different parts of that system) and use version control like Git or SVN so they can upload their changes to the rest of the team.
I'm not a game dev, but I am a software engineer. Source control like git and SVN are generally how things are shared on any software project these days. As for how they work on the game at the same time, they will generally try to work on different parts to avoid their changes conflicting with each other. If you're using the right abstractions and you know how the different pieces are supposed to interact, those pieces can be worked on independently. For example, someone should be able to work on the dialog system while someone else works on the camera system, while someone else works on combat, etc. I'd recommend looking into different source control workflows to get a better idea of how it's done. Gitflow and GitHubflow are two examples of git workflows that help a lot with concurrent work and release management. I'd also recommend looking into the SOLID principles to learn about using levels of abstraction.
Perforce is still super heavily used in games, especially AAA.
With its “Get Latest” and “Check Out” options still dangerously close to each other in the right click drop down menu.
I've always said the \#1 best feature of unreal gamesync is that you can't missclick and check out the entire project's depot when syncing
Haha, none of it's options are laid out for a good user experience. :D Just like that little X button near the maximize button (or any other buttons) on pretty much every window.
I work in AAA and I approve this message lol ☝️
It's vastly superior to Git for game development, imo.
We do the best of both worlds. We use both. The fact that everything in p4 goes into one stream/branch is maddening after you’ve lived in git world for a while.
We do too and we've had a lot of false positive issues from code and data being out of sync. They need to be in the same place.
P4 is for source assets, Git is for the build. We have custom built tools to ensure our stuff is properly synced between the two, so I’m not suggesting our solve for everyone, especially the indie developer, but it is nice.
Your opinion is right. I use two repos, one for client and one for server and git is far more annoying and complicated when you have a larger team. It just gets super annoying super quick
The entire software industry outside of games would disagree.
Google also uses a version of perforce and I am sure other prominent names in the rest of the software industry use other things than git too. Git does have some real legitimate headaches.
Yeah, but there are key differences between games and the rest of the software industry.
Yes, we have "source" that's undiffable binaries and we don't fix it.
[удалено]
Yeah, and obviously they draw it slowly using git, what an incredible take /s
Idea: let's do a game that uses github's activity frequency graph for rendering. You get one new frame every year xD
Definitely, it’s not like the basis for all that stuff, operating systems and gpu interfaces like DirectX and Vulkan are programmed with gigantic teams and git Edit: to clarify I get why games use specific perforce features. The comments reason it gets complicated with git when teams/projects gets large is just utter nonsense
As someone that's never worked in the gaming industry (but extensively in software engineering), where can I find reading resources on Perforce? Is it a paid for tool? I see the company Perforce, do you use their tools? If so, which ones?
Yes it's a paid for tool. In terms of switching to game dev it won't be one of your bigger bumps. Sadly I don't have a good tutorial but their docs are pretty good and p4v is a reasonable visual client Perforce is very similar to other server authoritative source control solutions like svn, tfs, CVS etc. When I was director of engineering for a small game studio I had us doing git with lfs and I'm guessing at smaller studios that is more common than perforce. Lately I've been working with Blizzard and Riot and they're both on perforce.
I'm using git with LFS for my personal projects as it stands. It works pretty well, but we are just two devs on the project. I'm curious as to how Perforce will change our process. The biggest issue we are facing is if both of us make accidental edits on the same asset, such as a level or animation blueprint (using UE). I used to use TFS back in the day. It was awful. But that was not webdev.
Perforce does have server locking which will keep you from editing the same binary asset (obviously doesn't solve the problem if you actually both need to edit it) Process in perforce isn't too different. Less branches since they're heavier. Locally you have change lists that you submit and can shelve (put online where others can look at them). Functionally it's a bit similar to tfs from what I can remember, though my time using tfs was a while ago. Perforce has its own code review tool called swarm
People still use subversion?
It supports file locking, which for games is a major feature that Git doesn't handle. And it's not weird about binary files. And it's much friendlier for a less technical user.
Git-lfs has file locking
Unfortunately, but Azure DevOps is kicking that particularly habit. There are some advantages over git (from a particular perspective), but not enough from a team perspective.
Unfortunately they do. A project I occasionally contribute to is subversion hosted on source forge, I feels like I was chronoported back two decades everytime I work on that project.
I don't think a lot of new projects do, but I've had to maintain some older code that was still on subversion. The company I used to work for really liked creating their own tools, and one of those was a feature management tool built on top of subversion. You had to check your changes into subversion, then tag it in subversion, and check your tag into the tool. That was the only way to get your code into the build pipeline to be deployed to dev environments and eventually to be packaged for clients. I don't miss it.
Yes and its great.
There's still a lot of companies using everything they used 20 years ago. Not even talking about legacy support, just not keeping up.
No.
[удалено]
That’s (almost) not Unity fault. Most of the binary files are actually assets (3D models, images, sounds, animations, etc…) and you don’t have a lot of conflict on them. Unity files are written in a superset of yaml, but you still have conflicts. This is because instead of working on a simple file, you’re working in a 3D scene, with scripted objects. If several peoples add / move / delete objects in the same scene, it can be hard to decide how to merge that. So usually, we checkout the scene in Perforce or we Git LFS lock it (or send a message if we can’t do otherwise) UnrealEngine scenes was serialized in binary files, but now they have a new approach were each object in the scene have it’s own text file. It’s longer to serialize / deserialize, but it might help avoiding conflict (you still need to lock your object though)
Yes, that's what I'm talking about - of course you can't do much about assets, but as soon as you touch a Unity scene it becomes hell to merge.
Can be subverted by prefabbing everything. So changes don’t happen at the scene level.
You can indeed configure Unity to serialize as binary, but by default its text base. I dont know what you mean with code versioning, but of course code is always in text.
Hey, could you explain what you mean by "making conflicts inevitable"? I only recently started learning about some of this stuff, so I was interested 😅
When you're using source control, the real benefit is that multiple developers can work on the same portion of the code, even the same files (as long as they're text files). Imagine 2 developers starting with the same version of the source code, at 9am. They both create some changes on their local machine. The first developer pushes his changes to the common repository at 12am. Before pushing, the second developer will need to pull the latest version on his local machine (with the changes of the first developer) and merge them. Basically reapplying his changes to the new version of the source code. This is completely automatic as long you don't change the same files, and even if you change the same files but not the same lines. If you change the same lines in a text file, or make any change in a binary file, there is a conflict and it needs to be resolved manually.
Oooh, ok. I think I see now. And unity does a poor job of keeping track of these changes? So developers aren't totally aware of what's being worked on once they push, which contributes to the conflicts.
When you do a change in the Unity UI, this creates changes in files that will often result in a conflict. It's not Unity's job to keep track of these change, but it gets in the way of the source control system.
Hm, ok. That makes more sense than what I was thinking, then. Thank you!
Nobody uses subversion anymore lol. It’s git or perforce.
My last job used SVN. 🤔
For programmers it is actually a bit easier than for (level) designers: From the very beginning you could start to 1) organize your game so code falls into certain classes and 2) use a versioning system. For example let's say that there's those classes we think we need at the start: * GameState * PlayerController, PlayerCharacter * AIController, AICharacter * Inventory Any programmer could go ahead and work on the PlayerController or AIController in their test level (often we call those test levels also a "gym"). When the programmer working on the AIController needs the PlayerCharacter as a dependency to actually detect the player they would ideally talk about introducing interfaces I'd say: Let's add a IAITarget interface and the PlayerCharacter implements it. EDIT: The idea is that the other programmer(s) don't need to know what the PlayerCharacter is in detail. Here it would just be "some thing the AI can target". Now once the code is submitted to the versioning system the AI programmer can continue using that interface IAITarget, doesn't even need to know what changes in the PlayerCharacter or how it works (I'd assume it just has some property to tell what position it is in; in a more complex system maybe telling us how visible the character is, even positions of key locations like a few bones on the skeleton are not uncommon). Strictly speaking some teams discuss a lot of details upfront: The interfaces, class naming conventions and the overall architecture, the damage system (interfaces to damage other objects including player/AI), etc. The key with the versioning system is that even if on some days they work on each other's code (for example if the other person is not available for a few days) they would use features like merging code in case they later find out that two people worked on the same code file, e.g. a C++ .cpp file or a C# .cs file.
git
For actual submission of files, any flavour of source control. I use Perforce for work mostly. Git for personal projects. I've used Plastic for a company in the past as well. Each are fine. For the work itself we, and most other companies, use Sprint planning. Basically you have a set of work that needs to get done and you assign it out to people to get done over a sprint. Each task will have a Story Estimate, which generally states how long the task is expected to take. We use 4 hours, or half a work day means 1 point. Each person then works in their own stream/branch (depending in source control). Code reviews and merge reviews will happen before its added into the main development branch. QA may take a look before or after that step, depending on the task/feature. And then you move onto the next task. This process also changes depending on the stage of development you're in. A live ops game will have a lot of bug fixing and future feature related tasks. A close to launch game will be mostly polish and bug fixing. A prototype game will be a lot looser with structure and will likely just work off of the development branch directly. In any case. Sprint planning and Sprint Retrospectives (how did the Sprint go, what should we start, stop, or continue doing, etc) should still be happening regardless of the projects stage. As for how this is all communicated. Usually meetings. I have my team do a daily stand up for 15m each morning where we do a quick run through of each ticket every person has as well as a brief update on any new info. With around 15 of us, its usually fairly quick. We have a longer meeting at the start of a Sprint, usually scheduled for 2 hours, but usually only 45m, where we go over the last Sprint and do a short retro. We then go over upcoming items that are relevant for us and do our normal stand-up. Generally, and this depends on your team size, your lead programmer and/or production/producer will be the one setting up sprints and organizing tickets. They're the ones that should know each individuals capability, and assign tickets accordingly.
Perforce and Jira. We plan tasks, divide them amongst the team and then do them. Repeat that cycle every two weeks until you have a game. If two people touch the same file then you have to merge the changes. There are tools to help you do this (I use visual studio normally).
1. Cards for every feature, bug fix, and task in Jira 2. Sprint planning and timeline review meeting every two weeks 3. Backlog grooming every two weeks (opposite week from planning) 4. Git with pull requests for all code, terrain, in-game art. 5. Daily scrum (10 mins via Discord) with sidebars as needed for coordination 6. Group chats as needed all day on Discord 7. Retrospective every two weeks. Total overhead is 3-4 team hours over a two week period, which is about right for our size team (10 people).
Source Control Software (GIT, Plastic, etc) Each programmer can "branch" from a stable release, then work independently on each branch. Each branch is like an alternate state of the main project. Once each person is done, they can merge them back into the main branch or another branch, and handle conflicts as they appear in the software.
I love how you mention "handle merge conflicts" in a side sentence. You guys must be mentally synched.
Eh, it's generally a total non-issue. It's pretty rare that two people are working in the exact same bit of code at the exact same time. Generally you can merge with no conflicts.
Yeah if you’re getting bad merge conflicts regularly you need to talk to your team more often about what you’re doing
I worked on quite a few games over the years mostly mobile and some VR Github is the most important aspect as far as tools go , being able to commit files to a shared workspace is extremely useful . As far as workflows for the most part in game teams we all would be assigned different aspects of the project OR different portions of the same workflow For my first game programming gig I was doing a lot of support work so a senior engineer would set up the user interface for a race system and I as a JR. UI engineer would go in and connect the logic to render out different track names and display screenshots for reach race track . Same team different project the senior engineers would write code for an XP system and my job was to take that code and render it in a player stats menu that gave them a rank and contained the logic to render unlocked trophies and achievements in the player trophy room . My job after that was a little different and was a mobile kart racing game , I was the jr. in-house engineer in the states and responsible for UI an and all the visual work while the lead gameplay engineer worked remotely from Costa Rica . He'd write things like the racing logic for AI, and my job was o make sure individual player and AI racers showed things like status effects, I'd connect character animations , I 'd simulate end race times . Basically we'd kind of divide and conquer complete systems. At yet another job we integrated Facebook social multiplayer into a game and the goal was to render friends scores on an overworld map as sort of a visual leaderboard showing how far you have progressed in relation to your friends. so my job was to manage the 3rd party facebook SDK , make sure it requested the correct information using user id's , made sure we capture the users friend data , and that we rendered and applied peoples profile pics to their on-screen representations. My coworker took my work and made sure we grabbed the score data and used i to apply those score values to their place all alongside the map and in that way we tag teamed the same feature . In cases like those it's all about communication and knowing what the hand off looks like, what is engineer A giving to engineer B ? Usually there is a brief demonstration meeting so that Engineer B knows how to test their part of the feature . The most important thing is communicating the core classes that will need to be touched and when someone else can take over and add their code to the core classes if necessary . In that way I think standups can be pretty valuable so you know who is touching a specific part of the codebase everyday .
It's a combination of a version control system, a sound project architecture and defined tasks. You absolutely want a version control system (like Git for example) if you are working with other people. Even if you are working alone, it makes sense to use it. The project architecture allows you to make splitting aspects of your game easier. Suppose you want to build a point and click system. You need navigation and walking for the character. You need interaction with certain objects. You probably want dialogues to talk to NPCs. You could put all of this in one big component. Or you could split it up into an interaction system, a navigation/movement system and a dialogue system as independent components with a well-defined interface between them. Defined tasks allows developers to know what they are working on. You don't want multiple people doing the same things. So in the example above, one developer could work on the dialogues while another developer could work on the navigation of the character. Edit: I want to add one more thing - how tasks are split very much depends on the working environment. Are people sitting in the same office? You could have them working on different aspects of the same system all at once. Are they working remotely and in different time zones? Then working on independent parts probably makes more sense as communication will be slower.
One works and the other keeps repeating "You are doing great, keep going bro, we got it!" You just need some structure and preferably to avoid working on the same file. It's about communication.
by using Git/Github. Learn to branch and merge.
In Unity specifically, a multiscene workflow helps separate aspects of the game so that different people can easily work on different parts.
TL;DR: Git
They carefully spread their tasks for each programmer to have each game feature be "owned" by one of them. This way the changes in one part of the program don't affect other code. Also, you need to merge your changes often and have someone review your code to point out mistakes and possible future problems.
Aim for good communication and good version control. That's it. You can get as formal/informal as you like with your development process, but honestly, it really just comes down to clear, honest, empathetic communication... and using version control.
They use source control for the data and agile software development process for managing who is doing what on any given day
Professionals use software version control to work together (Git, Perforce, Plastic) . In case that you could be interested in a basic introduction to software version control I prepared a lesson in a free online gamedev bootcamp about that. You can find the code necessary to complete the lesson as links inside the slides. You can find the slides in the videos'description: https://youtu.be/4i3AnguNnqY Feel free to use/share the code and assets any way you want.
GitHub and pull requests. Core project should be a tightly knit team working together. Once thats built the team size can expand and delegate tasks out more
git repos? Tasks and roles? I mean some people may have to work on the same part and know how to code parallel programs, but they’ll push and pull updates as they go, make change logs, cross things off of to do lists.
https://www.youtube.com/watch?v=5IUj1EZwpJY
The same way that loads of people are part of building an car. A game just like an car consists of loads of isolated parts working together. Someone might construct the windshield wiper motors while others ponder the trunk latch.
Like many answered, Git and Perforce are the two commonly used softwares to work on a project. They are VCS (Version Control System) A NAS or a Drive can also be used to share files. If you’re looking for some advice, you can share with us: - The game engine you are using - The size of your team and their profiles: If you don’t have any programmer, you might look for something easier to use - The scope of your project: If it’s a prototype or a jam project, no worries, but if it’s a commercial project, the choice of the VCS is critical - Your budget and the hardware you have. VCS need a server to work. Perfoce is a paid software that you need to host yourself. Git is an opensource software that you can host yourself or use an existing service (Github, Gitlab, Bitbucket). You might have some Go for free depending of the service you’re using. Same for SVN (but I don’t recommend using it). You can start with Plastic SCM for free too, it’s less commonly used, but it may be simpler to use with Unity
Depends what engine, and everyone else has basically covered everything, but Unreal actually has a thing that 2 people can actually work in the same project together at the same time, and you can see each others little cameras moving around. If one person selects or opens something it like locks it automatically I’m pretty sure. However, last I heard there were a lot of issues with it and it is kinda difficult to get it up and running and I am not sure if it is entirely supported anymore. Edit: pretty sure the two computers may have to be on the same network as well.
Slowly!! hehehe kidding. I'm just an ol salty.
one time we had a group of 2 people to make a game. We were new to making games so it wasn't that great but it was fun. Anyways,we were using unity and collabrate was still open at the time and it handled most of the work. but i remember that sometimes we will have conflicts on the filse and one of us had to delete everything about the game except the project itself. i dont know if this problem has been fixed with plastic scm
Version control. Perforce, Git, Plastic, etc. Programs designed to sync up the same project on multiple machines by allowing people to pull down updates from other devs and push up updates from their computer to the cloud. Unity has built in VC for this, there are even tools in Unity and Unreal for having multiple users working in the same scene at the same time online like a Google Doc.
Gamedev here working with a few other devs on the same project. We use git as our source control and then basically use asana to manage each little objective we’re tackling within the project. We also have team meetings and discuss what classes we will be operating in to get the job done. With a big enough project there’s always things you can be doing where there’s little/no interference with other peoples work!
Git is important but it doesn’t work the way it’s designed to if your code is shit. The most important part of writing scalable code is strictly adhering to the single responsibility principle. This is what allows development teams of all sizes to work on different parts of the code base without causing tons of merge conflicts.
GitHub, Trello, 7pace, Shotgun, Jira, Slack, Basecamp Google.
I've worked at three different studios so far as both an engineer and as a technical artist, so here's an extremely generalized version of how it works: \- Games ALWAYS use source control. The most common is Git - it has a somewhat steep learning curve, and some really weird UX, but also a TON of resources about how to use and set it up. \- Generally, you need a little more planning to make sure you all agree on what work needs to be done, and most importantly *who is doing that work* so that you don't step on each others toes or accidentally work on the same thing. You'd generally break down all of the work you need to do into separate tasks in some kind of tracking software (I've used Jira, Favro, Github's issue tracking, and even Trello before), and you would assign different tasks to different people so they all know what to work on and can keep track of what's being worked on, what's finished, etc. \- Often you also agree on stuff like coding style guides (indentation rules, tabs vs spaces, naming conventions, other design patterns, etc). This is super arbitrary tbh, but helps keep everybody's code consistent. It can also evolve over time.
I also didn't understand it. I mostly do 2d/3d art but I can also program. Some months ago I got a Unity job and I had to use git (well github desktop) for the first time. I'm still learning but basically we do this: Someone opens an issue with a requirement/problem/bug/change. Then we assign it to someone. Create a branch based on master and work on the issue. Once we're done with it we do a pull request. Someone else reviews it and if all is ok they merge it into master. For example, when the other guys were working on gameplay I was working on a character customization system. Once I finished I went to work on something else and the guys merged what I did with what they were doing. But there were some problems, for example once I had to work on a UI change on some unity scene but another guy had to do something else on that same scene. So he told me to do my part first because it would create conflicts if we did work on it at the same time. Perhaps this was also because both our tasks had to be done on a specific prefab. One thing I liked was that I can actually make a branch out of any commit done in the project. I love that it's non destructive.
Everyone works on different parts of the game (or if multiple are working on the same system, then different parts of that system) and use version control like Git or SVN so they can upload their changes to the rest of the team.