Added Unity Deployment Tools

[dh-nunes]

Added Unity Deployment Tools. This allows for automated deployment to github releases on every tag and automated docs generation and upload to github pages. Since I doubt you'll want to upload this to the Asset Store adding this now makes the most sense.

You can see an example of the default pre-release here and the default gh-pages here.

As a plus, it also allows this to be released as a .unitypackage, which makes a lot more sense than having to clone the repo.

I also removed the ProjectSettings folder (see #5).

To finish, all that is needed is for you to modify the ini file as per your preferences, before (if) you accept the pr, I'll just disable all the deployment so you can take your time to look through it. the readme will also need to be update, namely the links to point to your repo instead of my fork.

[ricardojmendez]

Thanks! Let me review it and get bak to you.

[dh-nunes]

Some extra info, the original readme from my repo is included in the .deploy/ folder, these are the builds being run and take your time looking through everything :)

[ricardojmendez]

Hi @GandaG,

This seems to turn the UnitySteerExamples project into a package that needs to be embedded on a Unity project, instead of the standalone project it has been until now.

Can you elaborate on how you see this working out? I can see the advantage of automated package/exporting, continuous building, deployment and documentation generation on UnitySteer itself, but I'm a bit divided on its usefulness on UnitySteerExamples.

I could see it if the examples were automated tests, but they are mostly sandboxes. I'm not entirely sure changing it this way helps, but I'm willing to be convinced.

Thoughts?

[dh-nunes]

@ricardojmendez,

First off, two things:

1. The documents for the examples are not needed at all, I only mentioned it so you could see that was an option and wanted to use for some reason.
2. This is geared towards newbies; UnitySteer is already a very complex project, no need to overload them.

As it currently stands, the examples aren't exactly a standalone project since you can't put in a folder and open it up in Unity (understandably). You still need to create a project within Unity and then move everything there. Furthermore, since the ProjectsSettings/ folder isn't required all that is really useful - meaning what you actually need - here are the files inside Assets/. So the "workflow" to get the examples becomes: clone this repo, make a new project in Unity, copy everything from this Assets/ folder to the project's Assets/ folder, and play with the examples.

What this really does is just turn this process into a 4-click newbie friendly one (since they don't have to know git - most newbies to Unity are also newbies to programming). Download the package, import package in Unity and play!

I will also add a line to the Readme under Usage so that people won't use this in an actual project.

I should improve my repo's readme, but I suck at descriptions :/ Hope this has made everything clear to you.

[ricardojmendez]

As it currently stands, the examples aren't exactly a standalone project since you can't put in a folder and open it up in Unity (understandably).

You can, actually, depending on the git client - SourceTree takes care of checking out the submodules for you, for example - but I see what you mean.

What this really does is just turn this process into a 4-click newbie friendly one (since they don't have to know git - most newbies to Unity are also newbies to programming).

Fair enough.

[ricardojmendez]

What this really does is just turn this process into a 4-click newbie friendly one (since they don't have to know git - most newbies to Unity are also newbies to programming). Download the package, import package in Unity and play!

I've looked at the zip files being archived here. Unzipping them, they seem to follow the usual unity package structure, but when attempting to import into an empty Unity 5.3.1 project after renaming it to .unitypackage, Unity complains all files are already in the project.

I've yet to look into how the package is being generated. Anything I'm missing here?

[dh-nunes]

I've looked at the zip files bing archived here. Unzipping them, they seem to follow the usual unity package structure, but when attempting to import into an empty Unity 5.3.1 project after renaming it to .unitypackage, Unity complains all files are already in the project.

Everything seems to be working for me... What do you mean by renaming?

You can, actually, depending on the git client - SourceTree takes care of checking out the submodules for you, for example - but I see what you mean.

That's not what I meant, you still need the unity libraries and some other folders I can't remember now, and since you can't exactly publish them in github you still have to go through unity's project generation.

[ricardojmendez]

Everything seems to be working for me...

Odd. I'm on OSX.

What do you mean by renaming?

On OSX, Unity 5.3.1 does not show zip files as an option when attempting to import a package, only files with the unitypackage extension, so I have to rename the file before it's considered a valid option for Import Package > Custom Package (it might be different on Windows).

That's not what I meant, you still need the unity libraries and some other folders I can't remember now, and since you can't exactly publish them in github you still have to go through unity's project generation.

I'm not sure I follow... Unity re-creates the Library on start, so it's not something anyone who clones the repository would need to worry about. Assuming someone is using the command line (worst-case scenario) all they'd need to do is:

• git clone [repo]
• git submodule init
• git submodule update

And then open the project in Unity. Using SourceTree saves them the last two steps, but they should not need to do anything else.

[dh-nunes]

On OSX, Unity 5.3.1 does not show zip files as an option when attempting to import a package, only files with the unitypackage extension, so I have to rename the file before it's considered a valid option for Import Package > Custom Package (it might be different on Windows).

No, no... The .unitypackage is INSIDE the zip file! I thought that was clear :/

I'm not sure I follow... Unity re-creates the Library on start, so it's not something anyone who clones the repository would need to worry about.

It does? You mean you simply tell Unity to open it as it stands and it automatically creates the rest? I had no idea o.0 well, this is not as useful as I thought then, it only really saves the trouble of going through git. But if you're not going to use this you really should explain that in the readme!

[ricardojmendez]

No, no... The .unitypackage is INSIDE the zip file! I thought that was clear :/

Aha... When you double-click it on OSX, it first unzips the file and then unzips the Unitypackage without asking, which is why I wrote that it "followed the usual package structure". Unzipping it via the command line results on getting just the unitypackage.

That's the sort of thing I was referring to when I said I hadn't looked into the generation process to see what was being packaged.

It does? You mean you simply tell Unity to open it as it stands and it automatically creates the rest? I had no idea o.0 well, this is not as useful as I thought then, it only really saves the trouble of going through git.

Heh, interesting, I had no idea anyone still expected the Library folder to be necessary - I can't even recall when Unity changed it so that it wasn't fundamental, but it was probably around the same time they added version control support and external meta files. Maybe Unity 3.x or thereabouts.

But to answer your question: yes, you can just clone the repository as is and open it from Unity, and it works as expected.

[dh-nunes]

When you double-click it on OSX, it first unzips the file and then unzips the Unitypackage without asking

I have never even touched a mac, I had no idea :/ Should I add something to my readme to account for that?

Maybe Unity 3.x or thereabouts.

Haha I haven't been around that long! Only came to Unity after 5 was released (my only interest has been 2D games).

Well then, I guess it's up to you then whether to use this. Saves a little time for newbies but not significant if it means changing your overall workflow. Make sure to reference that in the readme though.

[dh-nunes]

Would you prefer to deploy as a .unitypackage directly instead of a .zip file?

[ricardojmendez]

I have never even touched a mac, I had no idea :/ Should I add something to my readme to account for that?

I hadn't thought about it. I suspect it's a side effect of OSX automatically extracting .tgz files - maybe if what it encounters inside the package is another package, it just extracts it without asking.

Would you prefer to deploy as a .unitypackage directly instead of a .zip file?

I think that would be best, to avoid tripping OSX users. unitypackages are already zip files, so I'm not sure that recompressing it has a value (on the examples case, there's a 2k difference only).

Let me think about what's more convenient here. I'm currently leaning to leaving this repository as is, but there's definitely a value with people being able to just get a unitypackage for UnitySteer itself.

Thanks for your work on this!