Hello everyone,
I’ve always made small games using Unity so a flat structure was always easy to do. Now though I am beginning work on a much larger project and I have some questions about structure.
I wanted to create each feature of the game in an isolated sub-module. I think the common term is a Bundle, except they won’t be external. I’m also using AutoBuilder so I don’t need to use Unity’s bundle tagging, I think, but I’m not sure.
Does it make sense to have a Features or Bundles directory, and in it have things such as “Controls”, “Pathing”, “Camera” and in each one have Scenes, Scripts, Prefabs, etc. The Scenes would be used exclusively for development, testing, and design for each mechanic.
Then, in each scene meant to be the actual game I have in a directory such as GameActual or something. In there it pulls in prefabs and scripts from the Features/Bundles as needed.
Does this make sense? Is there a standard for something like this? When the project is compiled, will these bundles be separate so that if updates are required the patches can be small?
Before worrying about building new solutions for updating, decide which platforms you are going to target and then look at what is available on that platform. For example, I release games on Steam. Steam has an excellent update system that automatically distributes the difference between builds. So if your initial build was 5GB and you made a 100MB change, then users only need to download the 100MB change during an automatic update. You don’t need to re-upload everything, and players don’t need to re-download everything.
1 Like
Unity will only build assets required by the specified scenes in the build, so you’re good to go so long as you only build your playable scene when needed. (you can see what’s increasing build size by going through your editor log)
There’s really nothing special about building a larger game, name things properly, put them in sane folder structures, etc. One step at a time.
If I can make any suggestion, make each of your components isolated from each other. If you have a dialogue system, have the communication with that system minimal and don’t link these systems by hand in the scene, use events or tag searching on awake to get references across the scene.
Before starting a big project would be the perfect time to watch this video:
And this one:
1 Like
As far as breaking down a large project, remember to break big classes into small classes. And also remember to consider breaking some large systems into their own namespaces. In big projects, larger scripts tend to be harder to debug than small scripts.
2 Likes
I’m not sure what the expected advantage of bundles is, but the idea of separating systems with their own test scenes etc is a good one. In my game I treat each system as if it were something from the asset store, i.e., I create the base classes with their own tests/demos in their own folder, and inherit from them for custom code.
Besides isolating the scope of development and debugging, I know I will be building up a library of assets I can use in multiple projects, rather than having to hunt down code in scripts I can’t remember the name of, and extracting messy, dependent code blocks like entrails from said scripts.
1 Like
Hey guys, I know this response is suuuuper late but I consumed those videos and the other advice given here.
I just wanted to say thank you so much for taking time to share this knowledge with me. It has already helped me immensely!!
1 Like
