Hello everyone,
I’m a product builder and manager with over 8 years of experience but I’m completely new to Unity development. I’m overseeing a team of unity developers and designers working on a new project and have not been able to effectively manage the project.
I see my team going over the same things repeatedly as it’s very difficult to detect the changes in the Scene. Sometimes we get stuck in a loop fixing and seeing the same issues popping up again and again. I believe most of it has to do with the traditional tools I use which are not that effective with the projects developed on Unity. Are there any tools you can recommend?
What methodology do you use?
I don’t follow what you mean by this, but it makes me wonder about a few things.
How are tasks documented, assigned and tracked? If people know a thing has been done, surely that’s enough on its own to not try to repeat it even if it’s not easy to detect for whatever reason?
Are scene files being passed between people a lot? It’s pretty normal for that to happen from time to time, but the same scene shouldn’t be getting passed between people so often for this to be an issue.
Do you have some kind of separation between art / code / integration? E.g. are prefabs being used effectively? Are you making reasonable decisions about what goes in what scenes? Is your code set up such that you don’t need a bazillion things to be manually re-configured across multiple scenes when something is added or changed?
Is there version control in use? If so, are the comments / logs from that not clear about who has done what?
What sequence of events is causing issues to pop up after being fixed?
Absent of any context to give better info, I’d look at something like Jira and using an agile / SCRUM kind of approach as a starting point, though I suggest this to solve communication issues moreso than project management issues. I find it’s useful for project management, but I tend to combine it with other things.
Could you give an example?
Usually that is indicative of a team not fully understanding the tool(s) they are using. They dive in to hot-fix something, and it works, but next time someone else makes a change, you have this or similar/related issue coming back. Then another hotfix is applied. If left unchecked, this behaviour becomes organizational culture.
Instead, time should be taking aside to analyze the problem, understand why it occurs, and implement the necessary steps to prevent it in the first place. Sometimes this means changing the workflow, instructing the team, or improving the code or asset pipeline.
The solution has a lot to do with the kind of issue you are dealing with. For example a common issue is .meta file out of sync for an asset and the team keeps running into “missing references”. There is a known cause and solution for this, and you can prevent those issues with source control scripts that prevent adding asset files WITHOUT a acompanying .meta file which is most typical cause of that issue.
Another common issue is multiple users working in the same scene. Either concurrently, and then having merge conflicts. Or users not understanding source control simply confirming the dialog popup with “accept my changes” and overwrite someone else’s. A good strategy for that is to split the scene into multiple scenes, or create and work within prefabs for the most part.
Lastly, it’s impossible to tell what kind of tool you are looking for. Team communication like Slack? Source control like git? Agile task tracking like PivotalTracker? Project maintenance like Asset Hunter? Some magic automation tool that doesn’t exist?
What tools do you currently use? That would help giving recommendations as to what tools game devs typically use instead. For example: MS Project => PivotalTracker, Jira
there is no information in the original post. What can anybody say?
If I have to bet I’d bet on communication issue being culprit before any tool issue.
What you are describing is a pretty common pain point when coming into Unity from a more traditional product or software background. Scene changes are hard to review, and without clear ownership and checkpoints it is easy for teams to end up fixing the same things multiple times without realizing why.
What helped in a similar situation for us was separating two concerns. One was how Unity changes are reviewed and validated, and the other was how work is planned and tracked outside the engine. On the Unity side, we started being very strict about smaller changes, clear acceptance criteria, and short review cycles so that scene level issues were caught earlier.
On the planning side, relying only on generic task tools made it hard to see dependencies and workload across designers and developers. We eventually moved to a more structured project setup that let us track features, bugs, timelines, and ownership in one place and review progress weekly. Tools like Jira or even more full featured platforms like Celoxis helped because they gave better visibility into what was changing, who was touching what, and whether work was actually moving forward.
The biggest improvement came from tightening feedback loops and having a single source of truth for priorities and scope. Once that was in place, the Unity specific issues became much easier to manage.