GIGAYA

Unity announce their new sample game...

Based on the trailer, I don't know if it will adressed any concern people have with unity so far. Very unlike Unreal demo, it's mostly just a visual skin on old gameplay trope. Don't seem to bring any benefit.

 

Nioce.

 

A decently sized team, with an appropriate scope and goals with the end product delivered this year. And it looks rather good. I'm looking forward to diving into the project.

 

My favorite part is how when they show the game in the editor’s scene view at the end, it’s performing like ass.

Props for honest marketing.

 

1. It looks a lot more graphically pleasing, like an actual game would, and runs on URP. I'd like to glean in on some best URP practices.
2. The old 3rd person character controller was incredibly basic and didn't feel good. This new one seems rather competent and decently featured.
3. This new project uses all the latest bells and whistles - Input System, Shadergraph, etc. Basically packs the last 4 years of progress into this. Surely it's not the same as a demo from 2018?
4. Description claims the demo uses best C# practices in Unity for a scalable video game architecture. I'd like to learn from it.
5. Looks like there's a conscious effort to support and even further develop this project long term, unlike what has happened with previous Unity demo projects.
6. There's also a conscious effort in using their default engine tooling to identify main pain points, which are then communicated back to the relevant teams. Exactly what people asked for in the recently popular and controversial thread asking Unity to make a game. This is exactly what the community asked and Unity are delivering.
7. They are publishing the demo to Steam so they can experience the full development cycle from concept stage to a full launch.

There's plenty to look forward to, and this project is way larger in scope than any previous demo so far, which is great. Unity are actually using their own tools in a real-world scenario. Love to see it.

 

Their old samples were barely designed to be built into standalone players. They are actually publishing this on Steam, for free, and will experience things Unity employees are likely to never have had to do while working there, including:

1) Implement achievements.
2) Write a minimal save system that can work with cloud sync (PlayerPrefs doesn't).
3) Troubleshoot issues borne from a wide range of player's PC setups.
4) Having to publish updates (even if Steam is one of easiest platforms in that regard).

I hope they plan to publish this on consoles as well, there are several pain points there that everyone has to make their own workarounds to but Unity never bothered to address.

The benefit this bring is having people inside Unity put their tech to test holistically.

 

My guess:

There is only one stage, the island.
Made that way so there is no need for streaming of assets.

They might have used addressables, but more as an example than real need, since there is no unloading non visible objects.

No bright to dark passages.
So no underground or basements.

Probably no entering buildings.

Probably no lightmap.

Obviously no save system.

 

You will be master of optimization in no time.

 

is it supposed to be encouraging that unity are still investigating what it's like to make a real game? well it would be if they did that by starting an actual separate studio or three that made actual games with their engine.

i think what this should have been, is a project basis for 1st party multiplayer & large scale high fidelity levels. Happy with URP as a choice but it needed to also be a demonstration that their big talk about DOTS MP and DOTS for large, detailed worlds is panning out. instead it's a bunch of Creators exploring what it is to make games.

not encouraging is it?

it is not impressive to me that they hired more artists or better artists for a typical video game level scene and a character controller. i am the artist. give me the things i need to not have to make all the technology from scratch to do things with my art. or have to buy crap assets that half the time dont work.

honestly reading the blogpost left me feeling like the team's job was to learn multi-scene themselves, and learn this, and learn that, and basically for once road test it themselves... as opposed to give me something of any real value in and of this project itself. it's really backward facing not forward facing, in this way.

 

well there's a character controller! and a water shader! well that's game dev guys, what your customers do with it. what we want from you is the engine bit, and the engine bit we've been waiting on for a few years now is what i expected this artsy environment to be sitting on.

the fact you're telling me about multi-scene like its something new is just bad breath in my face guys

 

THIS IS SICK Unity finally will get usable character controller.

 

q_q people here will never be happy, will they?
Think I'll not look much more into the general subforum. A lot is just nagging around...

 

Well, they at least spent a couple million dollars on this, so people who cannot be satisfied can write on the forum that they aren't satisfied. I really don't know what did they expect.

 

I mean some unity guy TOLD in another bitching thread that the sample would answer question raised in that thread, he raised expectation too high, and we bit the bait.

I mean the presentation can still overturn thing, but I learned, I won't raise my hope anymore. I mean they just put some good asset in unity, good job, that's entry level tutorial, it wasn't even livestreamed so we don't know if pro builder exploded on them like that guy who tried to do a city with half the shader fidelity, which is the problem, we know unity can look good artistically, the problem is predictability, productivity and flexibility, ie removing pain point. So far the demo teaser isn't primed in showing that. How far the engine bend to our will is more important than doing predictable things with predictable looks.

 

As someone who uses Unity since a long time, I'd say: Finally. This seems to go into the right direction by listening to those of us who were quite vocal about Unity using their own product.

If it really uses the "basic" Unity features and does not include access to source code, it might really push the usability of the engine. Looking forward how far they take this.

NB: I don't know what people expected from Unity when they said they want Unity to produce a game for themselves. It doesn't really matter if this is through a separate company. It doesn't really matter if they are working on a game type which they already have tackled in the past. It's about pushing the engine and validating the tools at hand.

 

Currently yes, but we are discussing expansion.

We are evaluating Addressables.

There are some dark indoor areas! But most is outdoors.

There is both of these.

 

Do you have an actual source that this cost a couple of million dollars?

 

There is an internal test build to Switch. It just needs a LOT more optimization.

 

There is way more in the project than the trailer shows: save and load system, quest system, embedded cutscene system, dialogue, NPCs, enemies with AI, etc. and more other typical things planned!

For this project we wanted to use current public versions of Unity, existing tools and features and only public APIs. No alpha/beta/preview/experimental features. No source code modifications. Saw countless feedback that Unity should 'use their current tools and give feedback on them' so that's what we are doing.

However we will have potential opportunity to evaluate new/future technologies like DOTS in context of Gigaya in the future and get feedback on upgrade woes, performance numbers (better or worse), experiences, etc. IE: If we moved from PhysX to DOTS Physics what broke? What is better? Why is it better? How is it worse? etc then gives that feedback internally directly to R&D. If we started fresh with something like DOTS then it misses out that important feedback loop of taking a project forward through Unity releases and new systems.

I apologies if the project didn't align with your needs and expectations.

Honestly and personally, I wanted us to make a racing game like F Zero or Wipeout but then we would get the inevitable 'but what about XYZ? Im not making a racing game!' Its impossible to make a project that fits every scenario! The one we settled on atleast fits a fair amount of typical situations.

 

Seems like those 'hypothetical' questions about what game Unity should make were all a bit late to the punch.

You should use it just to experience the pain most of us already using it are experiencing.

 

Yes, I agree!

 

It was mostly out of curiosity; and was interesting to see where the overlaps and differences are in needs and demands between different forum posters. It was evident that there is such a wide demand for vastly different things; mobile vs no mobile, DOTS vs no DOTS, use current technologies vs use future technologies, 2d vs 3D, single player vs local multiplayer vs online multiplayer, mmo vs no mmo etc.

 

Obviously Unity should invest in a 4D single player MMO that can run on current gen consoles but also on gameboy

 

I volunteer NOT to do the port for Game Boy.

 

No, but 15-18 people's salary for ~9 months plus change and other expenses...

 

I'm excited.

The 3D Game Kit is fine for what it is, a simple game sample with cool assets to play around with, but code wise and project wise it's built like a jam project and not something you can expect to learn good practices from. Not to mention it's missing most of what goes into an actual game.

And I was excited for the the FPS Sample as well when it was announced, but it was dead on arrival just like most official HDRP projects, even the ones you need to pay for on the Asset Store. You can maybe get them to work if you use the exact same versions of every single package and library they used to make it, but even so most of them are also using custom and experimental stuff that never made it into the engine so by that point you're essentially just working with someone else's custom game project.

This at least looks more reliable. We'll see how it turns out. Maybe it even gets me to evaluate URP again.

And regarding the vertical slice part. If it's well made then the only thing separating this from a commercial platformer game is content and that "anyone" can make or buy. Making a solid character controller and all the systems needed to make your game play well is the hard part. Of course it's not a massive live service game like Fortnite, that would really stress the ins and outs of the editor and engine, but hopefully it's at least similar to the types of games a lot of Unity developers are making.

The first thing I will look for is if it the character controller is kinematic or not. I don't think Unity has ever made a project with a kinematic character controller, and imo any game without one just isn't a serious game. The obvious exception being games where the whole purpose of the game is physics interactions like Gang Beasts or Human: Fall Flat, but in any other case I expect every character interaction to be purposeful and not the result of "accidental" interactions with the physics engine. Edit: I realize the FPS Sample could very well have a kinematic character controller, but I was barely able to get that project to run when it was released and haven't looked at it since.

And using the CharacterController component doesn't count since it's a black box. Actually if Unity just made an open source replacement for the CharacterController component then that would be infinitely more useful than the recent Starter character controller assets they've released, which are just small wrappers for the CharacterController component. In fact I see no reason why they couldn't just create that package/asset in addition to the Starter assets and then those assets could be wrappers for that instead of the black boxed CharacterController component. It's kind of ridiculous when the key part of the asset is locked away.

 

If only we had 7+ years of development time like Fortnite had before it was released.

I wrote 90% of the character code so can answer this!

So we started with the built-in CC (whilst art team prototyped with starter assets) but moved away from it in first week due to its missing functionality and lack of interaction with unity physics (all well documented by the community over the years. ).

We tried both a kinematic and non kinematic rigidbody for the 'motor' of the CC but ultimately landed on non-kinematic as it felt more part of the physics world and a lot less rigid. That's not to say that a kinematic Rigidbody CC is not viable; it just didn't feel as good in this specific game. I'd probably use kinematic CC if we were making something less character physics-y like an RTS or Sims.

 

This stance seems a little odd to me, honestly. There's a kinematic character controller specifically geared for direct player control in things like platformers on the asset store right now and it's one of if not the best character controller frameworks for Unity there is right now.

https://assetstore.unity.com/packages/tools/physics/kinematic-character-controller-99131

 

I don't understand your confusion? That is a Kinematic CC (Ive used it before). I even tried it out one day in Gigaya and it works nicely; albeit was missing a few things we needed.

For Gigaya we did not want to use an asset store package for something as core as the CC. Also for various legal reasons; we can not distribute a paid asset store product for free.

 

My confusion is why you're saying it's not great for character physics driven stuff when kinematic controllers can fit that use case incredibly well. If anything, using kinematic controllers (this, and one custom built for my own engine) have solved multiple issues compared to non-kinematic ones.

 

I never said its 'not great'; I just said it didn't fit this game and our setup. Sure we could have probably done it with a Kinematic CC too; it just would have felt different.

Trust me, I spent ages going back and forth on this decision and experimented a ton with both and ultimately went with what felt best to control.

When the source files are released you are more than welcome to try your own KCC in it and see how it feels.

 

I guess, ultimately, I want to know more about what lead to this specific decision for the same reason I want to know what's been driving a lot of decisions in the engine itself for so many years now because I have to use the engine. If this is supposed to be representative or beneficial to Unity in some way, I want to know why.

Because a lot of decisions made in how to use the engine here reflect on how the engine is designed, I'd wager, and right now I'd call a lot of the core design of the engine pretty frustrating. For instance, you mention not using the character controller the engine provides, and I very much get that. That thing is basically a black box and a total nightmare to use, a complaint that's been made about it for more than a decade now. With that being the case, I want to know as much about the decision making process that's gone into the controller for this specific project, even if it's only going to be used for it.

I want to know what goes into the decision making process here more than I want to see Unity release these projects on Steam or even just as a package people can download. I need to know what the method to this engine's madness is.

 

Uhm, software- and especially game development is not an absolute. Details like those often depend on the developers taste, personal idea and goal.
Nobody doubts you could make a game with a kinematic CC. Here they happen to have decided for a non-kinematic one. Since those are not absolutely defineable decision, you likely won't get a satisfactory answer to the "why" question.

Similar with engine stuff too. If there were one perfect ideal, whe'd not have about half a dozen etablished engines with huge differences out there.

 

If they can not provide a satisfactory "why" then they should start working on why they can't answer that question. I literally provided an example of the problems this specific engine has in that regard.

 

I think that's a different discussion with entirely different people.

Productions Team exists as a studio inside Unity Company to use the tools and give feedback to R&D; both the good and especially the bad of experiences and workflows and provide data, help review future technologies etc. We are a new team and current existing engine decisions were made before our time (such as the built-in CC), but we can help shape the future moving forwards! Thats why we are building Gigaya with the current version of the engine (no DOTS, alpha, beta, etc) to have a coverage of 'now' (not complete coverage but its a start!). We have already had many discussions with various core R&D Teams highlighting many issues we have run into and vice-versa they have been asking us many questions too.

 

You can understand how frustrating that answer is when it comes to projects like this being so contentious in the threads that pop up every so often titled "Unity should make a game," right? It's very hard to not see the concerns about how this would simply be an arduous process that, at best, seems to be promotional material for the engine and a complicated and expensive boondoggle at worse being validated.

 

That shall remain your personal opinion then, I guess. Nothing more and nothing less.

 

If you had 'Keys to the house' and now run the company; what would you do?

 

Thanks for the reply. Nice to hear that a lot of thought went into this. Now I'm very intrigued.

Never having released a game myself and not really knowing anything about what commercial games do in this regard other than knowing which games I prefer and which I don't, I probably shouldn't talk so loudly about this, but in my experience whenever I try using physics for my character controller in a project where I want precise movement there always comes a point where my character does something I don't want it to do and I'm unable to properly fix it, but I guess that thing could often be so minute that most people wouldn't notice or care about it. I also get that very few games need 100% deterministic, pixel perfect movement and collisions, and that compromises have to be made at every step during actual game development where you don't have "infinite" time and no deadlines like my hobbyist ass has.

Either way, I can't wait to dive into this when we get access to it. It just sounds way more comprehensive than anything Unity has done prior.

 

For one, I'd put a total moratorium on projects like this, acquisitions, and even new major features, instead focusing on core engine functionality. Resources should be dedicated to evaluating current packages that seem stuck in preview (ProGrids, Kinematica, and Terrain Tools all come to mind) and figuring out what to do with them, while packages out of preview should get a great deal of scrutiny applied to their usability (Addressables especially).

Then, more attention paid to the SRP nightmare. Why do we still have to manually create our own post processing stacks when using URP? While that's hardly an arduous process, it seems a major problem that URP still isn't feature complete with BiRP and it's falling on the end user to resolve these issues.

After that? For the love of god and all that is holy, there needs to be a dramatic overhaul of the absolute nightmare that is the scripting reference documentation and, really, overall documentation in general. On top of that, lots of documentation is scattered across various parts of the site, making finding things an absolute nightmare. Each package has its own documentation, but often that documentation is out of date or woefully incomplete. What isn't there is in the scripting reference, which is often completely lacking in meaningful examples in how to use it.

These are general engine functions. These are things that people working in and out of games could all benefit from. These are things that are meaningfully important. These are things that make me not care about Unity making game projects.

Then I would feed John Riccitiello to a shark and roll around on a bed of money.

 

You cannot make a tool properly of you barely use it.

That's the entire reason game developers have QA teams and play testers. I don't know anything about you and your professional history, but would you release a game for sale on Steam without ever having it played from start to end and just wait for angry buyers' feedback to find out what needs to be fixed and improved?

And having the people who wrote the thing test it never works, in my experience. The programmer can use it for 100 hours and see nothing wrong, just for a playtester to break it in 5 minutes. Usually the people who code a tool or program develop blind spots to their usability issues, even worse if they are working solely on a specific piece of a more complex whole, where they develop a tunnel vision on their particular corner of the forest.

The production team is Unity's "play test team", and in my opinion it's something they should have done years ago. Companies like Adobe and Autodesk also have production teams whose sole job is to use their tools as real customers would.

This is not "wasted" money. Not everything is solved by putting more programmers on a problem.

 

I agree with you on many things listed here:
- Tidying up of current 'preview' packages.
- Sort out SRPs
- Improve Documentation.

All of these things are equally as important. Also all areas that Productions Team can shine a light more on (And we already have been so far)

(Disclaimer; I don't agree with feeding someone to sharks as a 'solution'. )

 

I have commented on this at length in the past so I'm just going to paste here what I said then.

All of these things are areas that the community has been shining a light on for a decade.

This is called a "failure of imagination."

 

It's a good thing! I hope they keep doing it.

If somebody is being fed to a shark please announce ahead of time and livestream. I don't care who it is. The shark should be a great white.

 

I do agree, but fixing those issues, paying more attention to feedback, and having a production team are not mutually exclusive.

 

But would it be Kinematic or not?

 

Something that wasn't already solved multiple times before by: Unity themselves, Asset Store, Github, various and many developers.

In short the problem Unity is still missing is *games at scale*. Like, real games. 6-14 hour playtime. Masses of content stuffing the editor long before they can actually ship and so on.

This game is a demo of graphics and some nice anims, so far, with a Steam target that won't be for sale and won't attract any negative criticism.

It's just a modern URP demo scene that can be played but it isn't solving real problems much from what I see. Everything internally at Unity about this demo will no doubt be "well this is tolerable so far..."

And never go far beyond so far.

 

How about we wait for the project to become available before condemning Unity's efforts in this direction? Lots of unproductive speculation in this thread, especially about specific implementations no one here has tested yet.

 

It is. If you don't have any personal stakes on the results and if you can avoid the tough parts of polishing and publishing a game by going "well, it's a demo / example so whatever" and shrugging away, there's really no point, is there?

We all know the engine is good at making prototypes and terrible at finishing a polished game and I would say projects like these fall much closer to prototypes than finished games.

I will take this opportunity of suggesting once again they make a team out of Unity higher ups, make them make a published cross-platform game that is sold for 20$, and if they get less than 85% on metacritic, they are all fired (or fed to sharks). Please also hire a film crew and turn this into a reality show, and then give free pop corn to all Plus / Pro users (Personal users just get kernels they can cook themselves).