Since we launched Unity DevOps last week, we’ve received a few inquiries wondering if Unity Version Control (formerly Plastic SCM) is exclusive to users of the Unity Editor.
Version Control has been, and will continue to be an engine-agnostic solution. Version Control works great with both Unity and Unreal, as well as any custom-developed in-house engines. In support of this, we recently published our interview with Monster Closet Games, who switched from Perforce to Unity Version Control for their Unreal engine game.
I don’t know why you would change the brand name of a service that has a pretty good reputation (PlasticSCM) and more closely associate it with the brand that produced the worst versioning service known to man (Unity and Collaborate).
The rebranding also implies that it’s exclusive to Unity somehow, which is what you’re addressing here, but it still feels like the first step towards it not working with non Unity stuff i.e. I don’t believe that the statement in this thread has a lot of staying power, for all I know you (not you personally, Unity) might change your mind next week and block all other engines / use cases, and the userbase here will go “Well, what were you expecting? It’s called the Unity Version Control! Of course it doesn’t work with anything else!”.
In short, I used to be able to suggest PlasticSCM to people, telling them it’s pretty decent (as long as they didn’t use the horrid Unity plugins!). I don’t think I can do that now.
Thank you for sharing with us AcidArrow. Plastic SCM was acquired by Unity with the aim of leveraging its great potential to even more customers. I understand the frustration with the history of changes, but since its initial design, the product has always been thought agnostic to engines and even industries.
As you’ve read in the article above, we have customers using Unreal and not only that, we have success stories in different segments not related to games. The strangeness occurs mainly because the name Unity is associated with the name of the company that has the same name as our Engine. Despite this, we have many products and services that go far beyond our engine and meet the different needs of customers who do not use our engine.
I hope we can improve this perception and that you can continue recommending Unity DevOps!
You bought Plastic SCM and its customer base that includes Unreal users. It’s just a matter of time for them to move somewhere else.
No CEO/CTO in their right mind are going to bet their shareholders investments for their [insert_competitors_game_engine] projet on a Unity service. The conflict of interest is too important and they’re probably not event allowed to do that.
I certainly won’t.
While I did recommend Plastic SCM to many people in the past, I’m not going to risk people questioning my expertise by recommending a Unity Service for non Unity projects.
Beyond how hard that counter intuitive idea is to sell, I’m also not willing to risk my reputation on Unity to never use that product against competitors.
Facebook did it with Oculus, they rebranded it and used the product to force buyers to have a Facebook account. It’s just a matter of time for Unity to do the same. They didn’t buy Plastic SCM, rebranded it and integrated it deep in their ecosystem to keep it open.
If this is bad news for me, a full time Unity dev, it can only be worse for any non Unity dev.
They’ve already done this. The PlasticSCM support forums are gone. I had to create a UnityID to be able to post questions/comments here. The move to integrate and force Plastic customers into the Unity ecosystem is on the move it seems.
Plastic SCM has a great reputation, this really seems like a shot in the foot to rebrand it as something so incredibly generic as “Unity Version Control”. Putting aside any “perception” about the association with Unity, it’s just a really generic name. “Plastic” pops, it’s recognizable in it’s field. If I ask someone a question and they say they are using “Plastic” or have “Plastic open on their desktop” that’s clear and recognizable. But saying you have “Unity” open when really you have “Unity Version Control” open is not clear. Making people say a whole lot more words to refer to the same software. Maybe could have got by simply calling the new name “UVC” or something to that end, but it’s still a much more generic and clunky name than Plastic
Nobody says Fork Version Control. SourceTree Version Control. Git Version Control. Don’t make the name of a piece of software or a service literally be the same name as countless other services the company offers. It’s only going to make things even more confusing for end users and potential buyers
Just adding another voice that a rebranding is ultimately going to hurt the service; many of my thoughts have already been mentioned but I’m going to reiterate them. It’s so much easier to say “Use Plastic” than “Use Unity Version Control”. I’ll likely end up saying “Use Plastic. For some stupid reason it’s now called Unity Version Control; don’t ask me why”. For the very small amount of community guides/tutorials, you instantly lost all of that brand recognition and help. Plastic already has an uphill battle with Perforce and this rebranding is not only cleaning the slate, but it’s also directly associating it with a brand (Unity) that a large percentage of the market does not want to touch.
This rebranding should have just been “Now introducing Version Control for Unity DevOps, powered by PlasticSCM”. It’s not too late to change your mind. Who knows why execs make these wild decisions without reaching out to paying customers on whether or not it sounds like a good idea. We converted, we know why we converted, and we’re now telling you that had we not been customers before there’s a good chance we would not convert with this rebranding.
Here’s a perfect example of why this was a stupid idea:
Imagine that Artstation was renamed to Epic Games Art Hub.
Not only would this be a gut punch to the supporting users/customers, but it also throws everything that the brand accomplished out the window overnight with ambiguity and confusion.
At the end of the day, it just feels like an investor-focused decision, not a customer-focused decision another shot in the dark to try to appease the almighty investors
But what if they changed it to Fab? (hey, it’s catchy, and agnostic!)
Putting my investor hat on, I’m not too thrilled with the rebranding either. As others have mentioned, “Plastic” is a recognizable brand name. Unity Version Control is…misleading. It seems like it goes against the engine agnostic messaging. Just like Vivox shouldn’t be changed to Unity Voice or SpeedTree changed to Unity Nature (or Oculus to Meta, you get the idea). These are solid brands that deserve to grow, and ultimately produce more value for Unity shareholders.
I understand the motivation behind taking a slice of the game development pipeline that’s been a big pain point and trying to simplify it. I think the engine agnostic thing is brilliant, and we’re moving past the Xbox/PS area of siloed ecosystems. From a shareholder point of view, if you can dominate the realtime engine version control space in price and features the rewards (in profits and share price) are greater than pitting all resources into a realtime engine v. realtime engine battle. This engine battle will definitely not be resolved anytime soon, nor should it, as the competition makes both better. But some of the supporting solutions like robust engine agnostic version control could actually have an upset.
I’m not sure why Epic hasn’t acquired Perforce yet and subsidized pricing for realtime engine devs. Mostly joking, Perforce customer base seems to stretch far beyond realtime engine space, I would just love more transparency on pricing if one’s game scales beyond 5 people.
This pricing transparency is something Unity is actually doing very well here. If Unity can take the opportunity to really bring forward something like Plastic which is excellent at what it does (been using since 2014), along with fair and public pricing to the broader developer ecosystem, then as a shareholder I’m very happy.
But, poor name choices aside, I think this is still possible. For my own reasons I’m developing my next internal studio project with Unreal. I love Unity (using since v2.6), and I still use it, and Plastic, every day for employers/clients and in the majority cases it’s still the best engine to suit their goals, but for what I want to make (co-op, cinematic action, leveraging actors, and large GB art files) Epic has just lowered the barriers to entry much faster.
I’d like to use… I’m gonna call it… UVC… for this Unreal project. The interview with Monster Closet is a good start, but as a developer and investor I’d love to see some tutorials for how to integrate specifically with Unreal. Maybe sponsor some creators to make youtube videos of the process. Perforce is entrenched with Unreal shops, so make it easy for the community (and later industry) to switch. Right now I’m trying to decide between UVC / Git / Perforce, and to whom to give my $ to. I probably will use UVC, and figure out the integration with UE5 myself, piecing together some old tutorials.
The article shows me that it’s possible and within the vision of the company, but I’d like to see the barrier to entry lowered and support put behind the desire to provide the best source control for everyone. Vivox documentation is a good example of this https://docs.vivox.com/v5/general/unreal/5_20_0/en-us/Default.htm.
Oh I absolutely agree, I just think it feels like one of those things where they can say “look at all these nice popular and successful tools that have our brand name right on them, don’t worry about the growing fears about the state of our product that was originally called “Unity””
Hi, are you going to be using the bottom bar to send me marketing bullshit?
Can I disable it?
I do not care what you do with your branding and if you are proud of something, I do not know why this has to take space in the TOOL I am using to do WORK.
It’s not like you can shorten it either as “UVS” will return results for texturing in the context of game engines (and ultraviolet radiation outside of it).
I’ll chime in just to throw my support to the concerns above. Originally when this was announced, I had posted a snarky post saying that renaming Plastic to “Version Control” was like acquiring McDonald’s and renaming it “Fast Food Restaurant”. It’s absolutely silly when git, perforce, svn, etc are also all “version control”. It’s silly when Plastic could be used for non-Unity code repos. It’s shutting the garden gates to non-unity customers (albeit it’s a perception, not actual exclusion), which to me seems to make no business sense.
And what about SEO? Hmmm. Maybe that’s actually the business strategy. To somehow capture web searches for the generic term “version control service” ?
I agree with a lot of the points above in favor of plastic, but most of all I personally enjoyed it being functional entirely standalone with the downloadable cloud client. For instance, in your most recent update (as of 4/6/2023,) you guys released a feature for making it redirect you to Unity Gaming Services when trying to add new organizations. While it’s cool to have these two features working cohesively, being able to do it in one place is MUCH more preferred. Also, for some reason adding seats for a project is pretty chaotic as of right now. I’m sure you guys are still embedding everything into a more seamless experience, but in order to invite people to a project, I had to set up a pricing plan (for the organization,) and in some places, the price is by seat or like 2,000$ a year per seat? I didn’t fully understand if these were separate options or not and it wasn’t very clear. Next, I had to make the project workspace on the Unity Version Control client, which didn’t really make a lot of sense, since other steps out of order had to happen in the browser. To put it step by step to add one person to my Unity Version Control here’s what I had to do just in the browser to get it WORKING (not including all the stuff in the client as well to get this functional):
1.) Create an organization through Unity Gaming Services (browser)
2.) Sign the organization up for DevOps with credit info
3.) Create a new organization project
4.) Add the member to the organization and give them individual permissions
5.) Had to give them seat access (in the unity gaming services for the org)
6.) Had to give them seat access (in the version control tab outer-scope of Unity Gaming Services for the project)
7.) Had to give them seat access (In id.unity.com?)
8.) Repeat this process over again for each member [- step 2], and to create a new server you have to do the credit info again too.[+ step 2]
But you see, one very notable highlight is that I have to add seating permissions in 3 DIFFERENT PLACES, and I really hope this changes soon.
The best situation of action –
1.) Keep it as PlasticSCM – a Unity Product. That way, it stays part of the unity ecosystem natively but it’s not just exclusive to Unity, like mentioned in the heading post. There are a lot of potential creative ways to use this outside of Unity AND Unreal as well, and I agree that calling it Unity Version Control is incredibly misleading if it’s not just “Unity Version Control.” Plus, all of the tutorials online for PlasticSCM – it comes up in the search quary already. You’ll be shutting down the valuable resources of the internet through search algorithms if you rename it to Unity Version Control, because if I look up Unity Version Control it’ll just tell me stuff about “Unity” instead of the underlying situation. To Google, PlasticSCM = Version Control Software, whereas Unity Version Control = Unity, and Version Control when applicable. It’s harder to find online answers to troubleshooting.
2.) Allow seating arrangement inside the PlasticSCM client itself, and remove the web-based methods (or at least make them update everywhere if you have to keep them). This way, there’s no confusion about where the different seats are.
3.) Please bring back connection profiles as part of PlasticSCM. This was incredible for being able to add servers to the client, where now you have to go through an absolute TON of steps through all the different versions of the unity website to do this simple task.
4.) Also in the future let us know with some sort of popup before something like this happens. I haven’t stayed the most up-to-date on the Unity forum but when my long-term project got erased when you guys rebranded and changed how cloud servers were set up that was extremely depressing. Thank goodness I made backups, I could’ve lost 12 weeks worth of work. At least you guys should’ve had some way to back up the files for a limited time. Maybe you could have a warning that this change was going to happen in PlasticSCM itself so you know that your cloud files are at risk of deletion due to an update.
5.) Please make the billing more clear. For instance, have a separate tab in PlasticSCM called “Billing” next to the server button that shows a more accurate chart than the current one offered in Unity Gaming Services. I paid 56$ for a team of 8 seats, but it says I paid 0$ and I owe 0$ at the end of the month which isn’t true. Also, on this billing page please list all of the ways you will charge the account, I think I can speak for a lot of PlasticSCM users when I say we don’t want surprise bills that just appear out of nowhere because we were building on “mac minutes” instead of “pc minutes,” over doubling the price. Please make this clear and put it in the client in some sort of list view with a graph at the top of this billing overlay.
6.) PLEASE add the ability to automatically checkin changes upon indexing local changes being present, and automatically updating the workspace/file structure when it indexes a change from the server. This would be extremely useful, and would allow for development in real time, something my team really wants for our long-term projects. I’m trying to make a python script for this right now since it doesn’t exist as of current.
I believe in order for PlasticSCM to function as a standalone product, it needs to perform entirely separately from Unity, like how you guys are proposing it – as a client that can manage all of the stuff admins need to see (like payment, cloud servers, & workspaces.) I’m not sure you guys will read this, but I am incredibly hopeful that if you do you take these tips from someone who absolutely loves using Unity and PlasticSCM. I believe they are incredible standalone products that do great separately and together. However, I feel like with the direction of PlasticSCM becoming Unity Version Control, I think you guys are selling yourselves very short with how much potential this product could have in its future.
I would agree that the process of onboarding my team members was very confusing. Having an organization and then source control groups and having to invite my team by email for each service was very confusing, even just having the option when adding someone to a UGS feature to simply click a checkbox next to someone who’s already part of your Org would be great.
But this thread is about the name change and how Plastic can be used by non-Unity developers as well, so I won’t go into much detail about that here
I should say it’s been really difficult to find explanations on how to do stuff in the new system already because there’s lots of information about how to use Plastic already available. And this is coming from someone who already knows the difference between Plastic and UGS. For someone who isn’t keeping up with the details, this will be a very confusing change, across the industry
another shot in the dark to try to appease the almighty investors 
(hey, it’s catchy, and agnostic!)
Having an organization and then source control groups and having to invite my team by email for each service was very confusing, even just having the option when adding someone to a UGS feature to simply click a checkbox next to someone who’s already part of your Org would be great.