[Discussion] Repository Cleanup

Just going through the files and folders, here are my thoughts:

Source/Base/CreateOnAwake

• i don’t get the use case of this classes. Can you make an example?

Sources/GameFunctions

• i don’t get the use case of this classes. Can you make an example?

Source/Logger

• AtomsLogger.cs should be in Utils. there is no need for an own folder for that simple wrapper class.

Source/Utils

• Vector2Utils.cs is never used

Source/Extensions

• all but GameObjectExtension are unused
• and if its only that one class, I’d move it to Utils.

Source/AtomicUI

• UIContainers.cs
  • GetComponent calls should be cached
  • more important: this looks, as if it should be an own project UnityAtomsExtension where common used Components could be predefined. The class itself looks like a imho pretty uncommon use case. I wouldn’t include it in the library.

Source/SceneManagement

• same as above, looks for me like a special usecase. (most of the time you want to do way more than just load a scene (load it async, to show a progressbar; play a sound; load it additively; …)

[AdamRamberg]

@soraphis Great! Just removed all the FormerlySerializedAs attributes.

WIll try to release v2.0.0 tomorrow or on Monday. Let me know if there is anything I should adress before releasing it.

[jeffcampbellmakesgames]

I believe the best use-case for using UnityAtoms for most developers would be using a core package as a set of architectural component where the use of these four types listed above can be used to promote reliance on abstractions decoupling systems and enabling single responsibility of a system (for a real world example, using scriptable events/event listeners to interact with a menu system written in code allows a designer to create a functional UI with sounds and particles without requiring an engineer to wire up many various UI elements in code).

That being said, there are various components of UnityAtoms currently that seem to be less architectural in nature and lean more towards allowing a level of scripting that is probably more oriented towards a specific implementation of a game. MonoHooks, GameFunctions, GameResponses, GameActions, AtomicUI, AtomicTags, Mobile are a neat idea in concept, but are generally a leaning towards a specific implementation of how to script a game similar to visual scripting or other non-code scripting methods versus an architectural component that is implementation independent (or in general may likely be duplicative of what end-users have already for the same functionality like touch input).

I would personally love to see a fairly lean core framework (Variables, Events, Listeners, Lists) with additional functionality built on top of it in subsequent packages.

I would probably advocate for an approach similar to this myself; one core package for the essential scriptable architecture components and for the others that contain some of the more niche/edge case functionality that details a specific implementation approach either to:

• Create individual packages that rely on core and build upon it. This allows for a modular distro of UnityAtoms and allows each package to rely upon and build upon the core package without a direct coupling of it. This is harder to do right now as there is not clear guidance on how to specify dependent packages as packages are not an official supported feature yet, but we should actually get more of this in Unity 2019.1.
• Create a core package and a full package that contains everything else. Development wise it would still be better to treat these other areas as separate packages with their own Assembly Definitions so that they promote the open-closed principle and do not tightly couple these components, but this would help them to remain in the same project

With a different repo organization and package release strategy it would be easier to support doing multiple packages with overlapping/different content from the same repository. I develop and support an open source (MIT) Unity editor tool here that I was inspired to make in part because this repo promoted the use of packages (which I really like and believe is an improvement to importing a unitypackage) and it offers an additional strategy for package distribution. It can also be imported itself as a package in 2018.3 and later.

Rather than host the package in the same folder as the Unity development project, I recommend cloning a second version of the same repository adjacent to the original and creating an orphaned branch (no former git history) that contains only the package.json and source itself (this step needs only to be done once per package distro to create its branch). This can be done locally like so:

git checkout --orphan branchname

I usually prefix my non-develop and master branch to help organize them into folders in GIT GUI tools and better indicate their purpose so my package release branches look more like this:

git checkout --orphan release/master git checkout --orphan release/develop

My tool allows you to specify a PackageManifestConfig ScriptableObject that defines all of the fields for package.json, the folders/files that should be included in the package, and an export location. From there it has a custom inspector that offers a one-click button to clearing out and updating your package source. Using multiple PackageManifestConfigs you could define multiple packages and update different release branches for each one.

This would likely require the source code were not itself located as a file package for the project and included in the Unity project itself, but it seems like this is currently being done more to distribute the package than as a typical means of development.

Overall the benefits of this strategy is that it decouples the location for how/where/when the source is developed and where its distributed, prevents end-users from downloading a development package that may be broken or with features half-completed, separates git history for package distribution and development, allows end-users to much more easily use Visual Studio or Monodevelop to work on the library, and supports multiple package distribution from the same development project. The downside for package release is that it requires a second clone of the repository to work effectively, but this is a one-time cost per developer that has to update packages.

Both utils and extensions were added at the beginning because I use them in my game.

I created a PR here to help take a first stab at removing some of the redundant code. My general thought on including this type of functionality in a library is that we should always ask ourselves is something like this because its a part of the library’s API we are intending to give support to or do they just seem generally useful, but unused. If its not being used internal to the library it typically should be removed and if its something that’s used internally, but is not intended to be used/supported for end-users it should be marked as private/internal. Overall this makes the library easier to support and build upon because we’re exposing the leanest minimal API that users intend to support and reduces the surface area of things that could break in an end-user’s application as things change (public utility functions are changed or removed).