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...
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'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.
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-Toolsfolder 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
.unitypackagerather than a proper UPM package.Speaking from a decade's worth of multiplatform Unity console / PC development, platform specific APIs which live inside the
Assetsfolder are a nightmare, not only do they pollute the game's namespaces / assembly but being inside the Unity project'sAssetsfolder 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
.unitypackageinto UPM packages...I note that there's already an issue (https://github.com/microsoft/gdk-unity-package/issues/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
Assetsfolder: https://github.com/PixelWizards/com.pixelwizards.package-utils (also the fixes for it I suggest here: https://github.com/PixelWizards/com.pixelwizards.package-utils/issues/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:
GdkUtilities.RootPluginPathfinds the parent folder ofGDK-APIsAssetsfolder tooGDK-Toolsfolder along with code needed to use the packageAssetsdirectory any directory calledEditorautomatically gets put into theAssembly-CSharp-Editorassemblyscidused by the entire project is assumed to be in a prefab as a serialised property of aMonoBehaviourand / or in theMicrosoftGame.configMicrosoftGame.configalso stores loads of weird development specific info like sandbox Ids and the scid (duplicating the info in the prefab...)ScriptableObjectassetsResourcesfolderMicrosoftGame.configfor buildsMicrosoftGame.configMicrosoftGame.configfilepath (useful for submissions etc.)ProjectSettingsfolder (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!