Added package manager support

[JamesMcGhee]

Updated the repo to make it freindly to Unity package manager.

Part of this is to remove the editor script dealing with writing the steam_appid.txt file. While handy it can get in the way of other modifications and its not really saving a user much effort. Note that a package is treated as immutable so we dont want to put anything in a package that might need to be edited by the end user.

The main change you will see to the repo is the addition of the package.json and re structuring of licnese into an md so the package manager can understand it. We also added an assembly def Steamworks.NET.Runtime which is configured to only work on valid Steam platforms which makes the #ifdef statements in your source redundent for platform specific compilation but no harm. This also makes it possible for other assets to reference Steamworks.NET properly. Also as a package manager compatable package its possible for other developers to create a dependency with it via its name "com.rlabrecque.steamworks" and the version they want to be dependent on.

Finally a minor update to the readme to include instructions on how to install it via the package manager.

Note the package manager can also support "samples" these are additional downloads the user of your package can pull in on demand. Also note that samples are the immutable exception that is they are pulled in as "Samples" into the main Assets folder and can be modifed by the end user without issue.

[JamesMcGhee]

Added your Steamworks Examples as a sample with a minor change. I added the camera back in to prevent the editor from griping.
This can now be installed from the package manager after the user has installed the main package.

Also corrected a cut and paste error on our readme.md edit

[rlabrecque]

There's been some ongoing work here: #389
And on this branch: https://github.com/rlabrecque/Steamworks.NET/tree/unity-package

Could you rebase this CL on that branch to see what we want to take from this?

I agree with merging the Example and Test projects in too, I definitely want to go with a larger Monorepo with the switch to packages.

[JamesMcGhee]

Yep will take a look at that this evening

[JamesMcGhee]

Okay so what is there now on the master takes its queues from what you had on the unity-package branch.

The only funcitonal difference here from your unity-package branch is that I have included samples for spacewar ... and of course the switch to md for the license file so Unity Package Manager will see it properly.

This should make it very easy to install, update, remove Steamworks.NET and selectivly install the examples scripts. Still needs some clean up around lack of namespace in the editor scripts, get rid of the IMGUI based UI in the example, etc. I will look at doing some of that later tonight to see what you like and dont like with it.

Heathen has a number of extensions built around your Steamworks.NET some of which we do release freely on Unity Asset Store ... if there is any interest in included it here as a sample devs can pull in I can see what from that we can pull and make standalone and donate to the Steamworks.NET project.

[JamesMcGhee]

I updated the redist regarding the steam_appid.txt ... keep spaming me about not being able to write the steam_appid.txt fiile so I used our method and removed some old bits of code I found there that are only applicable to versions of Unity that are no longer supported.

I pulled in a lite version of our Steam Settings concept (renamed to SteamSystem) and adjusted the names so that if it is adopted in Steamworks.NET it wont break anything for users using our toolkit. The core of it is a scriptable object that handles configuraiton and intialization of the API for client or game server based on UNITY_SERVER define. As an extra nice to have it also manages common artifacts (stats, achievements, leaderboard and DLC) these are also scriptable objects for easy referencing ... that can be striped away without adversly impacting anything.

The main bits are

SteamSystem = ScriptableObject and root of it all, this handles config and initalization of client API and game server API and also manages artifacts as scriptable obejcts for easy refrencing in Unity editor.

SteamController = MonoBehaviour which deals with as little as possible mainly kicking off the start up, update loop and clean up based on Unity events.

In addition there is an example scene demonstrating the extension in a manner similar to the current Spacewar example

[rlabrecque]

I think we're going to need to squash all the changes in this to one, and then discard a lot of non-changes like .meta files changing.

Then we probably will also need to move some of the other changes out into future changes, it's going to be too hard to take all of this at the same time. But most of this sounds pretty good.

[JamesMcGhee]

The fundamental change is everything except the Samples~ folder and the related samples entry in the package.json.

That would get you into a shape that properly supports Unity's package manager and makes life much easier for importing and updating Steamworks.NET

Interestingly just in the past few days we have had quite a few support tickets around updating Steamworks.NET plugin updates most of it comes from simpyl droping the unity package onto Unity. Unity tries to update assets by ID but any changes in name or additions or moves can result in duplicates or other issues and that is where we get calls :)

Putting it to package manager would make it a simple button press to remove the old and import the new.

On that my sugestion would be to strip back the concept and just do the plugin folder and editor scripts. Ideally updating the redist install stripping away anything older than 2018 LTS

Can always bring in samples, tests, etc. later. Thats a relativly minor edit, if you would like I can set this branch up that way. Your still going to have a big structural change on master branch as it does mean removing the standalone folder and the meta files will be touched in all that I'm fairly sure.

[KelsamGames]

If the standalone folder is removed, and the VS sln/csproj within it, how will non-Unity C# users build/use Steamworks.NET?

[JamesMcGhee]

I would honistly run that as a seperate branch and since Unity's package manager can be a bit finiky about the pull from git I would have Unity be on the master and then provide the tools for non-Unity based C# project use a given branch

[JamesMcGhee]

As to the example scripts

If you backburner pulling them, Heathen Engineering can have a think and ask our community what would they like to see in a simple demo of the API around Spacewar (480) and we can help build that out. I do think in hind sight that having the SteamSystem.cs ScriptableObject only deal with configuraiton and initalization is the way to go.

So if the SteamSystem SO only dealt with config and initalization it would have the following features.
App Id field that when edited will update your steam_appid.txt file for you and remind you that you need to restart (usually) for that to take effect. Could maybe even be fancy here and check if Steam has ahold of us if so warn the dev they need to cycle to have the change take effect if not skip that its fine.

Next would be the Game Server configuration and of course all of that buttoned up with UNITY_SERVER so that initalization done and what code is used is build setting specific and not something a dev needs to think to do in the config.

Custom editor script on this to keep it clean and simple, menu editor script not just to create the SteamSystem object but also to link back to your repo, documentation, etc. For that matter the SteamSystem object and its behaviour should have [HelpUrl(...)] populated as well

Finally the Steam Controller (call it what you like) but the behaviour. Keeping this little guy stupid simple my personal wants for that would be

1. does nothing but use its MonoBehaviour "Unity Events" to kick off initalization and clean up on Start and Destroy respectivly and uses its Update to handle for the callbacks check
2. either does not mark do not destroy on load or exposes a bool so that its a configurable option ... shouldn't do this automagicly with no way for a dev to opt out.

[rlabrecque]

My expectations are currently: (Where each number is a separate task)

1. Get Steamworks.NET working in a package manager. (The Standalone folder should still exist, there will likely be other top level directories in the future ala 4 on this list.) (I think this is like 95% done already?) This would get to a point where users and library authors can depend on just the core functionality, using their own scripts to wrap Steamworks.NET. The goal of this PR should be bringing us to 100%, I wouldn't expect more than 5-10 files to have to change for this now.
2. Evaluate what we need to do to bring over something like SteamManager/SteamController/Custom Editor Scritps/etc. This one's a little trickier, trying to please both users and library authors. I agree the solution we have isn't great right now, there's some debate to be had about whether Steamworks.NET should even be involved at this level or if that should be left up to libraries that depend on it.
3. Move the SpaceWar example over from Steamworks.NET-Example (I would want any unrelated fixes to happen in the Steamworks.NET-Example repo first most likely, It would actually be great to get it set up as project which is using the Unity Package Manager to pull in the project). Or maybe we just have better little example scripts in this repo that users can optionally import instead? SpaceWar is not exactly the bastion of quality...
4. Migrate Steamworks.NET-CodeGen into this repo (I've started on this)

[JamesMcGhee]

Notes on each item

I think "The Standalone folder should still exist, there will likely be other top level directories in the future ala 4 on this list."
Is going to be a problem.
Unity's package manager seems prety basic, you give it a repo link and it simply pulls down the repo's master branch as is no directing it to different folders etc.
To keep the pull down nice and clean and not throwing warning messages about imutable folders and cant create meta files
And in kind for the standalone pep ... so they dont need to pull down a ton of Unity specific stuff why not simply make a "standalone" branch that has only the bits standalone pep use and leave the master to be only the stuff Unity Package Manager uses. I think this is a lot cleaner than having 1 branch that has all usecases.

That said if its really near and deer to your or other peoples heart we can see what can be done here. I dont think you can direct package manager at a specifc sub folder or anything so its going to have to be a matter marking up the standalone bits so Unity doesn't complain about them in the package folders. Note Unity will complain if anything is missing its meta files and it will do taht cosntalty as it wont allow its self to create them. e.g. the LICENSE.md file must have meta file wiith it or Unity will gripe on each load that it cant modify the folder and that its missing meta files.

I am 100% on board with Steamworks.NET remaining true to Steamworks SDK and not doing anything extra. That is one of the reasons we went with Steamworks.NET over Facepunch for our extensions.
To me #2 is a replacement for the current Spacewar example. A minimalistic example that simply shows how one would use the plugin to integrate with Steam API. It shoudln't be part of the main package pulled in just another sample.
I do think the current structure of Spacewar example is to far out of alignment with what one would expect of a modern Unity project. So I think replacing the current SteamManager as it appears in Spacewar example with a scriptable object based solution and more modular behaviours using proper naming, minimalist modular behaviours, and other "Unity style recomendations" like help files linked to scripts (HelpUrl), etc. will both help demonstrate the APIs use better as its more in alignment with what one would see from other assets, demos, examples, etc. and would help guide devs to your docs for specifc subjects.

100% on board with a completly new take on the exmple scripts and that is what I really meant with the "Heathen Extensions" that was just a pull from some of our tools as an example to show an approch you would see in other assets. Happy as noted to work on a from scratch example or rather many of them. I do agree; I think it should probably be a few focused examples aimed at teaching the API more so than demonstrating.

3-a) Steam Initalization
This is the most important I think and could use the Scriptable Object + light modular behaviour as noted. It doesn't need to do anything beyond initalize the API and handle client and server intializaiton ... so many dont understand that there are 2 different intializations depending client vs server. This would replace what the current SpaceWar example is used for for most I think

3-b) Sample Scripts
This wouldn't be demo scenes just simple scripts writen verbosly demonstrating common uses cases bit like you might expect to find in the comment section of a YouTube tutorial some verbosly written scripts not meant to be ran in a scene but to show use of objects. Examples of topics I think would be good starters for this sort of thing.

• Steam user data
  get user name, image, state info, etc.
• Achievement
  get the current state, unlock it, etc.
• Stat
  again get it, upload score to it, etc.
• Leaderboard
  same again, set the score, query the board maybe a few options demonstrated here, etc.
• DLC
  Check subscribed, downloaded, open overlay to store, etc.
• list goes on :)

[rlabrecque]

Re 1: There was some discussion about the folder structure here, #389 It did seem like it was possible to nest the package in a folder based on PixelWizard's version. 👍

I guess, the primary question around 1 is what's missing from this branch currently to call 1 complete, I thought I had tried it out in a Unity project, but I may not have gotten that far. https://github.com/rlabrecque/Steamworks.NET/tree/unity-package
The list of things I have for that right now are:

1-a) Documentation
1-b) Merging into master

Possibly just missing the LICENSE.md in the folder as well?

Will read/reply to 2-4 later!

[JamesMcGhee]

Tested trying to install from his and yours and quickly nested my self on this fork and in all cases I was unable to install anything that was not set up in root.

So if it is possible its not as strait forward as simply setting it up in root ... or im just thick :)

Digging into it more trying out some of the git URL features that should work

"https://github.example.com/myuser/myrepository.git?path=/subfolder"

so let me give that a go

https://github.com/heathen-engineering/Steamworks.NET.git?path=/com.rlabrecque.steamworks.net

the above does work ... I find it combersom but its servicable

I do still think though it would be a cleaner process to go with root and use branches for other platforms ... or even if you wanted to make standalone the master

https://github.com/heathen-engineering/Steamworks.NET.git#unity-package

the above as an example would (so the docs say) pull from a given branch

e.g. my preferance as a user is for clean repos that only have in them what is useful to the person pulling it

Documentation on URLs and various options
https://docs.unity3d.com/Manual/upm-git.html

[rlabrecque]

Great info!

I agree that's not ideal, though a lot better than what we have now; I wonder if there's a way to get like a redirector of sorts. Like maybe having a package at the root that only includes the ?=path/com.rlabrecque.steamworks.net folder as a dependency or something?

[marwie]

Hello, UPM support would be really great.

If I may add some of my experience: We usually have our packages in situations like this in a package folder in the root.
That way it is cleanly and obviously separated from everything else, the name of the package is already present in the git url or local path so the path is easier to read.

Have you considered publishing to OpenUPM as well? (that way it would be even easier to add for a lot of people)

Also: installed via https://github.com/heathen-engineering/Steamworks.NET.git?path=/com.rlabrecque.steamworks.net as well for now :) thanks

[JamesMcGhee]

I have looked at OpenUPM before it sounds like a great idea but something to look into after the basics of of a Steamworks.NET package manager structure is sorted out and applied to the repos.

IMO getting a nice clean easy to understand structure set up is best for everyone.
steamworks git repo is the first or second touch for many new Unity devs looking to ship on Steam as its what comes up if you google Steamworks Unity and if you search in Unity Asset Store you will see our assets and similar most if not all of which again point back here.

That is part of why I favor spliting the standalone stuff away from the package manager stuff by branch or similar not just a folder in the repo. In my ideal world as a user of the plugin I want a nice clean only has what I want in it repo or branch so when I pull it down to browse and learn there is nothing there but what is relivent to my use.

[rlabrecque]

If I may add some of my experience: We usually have our packages in situations like this in a package folder in the root.
That way it is cleanly and obviously separated from everything else, the name of the package is already present in the git url or local path so the path is easier to read.

So that would end up being https://github.com/rlabrecque/Steamworks.NET.git?path=/package ? I think I can live with that.

Do you have any examples of other packages that are like this? Also what do each of these (?path=/, ?path=/com.rlabrecque.steamworks.net, and ?path=/package) look like in the Unity Package Manager and after import in your project files?

I went with ?path=/com.rlabrecque.steamworks.net originally due to PixelWizard's fork, given that he works for Unity and evangelizes the package manager to some degree it seemed ideal.

Definitely would want to look at OpenUPM more as well, that's probably an additional seperate step on my numbered list above.

IMO getting a nice clean easy to understand structure set up is best for everyone.

I largely agree, but the balance I'm trying to strike is just that there's a rather surprising number of non-Unity Steamworks.NET users, I think the structure with the Unity Package, Standalone, and .github folders (and soon also the CodeGen folder) strikes the best balance. Ideally we can have clearer installation instructions in the primary README.md, then in the package directory have the README.md that ends up getting imported with the package inside Unity. The thinking is if we get most people installing it via the package manager (or even implicitly via other libraries which depend on the Steamworks.NET package), then it's very clean for the majority, they won't even see the Standalone folder, etc. 👍

[rlabrecque]

I also wonder how the ?path= stuff will work with OpenUPM. What does using OpenUPM end up looking like as an end user or library author?

[marwie]

I also wonder how the ?path= stuff will work with OpenUPM. What does using OpenUPM end up looking like as an end user or library author?

Same as with Unity's packages. when you use OpenUPM you add their registry to the scopedRegistries in manifest.json

"scopedRegistries": [
    {
      "name": "OpenUPM",
      "url": "https://package.openupm.com/",
      "scopes": [
        "com.needle"
      ]
    }
  ]

and then you can add your package with id : version just like it was from Unity directly

[JamesMcGhee]

Do you have any examples of other packages that are like this? Also what do each of these (?path=/, ?path=/com.rlabrecque.steamworks.net, and ?path=/package) look like in the Unity Package Manager and after import in your project files?

Package Manager imported objects dont import into the project's Asset folder which is what is particularly nice about it
It copys the folder structure of non hidden folders under the "Packages" node. This is seperate from "Assets" so doesn't clutter the assets folder and must be wrapped up in an assembly so naming isn't an issue ... its also not editable hence the need for every thing in there already have its meta files less Unity Editor complain.

By hidden folder I mean any folder ending in ~ Unity will ignore e.g.

Samples~
which is where you would store your samples will not appear under the Packages > Steamworks.NET node but the other folders e.g.

Packages
----Steamworks.NET
--------Editor
--------Runtime
--------... etc ...

Will show

I largely agree, but ...

I get it and yes using a subfolder will mean package manager doesn't pull in the other bits. My thought was as a user using Git Desktop or similar and pulling the repo down and digging around as many are want to do.
For that use case I personally like he branch I pull to only have in it what I need for my case. So if I where building a non-Unity project I wouldn't want the package folder in there at all as an example. One way of doing that that I think would be clean and easy for people would be to use branches e.g a Standalone branch, Unity-Package branch and so on. That is a bit of an abuse of branches sorta ... maybe ... well not really depends on how you see branches :) point is if you did that and you fetched the repo you could hit the drop down select your branch based on what your doing (Unity, standalone, maybe you add more later who knows) and then your pull is a light clean only contains relivent to you directory.

All that said from Unity's point of view and how we will be using it ya I'm fine with the package manager being in a sub folder or whatever as long as it has all its bits in there and they all have metadata thats the only real requirement to get that "net gain" from all this effort.

Another advantage of moving it to a different branch or folder whatever suits is that the root doesn't need the meta files and LICENSE can be a .txt as opposed to .md for the root. As noted previously I dont think many people have a default program set up to read .md Unity's insistance that it be a .md is a bit anoying :) no reason to make non-Unity users suffer ;)

I also wonder how the ?path= stuff will work with OpenUPM.

Looks like UPM handles this just fine; haven't tried it yet but documentation wise I dont see a roadblock with subfolder or branch or both being used.
https://openupm.com/docs/adding-upm-package.html#upm-package-criteria

[JamesMcGhee]

Just a bit restructuring to see how it will look on the GitHub page

[rlabrecque]

Hmm wasn't my intention to close this, looks like it happened when I merged unity-package into master and closed it :/

[JamesMcGhee]

I can recreate if you need, let me know