AppLovin Proposes to Buy Unity Software in Deal Valued at $20 Billion

I agree, much goodwill has been squandered over the years. All of us gave so much, believed so much and just feel so disillusioned I guess.

Hard not to, it feels like Unity is the stick but Unreal is the Carrot. Not how these things are supposed to work. But I guess that does indicate fairly strongly that indie forum developers are basically not important to Unity's financial wellbeing.

But @LeonhardP has been given the green light to try and turn things around with the community. I think he wants to give it his best, so I'll support him on that and see if that goodwill can come back.

It'll be a long journey, make no mistake but we are seeing signs of change with the UI Blitz with developers and other things.

Of course it will depend on if Unity can invest in things that don't immediately match the spreadsheet. So far that was a successful gambit for every single one of Unity's competitors.

 

Just for clarification - Unity has officially declined/rejected that offer more than a week ago.

https://forum.unity.com/threads/uni...jects-applovins-unsolicited-proposal.1322844/

 

I can understand not choosing a tool because it doesn't fit your needs or because of the history of the company (eg malware from ironSource) but choosing to avoid one because the name is not to your liking is just incredibly dumb.

I know and have known engineers at various companies and none of them care about the name of the company behind the software they use. They might mock it but the name alone isn't going to make them pass it up. What's important to them is not the name but the software doing it's job and not being a pain in the process.

Of course even if Unity were bought up the name of the company behind the engine would still be Unity. If buying a company up automatically replaced the name of the company we wouldn't be referring to Unreal Engine as being developed by Epic Games.

 

Names matter, which is why companies are given a name and not a number.

Sufficiently offensive or idiotic name would give a good reason to avoid the company.

 

Only within very limited circumstances. If a company is facing the public then it can be a problem but I'm willing to bet that the majority of this community didn't even know AppLovin existed before the offer was announced, and a significant number likely didn't know ironSource existed either.

If we're developing for a client they might care but most of them aren't likely going to notice if it isn't immediately visible at all times and like I said a company getting bought up by AppLovin wouldn't mean everything would get rebranded as AppLovin.

 

I mean okay, sure, but I've also heard that one before. Every time the complaints about how Unity handles things as far as communication is concerned get just a little too loud we're told "okay so we're gonna try and do something about it" and for like... maybe a month they do, but then it's right back to effective radio silence once things have calmed down a bit

 

Ironsource didn´t spread malware, that was a misunderstanding (i felt for that too -.-)

Well is stupid to think that the name is important, but in fact it is and you are right, the name is important, i'm a graduated graphic designer (i think in english is recieved) the name is important because is directly related to the vision of the company, that's why names like: Unreal, Microsoft, Unity exist, when you create a company you can spend easily months just to create a name (if you really love your company, of course)

Anyways, why we are talking about this? isn't this old news already? did i miss something?

 

Well, that would be Unity's choice really wouldn't it. I mean, what else could it be?

You're basically still holding on for something, but Unity is not targeting developers like you, but mainstream people, or quantity that will go on to use Unity's services. These services will form the backbone of what Unity considers the metaverse to come. In other words, you've all been gamified.

Doesn't mean you can't do brilliant things, or people won't want that, it just means it really isn't going to change much for people wanting things they've spent years asking for.

I mean, people asked Epic for C# for a decade but it hasn't happened. Each company has it's own course at these scales, I think. In the old days you could ask and receive, nowadays it seems to be ask and get replies, rather than what you wanted.

 

I wonder how bare it would become around here if this ever happened... But, it won't, any time soon, if ever.

 

I'm not sure C# is more important than having 88 million miles of automatic networked streamed game content that you don't need lods, baking or anything to achieve other than putting it down. When you have that kind of power, C# becomes the limiting factor because there isn't a scenario where you or Unity is ever able to achieve that in a 10 year time frame.

So if C# is all that defines Unity's custom, they're in serious trouble. Unless of course Unity pivots to being full on with engine work, instead of full on with services work.

The reason Unity cannot do this pivot is because services make them the money and there is no ad revenue in endless streaming worlds or whatever. So tool for the job.

Would be nice if Unity committed to it, but the tech and tooling for that is just too distant.

If Epic did roll out C# overnight, it wouldn't really help people make games in Unreal. That engine is mostly led by blueprint, with a form of managed C++ being for when you need to optimise or simplify some things. You can't avoid the nodes though.

Some beginners like to speak loudly about C++ being hard and all that, but they probably also achieved absolutely nothing with blueprint as well. Some people are just like that, and very vocal about it. Unity serves these people well because of asset store. I doubt they release many if any games at all.

That's why I don't think C# is or ever will be the problem.

 

Fair points, but it still seems i read often enough that many people venture over to unity because "c# easier to pick up".

That said, I personally find both engines to be great, but if i had to pick a single defining factor, what it feels like to use each toolset... I would say , unity feels more like a one man show, and UE feels more like a big team. If that translates well.

Anywho, Interesting thread, enjoy.

 

the nanite and lumen is sure to bring in lots of eager noobies and we already know it is exciting for the big studios who can use tools like that to support their next-gen graphics pipeline.

but for beginner developers like me I think the standout with unreal is visual scripting. It is too bad Unity didn't capitalize on this sooner, I think.

All the time I see people having big long technical debates about this or that method and it is hard for me to figure out what the heck they are talking about. But if I do put in the effort, what I almost always learn is that they are talking about something I have already understood intuitively and didn't have so many problems with. because of the power of visual scripting.

It allows me to only think about code at a high level, so I am able to focus on big decisions and not get bogged down by minutia as much. This helps me to stay in the role of creative director more, and less have to play the role of engineer/programmer. For a soloist I think that is a big boon to productivity.

Just the other day I read about some tools that can be used but it requires C++ to implement. I don't know much about c++, but I just followed some instructions so that I can make some special classes in c++ and then expose them to visual scripting. That opened up some further possibilities in my project.

If I found performance problems with the visual scripting (I havent), then I could follow the same route. Just get some help to convert a few things over to c++ as I need.

This is a very productive workflow for me. It means I can stay high where I can move fast, and then, in a non-destructive way, jump down to low-level to solve problems only if it is necessary.

I can understand how experienced programmers who are accustomed to writing in a certain language or using certain toolsets (keyboard and text) would go with a tool that is most familiar with them. But for somebody without that background, that seems like a slower workflow from yesteryear. I don't think the future of gamedev is going to be full of people writing the same systems to solve the same problems over and over again.

Another example - I am not great at vector math. Whenever I need to use some, it is usually so far apart in time that I manage to forget how to do it. In the olden days, there is no choice. I have to study and get good at vector math. That cost a certain amount of time.

But nowadays, I just grab some pre-made nodes with dummy-friendly titles like "find actors right vector", or "find look at rotation" which has inputs like "target, source". I don't need to know the math; I don't need to waste any mental energy on that. I only care about the gameplay involved and the work that some programmers did who knows how long ago is still finding it's use through me.

People complaining about this or that being too hard or whatever I think haven't done very much work to understand where the real problems are. Writing in a familiar language may seem easier at first, but there are much bigger problems that will actually make or break a project. If you have to spend 1/3rd of your time fighting low level details and solving problems that have already been solved a million times over the past 20 years of gaming history, you are going to be behind people leveraging modern tools and workflows who are not fighting those battles.

 

Python i even easier to pick up, yet for some reason there aren't a whole lot of python games out of there aside from visual novels.

Sticking with C# is probably one of the unity's mistakes, to be honest. I'd prefer unity to have C++ bindings instead.

 

If you have a big game that justifies using Unreal, and try to make it in Unity, you'll probably spend most of the time making tools and not the game. This is why it's simply not true that Unreal needs a big team, since it already has all the tools but Unity needs all those made for it, plus missing features you'll make yourself. So I think Unity wins if you're doing something small, Unreal wins (even for solo devs) if doing something on higher end hardware (nanite/lumen). So the tool for the job thing applies here, but I don't think Unreal needs more people.

All those bewildering tools it has, are simply not there in Unity, someone still has to make them.

 

that is not a good thing to say about unity xD i can not say i'm agree with you but this makes me to stay away from unity in the next years...

 

He was simply being objective and practical. I agree with Hippocoder on "the tool for the job" point. There are areas where unity wins clearly and there are areas where unity has no chance in front of UE.

 

well i guess this is another case where quantity (of money, basically) wins over quality (of the product itself)

I know (for a couple of years) that i will need to learn c++ but damn i already hate to code and learning another language is a big waste of time for me... but i definitely want to create better games in the future.
EDIT: but what kind of tools does unity lacks?

 

First of all the whole C++ thing in Unreal is just managed C++, it's not that scary, and does memory management for you. It uses decorators to inject code. Usually people will make the game with blueprint and only convert some bp (a right click operation) to C++ later, or add to it.

As for the tools Unity lacks, where to begin? I can't really write this one without sounding like an Unreal shrill or fanboy, which I'm not. I love *all* tech and engines.

But Unity is quite far behind in the systems and tools to make big games. Everyone has to make them themselves and asset store tools are usually made so generic as to be a problem rather than a solution. Sadly, Unity would face that same problem making tools (making them extremely generic) out of fear people want to make different things, or through feedback. Really, all Unity needed to do was make the ultimate open world 3rd person toolset. This alone will satisfy nearly all the use-cases most people would want and ask for at the high-end scale (in short what Unity is missing isn't the niche stuff people need to make tools for ANYWAY such as weird puzzler X or RTS Y because those are super specific and not often made).

But delivering that messaging to Unity, I've tried to do it directly, but now I do it by example, and those examples do often bite. It does not mean I am anti Unity at all.

 

Releasing GIGAYA, retaining the team that made it, and having them continue to make and maintain projects like GIGAYA would have solved 99% of these issues and more.

But instead they were all fired and its never going to be released - so yeah not really sure what the answer to all of this is or even if there ever will be an answer anymore when unity are out of touch enough with their audience to be making decisions like this.

It does however send a very clear message about where non-mobile gaming sits in terms of priority going forward, and its obviously not very high at all if even a priority anymore.

Im treating unity as only for mobile and XR from this point onwards, and it will take a crazy amount of movement in the opposite direction we have been heading for some years now, to make me think otherwise anymore.

 

but, what tools? i still don´t know...
Character tools? texture tools? terrain tools? AI tools? i've seen many devs talking bad about the terrain system, also i've seen very bad reviews about the AI system but i do not understand why. Is that an example of the tools unity is lacking?
What other tools? i really want/need to know because right now i'm making a very basic game but i want to make better and more complex things in the future so, is a legit question
If it's not too much problem could you give me some examples of those tools unity is lacking?

 

Did unreal ever implement Mecanim alternative? Because all character controllers being interchangeable can save quite a lot of time. It also allows for things like limb length variation in UMA....

 

Do you really think the same company that cancelled GIGAYA would have taken any of the internal feedback GIGAYA generated seriously? This is the thing I've been saying since day one: dogfooding is completely meaningless if the overall corporate culture is such that any feedback, external or internal, is going to languish unless it has clear financial incentive.

 

I do not know the nature of your project. But here are roughly what I needed a while back. I did not find anything for them in unity, but many of those features did exist in Unreal back then(and now). And I could not just use Unreal for those projects due to the human resource state of my team and other internal legal issues. Thus the option for me was "getting the kinds of stuff (philosophy) from Unreal and implement them inside Unity". Here is a list of such stuff so that you might find them helpful:
1. A gameplay framework which

• respects inheritance with composition coding style
• has a bunch of frequently helpful commonly used gameplay features(damage, pooling, time reverse, custom dilation just to name a few)
• helpful abstraction to facilitate bigger production sizes
• might be easy to do multiplayer later with

2. Multiple tags for Actors and Components, the tags are also hierarchical.
3. A generic save system including encryption
4. A blueprint like task graph and task manager to see what is going on in a level
5. Ability to play, and mix any number of animation and animator controllers through code. Montage-like functionalities.
6. An UI system that abstracts away much of the complexity and buries it deep inside so that I can treat them like web pages. I sense UI Toolkit, but at the time of writing that library, I AFAIK did not employ UI animation.
7. A blackboard patterned AI library to construct AI logic elegantly
8. Weapon, ability, inventory
9. Vehicle

Many of these can already be found in Unreal. So I went for implementing it inside unity. Of course, some stuff makes sense only inside Unreal and some stuff makes sense only inside Unity, because of engine philosophy. I just tried and still trying to get the things that can be done. It was such a giant task and I have not even finished 50% of it, so far. But you are cordially invited to contribute at: https://github.com/kaiyumcg

And I have not even mentioned any graphics features. Anyway, I hope this would serve hint of how unity lacks the features I needed.

 

@impheris

it may be easier if you described your project in as much detail as you could, then if somebody has done something similar to that they might chime in and be able to say what sort of problems they had, if they to make any special tools, etc.

And if there happens to be somebody who knows unreal pretty well, they could point out if unreal has some tools for that. You might also describe the project at unreal forums, see if somebody could help you identify if unreal is going to give you what sort of features you think you need.

big named tools like "hlod system" or "procedural foliage" or "animation editor with x,y,z features" are easy to point out and that can help make some decisions, but there is a numerous tiny little helper tools that can make a big difference too. Stuff you simply won't think about or realize until you do a fair amount of work with either tool. I summarize it as "ergonomics". I think it comes more into play for the designer/artist roles more so than programmers - assuming programmers are doing most of their work in some IDE.

if you are making a game that is well within scope similar to many other games you see made in unity, there probably is no reason to look for greener grasses. If you have bigger goals in mind, it's definitely worth making a full test for yourself. And it is good to try and measure some indicators of productivity as well, so that at the end you aren't just reducing the experience to whatever gut feeling you have.

 

We already have this. Instead of "tags", just add empty components, and instead of checking tags, check GetComponent<TagComponent>() != null.

I've never used Unity's tag system because it just seems useless when you can do that instead. You can only have one tag, and there's no way to attach tag-specific data to it. Using empty components solves both of those.

 

From your list, character tools for sure. A human character with common animations is probably relevant to most 3D games. 2D is a bit harder in this case since it'd depend so much on graphics style.

Tools and functionality to handle mixed indoor / outdoor areas, and a lighting system which can transition from outdoors to indoors without obvious issues in either.

Unity fully embraced the multi-scene approach to developing stuff years ago... except not quite, because we all still have to roll our own cross-scene referencing system (or grab a demo from GitHub). Really that should be handled natively.

High quality, native text rendering. TextMesh Pro is good as a plugin, but it's still being treated like a 3rd party plugin years after acquisition.

Proper support for industry standard 3rd party tools. Technically the 3rd party can provide their own support, but it can only be as good as Unity's built-in systems allow. Example? Everything in Unity which has audio directly references the AudioSource component. That's pretty unfortunate, because it means that if you start working with industry standard tools such as WWISE or FMOD things get messy. The ideal solution is that instead of AudioSource, internal stuff works with an IAudioSource interface, and then WWISE and FMOD (both industry standard systems which go well past what is provided by Unity) can just use it in their plugins and everything is groovy. Last time I checked this wasn't the case so, for example, in order to use Timeline you have to have the built-in audio system in your project whether you're using it or not. This same point (to access functionality which is likely to be replaced / expanded upon via 3rd party support via an interface or similar) applies in other areas too, e.g. text rendering.

HLOD is becoming a common approach in large games, so a built-in solution to that would benefit many games, too. On that note, improved LOD support in general, ideally a fully automated system that we can run by default and just replace things where it matters. Neither need to be technically as fancy as the competition, it just needs to enable small teams to get most of the benefit with minimal additional effort.

 

While I frequently use this approach for hypercasual and midcore games, I wanted more elegant solution. Currently I implemented hierarchical tags with node based editor(using xnode) where you define the relationship between tags. Having builtin multitag supports for your entities(or gameobject or actor whatever you call in a level) and your components help managing bigger projects.

For data attached to your entities and components, I use an approach called "Data layer". Its a string-object dictionary serialized, can load from device if properly configured, can be viewed in the editor inspector. Then you can have an editor window to inspect/debug those data for actors(i.e. check for health of all cows but not wagyu). You see, when I do smaller projects, certain things are overkill. When I do bigger projects, certain things are necessity. Workflow, tools for the job in the end.