Prepating for up-scaling the open source project to a larger /diverce community

[studentutu]

Here is an ideal place to mark everything that can go wrong with the project when it scales rapidly. This place could also serve the role of the solution center for all of those issues. Please join and share your experience with large projects.

• [ ] Too many assets. Most of the project when upscaled will look something like this (70% assets,15% scriptable objects and resources along with them,10% plug-ins with huge libraries inside, 5% text assets - code, documents, json, cvs, and other text files ) From the assets, we have textures, meshes, audio/video -clips,

  👌Solutions :

• assets with uniform naming, folder structure. (Updated assets are never directly removed from the project, only constructive behavior).

• asset management - there are a number of ways to look at which assets are used and which are not.

• asset bundles to store/retrieve large chunks of data for the specific places inside the application

• addressables - for ease of use and convenient retrieval of the asset from different places (+ async requests)

• UI atlases to store the textures in one

• for the runtime texturing - virtual texture from one of the preview versions of the render pipeline

• for the audio - there is an F_Mod library that helps to create multiple audio banks, which can store the original data in a more compressed format. It is ideal for the simulations and such, where the sheer number of audio clips is overwhelming.

• for video - you can use smaller sized video clips, even remove the audio from the clip, but then upscale it and do some of the trickery with it using the ML packages like barracuda to upscale it nicely (if it even needs to be so)

👉References :

• https://www.fmod.com/ or similar commercial products for battle royal style games. There was once a Unity blog one of them.

• https://assetstore.unity.com/packages/tools/utilities/find-reference-2-59092 asset managment

• [ ] Complexity of the dependencies. Hard to debug. Maintainability of the project The project is so complex the bugs are nearly impossible to debug, or takes weeks to be found (release QA) or worse to fix them. One of the huge problems in the rapidly scaled application - is the quality of it.

👌Solution :

• use a setup scene. Adding it to the test scene should be enough to bootstrap the project. This allows quick prototyping without messing up the rest of the project.
• using interfaces instead of the hard code classes.
• unit tests (a new feature to test)
• integration tests (does it work with other features) - set up a test scene with everything in it. It will serve you as a common setup for all consequent tests
• regression tests - first thing after the pull request - run all of the tests. If it fails. Do not merge it in. Thus it will require developers to write smaller commits and pushes, as they will not likely to break something major.
• dependency injection in conjunction with the mocking library. A reliable way to test things without to actually write anything major apart from tests themselves. Zenject + NSubstitue will do the trick, Easy to use, easy to learn, fun to write tests.
• packaging - introduce assembly definitions and package functionality accordingly,
• CI - automated build will be your primary source of bugs for a long time, those bugs can't be easily be found just with a simple test.

👉References:

• the MRTK way of testing Unity in AR/VR/MR - https://github.com/microsoft/MixedRealityToolkit-Unity

• [ ] Design choices are different everywhere. Colors are not from the target pallet. Non Uniform features.

The constant issue with prototyping a new feature - is a lack of general consent of the others. At the later stage, everything must be uniform, and someone will redo all of the work once again.

👌Solution:

• use presets
• use prefabs/nested prefabs
• refactor code to suit the general flow. Use injections to quick prototype. Use interfaces to get the test done quickly,
• use scriptable objects to store colors for the UI, or similar minor issues like that.
• separate presentation layer (views) from the logic. It will help. Always.

👉References :

• the MRTK way of re-using the prefabs, data flow for the actual presentation layer - https://github.com/microsoft/MixedRealityToolkit-Unity

• [ ] Miscommunication. The feature is not properly declared. Too much manpower for a single feature. It is a common issue when there is a feature to implement - developers/designers can overkill it quickly, or even worse - completely misunderstood the feature required by the app.

👌Solution:

• 1 design documents both for 3D artists and developers. This ensures that artists will know what actually be happening to the asset , and for a developer - the design for the art and for the scene. It should be uniformed and be placed somewhere in the Readme page.
• feature should be sufficiently described - you can explain this feature to a rubber duck method.
• design feature should be locked. It should not interfere with other features, only extend them.
• example. Based on the example designer/developer can create a prefab, which will be used for tests and later development.

👉References:

• there was a blog on Dreamworks 3D pipeline, with more info on that topic.

[ciro-unity]

I don't get the list. Are these issues that you see on the project?

There are many solutions that we cannot adopt. FMOD, Zenject, etc. This being an open-source project, we can't use third party tech whose license is not compatible with ours. Some others we already have (Addressables). Some are not applicable (prototyping? we are not doing that)

For these reasons I'll close the issue, the list generates a lot of confusion for people who read the issue and think that maybe we are going to use these tools or implement these features/solutions.