[Discussion] Repository Cleanup

[soraphis]

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]

Source/Base/CreateOnAwake

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

CreateOnAwake is needed if you want to create Variables / Events at runtime. For example if you are instantiating a GameObject at runtime that is going to use state / atoms. I use it for my game in this way. I want to use the same technique / pattern for updating state on my GameObjects that I create at runtime as I have for GameObjects that are already in the scene at start. This is something that should be added to an example scene.

Sources/GameFunctions

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

GameFunctions are just functions (that returns something) as ScriptableObjects. They can be used for example for conditional actions. In the future I would also like to implement a way to react to several events / variable changes and send those changes to a pipe of GameFunctions.

Source/Logger

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

Just moved it!

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.

Both utils and extensions were added at the beginning because I use them in my game. Will probably move all extensions / utils into its own repository at some point. If at that point the the extensions / utils are used in atoms I will depend on the new repository in Unity Atoms (not sure how UPM handles dependencies dependencies though).

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; ...)

I'm not 100% sure here what should be included in Untiy Atoms and what should be its own package. Unity Atoms could just be the bare bone framework or it could contain more functionality and be more of a full fledged solution (some that every user might not need every time, but could be nice to have everything in a package). If Unity Atoms is only going to be the bareboned framework I think we should remove AtomicUI, SceneManagement, AtomicTags, Molecules and Mobile, and then move each to its own repository. Dividing up everything like that sounds nice at first glance, but I have experience of doing this and it could also be a real headache. I would really like other peoples opinion on this as well.

[mbryne]

I appreciate the clarification around the above and just want to add my experience so far with this. I have been using your master branch over the past two or so months and have loved it but I definitely feel like the underlying UnityAtoms should be as barebones as possible.

I have not had much use for the MonoHooks, GameFunctions and GameActions at this stage. I understand their usefulness but I find GameActions etc really clutters up the UI when adding a lot of listeners etc.

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.

[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).

[AdamRamberg]

Thanks all for your input!

I will when I have time move all the extensions that are not used in Unity Atoms to its own repository.

I'm also thinking that it might be a good idea to scrap MonoHooks, GameFunctions, GameActions, AtomicUI and Mobile completely from the project. At the beginning of this project I was imagining that using the techniques above was the way to go, but in reality in my experience they are causing more overhead than what it's worth. If anyone disagrees let me know.

AtomicTags are useful though and I think it should be its own package based on Unity Atoms. I'm not really happy with any of the solutions on how to handle repos having multiple packages (monorepos) with UPM. Think that @jeffcampbellmakesgames suggestion is a really good one though, but still feels a bit hacky just to support UPM. Will have to think about this some more and in the meantime keep AtomicTags in the project. The best thing in my opinion would probably be to setup our own registry and then we can publish each package from the same repo using npm publish - see this. However, that is a lot of work I would imagine.

Another note (just to add to the confusion on how to handle multiple packages in a single repo). Unity are promoting this file structure. It might be something to consider if Unity thinks that this is really important to comply to (even though I'm against that they should say how one should structure a project)

[AdamRamberg]

@jeffcampbellmakesgames got a question about your monorepo solution. When doing an --orphan branch on each release we loose the history and users have to rely on only release logs for difference between versions, which I don't think is optimal. Do you have any solution / suggestion about that? Or are you thinking that first time there is a release of a package eg. atomic-tags you use --orphan (for v1.0.0) and next time you release a new version atomic-tags you locally add the changes to the branch created last time (using your tool) and then create a new branch (v2.0.0) from that one and push?

[jeffcampbellmakesgames]

@jeffcampbellmakesgames got a question about your monorepo solution. When doing an --orphan branch on each release we loose the history and users have to rely on only release logs for difference between versions, which I don't think is optimal. Do you have any solution / suggestion about that? Or are you thinking that first time there is a release of a package eg. atomic-tags you use --orphan (for v1.0.0) and next time you release a new version atomic-tags you locally add the changes to the branch created last time (using your tool) and then create a new branch (v2.0.0) from that one and push?

For any named package (stable/alpha/beta/etc...) you make one orphaned branch per package once and any further updates to that named package are made on that same branch. This has the benefit of separating the development and distribution updates and makes pulling the package more deterministic as long as each commit on the package branch is incrementing the package version (history between package versions is also much easier to read, not mixed in with development). https://github.com/jeffcampbellmakesgames/unity-package-tools/commits/release/stable is a good example where there is one stable release branch with two updates to the package on their own commit (v1.0.0 and v1.0.1).

and users have to rely on only release logs for difference between versions, which I don't think is optimal.

When making the commit to the package branch for a new version, I try to write an abbreviated message for the commit that summarizes the changes that were made.

If you plan on trying to support multiple major or minor numbered packages for development (say like patching v1.2.1 to v1.2.2 while also simultaneously release v2.X packages), I would make release branches that support that. Heres an example hierarchy for supporting two major versions of v1 and v2.

• release
  • v1
    • stable
    • canary
• release
  • v2
    • stable
    • canary

With this path you'd end up having release branches for v1 and v2 stable packages looking something like this for naming.

release/v1/stable release/v2/stable

and adding it to the manifest json package would look like this for a branch revision-ish or specific tag if the package commit on the branch was tagged. https://github.com/AdamRamberg/unity-atoms#release/v1/stable. https://github.com/AdamRamberg/unity-atoms#v1.0.0

The reason why its nice to separate out the versions like this if you decide to go down this route is that its still possible to update older packages for bug fixes or feature additions, but still make drastic new changes for a higher major version, but without forcing users downstream to have to upgrade or potentially break existing SO assets.

[jeffcampbellmakesgames]

The reason why its nice to separate out the versions like this if you decide to go down this route is that its still possible to update older packages for bug fixes or feature additions, but still make drastic new changes for a higher major version, but without forcing users downstream to have to upgrade or potentially break existing SO assets.

There is an implied assumption here with multiple supported major versions that there is a branch for each for development and the PR for the additions for the relevant version would go to the correct dev branch.

[soraphis]

The best thing in my opinion would probably be to setup our own registry and then we can publish each package from the same repo using npm publish - see this. However, that is a lot of work I would imagine.

Here is a blog post describing the procedure

https://medium.com/@markushofer/run-your-own-unity-package-server-b4fe9995704e

The problem I see with that approach is the cost efficiency (having an own package server for 2 or 3 packages), but on the other hand - It could be an package server for the entire unity community (which is obviously a lot more work and basically its own project).

But on the other hand it would be a pretty clean solution. You could use a CI to automatically run tests on tagged commits, if all tests pass it would automatically upload a new version to the package server.

Unity are promoting this file structure. It might be something to consider if Unity thinks that this is really important to comply to (even though I'm against that they should say how one should structure a project)

The folder structure unity suggests would not bother me. I find it confusing anyway that there are "Project Settings" in UnityAtomsTestsAndExamples

---

For any named package (stable/alpha/beta/etc...) you make one orphaned branch per package...

Maybe I'm confused by " (stable/alpha/beta/etc...) " but shouldn't it be like this:

create orphan branchs for: "atoms-core", "atoms-tags", "atoms-ui", ... based on this branches develop features/fixes (e.g. in feature branches) "atoms-core/feature/stuff-1"

when a new version is stable tag it, for example with the tag "atoms-core.2.0.0"

The reason why its nice to separate out the versions like this if you decide to go down this route is that its still possible to update older packages

that's always possible, there is no need for a branch since you can start a new branch based on any commit you like. especially if your commits are tagged.

for example you have the old but stable "atoms-core.2.0.0" but development goes on at "atoms-core.3.0.0b" (which is in a beta/preview state) you find a bug which also affects 2.0.0. checkout the 2.0.0 tagged commit, patch the bug, tag the new commit with "atoms-core.2.0.1"

inclusion in the package manager:

https://github.com/AdamRamberg/unity-atoms#atoms-core.2.0.0
https://github.com/AdamRamberg/unity-atoms#atoms-tags.1.0.0

the graph could look something like this:

[AdamRamberg]

I'm considering using your tool @jeffcampbellmakesgames to release stuff. I just did break out all the extensions from unity atoms here and at the same time tried your tool. Works pretty good! One question though. I used the following folder structure:

• root
  • UnityProject
  • Assets
    • MyPackage

I then exported using your tool with Source Path to Assets/MyPackage and Destination ../Source. The paths are relative to the Unity Project folder so a Source folder was generated at the root. I then created a new orphan branch and called it release/stable. I then had to delete some of the old files (Unty Project etc.) and had to reorganize the project (the generated package.json doesn't have a files prop so the Source folder was not included the first I tried this so I moved all files to the root). The release/stable branch ended up like this:

• root
  • file1-mypackage
  • file2-mypackage ...
  • file999-mypackage
  • package.json

Next time I will generate a new release and commit to that same branch there is still this manual process of moving files back and forth. Or am I missing something? @jeffcampbellmakesgames

---

What @soraphis is suggesting (regarding branch strategy) makes more sense to me as well when working in a monorepo.

[jeffcampbellmakesgames]

@AdamRamberg Do you have branches for this work that I can take a look at? The only manual step at this point should be clicking on the export button on the PackageManifestConfig from this point forward. I can take a peek and give you some feedback.

[AdamRamberg]

@jeffcampbellmakesgames Sure, the repo can be found here: https://github.com/AdamRamberg/marvelous

I think I get it though. Do you have to copies of the git repo on your local machine? So the release branch in one folder and the working branch (with the Unity project in it) in another folder. Like this:

LocalReposFolder

• MyProject
  • UnityProject ...
• MyProject_Release
  • Source...

[AdamRamberg]

Here is a blog post describing the procedure

https://medium.com/@markushofer/run-your-own-unity-package-server-b4fe9995704e

The problem I see with that approach is the cost efficiency (having an own package server for 2 or 3 packages), but on the other hand - It could be an package server for the entire unity community (which is obviously a lot more work and basically its own project).

But on the other hand it would be a pretty clean solution. You could use a CI to automatically run tests on tagged commits, if all tests pass it would automatically upload a new version to the package server.

@soraphis I think that you are right. It's too much work (a project on its own) to setup a server for this. Would love to do this though, but feel like I don't have the time for it 😞

[soraphis]

I can't see how @jeffcampbellmakesgames's tool will be helpfull in this case, since it does not care about the way how the package is distributed. Which in our case is the only problem.

What we wan't:

• split the project into different pieces (core, tags, ...)

What we don't want:

• Create a separate git repository for every tiny module

an Idea that crossed my mind:

• have a master branch, that consists of a Readme file and subfolders which all point to different git submodules.
• the submodules point to the same repository itself, but to different orphan branches

I'm looking a bit into it and try to make it work. this and this look helpful so far, and this might indeed be possible

edit

• Create a unity project like you normally would
• make the untiy project a git project like you normally would
• add "Assets/atoms-core" to the git ignore
• git clone . Assets/atoms-core -> cd Assets/atoms-core -> git checkout --orphan atoms-core
• -> git reset --hard -> git commit --allow-empty -m "initial"
• now you've got an folder "Assets/atoms-core" which points to an orphan branch "atoms-core"

this way all the packages could be in the same git project. they had orphan branches but in the project itself are folders that point to those branches

[AdamRamberg]

@soraphis That sounds really neat. However, I still don't see how the consumer of the libraries is going to consume for example atoms-core in their project. The nice thing with @jeffcampbellmakesgames solution is that the orphan branch for each package inside the repo will only contain that package (eg. atoms-core, atoms-tags) and there is no Unity project in the orphan, only the source.

In my mind what we want to achieve is:

• One monorepo for all packages
• Possibility to develop the package in the context of a Unity project that is version controlled. The Unity project is also a good place for examples etc.
• A way for consumers to target a specific version of a specific package. From my perspective the only possibilities (keeping in mind UPM's restrictions) here is to 1) doing @jeffcampbellmakesgames solution (orphan branch for each package) 2) create our own package registry and publish packages there 3) have each package in its separate repository.

[soraphis]

The nice thing with @jeffcampbellmakesgames solution is that the orphan branch for each package inside the repo will only contain that package (eg. atoms-core, atoms-tags) and there is no Unity project in the orphan, only the source.

My solution would be just like that, but with the master having a folder linked to the orphan branches for development. the consumers would import it via the package manager from orphan branches as described above.

Only the master branch would have the unity project, the orphan branches would only contain the package data

<root folder, git project pointing to master>
├──Assets
│   ├── Examples
│   │   └── atoms.core
│   │       └── <containing core examples>
│   ├── atoms-core (git project pointing to atoms-core orphan branch)
│   │   ├── package.json
│   │   ├── Editor
│   │   ├── Runtime
│   │   ├── Tests
│   │   └── Documentation~     
│   └── atoms-tags (git project pointing to atoms-tags orphan branch)
│      ├── package.json
│      ├── Editor
│      ├── Runtime
│      ├── Tests
│      └── Documentation~          
└── other unity project folders

for the consumer I think we can agree on

https://github.com/AdamRamberg/unity-atoms#atoms-core.2.0.0
https://github.com/AdamRamberg/unity-atoms#atoms-tags.1.0.0

where the identifier (e.g. atoms-core.2.0.0) are tags pointing to commits on orphan branches, which contain the package only

• developing the package would be within a unity project
• the consumer chooses specific version by using the tagged commit of the version he desires.

edit: Ok I now get the drawback. Since you'd have to add the folders to the gitignore (see my previous comment) they would not appear in the git directory ... so that would be an additional setup step when cloning the project.

maybe I have to see if I can make it work with recursive submodules ... they'd be cloned with the project

[soraphis]

Github package registry beta: https://github.com/features/package-registry

would solve this problem.

keep everything in one repo, and publish into the github package registry via npm

[AdamRamberg]

@soraphis that looks very promising! I will take a look at it. This will probably eliminate the need for orphan branches for every atom package 🥳

[soraphis]

yeah, was a really fitting time for github to introduce this feature :D

[AdamRamberg]

@soraphis signed up on the waiting list, so will just have to wait and see if they accept my account for the beta. Was thinking a little bit more, is there anything stopping us from publishing packages to npm (even though we are not publishing js packages)? Will a package published on npm work with upm?

[soraphis]

whether npm will accept non-js packages, I don't know. possibly.

As for the unity site of things, when using another registry you'd add a "scoped package registry" to the package manifest. More info here: https://docs.unity3d.com/Manual/upm-scoped.html

so for the user it would be:

{
  "scopedRegistries": [
    {
      "name": "Atoms",
      "url": "https://skimdb.npmjs.com/registry",
      "scopes": [
        "com.mambojambostudios.unity-atoms"
      ]
    }
  ],
  "dependencies": {
    ...
    "com.mambojambostudios.unity-atoms.core": "1.0.0"
  }
}

https://skimdb.npmjs.com/registry should be the npm registry if i'm not mistaken.

This would be the same process as for the github package registry, just with a different url

[AdamRamberg]

I was able to publish a UPM package to NPM and use it in one of my Unity projects 🍾🎉 Check this out: https://github.com/AdamRamberg/marvelous

I believe that restructuring the repo to only contain an Unity project (that contains Unity Atoms - core, tags, etc) and use NPM to publish the packages is the way forward!

[jeffcampbellmakesgames]

I was able to publish a UPM package to NPM and use it in one of my Unity projects 🍾🎉 Check this out: https://github.com/AdamRamberg/marvelous

I believe that restructuring the repo to only contain an Unity project (that contains Unity Atoms - core, tags, etc) and use NPM to publish the packages is the way forward!

Very nice, are you in github's package beta or is this via a different site?

[AdamRamberg]

Very nice, are you in github's package beta or is this via a different site?

Nope, this is via npmjs. The uploaded package can be viewed here. Haven't heard anything back from Github's package beta.

Was thinking about one thing. Do we really want to have all the packages in one repo? If we keep all of them in one repo it would (in my mind at least) be hard to have different release cycles. The most reasonable thing would be to keep all the major versions in sync with each other - Lerna calls this fixed / locked mode. How would you otherwise keep branches for older major versions of individual packages? One downside with using "locked mode" is that a package could go up one major just because other related packages have done so even though there has been no breaking changes in that package. What do you think @jeffcampbellmakesgames , @soraphis?

[soraphis]

It's a kinda hard question and it puts my thoughts back to orphan branches (like described here)

alternatively we could create a open source organization creating public repositories for all modules

On the other hand, I've no real problem with the project being not a unity-root-project. In the case where we would support e.g. 2019 and 2020 we would need to test the package in both versions, so we would always have changes on the projectversion.txt

when looking at the ScriptableRenderPipeline repository, the core/HDRP/LWRP packages are always kept on the same version, and as shown by the changelog.md of the core package it gets a new version even if its unchanged.
that way at least tags in github would make sense

[mbryne]

Can I resurrect this issue by any chance? Super impressed with the work that you are all putting in and this is unfortunately outside my level of expertise to assist in any way but I'd love to know where things sit on the idea of grabbing a unity-atoms core package? Thanks again everyone!

[soraphis]

Can I resurrect this issue by any chance? I'd love to know where things sit on the idea of grabbing a unity-atoms core package?

I don't see this issue as dead. It is just, that we've expressed all our opinions and shared our findings (problems and how to solve them).

If I understand Adam correctly (his post here), he has a few larger changes in mind in order to release v2.0 (the one currently on the canary-branch)

So I don't think that the package will be splittet until this is done.

but I think all of us would favor a modularized unity-atoms library, its just that it seems there is no "best way to do it"

[AdamRamberg]

@mbryne Thanks! Splitting the unity atoms into several packages is in the pipe and will be done pretty soon in the canary branch. Like @soraphis is pointing out, I've got some larger (breaking) changes that I want to make to the canary branch before the release though + some clean up and added documentation. The different unity atoms packages will after the split be available via NPM.

[AdamRamberg]

When we are on the topic (see above ☝️)

I'm thinking of removing MonoHooks from atoms. At the moment it doesn't really add any value and there are other solutions out there that enables one to consume Unity's life cycle method as events or streams, eg. UniRx. Seems from the discussion above that others doesn't see the value in keeping them either.

I'm also thinking of removing all implementations of GameActions / GameFunctions. These are always going to be really specific for some use cases, while atoms should be a broad solution. However, I think it's great to keep the base classes in order to in the future share some library specific implementations, like preprocessors for variables.

I'm also planning of moving TouchUserInput (Mobile) and Atomic Tags to their own repos.

Not 100% sure about 2 things though. 1) should Conditional Actions be removed? 2) What should happen to SceneField? Should it be its own package?

Before the release of v2.0 I will also redo the folder structure (again) in order to support publishing packages to NPM. I will also clean up and work through the docs.

@jeffcampbellmakesgames @soraphis @mbryne Would love feedback from all of you on this one. From what I've stated above, is there anything that you think I REALLY should not do?

[soraphis]

1) should Conditional Actions be removed?

I had to look into the source code, because I didn't knew we had those oO.

2) What should happen to SceneField? Should it be its own package?

yeah, that i was asking myself when I made the pull request. though question. at which point is some feature to small for a package? at which point is a feature to specific to be part of a core package?

Before the release of v2.0 I will also redo the folder structure (again)

Does not bother me at all - go for it., I'd suggest leaning towards the unity suggested folder structure, if possible.

[mbryne]

Greetings @AdamRamberg et al,

I'm thinking of removing MonoHooks from atoms. I'm also thinking of removing all implementations of GameActions / GameFunctions. I'm also planning of moving TouchUserInput (Mobile) and Atomic Tags to their own repos.

Definitely no issue on this, the leaner the better on that core package.

1) should Conditional Actions be removed?

Ha, I didn’t see these either and rolled my own for a conditional IntListener, imho I think they’re useful but as an extension

2) What should happen to SceneField? Should it be its own package?

No preference here, I’ve not used it

Before the release of v2.0 I will also redo the folder structure (again) in order to support publishing packages to NPM. I will also clean up and work through the docs.

No worries here, no pressure but is there any update / rough ETA on this?

The reason I ask is that I’ve been working on a few custom units for Unity Bolt that bridge the gap between Bolt and Unity Atoms. I find Bolts variable / events system quite brittle, relying on strings for custom event names etc. A lot of this will be fixed in Bolt 2 but ultimately I love the asset-based workflow of Unity Atoms so would love to build that extension against that revised folder structure.

I’m also excited to see what comes of the packaging solution, as mentioned my knowledge is a bit lean on the package management side of things. As part of this work would it be possible to request the creation of a small sample repository that could be forked that could serve as a suitable environment for creating our own Unity Atoms extensions that could be consumed in a similar way?

Once again, thanks for all the work you have all put in on this so far. It’s without a doubt the best implementation of Scriptable Objects I’ve come across and I’d love to see it succeed and grow and will do what I can to assist.

[AdamRamberg]

No worries here, no pressure but is there any update / rough ETA on this?

I have been swamped with work lately and have not been able to prioritize working on unity-atoms. That said I have planned to get some work done here the next coming weeks and hopefully I will be able to make a lot of progress and hopefully be able to release a first version of 2.0. I won't make any promises, but I believe I can get something done in 3-4 weeks.

Once again, thanks for all the work you have all put in on this so far. It’s without a doubt the best implementation of Scriptable Objects I’ve come across and I’d love to see it succeed and grow and will do what I can to assist.

Thanks you so much! :) I would really appreciate help with issues and PRs in the future after I've released 2.0.

[mbryne]

Thanks @AdamRamberg,

No worries at all, I understand it's a labour of love and that food on the table always comes first so I appreciate the update.

I will definitely be contributing via PR's and I would also be happy to work together on the website / documentation if required. I'll also be working on that Bolt Extension as a priority for our own internal workflow.

I'll keep a keen eye out for the 2.0 project refactor as it would be great to work on the above against that revised structure but once again no pressure.

Thanks again, I'm excited to see the project grow and will do what I can to assist.

Cheers, Michael

[soraphis]

@AdamRamberg nice talk about UPM in this unite video: https://www.youtube.com/watch?v=22HIEQTyozQ answering a few of this discussion topics and defining a development workflow for future packages.

could be a consideration for your 2.0 rework

[AdamRamberg]

@soraphis Thanks! Just looked at it and I think my rework will be pretty aligned with their best practices. The Samples will not be there in the packages themselves, but that is something we can add later.

FYI. I'm getting closer to a v2.0 release. Been hard at work in the branch new-repo-structure. I aim to have something done this week.

[AdamRamberg]

FYI. The new repo structure has been merged to the canary branch. I'm pretty happy with the result. Been hard at work splitting the repo into seperate packages as well as adding documentation and just polishing it up. I've created this website for documentation: https://adamramberg.github.io/unity-atoms/

Some notes:

• I actually re-added Mono Hooks (can't really make up my mind here and I actually missed some of the hooks). They are in their own package though, so you don't need to add it if you don't want to.
• I've also added none generic base classes based on @soraphis changes in his fork.
• I will release the packages on NPM instead of on Github's registry. The reason is that Github only allows scoped packages to be on their registry (with an "@" prefix). Eg. @unity-atoms/core. This would be nice, however UPM does not like package names like that.
• A lot of changes have been made to the generator, which I'm very happy with and will benefit users a lot I believe.

Let me know what you think! The plan is to merge this in to master pretty soon and then release v2.0.

[soraphis]

Hey, nice to hear! I'll have a look into this this evening and throughout the week and let you know (either via issues or pull requests) if i find something.

[AdamRamberg]

After releasing v2.0.0 I would really appreciate it to close this issue. I'm planning to release v2.0.0 this weekend / early next week if nothing major comes up. Let me know if you for some reason want this issue to be open and then we can discuss that further.

[AdamRamberg]

One more thing. I would like to remove all the FormerlySerializedAs attributes in the code. Feels like a resonable thing to do in a new major version and to improve code hygiene. What do others think? Go or no go?

[P-Stringer]

Hi @AdamRamberg . Have you deployed to NPM yet? My project is having issue resolving the dependencies. I've also searched https://www.npmjs.com and there is no mention of it..

EDIT: Ignore that, I've found it but my project is still having trouble. I'll look into it.

[AdamRamberg]

@P-Stringer I just released a new beta version, if you follow the quick start it should work.

[P-Stringer]

Yeah I figured it out eventually. Was originally attempting to clone version 2.0.0. Great work by the way!

[soraphis]

One more thing. I would like to remove all the FormerlySerializedAs attributes in the code. Feels like a resonable thing to do in a new major version and to improve code hygiene. What do others think? Go or no go?

I'd agree to remove them. its a major release: major may break things. no need to be overly background-compatibility aware.

keep in minor, clean in major

[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.

[AdamRamberg]

A little bit delayed, but version 2.0.0 is finally released 🎉 Thanks everyone that has been part of the discussion and that has contributed to making the v2 release. I will close this issue and if you want to discuss something more specific lets start that discussion in another issue. FYI, looking for maintainers for the project, so hit me up if you are interested. Thanks 🙏