Hello everyone,
As I continue my journey learning Unity, I’m trying to understand how code is commonly structured in large Unity projects and in the industry in general.
I find it very difficult to follow random tutorials, especially on Udemy, as they often scatter scripts everywhere without a clear structure.
Coming from traditional programming, it all feels like a mess to me.
Then I found this video discussing the idea of having a single entry point in Unity:
And I also found this official Unity video that seems to use a different approach, not relying on a single entry point but rather organizing code in another way:
So my question to experienced developers is: Which approach should I follow?
Unity is really not made for having a single entry point. You generally build levels by placing prefabs that have scripts on them that initializes and updates in a pseudo-random order. Those scripts are each a tiny little entry point. This goes both for MonoBehaviour and ECS - you don’t get to have a main() function.
That has advantages and disadvantages. It makes it very easy to add stuff, and it forces you to have those scripts be very compartmentalized. On the other hand, if you do need specific ordering of operations between different scripts, it can be a mess.
A single entry point for all the code would require you to build stuff kinda differently. You’d have to only have data container scripts with no behavior on all your prefabs, and then gather them into collections that you interact with. You’d have to set up a central loop using the player loop system, and then use that to do all the things that are supposed to happen in a frame.
Is that approach better than the default Unity approach? It depends! Both on personal preference, and what kind of game you’re making. If you’re making a 2D platformer with independent enemies that you stomp, I think the default Unity way of independent scripts is the way to go. If it’s a turn-based like an XCOM or whatever, I think having everything centralized makes a ton more sense.
It’s also not an all-or-nothing approach. You can have all the important gameplay code work from a centralized system, but then have small one-off MonoBehaviours that control things like visuals where animations are not appropriate.
I don’t even thing you could have one, and only one, entry point into a Unity project. That would preclude you from using so much of the usual Unity way of doing things, such as Awake/Start/Update etc.
What makes more sense would be to have multiple singular entry points into different APIs that you have set up for your project. A lot of coding is often writing systems/APIs for other parts of your project to use. Often times that can benefit from having a primary entry point, though not always.
Otherwise project architecture is often decided by the needs of the project. You can have your preferred way of doing things but you do need to bend to your project requirements.
But at the very least, designing systems that have one-way dependencies on other systems, perhaps delineated by assembly definitions, is a good way to keep your project organised in general.
I create my game levels procedurally and so a single entry point is more natural. The creator script creates the world and then places the player and the enemies in the world.
They also have a tendency for copy-pasta and cargo cult programming. I’d say upwards of 90% of Unity tutorials are downright crap made by people who just happened to have learned Unity themselves.
Understandably. While Unity is powerful and flexible, it also allows you to create a huge architectural mess even with the best of intentions AND knowledge about software architecture.
Many available options/alternatives are simply not considered because they’re not known or not well understood. And then every project is different, and may call for different approaches.
You’ll also find patterns getting advertised, be it ScriptableObject Architecture (SOA) or MVVM or Dependency Injection (DI) and many more. Whether these are beneficial depends a lot on the project AND the team. In a programmer centric team you are more likely to find SOA a hindrance, whereas in a less technical team MVVM might be a total buzzkill, and in the wrong hands DI just generates bloated code with references everywhere rather than systems with ownership and responsibility.
I think one of the core fundamental learnings as a Unity developer is to consider whether something needs to be a MonoBehaviour, or rather a plain C# class/struct, or perhaps a ScriptableObject. And to learn and embrace editor scripting, and plain and simple C# event Actions.
And one simple rule to follow: a script should only be responsible for the things that happen to its object and its children, never siblings or parents. These tasks should be relayed to scripts that are on the sibling or parent object.
You can get most of the way there with a manager behaviour that everything subscribes to for their events, and then create a derived behaviour that uses its Awake to do the subscribes based off of its interfaces.
Like @CodeSmile said most of them are made by people who have no business making them with few exceptions. For example @git-amend has good intermediate to advanced tutorials.
While I don’t disagree with everything that has been said so far, there is a limit to how much someone can learn on their own through tutorials, books, and similar resources. Eventually, you hit diminishing returns, and your progress starts to slow down significantly.
In my opinion, the best way to move beyond that limit is to work at a company that not only uses Unity but also has experienced developers on the team. There’s a huge difference in what you can learn when collaborating with others, solving real-world problems, meeting deadlines, and working on projects where the requirements are defined by external clients (who often may have no idea what they are talking about) rather than by yourself or your team.
The growth you experience in a real-world job, especially when you’re working alongside more experienced colleagues, simply can’t be matched by theoretical learning alone. Given your background in traditional programming, I believe you’ll recognize this from your own professional experience. If you’re able to find a Unity role with a comparable salary and work environment to what you’re accustomed to, I’d strongly recommend considering it. It’s one of the most effective ways to move beyond the basics and start exploring the architectural side of game development.
Thank you — now I’m even more confused, haha.
What do you think about this open-source project from Unity?
Could it serve as some kind of “source of truth”?
do you know any other open source projects i can learn from ?
That’s mainly because superior code quality doesn’t get you more clicks, to the contrary I’d say. Most tutorials are designed to be for absolute beginners and slightly intermediary as these get, by far, the most views.
The open source projects, if they were designed to be learning projects, follow the same style. You’ll notice them by typical patterns such as:
most MonoBehaviour fields are public rather than private [SerializeField]
use of string-based indexing (ie GameObject.Find(“”) or Animator.SetBool(“”))
copy-pasta code and excessively long lines
This even goes for Unity’s own example projects. A complete project will hardly embrace all the best design patterns.
What you need to be looking for specifically is best practices, or just generally good practices and try and compare them yourself. Research what others are saying about these approaches. Start a discussion perhaps.
Like life itself, there’s no single source of truth, only preachers and influencers and a few well established ground rules like staying fit, eat healthy, don’t drink or smoke, don’t pray to godot, don’t be unreal.
Very strange in the backend world, you can always find open-source projects to get inspiration from and see how the big players do things. It’s surprising to hear that there are no reference projects, best practices, or official guides not even from Unity (which I’m currently downloading and reviewing).
There are three main aspects to this issue: the technical side, the architectural side, and the realistic side.
Advanced technical solutions, which some videos cover, often have limited appeal because they target a much smaller audience. As a result, creators are less inclined to make them. Additionally, these solutions tend to address highly specific problems and aren’t used on a daily basis like beginner-level content. Watching a video about a niche topic, like coroutine or tasks, might not seem useful today but could be relevant to a problem in six months or even a few years. By that time, the viewer may have forgotten the content, or it may be outdated. For instance, many coroutine and task tutorials have since been superseded by the Awaitable pattern.
On the architectural side, the lack of reference projects is largely due to the diversity of game types, each requiring different architectural decisions.
While best practices and guides do exist, game development tends to operate at a lower level of abstraction. For example, in web development, you might learn about the repository pattern, but at a fundamental level, this is just the dependency inversion principle where the interface is implemented by an adapter design pattern. Game development leans heavily on these underlying principles rather than standardized patterns.
This is because of two key factors: the wide variety of games being developed and the diversity of the teams making them. A game developed by a large team of programmers will have completely different architectural needs compared to one where the focus is on enabling designers or artists to work independently, or where testing and modularity are prioritized for QA.
This is also why looking at completed projects often isn’t very helpful. Architecture is fundamentally about solving problems and making investments now to save time in the future. When examining a finished project, you might see the final solution, but not the problems that led to it, nor the alternative solutions that were considered and rejected. Seeing the solution without knowing the context behind it doesn’t offer much insight.
Another consideration is that game development is tied to strict release dates, and programmers are just one part of a larger production pipeline. Their decisions are influenced by bottlenecks elsewhere in the process. Sometimes, instead of focusing on long-term architecture, they must prioritize building tools for other departments or fixing last-minute bugs.
And yes, many finished games contain poor code. But this shouldn’t be taken as proof that architecture doesn’t matter. Because game dev is a marathon, it is more like seeing the marathon runner that is about to finish first, when he is 100 meters before the finish line while the second place one is 500 meters behind him having a terrible running technique. This shouldn’t lead to the thinking that “look his technique is terrible, but he still is finishing first so technique doesn’t matter”.
This is only because before the end line, investing time to architecture doesn’t benefit, but solving last minute bugs and adding patched up code does. Everyone starts with the best intentions but before the end the code tends to get much worse, so even looking at released projects won’t give much help other than the solutions that were implemented the final days and solve last minute problems.
Finally, there’s the realistic side of things, how the internet and the game dev community work. Game developers form a large pyramid, with a broad base of beginners. As a result, content creators get far more views by making easily digestible videos that simplify concepts, even if they’re not technically accurate or offer ready-made code for copy-pasting.
Just look at the number of tutorials that show the defective singleton pattern or explain the Single Responsibility Principle as “every class should only do one thing”, followed by shallow code examples. These kinds of videos attract significantly more views than in-depth ones that explore the nuances of each concept, discuss different approaches depending on context, and require critical thinking from the viewer. They don’t offer the solution, just thoughtful perspectives.
Blogs tend to be a little better in this regard, as readers looking for quick and easy solutions often turn to videos instead. Still, high quality, in depth written content remains relatively rare.
As I mentioned in a previous post, nothing truly compares to real-world experience, working with a team, collaborating with experienced programmers, and learning from practical challenges. That’s where the most valuable lessons are found.
Well, in the “backend world” (nice term) you’re dealing with professional software developers and the juniors are most likely highly educated too. Then the subject matters are highly established, there’s a lot of different tech to choose from but ultimately there’s only one task: process, store and retrieve data. This favors established patterns and proven best practices. A lot of things are standardized too, or highly established general purpose patterns if not frameworks (ie NodeJs, Hibernate).
The main changes in architectural patterns developers are facing revolve around issues of scalability, security, resilience, latency. You can also often rely on just throwing better hardware at the problem or distributing it onto even more machines.
Games are quite different. For one, you’ve got practically zero kids wanting to create their dream backend service. Then each game can pose hugely different challenges. A 2d platformer with splitscreen couch coop has quite different demands than a 3D open-world online multiplayer game. And then for each things change dramatically when you want to deploy either on mobile or the web vs desktop or consoles. Not to mention AR/VR and TV games.
It’s kind of like NodeJs had different code bases, requirements and features based on whether you want to deploy to mobile Safari vs desktop Chromium, but also for each OS for both the backend service and the enduser website.
Thank you for taking the time to answer.
Can you recommend an open-source project that does things the right way — something I can use as a reference?
It’s hard to believe there’s just a giant void out there.
Can you recoment Thank you for taking the time to answer.
Can you recommend an open-source project that does things the right way — something I can use as a reference?
It’s hard to believe there’s just a giant void out there.
I never said it’s just a giant void. If you read my post more carefully, you’ll see that I explained the real issue: you can’t use these projects as reference points because the architectural decisions were based on problems that aren’t visible to someone examining them after the fact. These decisions were shaped by specific factors, such as the type of project, the circumstances, the team, the individuals involved, and many other variables.
It’s not that the projects were done incorrectly, it’s that there’s no single “right” way to do things. Everything is contextual, and without knowing the full context, you can’t truly evaluate the solutions. There’s no value in analyzing the “correct” solution if you don’t understand the problem it was designed to address.
As I discussed in my previous post, there is no one size fits all approach that can serve as a universal template. The “right” solution only exists within the context of a specific project, with its own type of game, unique team, particular requirements, distinct goals, and the people involved. What you see in the final product is just the outcome of that process, not the many problems faced or the alternative solutions that were discarded along the way.
It’s like knowing that the answer to the ultimate question of life is 42. That answer isn’t wrong, but it’s not useful unless you know the question. The same goes for examining the architecture of a finished projec, you’re seeing the result, but not the reasoning behind it and the problems it had to solve to be considered the right answer.
Off topic: You mean that in your search google shows the “Earth is currently computing the question. Please be patient”? Because for me, it has already found it:
Maybe we are in parallel universes or in different timelines
Yes, Google has the answer if you search for it. I see the same as your screenshot.
Earth is currently calculating the question. That was just me stating the fact that Earth is the supercomputer made to get to the question that lead to the answer 42.
Though the question might be as simple as “What is seven times six?”
Then each game can pose hugely different challenges. A 2d platformer with splitscreen couch coop has quite different demands than a 3D open-world online multiplayer game. And then for each things change dramatically when you want to deploy either on mobile or the web vs desktop or consoles. Not to mention AR/VR and TV games.
