Have converted this to a UPM package for my own use and have "some thoughts"...

[darbotron]

Hi

Firstly, thanks so much for making this!

The process of getting it all working and so forth has for the most part been relatively painless - certainly all the code in the GDK-Tools folder to handle copying about GDK .dlls, moving the various package files about for builds etc. would have been a nightmare to write from scratch.

That said, the biggest issue (other than the finniky behaviour of the GDK dev environment on desktop, which is nothing to do with you!) has been the fact that it's supplied as a .unitypackage rather than a proper UPM package.

Speaking from a decade's worth of multiplatform Unity console / PC development, platform specific APIs which live inside the Assets folder are a nightmare, not only do they pollute the game's namespaces / assembly but being inside the Unity project's Assets folder encourages data storage / integration idioms which tend not to help when maintaining a project supporting multiple platforms.

In fact, it's so much better to have UPM packages that I've invested significant time and effort in tools to convert the other platform specific Unity APIs supplied as .unitypackage into UPM packages...

I note that there's already an issue (#63) re: supplying this as a UPM package and the reason given for not doing that was "we support down to unity 2017".

Unity don't support versions of Unity older than 2 years so I would like suggest that it would be a good idea to move this over to a UPM package format - on top of that it's perfectly possible to just dump a UPM package into the Assets folder and it should work the same as if it was imported via Unity's Package Manager.

I totally get that setting up a project as a package looks daunting & faffy - I can recommend this MIT licensed repo which makes it easy to export UPM packages from code in your Assets folder: https://github.com/PixelWizards/com.pixelwizards.package-utils
(also the fixes for it I suggest here: PixelWizards/com.pixelwizards.package-utils#1).
I use a modified version of this to make all my UPM packages.

Generally making a UPM package is trivially easy, but in the case of this package is has been significantly more involved.

This is a list of the issues I've had to solve & solutions:

• file paths used in tools are hard coded relative to [projectRoot]\Assets
  • I fixed this so GdkUtilities.RootPluginPath finds the parent folder of GDK-APIs
  • the code I use auto-detects if it's in a UPM Package or the Assets folder too
• samples and sample code are in the GDK-Tools folder along with code needed to use the package
  • no fix for this, I've just deleted the samples locally
  • UPM packages have a nice mechanism for distributing & installing samples
• not all the code in the package is in assemblies
  • in the Assets directory any directory called Editor automatically gets put into the Assembly-CSharp-Editor assembly
  • in a package you need to manually add an assembly definition, set it up to be editor only, and have the correct references etc.
• the XBL scid used by the entire project is assumed to be in a prefab as a serialised property of a MonoBehaviour and / or in the MicrosoftGame.config
  • I've actually yet to solve this...
  • the MicrosoftGame.config also stores loads of weird development specific info like sandbox Ids and the scid (duplicating the info in the prefab...)
  • I'm not sure if this is usual when building GDK games in Visual Studio with C++ etc. but it seems really weird to me
  • I'm currently planning to put all the XBL ids and development info into ScriptableObject assets
  • to access in game you have a bunch of options:
  • add the asset(s) as serialised properties of a scene object
  • store in the Resources folder
  • put it in the Player's preloaded assets https://docs.unity3d.com/ScriptReference/PlayerSettings.GetPreloadedAssets.html
  • I'll also be using this asset to generate the MicrosoftGame.config for builds
  • which means it's easy to write build scripts which modify the MicrosoftGame.config
  • (though will likely also provide a manual override MicrosoftGame.config filepath (useful for submissions etc.)
  • note: that for other platforms platform specific settings are typically stored in the ProjectSettings folder (cf. the way the Unity GDK for consoles Unity Add-on does it).

There's probably other stuff I've forgotten but I'd be more than happy to offer advice / help out with this if you need it.

Thanks!