Official Introducing Gigaya: Unity's upcoming sample game

When you listen to something like this, pay close attention to what's not said. This script has surely passed through multiple hands and drafts.

 

If that was the case then he would have never given a clarification https://twitter.com/johnriccitiello/status/1548326529217679365?s=20&t=mkooCB623qF6q-68uQnCoQ

 

@The_Island Hey!! Are there any plans to provide the third person controller and other important tools from gigaya in form of small assets on the assets store???


Also can you plz tell me what's happening with terrain tools if possible... The latest 5.0 ver is only showing bug fixes!! Most important features and tools aren't showing any major progress for 1+ year, like for example terrain shader graph support...

 

Honestly it's tough for me to have any faith in unity anymore. Cancelling gigaya is something I just won't forget.
I don't care about the acquisition, or all the talk about malware.. which I think a lot of people misunderstand.
But it sucks to see them spending that much money right after canceling gigaya and laying off teams that work on game samples or assets for the community. Not a good sign.

All the promises, blogs, and hype only for it to be canceled months away from release. And this isn't out of nowhere, unity made many mistakes that damaged it's reputation the last few years.

I see a lot of people talking about moving to a different engine and so on, honestly that's not for me.
I love unity, the workflow, and the look of games made with this engine. It just sucks that most of what I love about it are things that have been there for ages. (Except HDRP which, for me, provides something I can't get from built-in)

I also despise the slow development of URP. I see people hyping up the 2022.2 release for it, but I don't think it deseves it. It has been so long since development started and we still don't have basic rendering features. You'd expect stability in return for the slow feature development, but no, you don't even have that. You'd be a lot better off with built-in if you wanted stability.

I do think URP provides something, it's all done in C# and open for you to change, which is great, but it just lacks compared to built-in and it's been a long time now.

Not a fan of how some important features are abandoned, even when they're just not up to par anymore.
Unity's occlusion culling is in a sad state, you're better off with a particular asset that does it 100x better.

Same with lightmapping which is still worked on but man is it painful when you don't create your own lightmap UVs.
Yet again you're better off with an asset done by a single person, with a ton more features and better auto UVs.

Just weird.

 

was that a pinky promise? Like the one about no workers were going to get fired a couple of weeks before they did?

And how and who is going to hold him to this?

If you're unsure of what someone is about, see what they do as a clearer indication than what they say.

This guy sold nearly half a BILLION in stock since IPO, and doesn't seem to hold much stock, now.

And has one of the most interesting careers of any modern CEO.

 

Still haven't paid enough attention, I see. Read this carefully:

When he's talking about the dog video, and the accusations of him being paid by Unity, he categorically denies Unity involvement in THAT video.

See how that's leaving a lot of room?

From the 30 second mark in the video you linked. Odd choice of words, or very deliberate choice?

 

I agree, this goes for many assets, but not all of them -- the lightmapper asset I'm talking about supports most things unity's lightmapper does. It even has it's own "light probe" alternative that's a lot better, and more accurate than unity's own light probes. The workflow is also better, almost automatic.

The only support difference between it and unity's lightmapper that I know, is that the asset only supports nvidia cards + windows for baking lights. That's it as far as I know, they both result in lightmap files.

 

Maybe be it will be release soon, i think they need to do something good to get some love from the community, even if is in a bad useless shape (i have seen that before in games... i mean...)

You need to take into consideration that unity also have some services...

oh -.-" you don't give me hope with DOTS

not in my case, i opened a 2019 project (a casual game i'm making in 2021 and it works almost perfectly, just 1 annoying bug

I agree, i think this was a obvious move to change to something different that the community want, tha cancelation of a desktop game to improve workflow on that matter + ironsource.... it is very obvious

The problem with what you are saying is John Riccitiello's story

That is literally corporate BS, this is nothing new for him. Do not trust this things for people like him, i mean he said "there will not be any layoff" xD

 

My trust for unity has definitely decreased after the gigaya cancellation, and i might switch if unity continues to not to deliver things they have promised without any believable explanations, but that doesn't mean i believe in those clickbaity, overly exaggerated news from Kotaku, other news channels and overreacting fellows from twitter!! I would rather believe in someone who actually works there and makes those decisions, or the employees!! Believe it or not, but John, in that interview said he hadn't revealed any information about layoffs to Kotaku or any other news, he also added that half of them were rehired to some other positions... In the same interview he explained exactly same thing from the apology post i mentioned above in a proper way, after the "f***ing idiots!!", sentence!! So that was definitely a "clickbait out of full context", so nothing sounds like a corporate BS to me!! If John really wanted to focus more on monetization and $$$, then he would have never made all the huge claims about democratization for artists and hobbyists during weta acquisition or would have never acquired it in the first place few months back!!

 

yes you are right, my bad...
Still that "i owe you this" is corporate BS, again, this is not new for him (and for us gamers)

 

I don't think there is any team still at Unity with the bandwidth and skills to do that. It would be such a huge amount of work and time for another team to learn it all, prepare/finish the project into packages, create the educational material and package it all up for asset store. And then maintain it and answer community questions about it. All without access to communicate to the former Internal Games Productions team who actually made it.

Im sorry, I just don't think it will happen at all.

 

Also the "there is 3000 employees" tossed on the problem is not a good argument, it assumes engine dev is a highly parallelized and siloed process, the baby in nine month problem, which is not.

And that's pointing to a failure of management, that harken back to the Conway principles which is the reason why in sometimes, in some industries like video games, management need to understand the game and engine making process. It's pretty obvious when employees talk, that they have a siloed organization focus on narrow definition of task, and that everything breaks around responsibilities boundaries. This end up in deadlock progression because nobody can take ownership of problem that overlap these boundaries.

Example: when hippo asked in the adaptative probe volume about floating origin, they say they can't do it, when pressed about it, they say it's dependant on the scene definition (not their jurisdiction) and also it overlap with other lighting implementation (not under their jurisdiction). When asked about very general technical question to assess the cost, it's been told to wait for Siggraph in one year.

Basically, employees will handwave a lot of concern because they literally can't do anything about it, and really no one can because it doesn't match how unity as a company deal with engine. Which is why a team of very talented people can't move the engine forward and unity is stuck in endless pain. They need a refactoring of internal organization.

 

They actually do sprinkle it around in places wherever they can. Much of Unity's stuff is Burstable and Jobified. Graphics Jobs? Big perf gain. That's DOTS Jobs. Same for SRP. Now, you can't remove Burst from packages if you use URP, for example, because URP depends on it.

Another? The new replacement for Umbra is made in DOTS. It's dynamic, terrific and extremely fast. There is a whole team on that. I spoke to their leader once and he was kind enough to mention that it is coming to gameobject land! So everyone can and will benefit from these technologies. It will obviously take some time but some of it is already here.

So Unity's plan is indeed... to propagate the DOTS technology throughout the existing Unity. So none of the tech will be lost, but for optimal greybearding, you will want Entities, and some things probably won't be able to be ported to gameobject Unity.

 

I think really the big mistake Unity made was organising it in a well-meaning way for a Utopia of packages, split concerns. This was done in a very well-meaning way.

In theory it was great: we will split up old Unity into all these separate responsibilities so we can tackle each problem with more staff. What is more, the way they did their source control was also well-meaning but served to create huge bottlenecks with race conditions, regressions and so on.

The reality is that can work for some software. It can work for an operating system. It can't and won't work well for a game engine serving multiple shifting markets.

This all came about because Unity hasn't made enough games. Keep with me on this one as it's indirect. The reason for this is because when you make games (and by definition the game engine) you need a certain pattern to solve problems. As game engines are highly dependent on interop and pre-planning, you can't just split the codebase up into individual modules that do repeat work WITHOUT still acting like it is a whole.

Unity failed the acting as whole thing and went (this a quote from a movie) full retard. As everyone knows:

Spoiler

So you had a Unity that wanted to untangle all the dependencies at first. They wanted to move code that was touched on by multiple parts of the engine into their own areas (I clearly remember this, and tend to remember nearly everything I read) so that Peter didn't get hurt when someone pulled Paul. This is admirable and still necessary. But then they went full Tropic Thunder in source control, in packages, in staffing.

No game studio goes that far at all, because they know full well what happens: entropy and diminishing returns. The fact is when you have a game engine that requires temporal solutions, and requires solutions to be carefully planned for optimal peformance in order to keep up with competing technologies, you can't have all your staff spread out doing multiple versions of the same thing. You can't bottleneck your source control because of NDA and more.

They're just hard, hard lessons Unity is still learning. It's hard for Unity because they pay the brightest minds and the brightest minds tell them all their mistakes were the right thing to do. What they missed out though was it was the right thing to do for enterprise software, not a game engine that so very much does need interop on a much lower level from staff up.

Hard lessons, costly lessons. I can see Unity is busy rolling back a lot of these decisions now. Packages are being tightly coupled to editor versions. For large companies there are a number of strategies in which you employ your source control. Unity's changing and has changed that too. All rolling back a bit.

Sometimes you can really put the cart before the horse. I know Unity did. Went home empty handed.

 

Is more simple, there is no need for unity to pay him to make that video.

The youtuber has a channel making tutorials and videos related with unity. It also had some sort of collaboration with the company for past videos. Nothing wrong in that.

But, he will not start saying the truth right now and bite the hand that could, in the future pay him to do other videos.

He is running his business that involves talking about unity and sometimes collaborating with unity. What could he say? If he talks the truth, the truth can run his youtube business to the ground.

 

The ideal world would be to add an extra layer of abstraction to Entities or make it less verbose. Not because is hard, because when you want to write complex systems, it will take you trice the time to write it in ECS, which is also a huge factor programmers take into consideration when adopting tech. If a tech is not wide-spread and adopted due to high entry barrier, it will die overtime, no matter how great it is.
I like the idea of data driven programming, I've been working with this mindset for a long time. The first game i made with Unity I had a large group of zombies running on the iphone1 smoothly. It was only possible thanks to a data driven approach (way of handling enemies and buildings). Most games literally falls into it naturally. Eg: different sets of instances (entities and components) that do X, Y and Z stuff (systems).
Also, having a visual scripting system that is also powered by DOTS will be revolutionary and more accessible to non coders.
But my fears right now is that this tech as great and promising as it is, might die because of its high barrier entry level it has.
DOTS is not something for school kids or amateur programmers, is for intermediate and/or well seasoned programmers who understand how to split data from behavior when designing systems.
So making this tech a lot more accessible, will allows everyone adopt it more and perhaps Unity might ditch MonoBehavior all together and focus 100% on DOTS. Otherwise is going to be a new fragmentation in the Unity pipeline.

 

Unity is an oxymoron.

 

This!

 

But they were not developers ?
Right ?

Just some sidekicks.

 

This silo approach reminds me of Addressables versus the now abandoned Asset Graph, which had a lot of functionality like a per-platform settings system (which I really miss because different platforms work better with different asset bundle compression settings, for example) and ways to auto-assign addressable groups based on user-defined rules which are not in Addressables because it was made by a different team.

 

This kind of problem is worrying.

@The_Island what makes game different is the creative process, in software it's much easier to compromise because the experience is formal and strict. But as soon as you introduce dirty artist and designer, all hell broke loose. Sometimes in order to hit a specific emotional target. There is always the option to say no, but then a game will feel like they are on a template, and in a creative market, emotional experience get rot over time, so there is an incitive to push boundaries.

I don't have a good example on top of my head, let's pick a specific game idea:
Let say the artist want a swipe transition like in star wars, that mean rendering two full scenes at the same time, this will touch physics, rendering, animation, etc... Obviously the code didn't started for supporting that, as the assumption is that you only have one level at the time, usually and hide the loading with fade to black transition. But the effect isn't gratuitous, it is expected to have a great narrative impact. After concertation with the artist you realize that it's going to happen within canned animation, where the camera is locked. The issue is that the player character is customizable, and interaction modify aspects of the environment and there is a time of day system. There is many solutions, some aren't always technical, but there isn't an obvious right way to do it. The way the company where I used to work dealt with this is freezing the background into a few screen gbuffer textures, some prebaked, while unloading the current world and loading the next, only keeping important character animation and audio, and streaming one time use effects.

But that's just one game. The reason people ask unity to make game, it's that they meet many wild requirements to develop an instincts about how to properly position the engine. If your engine break thoroughly as soon as someone do something a bit outside or just lock options out (see original design of shader graph, not allowing vertex and light programming among many thing), that's a problem. Solutions don't have to be perfect, shaderlab and surface were innovation that were not perfect, but were exactly the kind of thinking you had to do to tackle, the ability to generalize divergent requirements, which is also why nanite is such a head turner.

Tldr: software have clear and fixed requirements base on well define tasks, there is a clear convergent metric of good and bad with a market that has well understood need. Game are arts, there is no clear requirements, metrics are divergent and tasks are nebulous, market are fickle and what's good once might not be anymore, only to return a few decade later. See darksouls and elden ring going the opposite way of the assumed best practices and banking. Making a generic engine like unity is essentially solving the divergence problem. This kind of thought process need to be baked at the culture level of a company.

 

If I were to print this and hand out to every single person who asked me why I don't switch to Unreal, would you want royalties? Because this is just what I'm going to do from now on.

 

@The_Island
It's not about solving everything, it's about generalizing. I picked nanite and surface, two things that don't actually solve everything, but make pain points significantly less of an hassle.

I understand it feel likes you have to solve everything when you aren't use to that class of problem, but the idea is more strategic than everything, everywhere, all at once.

Surface was born, as per Aras blog, from having to author countless shader variation, realizing that light was a big issue. Surface simplify this part by introducing a struct to which you write to and act as a contract between you and the engine lighting system. It also allows you to redefine lighting by decoupling the light pass from material by mimicking an extra step in the pipeline like vertex and fragment. So now you could inject material and lighting response separately. It was not everything, it was fragment lighting only, no vertex light, it didn't change how unity process light nor the underlying pipeline. What it did was a conceptual leap to recognize and formalize aspects of writing shader, under a generalized format, without removing existing options and still being felt like a logical extension, instead of a one more different way of doing.

I want to mention, I'm not comparing unity to unreal, I'm contrasting to specific solution done right by unreal, if you don't like unreal, think better shader. Metahuman and nanite are well thought out solution that generalize issues into integrated workflow, it's not about the engine, it's about the maturity of the approach in these specific way. I understand in the given climate of defiance, it's a nuance that's hard to grasp and push to the defensive. It's just that recently a lot of unity solution were half baked, how do we convey a better approach?

 

Well, cannot blame them.
Many times I have searched for particular feature (even basic ones) that was just missing in Unity and was present in Unreal for years.

 

Addendum:

I want to point some irony, unreal's solution mostly exist BECAUSE of unity, they took at heart the message unity was sending and worked on it.

When they made unreal free, I remember their early attempt at community feedback lifestream and being dumbfounded by user wishes like toon shading, saying that's not what the engine is designed for and why you would want that...
Competition is what made unreal adapt, they aren't there yet, but when they commit to one idea, they do the whole job. But that's a relatively recent development and shift in culture. Modern unreal is really just more unity.

For example, nanite isn't existing in a vacuum. They anticipated many pitfall. When unity present a demo, people always ask how are we going to match that? Therefore what's the point. It doesn't help said demo are usually done with skills and tools inaccessible to most. That actually hurt perception of the solution offered by unity.

Let's look at nanite, it's a solution to multiple things integrated together, ie occlusion, mesh density, streaming, draw calls, object density, storage. It generalize. It doesn't work on low end, aggregate mesh, foliage, skin mesh. It's an addition not a replacement. They set firm boundaries to manage expectations.
Okay, but how am I gonna match that quality level? Their answer is that you don't have to, to get the benefit, BUT if you want to, here a free library to kitbash scene.
Okay, but I won't be able to build system to manage that density of details. Their answer is the world builder, that automatically partition the world for you, help you navigate in editor those partition, handle streaming, handle version control, handle multiple user, handle Lod.
Okay but I will never have the the time, skill, resources to have characters that match the quality of these scenes. Their answer, meta human, which is mostly limited to facial editing, has limited hair and body options, while still trying to cover the fundamentals, has limited body type. Ie they aren't solving what's unnecessary, the hard part is the fidelity of face and animating it.
Okay but what if I want more specific face than the editor allow, like facial scan. There is mesh to metahuman that solve and simplified the entire march of death of cleaning scan, retopo, and creating blendshape into a five minutes process instead of multiple month. And if you need some touch up, you can still export to dcc, ie it integrate and extend existing workflow.
Okay but even though I get great face, performance capture is costly. Their answer is livelink, use your phone camera to get the face animation data.
That's a 360 degree set of solution, that work together, to a single class of problem, they aren't stopping at a silo, but thought of all implications and propose a generalized integrated set of solutions to address that problem. It doesn't replace, it integrate and extend. It does not solve everything, try making no man sky, you probably can't use that. Unity doesn't have that level of integration in its tool.

The difference isn't the engine, it's the process with which they use to address a problem. That's why doing firefighter in other's studio isn't helping dogfooding. Because you get stuck into a rut of only solving small specific details and fail to generalize into a bigger picture. Surface was a solution that generalized well pain points, but because at the time Aras was probably mostly alone consultong and helping a diverse set of problem in different setting and had the ownership to address them. It's a forest and trees situation. Too many firefighters doing specialized solutions, don't help pool the knowledge into a bigger vision, you end up thinking faster cars is what the user want.

When I'm talking about unreal, I'm talking about the process, how they took and made their own the motto of unity. How they adapted to that competition. And how they approach making solution. I mean look at the mess with the different UI solutions that barely work together, and the initial trajectory of the scriptable render pipeline, which was a great idea but half baked, the idea of composability was a way to propose a generalization that make sense, but where did that go? Urp and hdrp being replacement and replacement of each other is a trainwreck that hasn't finish yet, they lacked the right abstraction by looking at their problems as silo. Imagine if birp was separated into unlit render pipeline, pbr metal render pipeline and pbr specular render pipeline, would that make sense?

So forget about unreal, I'm using that as an example, the process is what matter. I'm pointing something with my finger, it's not the finger itself.

 

@neoshaman
Spot on!
Ignoring both engines large share of issues, Epic design Unreal around many tools that are common in the game industry where Unity design the engine around services and API for people to create tools/services. Still not everyone needs the amount of tools Unreal offers and other way is also true, many people needs out of the box tools (and solutions to hard problems) that Unreal engine offers.
But yeah, I don't want to derail the thread either.

 

C'mon, Unity's Game Services are great. So is the editor, the Asset Store and above all the community. With Nanite and Lumen the competition (Unreal) did two big steps in the right direction that's for sure. But let's be honest, the only "real" reason someone would switch from Unity to Unreal are exactly those two powerhouse features. In my opinion Unity was waisting too much time in solving solved problems for the x-th time. The competition has spearheaded the direction which Unity has to take next. I personally don't see a problem in this as long as Unity reacts accordingly to keep up and improve the core of the engine.

 

I wrote this in a different thread but I want to expand it here a bit because is topic is related.

To understand what happened with gigaya you need to know about the long, sometimes forever, loading bar bug. If you didn't already meet up with this bug you can check this thread

https://forum.unity.com/threads/editor-progress-bar-stalls-request-for-bug-reports.1137817

so there is this bug which, my theory, may be related on how the editor is dealing with the files of the project at core level. The ones that are in the Library folder. The editor detects that the files had been changed start updating all of them randomly. More files you have, longer the loading bar. Sometimes is just doesn't update them and just hangs there forever. As we all know that folder can get quite large even for small, medium projects. Since the unity devs didn't test their code with huge projects that are opened and closed day after day they didn't catched the issue in the 2020, 2021 and 2022 versions.

If one have small test projects the editor works just fine. Which why many mobile developers may not have this issues, because they will not included a complex character with clothing, and animations and whatever. Or complex worlds with many props and intractable objects.

But some had issues as you can see in this thread

https://forum.unity.com/threads/lots-of-busy-hold-on-etc.833644/

What I think unity devs/management do while this happens,

At start they don't understand the issue, they think is the user fault, the hardware fault, assets store fault.

Anyway it is hard to admit you have built the core of your editor wrong. no one likes to admit that. It obviously works on your fast workstation where you have tested with simple projects.

Here comes gigaya. Unity says, we listen, keep my beer I will build a game and show you all that you were wrong and the engine is more than capable in creating high end games. We will use the default editor, not a custom build like genshin impact uses. You will see.

Uh boy, these issues show up. The people on those threads are right.

What do we do?

Do we fix the 2020, 2021, 2022 version at huge dev time and cost? We need to rewrite the editor core on how it deals with files. Then all the systems, hdrp and urp and whatnot. need to work with the new concept.

Then if people want to update their project, they will not be compatible, we need to create some sort of conversion tool, but that is a big can of worms. Not gonna happen.

Well, we could fix this for the 2023 version. But here comes the issue, the work on the 2023 version has already started for months now. Gigaya has shown the issue recently.

We can stop gigaya development till the next version exist the beta? That pose a couple of problems.

What we do with all the people that were building gigaya, we keep them around doing nothing? Because they can't build others games. The editor is broken

And is even possible that gigaya can be updated for the upgraded/fixed editor core? Probably not.

So, decision. Fire the people to avoid paying them for months while they do nothing.

Lock the broken gigaya project in a archive vault.

And the big MAYBE, do we stop the unity 2023 development and we fix the issue?

OR we don't care now, we will keep the broken core like it is, and we go ahead and we fix these issue for the 2024? We will rewrite the 2024 version from ground up when we start the development on that in a few months, we make a big launch next year (around October) with nice features, and projects for the users. Everybody happy.

Or maybe we just don't care. we will try to build an adds company and hope we foul unreal users to use our ads instead of the competition adds.

 

@dorusoftware
You have shared this assumption of yours in 3 places now I think.
If that were true, what do you think are the studios of large games doing like the makers of Subnautica and Genshin impact? Or other larger games you see in the in-progress section of the forum?
Have they rewritten "the core of the engine" themselves? lol

There is no absolute blocker that prevents a huge project in Unity, let alone a midsized one like Gigaya.

 

Genshin impact, yes. subanutica most likely used the 2019 version. actually, we don't know if Genshin impact use the newsts version. they may use the 2019 version as well.

I don't know man, this thread is about unity not being able to finish gigaya. what you have read here till now? because I don't see any gigaya project.

 

It isn't a small bug, it's more like a major regressions added up due to the addition of new tools and features.. The team is continuously working on fixing it for years, and here is the latest progress on it
https://twitter.com/s4schoener/status/1550477560869519362?s=20&t=spo_QOiUc3RfW2rb5XwfyA
And their long term plan is to move to the latest version of .NET

 

@dorusoftware A nice theory, but pure conjecture and wild speculation. You have no idea what's going on internally. Maybe you should go work there and find out for us instead of fanning the forum flames with your fantasies

 

Gigaya isn't being finished for business decision reasons, not for technical or unexpected high effort reasons...

 

well is a theory, better than nothing I think, do you have another one that make sense on why unity decided that alienating their user base out of the blue?

till now I've seen two types of unity users, those that got the loading bar bug and those that don't.

if is not finished because of management business issues and is not finished because of technical issues? What remains? The CEO just deciding to do it out of spite against us? Please do explain

 

Did you read this official announcement from Unity?
https://forum.unity.com/threads/int...oming-sample-game.1257135/page-2#post-8278305

 

Yes I did. confirms my theory 100%.

 

They really need to make a proper full response; it's been a month and people have talked about this to death.

Surely letting people speculate further details isn't ideal. Is there no one left that was involved with the project to give a legitimate official break down? I don't expect Ant or anyone else to really talk cause they have their future careers to worry about.

I mean I imagine there's no real decent PR response that can be made for this cause I think they did this without a plan or any legitimate reason beyond what's stated.

But there's not really any damage control effort from any of this as far as I know. Is ignoring things really a good strategy after so many blunders?

Also, this hasn't been done, at all. I appreciate @The_Island stepping in to help, thats great. But it seems like they're doing that of their own accord and no one official is responding.

I think one thing's that's clear is The_Island did diffuse the heat a little, you'd think Unity would like more of that before people get annoyed at the silence. And other things being posted elsewhere now that a lot of people are being pretty negative about Unity.

 

Source?