GIGAYA

https://assetstore.unity.com/packages/tools/physics/scivolo-character-controller-170660# if people want another free alternative... that can also handle any rotations too.

 

I have not. There's an upcoming project where it might be relevant, though, so I'll take a look, eventually.

 

Awesome. I think this actually nails most, if not all, of the stuff I suggested when you asked what Unity should make in the other thread. The one contentious point I remember is that I said "realistic" graphics, but the purpose of that was to prevent style-based workarounds, and I don't think the style here is going to side-step much of anything, so... groovy.

I'd love to know what solution you took to cross-scene referencing, as I know that's something that many people solve for themselves, and also that Unity has previously made a sample implementation but never adopted anything natively.

You mention async scene loading. Is that for areas inside the game's level getting loaded as required, or is it just for nicer scene transitions?

Did you use Unity's provided localisation tool?

- - -

Personally, while I've zero interest in seeing Unity scale this out to be a 10+ hour game, I see far more value in a sample or demo like this than I do in Enemies. Gigaya addresses plenty of requirements I see in real games over and over again. Not all of them, but that would be unreasonable to expect. On the other hand, Enemies shows me that Unity can be used to make a single-shot short film that looks nice. Which is cool and all, but... how many of us are doing that as compared to making games, simulations, training tools, VR/AR applications, and other generally interactive stuff?

If Unity takes it further I'd like to see them address moving between levels / worlds, ideally in a seamless manner. I don't really care about the scope of the sample's implemented content, as long as the systems in place demonstrate that they support scaling.

 

But what is the performance like? I'm hoping it will be horrendous then updated with DOTS or something to fix it. That would be educational.

 

This is fantastic to hear - I was about to raise this as being my only concern but you guys have already addressed it, well done! Really keen to get hands-on with the demo when it releases and have a bash around, and particularly curious to see if you've implemented any custom post-processing for URP, or just gone with existing effects (I spot the trademark Unity bloom in the trailer - not a bad thing).

 

The stuff in the video I saw doesn't show anything I recall having trouble getting decent performance with in the past. So even if they bungled it in this case it's not a concern for me, because I'm already confident it can be done.

That said, I would like them to put it on Xbox One and PS4 and (maybe Switch later) and get it running well on those if it's not already. That's the hardware target I'd expect for a game with the visuals on show (from memory of one watch nearly a day ago), and hitting that is where trickiness tends to rear its head. Some of that trickiness (and stuff related to platform requirements) seems to be commonly addressed by many developers, so Unity solving it once would be neat if they're not already using this to do so.

 

They said they already have an internal build running on Switch and that it indeed needs a lot of optimization.

In my experience doing console porting, Unity performance on consoles has always ranged between bad to significantly worse compared to even low spect PCs, depending on the version. The problem is always the same: CPU utilization, specially on the main thread.

I always felt they never did sufficient performance testing on consoles. Yes, the CPUs on gen8 consoles are all pretty low on single thread performance, but it's obvious Unity is not doing things as well as it could. To make it worse, feedback regarding console stuff is less common due to various reasons: less people with console access, devs on deadlines who don't have time to prepare repro projects, devs working on older versions which will not benefit from fixes because they usually only hit the latest betas, etc.

Example: when optimizing multiplayer on a multiplatform game we found that the Stopwatch class had a significant cost on PS4. The reason? Instead of using the CPU ticks as a source of time (as it should) it's reading the system's date and time, which is a much slower call not designed to be called hundreds or thousands of times a frame (which happens when you are using Spotwatch to timestamp network packets). Fortunately for us, the implementation for this (and other low level functions) is exposed in C files in the Unity install folder and can be modified (a small glimpse of what could be done if we had source access).

 

Well it uses asset store post effects and Unity staff said it could use optimisations, and so I'm wondering what would be the most effective way to do that in Modern Unity given a base game to work from like this.

The key pressure I'm applying for dog fooding to be effective is for Unity to fix these issues within the engine, not in code that people do themselves, which is something one can do in any engine and invalidates the reason such a project would be useful for: dog fooding.

TLDR: I've been doing workarounds in Unity since 2 and 3, I would like Unity to learn why these workarounds still exist year on year. Thing is if you don't want to work around, the answer probably does lie with DOTS like I implied.

Assuming Performance by Default still stands.

 

Honestly, doing software development in entirely other fields (including development of visualization libraries) and occasionally gamedev, has taught me that there's no project without workarounds. No library or engine can foresee what every end-product shall be capable of.

Sure engine developers shall always try to cover all cases efficiently, but with our personal usecase in hand it is too easy and also silly to say "the engine should simply be capable of that efficiently".

Of course, if they encounter things that require workarounds in this game, it should be evaluated whether it can be meaningfully fixed within the engine without hampering other features. However as a dev, I'd be not surprised to often find out that the reason that it is a "problem" in the engine for the current project, is because it has been developed to suit other usecases better.
Especially performance is a very common case for that. A solution for Usecase A will be nonperformant for Usecase B and supporting both is significant extra work.

I put "problem" in quotation marks because when there is a valid workaround without too many downsides, it's hardly a problem in my opinion.

Btw. not sure DOTS would really do a lot for Gigaya. Thought that shines most when you have large numbers of relatively similar "things", doesn't it? Like the moving decorations in their famous super city example.
Of course currently we don't even know whether the painpoint is CPU or GPU at all.

Honestly that often is just not possible for something as versatile as a game engine.

Theres a thing that more likely stands: The rule of thumb that higher abstraction (and nothing else is the result of relying on defaults) means less performance on average over all usecases.

 

I think you're looking too closely at this. The workarounds I refer to are for gaping holes for which the competition has very well covered like hlod, streaming assets and so forth. These "workarounds" aren't as trivial as playing games with the API. It's a gulf of missing API and bad API choices. Big difference. The next workarounds will be for GPU driven rendering, for which Unity still does not have natively.

But sure, defend them, even if it does defeat the point of dog fooding.


I don't know, why don't you ask Unity, since they're saying that, no-one else. I'm quoting them.

 

Gut feeling is that it will be a good sample demo, but falls short of 'dog-fooding'.

Just judging by some of the 'official' replies here, its clear that the project is designed around using what is available in Unity, neatly side-stepping the many problems developers have faced with incomplete features. Granted in regards to SRP's they have slowly been getting more feature rich and heading towards parity with the legacy renderer, but we're still not that there yet.

I'm not sure I can fault them for limiting themselves to vanilla Unity, in many respects that is a good starting point, I think my concern is that defined the design of the project, instead of say having a great game idea and trying to implement it when the engine is missing some features. It also means that as far as I've seen in the trailer there is nothing particularly challenging in the project in terms of gameplay or graphics.

Everything I've seen listed as 'features' of the project could be considered somewhat of challenge to create/code ( depending on a persons capabilities), but not due to problems with the engine. A good example of this is the small scale use of assets/single level and not using addressables and limited gameplay mechanics. Again though I'm not sure I can fault them for wanting to get something up and running first and expanding the scope later.

What I would love to see from the team of Gigaya is a 'no holes barred' post-mortem of the process to date. A couple of decades ago GameDeveloper (Gamasutra ) used to run that every month in the magazine and I learned so much from the gaming companies that participated. What went right, what went wrong etc. Heck I've still got a dozen or so of those magazines that I look back at from time to time. E.g. Thief: Dark Project and The Internet Sucks: Or, What I Learned Coding X-Wing vs. TIE Fighter

So yeah a full on post-mortem, perhaps with multiple blog posts over several weeks would be very interesting and inciteful as to what they learned during the progress.

 

Using vanilla Unity is a challenge by itself. Pretty much everyone out there use some 3rd code to fill the many gaps in features, usability and performance. Them having to roll their own and deal with the native stuff can hopefully help in bringing those gaps to the spotlight.

 

That's all well and good.. But why is there one crab only? Where is their mate? Are they doomed to only transform translate x, never meeting each other on the Gigaya beach of lost love..?

 

More importantly isn't this really the future of dating games? Why couldn't dating involve jetpacks? Anyway I'll stop posting now.

 

Your lack of knowledge of the dating game scene is showing because I promise you that jetpacks would be absolutely mundane compared to a lot of stuff out there.

 

Is It Wrong To Pick Up Jetpacks On An Island?

 

A few things.

First, you need a solid foundation before you can build the rest of your house. In an exercise such as this I think it's important to start with the fundamentals. Limiting themselves to the core stuff that's meant to be production ready and realising for themselves that, yep, there are still issues to address, is likely to be of far more value than realising that some of the "advanced" stuff has issues. No bells and whistles, nothing fancy, just "what is it like to ship a nice but basic game with our own tools?"* They've picked a game that looks as if it belongs on a PS4 and Xbox One, so naturally I want to see it get there. (This is why I'm less concerned about Switch, but that would be cool, too.)

Second, I do believe that Unity's strong focus should be on the generic stuff, things which are applicable to many real-time interactive applications. Going from there to project-specific needs is my job, or from the Asset Store. The high-priority stuff for me (as someone who works across many types of projects) are things which will apply to every Unity project, or a great majority of them, such as ongoing issues with the Input system, prefabs and UI system, at least two of which I would consider both foundational and "incomplete" as they are. I digress. Back to my point, if Unity really does need to "feel the pain" to convince themselves of what needs fixing then they should feel pains that are as common as possible to their customers, rather than project-specific stuff. (Addressables would be high on that list, too. Why aren't they so easy to use that everyone just does it by default?)

Third, in case I'm missing something here, anything that Unity acknowledges as incomplete / beta / preview / experimental / whatever shouldn't be relied on to ship projects anyway. I fully agree that Unity should get in the habit of using the feedback they receive on such things (see: my repeated gripes with the new Input system) but I don't see "unfinished thing is unfinished" as a problem that needs solving.

Fourth, if Unity are getting value out of this exercise then it shouldn't be "finished" and it shouldn't be the only one. They had to start somewhere, but it should be just that - a start. They should revive their community project and complete it. They should do this again with a mobile game, a web game, a VR game, a multiplayer game. Maybe with a non-game or two (though from experience making both I suspect a few games would expose far more than non-games would).

For context, a couple of weeks ago when Andy asked what we thought Unity should make, my (paraphrased) answer was that they didn't need to make a game at all, because their customers are already giving them all of this information. I understand that filtering the information will be tricky (there are plenty of people asking for unreasonable things, making mountains out of molehills, etc.) but it is all there, far more than Unity will get from doing a project or two of their own.

 

Actually, this is a rare example where I am asking this question this way: Why Addressables isn't the default? Why do we need to use them?

Same here, and I'm pretty sure, we're right.

 

IMHO, big assets as textures,meshes and audio should not be loaded until needed or until forced to be loaded.
When I call "unload" on asset, I should be able to call "load" on the same object to load it back to memory.

 

I honestly really love what you're doing here. I have no idea why there are still so many negative posts, as this is exactly what people have been asking for for years. Especially those "that's great, now do an open world game" posts are honestly ridiculous. As far as I see it this is the perfect size of game to try out as many features as possible without landing in a 5-10 year long development cycle. I honestly think you hit the nail right on the head by doing it this way.

I have one question, or maybe call it concern. Are you planning on making the pain points you identify public? Because I feel like a major part of finding out how to make Unity better would be for you to experience development yourself, make note of your experiences, and then discuss them with other users. Or will this be an internal process that we might or not might not see the outcome of? I feel like a lot of Unity users need a bit of hope that you are completely aware of the exact same problems they face on a daily basis.

 

I will argue. People wanted Unity to make a game. Making a game should look like this. Not generic assets shoveled to a place with generic code from generic frameworks in a generic engine.
I'm feeling that people who lack skills and ability to plan properly wants Unity to make it so they don't need to plan properly. (For team size, ability to choose project with proper size for the team and skills).

This project is proper for the team size they have. They shouldn't make an open world, gigantic game with 8-15 people. And Unity users shouldn't do that either. Nothing is wrong with this project if we are looking at it as a game project.

I still think it is a giant waste of time and resources though.

 

Yes and no. As I said I sort of understand why they did this, but I fear that the capabilities of Unity have informed and defined the project which is not the case of anyone who is researching a game engine for a new game is doing unless they want to make 'generic platformer the game'. It side-steps the issues and whilst its perfectly acceptable for a 'sample' project, it is most definitely not dog-fooding the engine to any great degree. Of course even with such a straight-forward design they will still have come across some pain-points but they wont have challenged themselves or the engine.

Judging by other replies in this thread I feel many people fundamentally misunderstood the reason why those of us who wanted to see Unity use their engine for a finished product wanted. Its to experience the pain points, to run up against the engines incomplete features, to push the engine, but not in a 'here is a cool demo that we rewrote custom chunks of code for but you'd need source access to do' way. But push the engine in terms of using all the features Unity have promoted and create a complex project that pushes the features to discover the problems. More over its about constantly having projects like this in development, with a more direct line to the engine developers so that pain points can be rapidly discovered, targeted and fixed.

I think a good example of pushing Unity might have been to make this platformer emulate say 'Ratchet & Clank: Rift Apart' Rift effects as it combines visuals with having to load in different environments from different scenes seamlessly. Sure maybe PC's don't have the gpu /SSD throughput to match the bespoke PS5, but you could design around that. I'd then go further and look to see if there are use-cases for all of Unity's released packages, for example how maybe Live Capture could have been used for face capture and cut-scene production etc.

Ok, this is weird as you kind of highlight everything I've been saying in this paragraph, yet you start the post saying they shouldn't. I think there might be a mis-communication going on. Granted you do call out specifics such as 'incomplete Input, prefab or UI system' which are more common level things than I've talked about, but I think we both agree that even 'released' features have issues that need to be felt. I guess my concern is that again with such a simplistic game design one might not necessary be impacted by those problems and that issues with the ones you've mentioned might have been designed around.

Indeed having watched the Twitch discussion, I'm both amazed and dejected to learn the game doesn't even have an 'invert Y' option for the camera controller - https://www.twitch.tv/videos/1435336001?t=04h33m57s. Sigh, and sure I have to admit you can't get everything in the game straight-away and maybe this announcement is driven more by the timing of GDC than when is right for the game, but I think it might go to show that perhaps the project hasn't truly faced the amount and degree of pain points yet.

Further more I'm getting concerned that Unity wont actually acknowledge these pain points publicly, at least not to the degree I would like to see. Not so I can 'point & laugh' at Unity, but so that I can see they have truly come to understand the seriousness of the problem. It would also be nice for some cases for them to highlight the pain point, propose their solution, then ask the community/customers for their suggestions to ensure that issue are correctly addressed.

While I can see the point you are making, I'm not sure anyone is arguing for that. For me one of the issues that has plagued Unity of late is that of releasing features that ARE feature incomplete. For example I'm pretty sure URP was released ( not beta, not preview) and yet was missing basic things like camera stacking. Sure over the last few years many of those features have being retro-actively added, but they should have been their in the first place, URP should only have come out of preview when it had feature parity with the legacy engine.

This again goes back to dog-fooding, where your design is led by ideas and concepts that should be achievable with a game engine, only to then find missing, incomplete or buggy features that either slow down, prevent, require absurd workarounds or ultimately dropping of a game features in order to complete the game - these are the pain points that Unity needed to experience and learn from.

I mean it feels like every single time I try a new feature from Unity I find it buggy, incomplete or ultimately unsuitable for purpose. Want a recent example? Unity Recorder (Released status )

I had a new client that wanted VFX animations rendered to video. Well I've used Natcorder in the past for recording from standalone, but this time I can just do it from the editor, so Unity Recorder sounds perfect, bonus points that you can add a recording track to a timeline. But ever since release you could not define the bitrate of mp4! It was hardcoded to 8Mbps for the highest setting and that is just unusable for anything with motion at 1080p. It has taken a change to the core Unity Editor to have that become a user setting and that is only in a recent 2022 beta of the engine! Except I couldn't move the project to a beta release of the editor, not in the last few weeks, so I had to render everything using ProRes creating massive files.

Another example Live Capture. I hadn't even heard of this, but its such a cool new feature and again is stated as 'Released'. Unfortunately its heavily geared towards film production and has a confusing amount of repeated complex camera settings - I think there are like 3 different camera setup parameters on 3 different gameObjects, each one sharing the same settings but using different parameters for some reason and lacking documentation to understand why. The real problem though was trying to use RenderDoc with that package installed caused Unity to hard crash every time. In the end RenderDoc was far more valuable to the project than Live Capture would have been so I dropped it.

These sort of examples seem to happen to me every time I try out a new feature or package from Unity, doesn't matter if its 'Released' or not.

Not sure I agree with the not finishing bit as I think its too easy to ignore pain-points that happen towards the end ( e.g. not having an invert Y camera control option ), but by the same token it may well tie up resources for way too much time. I do agree that they should have multiple projects on the go, perhaps with an overlapping timeline and explore different types like VR.

 

Can you give some examples of issues you think they're sidestepping that are relevant to a) general game development and release or b) 3D platformer games, which are a fairly common and popular type of game?

I didn't mean they should abandon the project pre-release. I meant that they shouldn't consider it to be finished at that point. As a sample it needs to be maintained on each target platform until (ideally) it has a replacement.

Definitely miscommunication. My first point is that since they're doing this they should start with the foundations. My second point is clarifying what I think the "foundations" are, and agreeing that some of them are unfinished despite being described as ready. My third point is that Unity do need to also better use feedback for in-progress stuff as well, but that I don't think this is the avenue for it, at least not yet. And my fourth (as mentioned above) is that this one stage of this one project shouldn't be the finish of the overall project. Developers need to maintain projects for months or years across multiple platforms, and often publish updates,extra content, etc. Just making a thing and getting it on Steam (one of the easier platforms) isn't indicative of developer experience if that's where they stop. Plus, it's only one of Unity's many target platforms.

 

So Unity has an FPS and 3D Platformer/Adventure games what other genres do they need to cover next?

 

Unity has also RTS Spell Out. And I think motorboat racing game.

Now only missing is, one click make MMORPG button.

 

"Genre" with a lot of objects (foliage etc) and assets (10GB+), big world with occlusion culling, buildings that you can enter and dark dungeon with many dynamic lights inside.
Everything without loading screen.

Does not matter how artistically crappy it will look, they can spawn objects at random.

 

The thing is THE MAKE GAME BUTTON is an ongoing joke but automation eventually takes over in all areas where people re-create the same types of things food, cars and eventually games.

With procedural generation, AI helper apps and QA AI testers creating a game in a pre-existing genre will get easier and easier.

And it's going to have to happen for the META verse to take off, actually didn't Facebook automate website/blogging and dosen't it have the same plans for 3D virtual worlds!

 

yeah, automation definitely designs cars and recipes.

 

I can definitely churn out some food recipe application in 10 minutes.
Bon Appetite.

 

Automation has yet to reach any of the points you've described here in any fields in any real capacity, let alone something as dramatically complex as games.

 

@Murgilod @sxa So you don't think Facebooks Meta is going to change virtual world creation the way facebook changed websites/messaging.

 

Absolutely not? Interest in Meta sharply dropped off after its announcement because they have yet to actually explain in any coherent way what it would mean and who would actually want to use it. The entirety of what is being pushed as Web3 is seen as either a joke by those who understand the underlying concepts or completely muddled confusion to everyone else.

That's why the only people you see jumping in on it are people who are trying to use it to sell things, not people who are interested in the concepts or technology.

 

I would risk here to say: one of the greatest benefits of Gigaya is that the community is now more focused on talking about Unity's sample/evaluation project than discussing other engine's demos and features

Awesome, just keep development and discussion going!
Not having a continuously developed project by UT is (was?) one of the biggest causes of Unity problems.

 

Congrats @Andy-Touch , you will never be able to fully satsify everyone at the same time but I think gigaya is a massive step in the right direction and already addresses a ton of issues with past samples. Please continue to develop it, listen the community suggestions (the ones that make sense, not everyone suggesting things are making feasible or even sensible suggestions) and I think this will mature into a really useful sample for a wide range of unity users

I do echo the sentiment that some sort of runtime streaming needs to be in this or another sample, because that often is a big issue streaming of large worlds etc

But in general its great and the philosophy of using only public releases etc is a great one that I hope you take with you to all future samples. This is probably the first time in a very long time I have actually cared about and wanted to use / study a unity sample that is released, so congrats is in order!

 

From a beginner's perspective, I absolutely cannot wait to dive into and dissect various things in the project to learn myself and push my own boundaries. So I cannot talk about the current state of Unity and what its strengths/weaknesses are. I just think its an amazing time to be involved in gamedev with the amount of resources available to us. It makes me feel like a child again and thats always something I always strive for.

 

I hope you're going to release the project on github, like you did with BoatAttack https://github.com/Unity-Technologies/BoatAttack , because that would make it easy to browse the code without downloading something first and of course to submit pull requests and report issues.

 

@Andy-Touch Are there any plans for Unity to deconstuct the project into re-usable templates - kits - assets.

E.g. Sub-systems, atomic mechanics, assets.

Ideally then a set of teaching learning sessions could look at each element and build up the game in a way that would allow developers to dip in and re-use the elements they want for their own projects.

Ideally the boat demos water would be on the asset store and in a learning session.

Or think of it from a developers perspective where they can go to a Unity demo(s) with a shopping list of things they want for their game and pick up the items they need. e.g.

1. 3rd person charcter
2. Jetpack
3. Mission system
4. Inventory
5. Dynamic foliage
6. Dynamic ocean
7. Wild life
8. Pacific Island

 

(4) Introducing Unity’s newest game sample, Gigaya | Unity at GDC 2022 - YouTube
GDC videos are here

 

Looking forward to this. If it's a smooth running, feature-rich demo using everything already available in the engine, it will be exactly what has been required for many years now.

 

Yeah, I was pretty impressed with the prior 3d Game kit as an educational project when it first came out. It sounds like GIGAYA is a giant leap beyond all previous demo projects, though. Good job to everyone who worked on it!

 

Oh interesting seems they are using the Experimental AI Navigation package, so not exactly
"No alpha/beta/preview/experimental features."

 

I hoped the character would be some kind of "MetaHuman" (I forgot the Unity term for it), but it's not. It's a real human scanned and brought into the engine (link). Still impressive and all, but I assumed you'd use the demo as an opportunity to show off your Meta Human technology as well.

PS: The speaker who presented the Inside Unity’s new flagship demo, Enemies talk was really entertaining to listen to. Good presentation!

 

Hadn't seen that one, impressive stuff!

 

Would this be an ideal project to introduce Direct Storage?

 

Literally no.

 

You may have jinxed us. I heard today there is some "exciting news" coming from Epic on April 5th.