experimental checkin feature for gluon
I hear from my designer-y people that they'd like to be able to experiment with features before checking them in to the cloud. Naturally this can be done with branches with the regular plastic, but I'd like for them to keep utilizing the simplicity of gluon.
I don't have a solid suggestion as to how to implement this, but as an alternative to checkin you could provide a "experimental checkin" action. Gluon still behaves as normal, but these checkins are only present for the user. When the user is done experimenting, they can checkin their experimental changesets to the cloud or abandon them alltogether.
Like I said I don't know if this is feasible, but it would be a handy tool for the linear workflow gluon provides!
Niklas Lindblad
shared this idea
-
Niklas Lindblad
commented
Hello,
It's been a while now, but I'll try and recant the incident that sparked the idea:
We work in Unity, meaning the designer works with modifying values in prefabs, scenes, ScriptableObjects. All of which can pretty much be regarded as binary files due to their complexity.
At some point, our designer feels that the game doesn't play as well as it could; and wants to try this big overhaul of all the gameplay systems. They want to change everything from how quick the character moves to how obstacles are placed in the environment.
It would be undesireable to push these changes to the cloud directly, as it would limit the ability for others to test their own work (imagine working on the animations only to find suddenly the character is 10x faster). It would be preferable to have this new change to come when it's ready for the whole team to continue working with. This can of course be solved using branches, but I want to take the time to describe how this particular user phrased their preferred workflow:
What they wanted was to have a way to add checkpoints to their workspace. Imagine the use case above where you do alot of tweaks and changes and find something that sort of works, but you still want to keep experimenting. So you make a checkpoint of the current workspace state and keep on trying other things. In the end, a collection of these checkpoints will be available for the designer to browse and ultimately choose from as the new design for the game.
To describe it in a non-gluon workflow; what the designer wants to do is to create several branches, each containing a different redesign for the game. This somehow streamlined into a gluon workflow.
I recognize that it could be a simple case of 'use plastic gui instead'. But I'd like to highlight two things:
Firstly this is a pretty rare occurance, but when it does it kind of throws a wrench in the user's workflow. They're essentially left with the option of either not doing it and stick with gluon, or take the leap to the more advanced, daunting and unfamiliar gui.
Secondly i've noticed several people in our office encounter similar situations. Our audio fellow wanted to try a new plugin, while our graphics artist wanted to experiment with various third party assets.
Gluon is awesome, and it has really helped us with our workflow (my time spent helping people with merging has decreased dramatically :D), but sometimes we hit this wall where gluon can't be of help any more due to the streamlined feature set. Therefore i'll make it my duty to let you guys know when we run into these kinds of problems, so gluon can truly become the obvious choice for artists!
TL;DR Artists want to be able to try things safely too! :D
-
Hi Niklas,
Looks like an interesting one. We designed Gluon for maximum simplicity, so we purposely kept branches out. But... yes, what you describe is exactly that: branches. They could be somehow hidden for the user but...
Tell us more about why you find it useful. I mean, why they feel like checkin if they don't want to send it to the cloud?
