How long was GIGAYA in development ?

I don't want to make another topic about this, but all GIGAYA threads are closed.

This question might have been already answered somewhere but I could not find it.

So how long it was in development.
How many man-hours were put into non assets elements.
Especially programming.

 

Longer than you'd expect, not as long as you'd hope.

 

I can give more actual data; having worked on the project from day 1 until the end.

Started around May 2021. Started entirely from scratch (no code, assets, content, etc). Team was about 7.
First playable prototype of mechanics (Custom CC, Environment, Puzzles, Gameplay Loop, etc) around end of July.
Based on internal and external feedback revised some design and systems for next few months.
Then we worked on polishing more, improving existing systems, adding more details, adding more puzzles, etc.
Unveiled publicly at GDC in March 2022.
Cancelled June 2022.
We were aiming for release by end of 2022.

Dev Team was 2 people (me and one other person) until about January 2022; then the other developer left the team (to work on his own games at his own company). Then we had 2 more developers join the team.

Team numbers ramped up more at the start of 2022 and at the end we were about 15 full-time. But over the course of development we had some people join for short term; for example game music was another person internally at Unity for a few weeks helping us out.

 

Im sorry, I don't know how many human-hours were put into non assets elements.

What is a non assets element?

 

I suppose it means all none third party assets.
Like custom code, custom scripts, custom tools.

While it is rather too vague, I would expect to see som breakdown on
- concepting
- design
- scripting
- UI
- tools
- debug
- art models
- art animation
- art textures
- art shaders
- audio
- gameplay testing
- other

 

Sorry to be the bearer of bad news, but I doubt you will ever get a detailed breakdown like this seeing as the entire department (especially including the people who would have these kinds of numbers) no longer work at Unity.

 

No worry @Andy-Touch.
It was more dethorical question.
Sure, I would love seeing some numbers, but I know there maybe some data, which can not be published, or is hard to get hang of.

We could perhaps guestimate:
- 2022 May to 2022 end of May.
- That is full year, full time.
- Let's say 8 months 7 devs about.
- 4 months 15 devs about.

What was the split of coders / artists?
30 / 70%, or more like 50 / 50%.
Or perhaps different split?
I presume, there wasn't anyone responsible for the marketing in the team?

 

Over the whole project id say at any point approximately 25% of the full-time team were programmers. The rest were producer/project manager, character artist, character animator, environment artists, game designer, vfx artist, audio contractor, etc. We collaborated with some marketing folks outside the team inside Unity but pretty much all the content shown in text, screenshots, video, etc was done by us.

 

By non assets I consider most things that were made inside unity.
Especially scripts but also shaders.

 

Scripts and Shaders are not assets?

 

As far as internal definitions have gone in my projects at least, I've never used "asset" that broadly. Asset has always referred to things like models, textures, sprites, audio files, etc., while anything else has usually been referred to as scripts, shaders, and markups.

 

This!

 

To me, anything that is a 'file' is an 'asset' of some kind.

But I feel this misses the point of the thread haha.

 

Does it though? "Non-asset elements" specifically mentioned programming in the OP.

 

From an engine perspective that's true, you feed it to the engine. From a production perspective it's the dichotomy between data and process. Script are data for the engine, but process and behavior from production, because they need to be fed the data.

 

I think we are all splitting meaningless straws here.

 

It's a pretty reasonable separation to want to make, especially in the context of Gigaya as a Unity project, with all the workload and workflow issues that entails on the development front.

 

Ok, going by OP's definition of non-asset elements; no idea on exact number of hours. Id estimate 'a lot'.

 

did you develop any tools which might have broad utility? If so, can you say anything about them?
Did you identify any problem spots with the engine and share feedback about it? If so, what was the feedback/problems?
Any parts of the production you felt were unnecessarily difficult, but you couldn't find a solution for, so you had to work around?

I don't personally care, just asking some questions I think might bare more helpful answers.

 

Going to be fairly candid.

Yes! For example: Surface Type Detection, Cross Scene Referencing, SFX Tools, Own Object Pooling, Generic Platformer Systems (Like moving platforms, elevators, etc), Collectable System, Quest System, Save System, Scene Collection Loader and more! We mostly built these things for Gigaya but hoped we would expand them for other productions too and improve them each time. Like a real studio!

We had hundreds and hundreds of hours of meetings with various R&D teams highlighting issues, feedback, experiences and also getting advice and best practices from them back into the project.

Some main issues we ran into that were recurring topics:
Lack of HLOD/Decent LOD System, Lack of usable Occlusion Culling, VFX Graph Performance, Visual Scripting Performance, Build Time length, Shader Variant build length, Physics Optimisations, Plastic with Cloud Build, pain making a Quality Settings system with URP, general tools and systems missing from Unity that we had to build ourselves, etc.

Mostly scalability across the board; and the connection of that to performance.

Just a few topics:

Personally, I ended up removing Visual Scripting from a lot of areas of the game because of compilation and performance issues were so frustrating and predicted fixes were too long to wait for. We started the project as a Hybrid of Code and VS but then VS usage was reduced to just the enemy state machines. And even then we were investigating removing VS from them too because of same reasons.

Also we were investigating removing Runtime Rigging from some areas due to performance issues. Its fun and does a lot for you but in the end it cost us valuable ms for not a lot of visual gain that couldn't be handled by pre-baked anims and clever blends.

Lack of a default scalability in environment was a big issue; especially as Unity's LOD/HLOD story is.... confusing. I ended up prototyping a rough HLOD system specifically for Gigaya but we didn't end up using it as the root of the issue is Unity should have a solid one out of the box. And I didn't want this custom HLOD system to be added to the pile of other HLOD Systems.

URP Shader Variants was another story; and contributed heavily to longer build times. We were investigating solutions but never got a chance to pursue them more.

 

@Andy-Touch ,

what was the reason for using visual scripting? Did the team feel like it was going to decrease production time, or you just wanted to vet the system because you know many teams might use it?

A lot of those issues are over my head, but it's interesting that you faced problems with scalability because I thought that was main intent of render pipelines was to give more options there.

I'm sure it boils down to specifics which is going to be beyond my understanding, but in general, was the problem stemming from render pipelines not being fully-realized yet, or something else?

Do you think there might be an lessons learned, after-action-review type of thing made for gigaya, official or otherwise?

 

We had a lot of non-programmers on the team and it was a new system being added to Unity's toolset. We wanted to try and go hybrid to pressure-test VS but also open up flexibility to more people to implement visual elements. I liked the process of writing custom VS nodes with various contextual data that then the artists could use in a framework they are more familiar with than actually writing code. It also helped lift a burden from 2 programmers.

I hope that the issues we raised and reported will be addressed soon as it was the only feature that pushed us to entirely remove it due to the blockers we had. And its a pretty big feature!

Scalability is not just specific to rendering and render pipelines but applies to pretty much every area. But its true that like 95% of our specific scalability issues were rendering related. I think URP and HDRP have some really nice features added; but need more focus on making them them more usable in depth.

No idea! I hope that even though the project never finished & shipped that some of the information unearthed and reported was of use to some people inside and outside Unity and that the tools and product improves as a result of it.

That was always our mission; and it was a fun mission to be a part of!

 

A good custom HLOD system is a lot of work. You would need to batch objects into a hierarchy, shaders should be shared among the objects to make batching work great, creating LODs of combined objects (with overlaps at the edge-cuts), reprojecting textures for the given (combined) LODs, optionally write a custom culling algorithm and last but not least generate scenes for each LOD and stream those using the addresables system. All that, only to render static geometry. And we all know that this is one optimization area only and that there is much more to optimizing a game than static geometry. Nonetheless it would be so much easier if at least a solid HLOD system could be provided by Unity in the near future. The more the engine solves out of the box, the more we developers could focus on making awesome games / products .

 

I agree! The prototype I made was aimed at solving only a few of the pressure points we were up against specifically for gigaya (and was admittedly bruteforcing for our scenarios only), but it became a slippery slope to so many other areas. For sure Unity should provide a robust system out of the box managed by a full-time team. Or look at ways of solving the issue HLOD is trying to solve but in other ways (ex: Nanite).

 

Searching for what this was and found this repo started about 3 years ago: https://github.com/Unity-Technologies/HLODSystem
@Andy-Touch did you attempt to work with this version or even know that it existed?

 

Yes, we tried this out but it did not work well enough for our setup. Its also not really an official solution.

 

I'll be candid as well because this is just so, SO frustrating to read especially.

The ones I've highlighted have been community complaints for, in some cases, nearly a decade. The ones I've haven't highlighted are either ones I've not personally seen/experienced for myself or are too broad for me to really go "yeah, this" like "systems we had to build ourselves" because that happens in all engines.

I guess these revelations just really hammer home how it's not just Unity having a communication problem on their end, but also making it more obvious how little the developers using the tools are listened to in a way that gets passed on to engine development.

 

Thanks @Andy-Touch for all your work and for going in to so much detail on this! It is very interesting to read about the issues you/the team had!

 

Thank you for sharing, it is quite interesting to hear these details! Likewise, a bit frustrating because it seems Gigaya was clearly exposing some shortcomings of the engine, with HLOD being something that every decent sized game needs and would need to deal with.

It sounds like the .git project was like 50-80% there and it would have been great for someone to hear the feedback from your game and then decide "Let's just put a team on that HLOD git project and finish it up!".

Same deal with all of the items @Murgilod bolded - all of those are about 70-90% there, someone just needs to realize that last 10-20% of effort can make the difference between a useable tool and a nice experiment.

 

Hmm, be careful to not fall into the "the last 10% of a software are another 90% of work"-trap.

 

This thread only reinforces my intent to explore other directions. Other engines are solving problems Unity refuse to address, such as proper LODs and pathfinding. Movie lions look all nice, but they don't really address gamedev problems. GIGAYA was meant for that and Unity have clearly stated it's not their priority.

Client is asking to ditch Unity altogether after the current project. I'm not sure how realistic that actually is considering existing tooling and experience with the engine, but it's happening. Not that Unity would feel the loss of a few Pro license subscriptions in the face of mobile ad millions. But if our work is not Unity's priority, then we won't prioritize Unity either (or at least we'll give it a serious attempt).

 

That's what I'm saying, these projects all hit that last 10% part and just stop. Somebody (the user) has to do that extra work or just deal with the shortcomings.

 

It's like the hair shader not working on urp despite them stating it would. They haven't even checked if it was properly set up and send it to die on GitHub.

 

Not that I'm really plugged into the professional game dev community, but every person I've seen report that they tried other engines reported that it was much easier than anticipated.

Same goes for me, but I didn't really know anything starting out so I don't think that counts.

 

Just want to add that the R&D teams and engine developers we were working with every single day are highly skilled, brilliant, helpful and very passionate people who really want to make the very best product possible. I already miss working with all of them.

 

Adopting all the new Unity tech is almost like learning a new engine anyway, maybe even more challenging since a lot of it is poorly documented, lacks feature parity with legacy systems, and frequently introduces breaking changes for very little benefit so far.

The amount of mental processing power required to keep track of package and asset incompatibilities, gotchas and dependencies is growing every day and I just don't feel the cost justifies the effort. Unity has become fragmented and bloated. Opening a different engine that has a single solution for any given system feels amazing, like a lot of weight lifted off my shoulders since I don't have to waste time evaluating 2-4 solutions for any given thing every 6-12 months.

The ones I've spoken to directly have always been knowledgeable, keen to listen to feedback and demonstrated an understanding beyond my laymen takes on complex topics. But they also were frustrated by the management, general bureaucracy and slow internal processes. At the end of the day, the management and established corporate structure determines engines development, not the brilliant engineers who implement whatever the higher-ups dream up.

 

I'm only surprised you haven't listed rebuilding of navmesh, anything related to baking lightmaps, UI, and scene management. I suppose you haven't used them too extensively.

Also, I'm surprised you've removed visual scripting, I know it's terrible, but there was some narration in the youtube teaser, and that's usually done via visual scripting to unclog the programmers. We are using unity visual scripting for dialogues, cutscenes, quests, tutorials, and even serialized custom events (via hacks). Everything works well enough, the only annoying issue is the reload assembly.

I have a question too. Has any team you've talked with, released a specific update to the tool? It would be nice to hear about small QoLs or specific bug fixes.

 

Yes, I have used them extensively. Although, I have not personally baked a lightmap in a long time as usually work with people who are specialists in that area and they do it! These domains just didn't really pose an issue for us but we did use all of them on Gigaya. The other topics were bigger challenges.

Most of us didn't really want to remove VS as we wanted to lean on the hybrid of code and VS and it was a nice workflow for some areas.

But it really did reach a point where maintaining it, stopping it from constantly breaking and trying to figure out how to make it performant was eating up much more time than the rest of the game and project. And R&D's planned roadmap that addresses some of our issues was too long to wait (years) so I made the decision to unblock us. Was it the right decision to be made? I still think so yes; it sends a much clearer (I guess drastic) message of an issue than just 'putting up with it'. Speaking to many friends at studios recently and they ran into similar problems with Unity VS (plus extra problems we also ran into like a nightmare to debug) so its not an isolated problem. I hope Unity prioritizes these common community complaints and woes as internally I think we were the only production team that was actually using it (for a time).

Unfortunately I don't have that exact data to share; and it depends what the release notes are like for future Unity versions! I don't want to make any uninformed promises now im no longer an employee and can't double check with release management.

 

Unity is the wrong tool for the job for a game of Gigaya's scale. That was proven by Unity's own staff at the time.

Pretty shocking really, and goes to show just how much extra work devs would have to do to make it work. Even if the engine was fixed overnight to handle this kind of workload, it's still missing a decade of neglected tooling.

I guess that's why so many notable Unity devs moved to other engines, like Facepunch etc. They warned us, we ignored and here we are!

 

It's not just that UT was warned, but that UT has been warned for a decade and beyond being just warned, requests for features that have become standard in most other engines were also ignored. On top of that, features that did get implemented were lucky to get implemented even half of the way to what could be considered industry standard.

Most experienced devs I know would have left Unity a while ago if it wasn't for Unity's single core strength: scalability in performance that goes in more than just one direction (see: UE4/5 scaling down poorly, Godot scaling up poorly due to its lack of features, etc.) and the dramatic ease that comes from only having to deal with one engine in a situation where you may have to maintain more than one game.

If an engine with reasonably support comes along that matches that scalability, Unity's going to deal with a pretty significant exodus.

 

Looks like a matter of time, time to rise the low end toward unreal.

Godot on the other hand, I'll wait to see version 4. The creator was warning it wasn't a AAA engine, as the main thing that separated AAA and indie was the massive file streaming and management. But lately he seems to have change his tunes, also it seems new members jumped at the challenge with a system I think was dubbed swarm. So wait and see, but that's not a good outlook for unity to have fire lit up under its chair like that.

 

Admittedly, we knew going into the project that default Unity wouldn't have all the vanilla tooling or workflows required. And it was intentional to shoot for something just out of typical scope to try and highlight issues, blockers, annoyances and missing features internally. Its true that these things have all been ranted about by the community for up to a decade but we hoped that doing it internally would have more value and eyes closer to the core.

With no more internal game productions team, I guess Unity has now taken the approach of prioritising direct feedback more from external studios and projects. lets hope that rings true and things like HLOD and better Shader Variant handling is higher up the priority list.

 

I think it's true, yeah. It won't happen overnight, but it will bleed devs at a rate they complete games with, because it's projects at that size that tax Unity.

That still only theoretically works though. Everyone else is actually making games themselves and thus will get hit hard if they don't act. Unity can talk to thousands of devs, do nothing, and still have no penalty.

Put it this way... if after all these years of claiming that Accelerate or equivalents have been so beneficial... they STILL get blindsided by something as straightforward as Gigaya, then I think that says it all.

Maybe you're just feeling soft hearted or something. I understand.

 

I was being kind of facetious and sarcastic. Unity for sure needs some 'skin in the game' to identify issues upfront and in advance, before they reach studios who cant wait for years for a maybe-fix or a system to be usable or be finished.

 

For Unity to bleed devs the # of new devs would have to be less than the # of devs using another engine
It seems most of the unhappy crowd are PC/console devs, but given how console and PC are stagnant and even shrinking that "exodus" may not materialize

It's not just from double digit mobile growth. Unity "non-games" revenue from tools and such has been quietly growing. At the current rate, 50% of Create revenue will be from "non-games" by the end of this year. These are paying (mostly enterprise) customers that will get an ear from Unity and make direct requests.

 

Most likely, yeah. I'm doing a project of that kind of scale at the moment and, while I'm not annoyed at Unity as others appear to be, in the time since that project started other tools have become a better fit for some significant parts of the work. So next time I'm planning a project, what tool am I going to choose?

And certainly I expect other people will be in exactly the same position.

I don't think it's doom-and-gloom for Unity as a business, they very clearly have their strengths, and there are projects I'd definitely do with this set of tools in the future.

 

Honestly @Andy-Touch hearing the amount of clearly beneficial findings from gigaya that were discovered alongside the tooling that was created - this just absolutely is like taking a sledgehammer to the face.

Its annoying to know that the one chance to rectify things people have asked for around 10 years to have in the engine, was thrown down the drain.

@Andy-Touch have you considered applying for a job at unreal (this is a real question btw not like a sarcastic comment aimed at unity)? They may be more willing to listen to the experential knowledge you bring, and I think it would be a waste of such talent if you were unable to continue contributing to game engines. I know they are not exactly a great company to work for in many ways, but at least it might seem more "fulfilling" in some aspects in regards to overall direction and actually giving users what users need.

EDIT: @Andy-Touch based on your findings with Gigaya and your knowledge of what is going on at unity behind the scenes, if you were to start a new game project right now - would you use Unreal or Unity? (hoping you can be candid on this point as I am sure its useful to many in this thread)

 

I have some friends over at Epic who I have worked with before and would love to work with them again! It really depends what kind of role it is, if the team is a good fit and if it has a positive mission.

It really depends on the type of game. Most studios I have spoken to recently are thinking about changing engine/technology in the next few years (for various recent reasons) so I have 2 small prototypes im building to learn UE5 and Godot; I see both as likely viable options in the future as their tooling improves; especially Godot which reminds me of Unity 3.5 but with a stronger foundation.

 

Could you elaborate a bit on this? I'm curious about what has peeked your interest and what is not there yet. Also, are you trying the godot 4 alpha?

 

Thanks mate, I think your answer speaks volumes as to the current vs future landscape of publically-available engine-based game development

I also from the limited time I have spent with Godot get the same "warm feeling" when using it as from past unity versions (i.e. 5 and prior versions). I very much think that with the right direction and time, it will become what I think a lot of us are missing when we use unity today (which almost feels like its become another engine these days since 2017.x, so different from the feel and direction of the 2-5 era).

Thanks for being so candid!