Or simply being able to import multiple objects from the editor, rather than having to go through Windows Explorer to drop a bunch of stuff in the Asset folder.
Scene with an object that references a material that references a shader and several textures all spread all across multiple folders.
Basically, pretty much the main reason why you would ever even want to export package in the first place is when you transfer a scene, and you want only transfer it without all the unnecessary and unused resources. A scene references meshes, materials, audio clips, scriptable objects, etc., and when they are not in the nearby folders tracking those down by hand will be major pain. Thats’ what package export is for.
Interestingly, internally unity handles references via guids, and those guids are stored within meta files. Because of this for majority of tasks just copying things via file manager should be sufficient, as long as you don’t forget the *.meta files.
Getting back to the topic, I think reusable materials would be:
Sounds (effects, not spoken lines)
Base substance library if you’re using it.
Code
Some of the music
Fonts
Textures for particle systems.
And pretty much everything else will have to be scrapped and recreated.
Might be wrong about it, but basically graphics evolve over time, graphic standards change, and that makes reusing old models/objects difficult and old objects will stand out as a sore thumb (as they say). Good portions of codebase, however, can be usually upgraded to the new project.
I’ve always started a new project using my last project. End up having to rip out a lot of stuff specific to that last game but it still works to get a “jump start”.
Lately I have been reverting more and more to old practices so am focusing more on building game template projects that contain skeleton files and methods that I can detail in later.
Also I generally have a utility class/code file that can be dropped into any project to provide an easy wrapper for common functionality. For example, one of the first things I did in AGK2 is to create an InitDisplay method that wraps up the boiler plate so I can just specify width, height, window title and desired frame rate. Later I updated it to specify using Windowed mode or fullscreen.
Anyway completely agree with what you’re getting at. Reuse as much as we can to save time. Time is the only thing we can never get more of. No sense in wasting time writing the same utility functions and skeleton structures again and again.
Just recently I decided this was the most important thing in game dev, to make reusable assets so your next game can be spit out very quickly. It’s hell to always start a new project from scratch every time. Just need to do it once and well, and make the future of game dev 10x easier. Decided I should keep in the same art style, same UI style, similar types of games, etc to make the process more reusable. I will never jump ship anymore from like 2D to 3D, or Pixel to Vector, etc as making that process reusable is pretty much impossible. It’s crazy how much of your scripts from staying 2d pixel art really depend on the game staying 2d pixel art.
UI imo is one of the most important parts that take literally forever to make, and seems to always need to be refactored from every project or remade from every project. Decided to just do it properly once, and always have the assets ready. Properly I mean documented like crazy, structured nicely with no dependencies, etc.
I also figured I should make more useful reusable stuff like special importer scripts to handle importing of 2d assets, or button extensions, etc and to make sure they literally work by attaching the script and never worry about it again.
Shared / common / agnostic tools have thier own repo.
unity packages. (Export/import)
custom export/conversion batch tools
For personal projects and prototyping, I use forking. I have a project called Core that has all my tools and common libraries and a handful of prototype/placeholder assets. Anytime I start a project I fork from that.
I have a project that has all my sounds, and another that has all my particle effects. When I need something, I just go shopping in those two projects and ´export´ what I need. For what it is worth, since I only make 3d games, I also have a project file that is nothing but terrain textures, another for rocks, and another for plants ( I have thousands of plant prefabs). It is just easier to have them in their own projects and go shopping and export, rather than importing huge packages and then deleting most of the stuff.
I also have created an asset package that includes everything that I use for every project, which includes a bunch of editor scripts and some common tools. When I start a new project, I just drag that one asset pack into the scene and voila, everything is there.
Export Package - it is your friend, use it to create your own ´starter package´.
Just to add, you can also include things like a start menu, options menu, credits scene etc.
Again, create a new project, add nothing but your most useful tools, then add your ´always´ scenes like menus… then export everything into a pack.
Same here. Adding a suggestion: Import Unity Test Tools into this project, and set up thorough, automated tests in a separate folder. Whenever you make a change, verify your tests. It’s especially important for this project to be bulletproof since all your other projects will rely on it. You can exclude the test folder from your ‘starter package’, keeping your other projects smaller and tidier.
None of these address the need of multiple projects through a large organization, with multiple dev groups. The same way that we have a common code base to promote consistency and easy of use, we also need a single common assets base. I am desperately looking for a way to accomplish this. We can do this with code in .dlls but what about assets? Here is an example. And organization secures the rights to several fonts. No other fonts should be use as the organization needs to approve them. We need a single location for these fonts, that can be updated when a new fonts is approved and automatically “propagated” for use by all the projects we are working on. I can’t find a good way of doing this. It always comes down to “copies” and having different copy’s of an asset leads to problems figuring out who is using what. Plus the user needs to know what he/she is looking for and where.
Another example. We have two projects that use a base button in blue, the button is a prefab. You can go hunting for it and use it. Now the artist comes in and makes a new red texture for the button, and we want all our buttons to look the same way. He changes the prefab. But the guy on project (gameB) did not get the memo. So he did not go an get the new prefab and that project now is out of sink. So what’s the solution? Any thoughts? Should the assets be embedded into a .dll ? Update the .dll and the assets come with it? Can that be done?
So what’s the solution? Any thoughts? Should the assets be embedded into a .dll ? Update the .dll and the assets come with it? Can that be done?