How much reuse do you get from project to project?

Regardless of game type most games have common features, e.g.

• UI - Menu / Inventory / Hi Scores
• 3D Models
• Textures / Substances
• Skybox
• Sfx
• Particle FX
• Controllers
• Meta Logic - Score System
• Pick Ups
• Prefabs

And with Unity's common engine, API framework and component system it should be easy to reuse/refactor code and items between projects.

Q1: So how much reuse do you get from project to project?

Q2: Could Unity make it easier to reuse items between games?

Q3: How do the professionals track and re-use assets, do they have databases/catalogues or libraries of assets?

 

Particle effects and models for prototyping projects. Also, don't forget Editor Extensions from the Asset Store! Many of them are highly reusable.

Overall, for real projects, not much reusability since I don't make universal scripts.

Doesn't Unity has "Export Package" feature where you export an asset and its dependencies? What can be easier than that?

 

Yep. I've used it for loads of reusable assets.

 

Could the asset export work better as an Import e.g. use case

• Start New Project.
• Realise you can reuse something from an old project.
• Find old project 'Not always simple'.
• Power up old project, could take multiple attempts, export assets.
• Import Assets.
• Close Down Old Project.

What if you could import assets into the new project with an external project viewer e.g.

• Start New Project.
• Realise you can reuse something from an old project.
• Use Import Viewer to find old project and view assets.
• Select needed assets and Import.

Surely this would be a workable* and cleaner import UX?

*There could be issues with Unity versions, but within a version range e.g. 5.x or 2017.x this could work and be easier?

 

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.

 

You can copy stuff between projects via file manager. You only need package export when you're exporting scenes with COMPLEX references.

 

Please define

?

 

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.

 

Wait, so in the end, I have to find my old project, which you mentioned is not always so simple.

Just have a dedicated folder full of .unitypackage files that contain reusable assets.

 

Yep, I do the same thing. If I have a thing I think I'm going to use more than once I typically make a unitypackage out of it pre-emptively even.

 

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.

Might be wrong about it.

 

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.

Basically building a game dev library of code.

 

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.

 

1) Forking
2) Shared / common / agnostic tools have thier own repo.
3) unity packages. (Export/import)
4) 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.

 

And particle systems. I have ~30 basic ones that I always start with, saves a lot of time.

 

I have about a hundred different projects scattered around. When I start a new one I typically copy and paste whatever I need in.

It's not the most efficient system, but it works on a small scale.

 

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.

 

As a solo Dev reusability is a big plus for me

 

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?

 

There are asset bundles which your game loads and uses. Maybe using networked (soft linked files to a common network drive) asset bundles you could have a core set of any type of art asset that appears in most of your games. You would still want the core asset bundles under version control just in case.

It's a pity you can't combine projects the way you can scenes in Unity as this would allow much easier reuse, it could also make assets from the asset store work easier.

 

As far as 3rd party assets I use, large sound effect collections, particle effects, fire and explosion effects, skybox and terrain collections, water systems, Table Pro for organizing and displaying UI tables, and Circular Gravity Force which is awesome for pushing objects around an explosion. These often are the first things I import into a new project before even starting any work on it.

UI themes can be used between projects, but depends on if it fits in the type of game I'm making and if I really want to have the same UI look between 2 or more games.

As far as in house scripts I use between projects, I use my CSV reading/writing script, my music manager script, my 3rd Person Camera Controller which is something I have up for cheap on the asset store, scripts I use for setting up and changing game options, scripts I use for handling command line arguments which I use for headless server builds, scripts I use as a starting point for working with UNet messages, and I'm sure there is more.

I often find myself working on a problem and then remembering I already solved this in a previous project, firing up that project, seeing what I did, and then copying either entire scripts or sections of one over. If I do that more than once then I generally create a project independent version that I can just drop into any future project.

 

It goes further than that, there is rarely a reason to throw out a system that is re-usable within the same game-type.

Well, easy is relative and IMO there are better ways.

This is a topic I am kind of obsessed about currently. First of a list of things that I re-use personally:

• Statistics\Attributes System
• Dialogue System
• Quest System
• Inventory System
• Save\Load System
  
• Building System
• Crafting System
• Ability System
• Audio System
• UI Framework
• Navigation Stack
• FSM
• Animation Framework
• AI System (GOAP)
• Pooling System
• General Extensions
• Zipping Library
• Path-finding System
• Math Extensions
• Terrain Editing Extensions
• Entity System (Not ECS)
• FPS Controllers
• TPS Controllers
• 2D Camera Controller
• C# Build System
• Voxel System
• Package Manager
• DI (IoC)

All of these (Minus the DI and Package Manager) were made for a game and found to be useful in the next, maybe with some bug fixes or a better API but usually the base is re-usable.

They are making steps towards this, the first step is Assembly Definition Files will make dependencies and modular code a lot more manageable. However the current system is actually pretty terrible and it doesn't have to be because this problem is solved many times over across linux distros, nodejs and even C# itself as a language. The second and bigger step is they are starting to install npm and are planning to use it as a package manager.

If you look at the bold item above you'll notice I have a package manager and there are three things any package manager does that makes it much better than the current system of unitypackages or the asset store.

1. Install package and it's dependencies (And their dependencies, etc) easily from either CLI or GUI
2. Ease of upgrading and downgrading packages
3. Custom repositories of packages and custom\self hosted packages

If you look at nodejs and the way packages are handled there you will see they have a much better ecosystem with a better ability to get up and running with projects.

I have been using Unity since the start of my professional career as an intern at N3VGames in 2012/2013 and use a package manager that uses git as it's source for packages and user config files to track custom repositories (Although I only have 1 ).

Basically it goes like this, add a repository to the package manager so in my case is simply:



A repo is just a git repository with a file for each package which looks like this:

Code (JavaScript):

1.  
2. {
3.   "name": "ubGridArray",
4.   "description": "1D array as 2D array.",
5.   "parentDir": "Packages",
6.   "childDir": "ubgridarray/Assets/ubGridArray",
7.   "location": "https://nhold@bitbucket.org/packages/ubgridarray.git",
8.   "versions": [
9.     {
10.       "version": "1.0",
11.       "branch": "version-1"
12.     },
13.     {
14.       "version": "1.5",
15.       "branch": "version-1-5"
16.     }
17.   ]
18. }
19.  

Then you just install the package you are interested in and update it as needed:

 

Yes in fact I was wondering if an answer would be to create, essentially, a "private/corporate asset store" ? Where people can import as they desire, exactly as the Unity store works. But that still does not prevent people from changing something in their project and "forgetting" to update the asset used. So again, hard to keep consistency across projects

 

This package Manager looks great, where is it available?