To summarize, I wanted to share with the community some of what I’ve learned over the years of working with Unity on working on my own large projects. There have been times I was so frustrated with Unity that I almost switched to UE4, but in the end I’ve managed so far, handled most of my problems. So lets dig in.
More assets isn’t always better…
While having more assets in a project can easily make it look better, the more you include the harder it becomes to manage, and the more time it takes for Unity to process things. Now they’ve tried to address some of these issues without a new asset pipeline and other features, but it’s still a problem when the project becomes too large. Take it from someone who had to slim down a 130gb project. It is best to decide at the start of your project the assets that you want to include, and minimize the amount of files you use. Consider how many different files you will need. Models, Textures, Audio, UI, Animations, Scripts, etc. It all adds up very quickly. So before adding a new object or material, see if you can’t create what you want out of what you have, and maybe even look at replacing something you don’t use with the object you want to add.
Organization is key…
When it comes to game development, things can easily get out of hand, and trying to navigate your file system can be pure hell. It s ideal from the start of your project to organize your folders and every time you import a new asset, organize it into your main folder structure or you will regret it later. It is also useful to create editor scripts and windows that handle the organization process, or visually display organized objects in a usable manner.
Data is your friend…
When creating object ideas and concepts such as Items, Dalog, etc. It is a poor idea to try and create these things as objects in a scene, you should always create data objects and data editors to handle the data aspect of your game. The best thing to do is create a Game Editor that is a end-all window to editing all your data, with organized tabs and everything linked together so you can easily select an item as a required variable in a dialog or whatnot. These things are simple once you learn the editor API, and will save you hours and hours, and possibly even save your game.
Be selective…
The more things you can get rid of the better, in a massive project you’re going to try and add all kinds of features, areas, details, and other things. Ask yourself if you need this, if it’s going to be important to your game, are you going to use it enough for it to be worth making? If not, don’t add it, if you already did, remove it. Sometimes it doesn’t matter how long you spent on something, if it isn’t worth it, it isn’t worth it. The important part is finishing the game, if you want to add extra features you can do that in an update.
Simplify as much as possible…
Complexity is great, but when you start to see 300+ code files and some of them containing 5000+ lines of code, tracking down a bug becomes very difficult. In large projects, try to create categories of ideas and inherit from them so that you can simplify your access chain and more easily determine how things are progressing. For example, when creating a game that has both NPC’s and Players, it might be a good idea to make both the NPC and the player the same type of entity, and simply change how they are controlled through inheritance scripts.
Lighting is your enemy…
In a large project with massive scenes, lighting becomes a tricky issue. Where it be shadow draw distance, or too many pixel lights, it can be hard to handle this. There is no grand solution either, you just have to be strategic about how you do your lighting. The reality is you can’t bake a 10 mile X 10 mile area of lighting, it would take days and be a massive number of files. So we’re stuck with realtime lighting and that creates problems. For reasons like this it is good to create triggers that enable and disable lights in areas the player is near, but cannot yet see. Sometimes even writing code that determines camera distance and angle to the light. This of course doesn’t work in any situation where the light might be casting shadows into the players view but still considered out of distance.
Shader overload…
So many assets these days come with their own shaders, and so often we find we need new shaders. Unity ha an inherit shader keyword limit that can be bypassed with some near features in 2019.3, but this isn’t ideal. In reality, it is unlikely you actually NEED that many shaders, and as such it’s good to delete any shaders you don’t plan on using the moment the enter your project, or just not import any shaders you don’t need. Try to make the standard shaders work anywhere you can, they’re pretty good looking actually.
Game Editors…
If you’re serious about making a big project, you’ll need a game editor, or you’ll never be able to organize all the data that the project needs. Build a special Editor Window, or a series of them, that handles the creation and editing process of all your data. Include paths to access your data in ways you need it. For example, if your dialog system has a “IfPlayerHasItem” check, then make a system that lets you select from your items and assign an ID. Never use actual object references for heavy objects like items, use ID’s, and load the when needed. Create a solid data structure for your game and stick to it.
I’ve learned a lot more but it’s getting late and I’ll update this later.
Hopefully the things I’ve learned in Unity can help others, beyond of course the code and tutorials I’ve written lol.