How far can you take a creative app made with Unity without competing with it?

Based on feedback so far I'm probably going to reign in the freedoms a bit, to include a) not realtime interactivity with objects, b) no reprogrammable scripting of objects that does realtime stuff, c) ability to build gui from pre-made widgets only and not design the gui appearance, d) everything more geared towards content creation and recording of animation frames etc, for use in unity projects or exported as movies or animation files etc.

This removes the possibility of "realtime interactive content", of "making a playable game", and of the potential to give dynamic AI or user-control to objects/characters/enemies.

I think this would make it less of a competitor with unity and now it moves away from Adobe Animate more towards something like Toon Boom Harmony, Synfig, Moho animation and so on focused more on passive/static content creation/recording/playback.

Still waiting for a reply from unity for a week now.

 

When it comes to interactivity, the problem isn't if there's interactivity in the app itself, but if it allows interactivity in the end-user's final product. The real-time interactivity & customizable tools in your app are meant specifically to produce animation, not games, and as long as you don't allow the end-user to include that in their final product, then you have no game editor.

However...

Unity is also geared towards film. Since your app is specifically for producing animations (i.e. films), it may be considered a competitor to Unity on that front regardless of if it's only for 2D. If films are easier to produce in your app than in the Unity Editor, then people may use your app instead of the Unity Editor; you might even get users who otherwise wouldn't have even considered doing 2D animation in Unity to use your app.

If Unity wasn't also geared towards film, I wouldn't have added this. But since it is, I think it's important to take into account.

 

I think I agree in terms of the interactivity. If the result or output can't be considered a game generally speaking, especially if it's not "controllable in realtime" like feeding it keystrokes and having stuff happen in response, then it can't really be a game. It could loosely be a game just with a basic GUI that causes certain things to happen such as switching scenes/rooms or triggering animations to happen via the GUI etc.

Re film yes Unity is branching out so much it's hard to say there isn't any visual industry they aren't touching upon or invested in. Since my app is made with unity you could say, if unity can do it so can my app, which can't be the grounds for a comparison really because that would rule out absolutely all apps from 'having bits of unity in them.' lol ... but there has to be some kind of middle ground in terms of a focus or subset or something.

 

Technically speaking Unity doesn't create an executable either. The executable that is distributed with a build is just a pre-baked executable that never changes and it's sole purpose is to jump-start the code stored in the DLL files included in the build.

 

I'll give you the award for the best tangent ;-)

 

And that's the basis of the answer.
Regardless of technical details or effectiveness, if you're making a general purpose editor of your own then it probably competes with Unity's general purpose editor. Past that you either need professional advice or to choose another path.

This stuff is deliberately broad, with good reason.

 

Yea I realize that the more 'closed' an app or game is, the less unity has an issue. When it becomes more 'open', with modding and scriptability and a high degree of configuration and the potential for "creativity", it starts to expose the underlying engine more and starts to compete with it more. Games filled with artwork and stuff is very specific in its form and narrow in its focus. Widening the focus and letting things be very open ended becomes much more competitive with Unity itself in a way.

 

This discussion is rather riduculous if you ask me.
Has Unity EVER taken something down for this reason?!

@imaginaryhuman What is your position btw? If you are "just" an indie who is doing one of their first games alone or with friends - so not a full on corporation, then just start developing and experimenting!
Don't worry about lincence nonsense like this. It's a waste of time.

 

I like to be honest and up-front and aware of where people stand. It's a part of a healthy relationship. I don't know if Unity has ever reacted to software like this or not, and in general I feel Unity is a friendly bunch of people and I'd like to remain friendly with them. But their official legal license does say that you can't create a competing product, and it's there for a reason.

I'm indie and individual yes but have been doing software stuff for decades. I'm asking about this up-front before I dedicate a whole lot of time to working on this project. I don't want to waste time and just be blind about it and end up having to ditch it later.

 

It was even discussed on Unity forum. But I don't know how to find topic.

 

still waiting on a response from unity re my ticket, 9 days now.

 

Who did you send the ticket to? I'd be contacting my regional sales rep for this, not the support team.

 

support.unity.com

regional sales rep? what's that? i've just sent a message to the unity sales team via the contact form also, is that what you mean? seems like i have to wait for them to contact me before telling them anything.

 

That should be fine, the only option there is non-technical support.

I thought there used to be a page with a list of regions and associated people on it, but I can't find it now aside from the advocates page.

 

In Unity time that is barely a blip. I sent an inquiry to the 'Unity Customer Experience Team' and it took three weeks to get a reply ( that didn't even answer my question ). Last time I looked, the asset store team was taking 3-4 months to reply! So I'd expect another week or two at minimum before you get a reply.

I'd be surprised if you get anything remotely useful back in their reply, most likely nothing more than a copy and paste of the T&C of Unity about creating competing products, so don't expect to get any real answer.

 

i'll wait

 

still waiting. the unity sales team is not the people to contact, so they tell me. told me to file a support ticket. still waiting 2 weeks almost now for any response.

 

You might have a better/faster time reaching out to someone like a unity product manager or something on LinkedIn

 

Well I mean, there was the whole improbable fiasco which was 100% centred around the usage of unity within a tool to create new experiences, improbable broke the TOS and then instead of working it out they threw their toys out of the pram publicly which ofcourse made it worse.

Yes they were a large-ish corp, but its just to point out that yes unity have absolutely and will continue to protect their TOS and Brand.

 

Please do not harass people on LinkedIn. It's just not nice and it wasn't made for this.

 

I'm just waiting for now. This isn't my primary project. I'm thinking about either doing it all INSIDE the unity editor, which has its plusses and minuses (but would be fully license compliant), OR doing it as an app and having to lock-in some stuff and pair back some open-endedness.

 

Here's a spinoff question.

Let's say someone creates an ASSET on the asset store, which is a tool for creating simple games. The asset obviously runs in the unity editor and outputs unity-compatible objects and stuff. When the project is built, it runs the 'game' that the users "made with it in unity". The capabilities of this "tool", this editor extension, overlaps with some unity capabilities and IF it were an external tool would clearly compete with Unity - as a kind of game builder.

Now consider a what-if. What if a user buys the asset, downloads the tool into an empty project, builds the project, and this allows the asset to run as-is as a desktop app. The desktop app is not for sale directly. But the desktop app can then be used by that person to build more games. Does this now violate unity's terms? Because technically now the desktop app is a unity project which was built by the unity editor under asset store licensing. If someone did this would it violate terms based on the idea that the asset has not been 'modified' or 'used in another project' with enough sufficient alteration, configuration, or adding extra stuff inside the unity editor before it was built? ie its sort of a project with a raw asset inside it running in a default mode. Provided the built app isn't for sale, presumably this is still within the license terms? A person making a game with it is effectively doing no different than building a run-time configurable unity project. I know this is again a bit of a gray area. What do you think?

 

You have too much free time. You need a hobby. Other than hypothetical legal questions on non-legal forums.

 

And NOPE. At this point your scenario falls apart.

Asset manipulation in the project requires UnityEditor namespace, and that one is stripped when you build the game.

The user will not be able to compile it as a standalone project, or it will not function when built as a standalone app.

Honestly, you're supposed to know t his.

 

what if all this is just a dream?..

 

Actually you have misunderstood what I was getting at which is why you think I'm in error. I was proposing that the editor app is capable of running as an in-unity-edtior tool OR as a runtime tool. I wasn't suggesting it was an editor application only, which obviously would not work in a build.

 

You over complicating things.

You basically talking about assets and toolings like RPG maker, which works in editor. You can build a game and sell, it if dev wants to.

If user/dev use Unity and assets to build a game, that is what everybody does here. As long dev got licences to each used asset.

 

Sure but the case I mentioned is the possibility that someone would put the 'rpg maker' into a new project by itself and build a desktop app version (if the maker were able to provide runtime editing that is). If, say, rpg maker had both an in-editor window to forge rpg games, but also had a runtime editor "in game" that let you completely configure the game as much as in the editor, and someone built that app with an 'empty' game configuration, they could then use the desktop app version of the rpg maker to continue 'making games'. The games would run INSIDE the rpg maker program and would depend on it as a kind of 'player', so they can't make a standalone game as such but they can make a hosted/runtime game that runs inside the desktop app.

 

No, I have not.

The scenario you described is something unity devs thought of, likely around version 1.

Editor API plain does not work inside a built game, and any level generator made as a unity addon will work through Editor API. It is done this way specifically to prevent accidental creation of competitor.

Your scenario is synthetic and has no footing in reality. At least in case of unity.

In this case a more important question arises: whose dream it is?

 

I'm pretty sure this would indeed NOT be permitted.

 

There's no reason why an app couldn't have an in-editor custom editor window using editor api's while also simultaneously having a runtime component which is a separate codebase in the same project. It's no different than e.g. having a custom inspector editor which runs in the editor and also in the same projecting having a runtime editor in-game. What you're ASSUMING is that I was talking about a single editor-based editor which only runs in edit mode which, as I said, is not what I was talking about, and is why you did not get what I was talking about.

 

Dude, your initial statement sounded like this:

Which basically means that somebody made in-editor tool, and some clueless user, accidentally ran it play mode, and the world has came to an end, as a legal Cthulhu has awakened and devoured minds of mankind due to breach of unity EULA. The key word is accidentally.

That can't happen, because of the reasons I listed. Editor and Runtime API behave differently and things that work in editor, won't work in build.

Now you're moving goalposts. Now your asset builder made the API work in both runtime and editor mode ON PURPOSE, which means walking extra 50 miles to achieve something that can be done with significantly less effort. Because you can't accidentally do this.

Now, it would be nice if you kept hypotheticals plausible when you move goal posts. Because this scenario isn't in the realm of plausibility and as such is not very useful. The initial scenario where somebody tries to build an editor tool in the runtime build was at least in the realm of possibility, and I explained to you why this wouldn't work.

At the end of the day, the advice is still to consult a lawyer.

 

I don't recall moving goalposts, I put them where they were to begin with. Oh well.

 

I'm having a "legal ArowX"-vibe.

 

Can we conclude that the answer to the title of this thread is: “not very” and move on?

 

Have we fully seen how far you can creatively take a thread on competing with Unity?

 

"Some things mortals aren't meant to know. This is one of them"

 

@imaginaryhuman The only difference between this and your original question is how the user obtains the app: instead of downloading an already built app from another store, they're downloading an unbuilt Unity asset/project from the asset store and then building it themselves, essentially treating the Unity editor as a build tool rather than a game engine. The fact that it also has an editor version wouldn't change anything.

So, whether it's a competitor or not is still the same as before: can the built app replace Unity?

Also, according to the submission guidelines:

So, if they wouldn't accept your tool as an app, then they might not accept it as an asset/project that's meant to be used as an app, either. But you would get a definitive answer during the submission process.

Also... It's not like you can't make a Unity competitor with Unity period, it's just that you can't do it without explicit permission from Unity:

So you would need to ask for permission first (which you're already doing).

@neginfinity @Antypodish You can make an editor in your game without using Unity editor code (ex: a level editor), which is the very basis of this thread.

@neginfinity https://eyebleach.me/cats/

 

Points well made, thanks.

 

Hmm. Well after waiting 4 weeks for a response, a customer service person responded to my request. Their initial response was a misunderstanding of the question, so I responded back that this was specifically about license terms. Then they responded back that this person was not qualified to give such advice and that I should seek the counsel of a lawyer. So essentially what they're saying is that Unity themselves are not willing to have someone assess whether something competes with them or not, and some third party has to make an educated guess on the matter. lol

I'm pushing them back one last time to see if someone more qualified can respond.

UPDATE - latest response just says they won't give legal advice, end of story.