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
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 @ .
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:
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.