Unity Technologies: please make a game.

A or B doesn't matter, just force the team to upgrade to a newer Unity version every month or so, including jumping to the next major LTS or Tech.

Also make the team comprised fully of Unity's top executives, then hire a film crew and make a reality show around the creation process.

Also if the resulting game isn't a hit and critically acclaimed, the team is fired.

 

To me the most beneficial thing for unity would be to handle the real lifecycle of a game close to how the end user experiences it.
So the 3 areas should it focus on for me would be to:
1. Create a game released across common platforms and storefronts, at least pc, one console and mobile.
2. Update the game engine in pace with the current LTS without source engine alterations, upgrading to "new" engine features as they become available in a stable form. Wait for fixes for essential issues to get backported and hassle with upgrading to new systems just like your average user.
3. Regular content updates. No one and done stuff like with the demos that are done as soon as they are shipped. Deal with fickle appstore requirements when they change, content/feature creap of an ongoing process etc. Really see it as a living project that should be able to be self sufficient eventually.

As for the stable vs preview/alpha/experimental, I would say it should be on the cutting edge of stable features.
Does unity consider something stable? Throw it into the game and experience all the pain points would have if they still blindly believed in stable unity features. Are there issues? Time to spend more time on the feature. This way the game could act as a filter for "feature readiness".
Longer term game features could still be developed in line with new engine features to provide feedback and be able to work on it ahead of time. They would just not get rolled into the game till the engine feature is ready.

 

Yes. Because money (and t

Unity must make semi-open-world-3rd-person-networked game. Which is sold* on all platforms, and works.

The reason it must be 3D networked is because that is where the players are, and that is where Unity can really add the most value to the developers using it's engine, and for itself. It also touches on perhaps all areas of the engine, so any improvements in workflows should trickle back to us as the developers to use in our own games.

 

I'm really glad that this thread has opened up some healthy discussion on the matter.

Start with A). Many of Unity's core/current tools still require additional work in order to be properly used in some scenarios. I'm not even talking about genre-specific content, I want to be very clear about this- I don't believe Unity should be the one responsible to create, oh I don't know, a car controller that has tight integration to some sort of Controller-Pawn architecture. I do want you to use your own tools and try to make something from start to finish and realize stuff like "hey, did you know that there's no way to find out when a Timeline cutscene has finished playing?" or "hey, did you know that there's no way to have an UI Image that is both 9-Sliced and filled?" or "hey, did you know that there's no way to pull off a half lambert in HDRP?" or "hey, did you know that there's an occlusion culling package over at the asset store that flat out beats Umbra with no disadvantages whatsoever? Same for lightmapping?" or "hey, did you know that if one of Unity's packages gets updated and you liked the previous version better for whatever reason, you cannot rollback?"

Download the latest version straight off Unity Hub. Use your own packages, latest version, no preview packages. No tools from the Asset Store, art assets only. Make a game, from start to finish. Use the new Input System since that's not on preview anymore. Once the game's out, keep updating it- make it the official Unity demo, use it to show people what the engine can currently do without any external assets/modifications.

Unity is a great engine and I will not jump ship unless something catastrophic happens. I like to think that if something went wrong with my game/project, I am the only one to blame. With that in mind, there are things that I personally believe could be improved that are beyond my reach, things that might be more noticeable to you if you make a game. With this, I believe you'll have a better product and we, your userbase, will be happy. Of course, I have an extremely simplified vision of how these things work but this is my honest wish at the moment regarding Unity.

 

I think the most important thing (if Unity were to make said hypothetical game), is that it is a game that is continually updated, and isn't just a "release once and forget" sort of game. This way, simply using cheap hacks and workarounds isn't as viable as otherwise the problems will keep snowballing over time, and it (at least I hope) would help the team at Unity see what kind of tools the engine needs to resolve pain points that currently require workarounds and whatnot. That said, picking a genre/game-type that has enough replayability to justify being continually updated would be a good idea, eg. an open world RPG or a multiplayer FPS - hell, it could even be a tower-defense game, or a puzzle game, as long as it is designed with replayability in mind, as long as it uses a good amount of the engine's capabilities.

 

The reason some of us want you to make games is because features you need will get added immediately, whereas if we need a features, it feels like it will be added to a list and maybe implemented if any of you feel like it someday (maybe 2 years from now, if it gets enough votes). I don't necessarily want to play the game or care if it's successful...

And there are many tiny things that would be different if you made games. For example, the screenspace/contact shadows have no distance fade near/far setting.

Another thing I think is lacking at Unity is an understanding of what the latest tools/workflows are. So when you assign a team a job, such as "improve the terrain", they don't even seem to attempt to make anything cutting edge, they end up just taking a year to make something from 2008. More research should be done to evaluate modern tools before trying to implement something into the engine.

- Open world survival
- PC
- Realistic
- 25
- Sandbox, moddable, multiplayer

 

Totally agree with this and something that they need to pay more attention whatever the case. Yesterday i opened the 3d game kit in 2021.2 without any error at all (that project is from 2018) that is something very rare in "unity's world" but very pleasant

 

1. Rogue-like dungeon crawler
3. Any, URP
5. Randomly generated levels, multiplayer
Reason : Unity is really hard to optimize for levels with a lot of dynamic lighting, especially in URP.

1. RTS
2. PC
5. Deterministic, massive amount of units simulation, multiplayer
Reason : Would be interesting to see Unity tackle a fully deterministic simulation in real-time multiplayer games.

 

Andy-Touch said: ↑
Throwing this question into the thread out of curiosity.

If Unity was to make game:
- What genre would it be?
- What platform(s)?
- What art style?
- What team size?
- What 3 areas should it focus on? (Don't list engine features; please, list more generic concepts IE: 'Replayability')

Here is a follow up speculative question!

If Unity was to build a game, would you rather it was:
A) Using current tools and technologies on LTS version to demonstrate how to achieve certain things with the technology of right now and give internal feedback on current systems and workflows.
B) Using preview/alpha/experimental builds and packages to give internal feedback on future technologies before they reach the public.

Dear Andy-Touch. Just a 2 cents.

I believe that Unity could try to make a full game; FPS genre...now it could be anything else, mmo, rpg, multiplayer...but it should be in 3D; not to say that 2D is not important (after all,many of mobile games or PC games made in Unity are of the 2D pixel like scrollers); I could understand that certain people prefer a 2D game made by Unity...but, why- not? Because we have to be real, 3D is the next-gen (am not saying there are no 'nex-gen' 2D games...it's just not really want people think of 'next-gen'; some people don't care about that and that's fine, will play 2D games, but the Large majority of people 'out there' like/want Next-gen - 3D; Ori and the Blind Forest is 2.5D, but it's because it has beautiful 2D art (direction) and such it is seen as 'next-gen 2d/2.5d'..but there is nothing next-gen about it; the VFX and art 'sell the next-gen' look; but it's not 3D, it's 2D); thus, in full 3D/polygons, you could use HDRP or Built-in - but not URP; URP is used by many, but it is not next-gen (it is a 'lite' version of HDRP; and the shaders are not as complex/more like mobile shaders - it shows; URP does not approach UE5, there is a substantial difference in certain shots; if you would use URP, it would have to be 'as if it's HDRP - but on URP'); HDRP does approach UE5 visually; or Built-in. Now, you may not care about that; but, in the end, it is important, because competition exists; UE5 is the competition (let's not kid ourselves) and it will 'take the AAA games' in the future; 3D games, Unity will continue being used mainly by indies; but this is the Chance to go beyond that and try to make a AAA-like game...but on very constrained budget and resources. To show, that Unity engine, can be used to make a game as nice/visually impressive as that Echo/Wind Stalker Demo in UE5 (The one when UE5 was shown the first time)...now you may say : ''Tech demo''; but it would need to be a full game or nearly-full; and that you would try to make a game - With Assets...using your Very Asset Store.

Why? Because many devs need to use your asset store; you can develop your own tools to make your game..but what'S more interesting is using the asset store to make your game. I hear too many people scream : ''Asset Flip'' in derogation...it gets tiring, most people don't care (thankfully); but it's just that gamers will say : ''Oh you bought Sinty assets and slapped them in your game/fake dev...anybody can do that and these assets are in every game...I don't buy games made with the Asset Store; they are assetflips/shovelware/low effort games''. I tihnk that is wrong, but certain people think like that (they have a point, but they always forget that games are massive creations and not the :''it's easy..download asset - and resell it - asset flip/voilà! easy money/cash grab''); when we Need the asset store to make a game that is a bit bigger - and on lesser means. In my game I am using Quixel assets (that are also in the UE5 demos. since Epic, acquired Quixel; in your case, Unity...you acquired Weta-- use their HQ film assets...photo, I await your Weta assets...) 3d photogrammetry; this kind of tech is important because Unity engine struggles on that (when ultra-high poly scene; it's why I said that Nanite equivalent was required; LODing it some way; this will show you that you will face problems with 'too heavy assets' and how exactly to make them all work together - while keeping 60fps/no micro-stutters or 'hitches' while loading; the game should run at 60fps - 1080p min. on Geforce 2070 min./Radeon 5700XT; 16-32GB RAM, i7 i9 quad or octocore. recent);

- What genre would it be? FPS 3D, or RPG 3D, MMO 3D (or SMO 3D, small multiplayer 3D)
- What platform(s)? PC - not low end; mid-high end Geforce RTX 2070/3070 at least minimum (below that too low), XBOX series X PS5 console (mobile skip this time, it will require heavy horsepower).
- What art style? AAA-like - check UE5 demo; akin to The Heretic level.
- What team size? 1-5 people; preferable 3 people or less...which will demonstrate solo devs can make this. The highest cost will be the assets outsourcing to Asset Store. If people tell you : ''Unity made a game and it is an asset flip...'' tell them: ''Yes, it is an asset flip...we commissoned (the Asset store) for some 5000 assets....any other questions?'' (I.e. Check the game Horizon Zero Dawn (Guerilla Games) this company outsourced 14,000 assets over 30 outsourced studios..and not one person called it an asset flip/it is an Award winning game; the studio Guerilla Games did not make 1 single asset; only art conception and the game itself (they said: ''we don't make assets...we make the game/focus on making a great game..not assets of this quality which would require 5000 more artists''); the 30 studios made the art assets in entirety (mostly China 3D asset farms that produce high quality Quixel-like assets for a AAA game)). People said they prefer 'stylized realism' over 'photorealism'..which may feel boring/déjà vu...thus, you could stylize it a litte..but just a little not cartoony 3D game (unless that is what you wish to do; but, the realism of The Heretic or Book of The Dead, CGI is a good point of reference in terms of visual realism and stylizing it a little so it's not just 'photorealism', like every other photorealistic game (same thing...thus, work on the look/look dev))..
- What 3 areas should it focus on? Visuals (Extremely important); Stability (Run 60fps, smooth, no crash/hick up/microstuttering (the game is not meant for lowend hardware...it will stutter on it unless degraded graphically; next-gen means next-gen hardware); some people may say : ''we don't need a next-gen Unity game''...but I think we do; if Unity wants to keep relevancy in terms of its HDRP/graphics etc...otherwise, people will run to UE5 and Unity will stay mostly lower end 2d-3d games; and I think that is undercutting self; why not, try to make a big game; even if it did not go so well; all that you made will be helpful (as other said : ''you will have dogfooded your own thing/medicine/engine - faced the same limitations and problems'' that devs do when they try to maek said big 3d games with your engine.

Just a 2 cents. Sorry for the length.

PS: A) Using current tools and technologies on LTS version to demonstrate how to achieve certain things with the technology of right now and give internal feedback on current systems and workflows.
Plus, use assets to make it happen. On very small team. If you are a team of 25+ it will be good also..but will show that most likely, solo devs/2-3 people teams, won't be able to do this. So aim 5-10 people or less .....
''get creative with nothing/feel the constraint'.

 

I think there are two games that could be made here:

Game A -
Genre: Any mainstream genre (FPS, TPS)
Platforms: PC and major consoles
Art Style: High quality refined visuals; basically HDRP
Team size: I'd say A - AA Studio sized
Focus: Regular content, community, and most importantly... fun!

Game B -
Genre: Anything that's not game A; weird indie anything
Platforms: Same as above
Art Style: Unique and creative. URP obviously.
Team size: Small indie team
Focus: Being different; exploring new ideas; and also fun

Idea being both games would stress test HDRP and URP but also use a large swathe of packages provided by Unity. I'd also expect all the main useful packages to be used. Addressables, New Input System, UI Toolkit, etc.

Obviously no packages outside of Unity. (No Odin Inspector!)

I want to say A assuming that includes stables versions of the aforementioned packages with the hopes that glaring faults can be found and fixed in future releases.

I will say I don't know if this will actually be of any benefit, and of course this whole thread is purely hypothetical. But it's a fun thought experiment.

 

I have a better idea actually.

They should make a game in Unreal instead.

 

Can be B But only when you promise that custom features are going to be in the engine.

And later the same game in Unity

 

Only if EpicGames also makes a game in Unity.

 

My vote is on the "don't", unless there is a serious chance to become successful and could rake in money without exploiting either players or developers.

 

That's a reality show I would watch.

 

A and B.
A to improve the workflow, pipeline and out of the box assets of Unity.
B to expand what is possible with Unity pushing the boundaries.

A would be a modern most popular game style genre platforms e.g. Fortnite.
B would be to explore what future games with Unity can do e.g. Crysis.

Then the support developers and the tech developers can both work on a game.

 

For real; id be curious to know your actual answers to the questions!

 

What do you mean by 'exploiting players or developers'?

 

Devs and Studios have already have a direct line to Unity. We have several support teams who visit studios frequently to gather feedback/experiences/data to process and share internally.

 

That's widely known and a good start! But it doesn't adjust the direction Unity takes when choosing what to work on in the engine. It just band aids *existing* Unity decisions.

There's a very big difference between making long-term decisions that would affect your bottom line in a live ops title vs not really having ANY responsibility other than fixing bugs and taking note of pain points that again do not change Unity's overall direction or engineering.

It just means when Unity wants that to be actionable, 100 other things came first, or there's no-one available to do that job. That sound familiar? well because that's what "direct line to studios" does instead of managing a live ops game you made yourself for profit.

There is zero skin in the game.

 

Don't get me wrong; I agree with you! And im fully aware the differences.

I was just highlighting that there is plenty of information and feedback from external studios (and recently unannounced internal production studios who are currently doing many things listed in this thread; more info on that soon... ). The core question is prioritisation on what to do with the feedback and direction to go in and where the investment should be.

 

And I know you know, honestly I do, which is why I like to kind of spell it out. It becomes referable and easier to explain a point for many.

 

If there has been plenty of feedback, and I believe there has been, then obviously the problem is somewhere else and it won't be solved by making a game.

The sentiment behind forcing Unity to make the game is a vindictive one, users want to punish you, to force you to use the same terrible software we use every day. But if there are no stakes behind it, it will just be cancelled before it's finished, exactly what happened with the open project.

So, in order for Unity to become a better engine, I don't think making a game is the solution, the problem is elsewhere. Where exactly, I don't know, and at this point, I don't care.

On the other hand, my idea of turning this into a reality show is pure gold.

Make a team comprised from department heads and executives, make them make a game that will release multiplatform and sell for 25$ dollars. If they don't manage at least a 85 metacritic they are fired.

All the time have a film crew with free reign to shoot and edit the process and then release that as a reality show / documentary.

 

OK B to expand what is possible would arguably be better time and effort applied than A.

 

As someone who's deliberately avoiding their DOTS project because of the seemingly random errors I get (from things like standard GO-Entity conversions, to Jobs errors from interfaces I'm not even using (IJobParallelDefer?), to unknown Burst call stacks), it might be cathartic to see Unity tackle that themselves.

I'm generally on Unity's side in these threads and find the hand-wringing about Unreal quite silly, but abandoning the open project and saying "there's nothing more to be gained from this" is pretty bad. Just finish something.

 

Thank you for your honesty!

 

Post mortem - what went wrong.

 

What the words mean. No 60 hour work-weeks, crunching until their nose bleed, impossible deadlines or "just get more bodies"-attitude. On the player side, no whaling, excessive microtransactions (preferably none at all) or crypto-BS.

 

The reason why it's a better decision to buy an already established AAA studio at least Guerrilla Game's level (please - no indies) is that you don't waste millions experimenting and figuring out how to form a proper award winning AAA studio.

Imagine if you tried to the sell the idea of Unity trying to form their own inhouse weta from scratch? It's comedy isn't it? That is why you buy the ready made leader in the market you want to enter or dominate.

Hit the ground running. Lots of good angles to this.

 

How about adding MIDI support first.

 

haha, why do you use a program you do not like?

 

Unfinished projects I do not wish to port.

 

Okay but the thing is, the real S*** that is actually one of those things that infuriates me?

We've been giving this sort of feedback for ages. In fact, there's been multiple threads about how Unity needs to "eat their own dogfood" and how that's ultimately a fool's errand. We've all said for quite literally years that feedback in general seems to go absolutely nowhere with Unity. I know I've trotted this out in the past, but how in the world did the "Improved terrain system" suggestion on the old Feedback site exist for nearly a decade and the only improvement we ended up getting were some pretty meagre changes to the old heightmap terrain?

I bring this one up in specific because the Feedback post was quite specific: people wanted a new terrain system that would allow for things like overhangs and caves that did not require the use of a separate modelling program. They wanted a terrain system that functioned similar to the one that had become the norm in CryEngine around 2008-2010 or so because it would have solved many of these issues. This was one of the top three voted suggestions since it was added to Feedback ages ago.

We never heard anything about this.

When UGUI was in development and the first hints of the canvas stuff was coming out, people mentioned that they wanted easy ways to script things, many suggesting some sort of markup language support that was pretty common in industry standard UI tools. This didn't happen, of course, and we didn't get any hint of markup language UI tools until UI Toolkit/UI Elements became a thing.

People have been asking for better support for custom image effects in URP. I haven't even bothered keeping up with that at this point because it feels like by the time we actually get something that doesn't require us to go to some third-party tutorial/training site that has half its API references out of date, the sun will be about to explode and engulf the earth.

I bring up these wide ranging examples across a fair few years because I want to make it abundantly clear that this is a historic problem with Unity's development. Unity isn't like a game where players asking for disparate and conflicting gameplay features can throw the balance of the whole thing out of whack, but a creation toolkit that seems dramatically more interested in back of the box features than making those features actually work reasonably well.

Another thing I've brought up is how the Feedback site getting the axe was more indicative of how Unity is not as interested in feedback as they claim, and the way this has continued makes this clear. It feels like we are less giving feedback and more giving bug reports because that's the only thing that ever gets any answers. So I have to ask...

Why should we think our feedback is at all being listened to?

 

I think you could add backlash about removal of Beast to the list. Can't say I personally witnessed it, but I saw the echoes.

 

They should make Unreal as 4th render pipeline in Unity.

 

Tell me if these nuggets I've gleaned are true.

Unity is:
Publicly traded company
Makes primary revenue from advertising and other non-game dev areas
Unity is likely to earn more money from asset store sales than game dev success stories

If at least two out of three of those are true I think everybody here can answer questions like this on their own and leave the poor community management employees alone.

 

Back to the game...obviously it has to be an open-world 3d networked multiplayer game. It works for most developers and for most audiences.

And obviously Unity could make a lot of money in that space.

 

Two of these are problems from before Unity was publicly traded (a recent development) and they've gone on record as saying that their primary revenue isn't Asset Store sales. On top of that, these are just three examples when the list is basically a laundry list.

Beast I at least somewhat understand because support from Autodesk was limited at best and I believe they were changing the license requirements around it.

Now Enlighten was a real debacle because the people in charge of Enlighten's licensing fired back saying that they were willing to work with Unity to continue licensing but Unity was the party that decided against it.

 

1. I don't care too much, maybe a battle royale.
2. Mobile is definitely needed, but do similar for PC, VR, Console, etc.
3. Everything from the Asset Store. See how that works out first hand.
4. As small as possible, preferably one person as you have so many customers like that.
5. Fully Featured. Complete. Released.

On mobile it would mean a game with multiplayer, ads, IAP, analytics, leaderboards, cloud saves, privacy settings, native features, etc. This all has to go through approval on the iOS and Android app stores, and updates (new game feature releases, but also Unity versions, major and minor), plus dev machine changes.

There is a saying that the first 90% of a game takes 90% of the time, and the last 10% takes 90% of the time. It refers to all those final tasks being more of a pain than expected. It feels even worse with Unity, where it seems like it is 90% of the game takes 10% of the time, and 10% of the game takes 90%, but Unity's own projects seem to focus on the first bit.

 

I think option B would also be a good opportunity to work on improving the DOTS integration as Unity now has two disparate systems that could work more cohesively if the API was designed that way.

Also a large living open world might be ideal to show off the potential power and performance of DOTS on modern hardware.

 

Option B.

The goal should be to solve difficulties faced during development by modifying the engine, using an LTS wouldn't do much beyond bug fixes and wouldn't be much different than partnering with an external developer: they wouldn't be able to do anything about UX, pipeline or more structural performance issues which could benefit the project (all those would be added to a backlog and only materialize months or years later).

For example, to this day there are several obstacles to doing hitch-free streaming in Unity. All high profile games which do it, like Inside and the Ori games, use source code modifications that apparently never made it back to the engine.

 

A. To see where the existing pain points are that don't go away.

 

that is exactly why using LTS is a better option. Using a stable version and tools = faster (and solid) development

 

How many of those contribute a dime to the Unity Pro or Indy coffers? I noted you listed pain points. None of those are Unity's business..leaders boards..in-app purchases. There are many third party API's handling those. If they are not well integrated it is not the fault of Unity..It is the people who thought making the API like a C# enterprise API at fault usually.

Unity should stick to making a framework to build the interactive3D world and the toolsets should be generalized to creating that content. Games are a slice of that but in my years contracting for Unity the long term payers were not games. Those 100+ contracts..if they ever got initiated (game idea guys love to yak but when it comes time for the John Hancock or paying an installment they can be scarce as hen's teeth) were about 25% of the content types I was asked to produce. Somehow..some way..I always managed to finish those with all these project squashing and years killing bugs this thread is rife with. May be that if I didn't I would not eat. There is an urgency to the experience of an empty belly that cannot be appreciated till experienced. That does not mean that I have not had my share of run my head into the wall issues and unfixed bugs, but as the old saying goes, there are more than one way to skin a cat.

 

We should not answer those questions in that way as to what would be the most annoying but in what'd be the mostikely to actually yield improvememts on the published versions of the engine.

If they were to use LTS versions, whatever Feedback those devs give the engine people, won't benefit the game devs since they are stuck with LTS which may only receive bugfixes and stuff like that. So the motivation to report in detail would be low.

Therefore I'd vote B and go with newer versions and constantly update - that has better chances of improving things if you ask me.

 

To yield improvements they have to be willing to make said improvements.

Remember how editor iteration speed was pretty terrible, even Unity acknowledged it, made a blog post about fixing it a few years back, and it still is getting worse with each major release?

 

I've seen it sit at various stages of the startup/in-editor compile process for literal minutes at a time sometimes with the 2020 LTS.

 

I add the new Input System feedback request to your list of examples. We were asked for feedback, gave a bunch of it, and the response was just to mark it as released - I think as it was? Development then slowed to a crawl, and long known issues are unfixed when I last checked.

 

Following up my previous post, though, I think that feedback probably does get listened to by developers, but they don't have the authority to act on it.

When I gave feedback on the Input System it was essentially "I just ported a large game over to it, here's what still needs work". A (good) developer would focus on the latter half of that and figure out how to make it better, but my hunch is that a manager or exec looking at it would focus on the first bit. "That guy says he just successfully ported a big game to it. Sweet! It must be good then!"

Guess who's making the decision about what the devs get to spend their time on?

Either way, it's not getting acted on reliably or sometimes at all. And I've previously given constructive criticism about how they gather info. (Eg; highlighting the time they asked how we learn to use new stuff and didn't list their own docs as an option. No wonder they're not getting the attention they need if they're not even being considered for evaluation!)