Looks like Unitys CTO has been replaced

Please make your own thread if you want to ask about specific issues, rather than hijacking my thread. This is specifically about the topic in the title of the thread, which at this point has been answered and has nothing to do with the package manager. Thankyou :slight_smile:

6 Likes

The broader issue is that this same claim has been made what feels like dozens of times at this point.

1 Like

And it’s entirely possible, perhaps even likely, that it’s been true and valid every time. Continuous improvement isn’t a thing that’s completed and stopped, it’s continuous. I would hope that there are improvement projects being both kicked off and completed on a regular basis. That’s a good thing.

I’m talking about how these things are never actually reflected in the engine. All these backend changes don’t actually mean anything in the face of things like “Unity adding features that would barely be considered betas anywhere else and calling them production ready” or “Unity’s documentation completely slipping in quality for years” or “Unity’s base feature set languishing due to not actually getting updated, instead getting replaced outright with the aforementioned barely betas.”

These things aren’t true and valid to developers.

1 Like

Yeah, I get how it feels like it’s been heard before.

I remember that when we first moved to packages, faster iteration time was one of the benefits we described - and it was true, at the beginning! In the very early days of ECS, when we were still working with a hand-picked set of customers on a private basis, I remember watching a customer report a bug via our Slack channel. The bug was reproduced, the issue was fixed, a test was written, the change was committed, pushed, and a new version of the package was created as a TGZ and provided back to the user - in 15 minutes, start to finish. It was glorious to watch. However, as projects grew, as more users adopted things, as more dependencies were created… things got slower and slower. It’s easy to be fast when you’re small; it’s hard to keep that speed when you scale up, especially when the slowdown is happening gradually (the whole ‘boiling a frog’ concept).

On the topic of improving core functionality, though, let me share a concrete example of the velocity change. For the past few years I’ve been focused on the internal systems upgrade that I mentioned, but I still try to land small improvements to the engine on a regular basis, partly just for the sake of improving it, but partly to stay in touch with what the experience is like for developers.

Last summer I landed Transform.SetLocalPositionAndRotation(); I committed the API itself (plus functional tests, performance tests, and documentation) and opened my pull request on August 25th, and it landed into trunk on September 7th. So, 10 working days to land a very small API change.

Fast-forward to January 2023: I introduced a new overload for GameObject.CompareTag() which takes a “tag handle” (about 2x faster than passing a string, and 10x faster than doing .tag == "blah"), again including functional tests, performance tests, and API docs. I opened my pull request on January 24th, and it landed into trunk on January 30th, so 5 working days. That’s still about 4.75 working days too long IMO, but a 2x improvement is a great start, especially considering that I was multitasking with other things. (As I mentioned before, I did also fix a bug in the buildcode for the Editor last Tuesday, and it was in trunk the next day, so things can be that fast).

You could argue that our development velocity doesn’t directly impact quality - “it doesn’t make bad code good, it just gets bad code into trunk faster” - but it’s a widely observed effect (e.g. Boyd’s Law) that at the system level, faster iteration times result in a net improvement in quality. People have less incentive to make large batches, which means code review can be more focused and changes are more quickly available internally for QA; landing things quickly means developers have fewer in-flight pieces of work to mentally juggle; and so on.

It will take time to see the effects, and I’m not claiming that fixing velocity is going to fix everything about Unity - there’s plenty of other things we need to solve (I predict you’re thinking “that’s nice but improvements to the core APIs should be more than a matter of one engineer doing it as a kind of spare-time thing”, Murgilod, and I agree with you :)). But speaking as one of the many engineers trying to make the product better, I do think it’s a step in the right direction, and one worth celebrating.

Re packages: we’re aware that the velocity problem is not limited only to the core Editor codebase, and there are things we are exploring around improving velocity there as well, such as the change we made to the way the Graphics packages are developed . While I know there have been some downsides to that change, you can read in @AljoshaD 's latest post in the thread that it has been very effective for our velocity, and has also made it much simpler for us to work on levelling-up the automated testing around the packages.

33 Likes

ohhh, so what has happened is that Unity now has faster internal dev, or update - efforts, and perhaps everyone is going to also benefit when we get features that are both better, and faster, and also bug - fixes, alright this may be important news, and an even better reason for learning, or making content also in Unity engine, that’s also sort - of cool . . .

for me, as someone bit on the indie - side, the important thing is that the engine stays that way, or it’s almost easier to make stuff in Godot, or other grass - roots engines, or there are a few that are mostly open source, not something a corporate engine can do, also over licenses to third - party technology, however that’s one of the advantages of the more commercial engines, that one gets the best // industry - leading also ’ tech ', or features, overall quite happy with the Unity stuff, except perhaps the recent IronSource - merger, overall wasn’t looking to add, or even think over half - blatant monetization, part of the fun of making video - games, or taking-a-break from reality, or the also corporate world is to make video - games, maybe indies need almost ’ help ', or to be half - flogged to make money, bit lol, however looking at the stuff now the engine is perhaps more monetizable, however less-fun, and releasing a title, or at all product in Unity now feels a bit ’ cheap ', or perhaps bit more ’ CEO ’ than was ever looking to, it’s also a problem for people that have invested years, or a ton of learning in Unity, that they can’t just fast - migrate to another engine, however after thinking about it, think it’s a bit weird move, however that the leaders, or people that understand the dev - market better, perhaps adding this feature, or extention to the software is actually for the better, or the average Unity - dev almost needs help to make more money, or it’s perhaps either upsetting, or ’ weird ’ that devs working over Unity aren’t better at monetization, not sure overall it was for to benefit the fans // different devs that work in Unity, however it’s bit like adding ’ loot boxes ', and over how much think money the stuff cost, it’s almost like sending a message to most devs it’s also time-to-get-greedy, or it’s almost big-sell-out day, and that goes bit against video - games, media, or art being made for fun, and to specifically ESCAPE that feeling, or ’ corporate ’ world, at least that goes for me, it’s break from the hum - drum, or where people are ’ free ’ from the various realities, or life - pressures, now it’s like the ’ un - fun ’ part of life is a pedigree at the Unity - engine, and that’s perhaps why thinking bit over finding another engine, despite Unity overall being amazing // feature - full, and bunch of other stuff . . .

Let’s put this to a test. Ever since the Terrain Tools have been introduced there’s been the critical bug (my personal classification) in the Unity Editor that once you click the terrain gameobject all heightmaps are being loaded into memory.

Here, this is how it looks like:

100000001248582--1209354--memory.gif

Have 25 heightmaps as brushes in your project, click the terrain gameobject and bang out of memory crash of the Editor only for selecting a gameobject, you lose all your unsaved changes. The fix should be trivial, show only the thumbnails in the Editor, load/unload the heightmaps per instance when you use them.

Here’s a ticket:

https://unity3d.atlassian.net/servicedesk/customer/portal/2/IN-21309

It’s been completely ignored by Unity.

I don’t see improvement of core functionality, nor velocity change. The ticket system and classification definitely needs improvement too. I’m pretty sure the devs would fix this, but it seems like the ticket got lost.

10 Likes

Eh, I could cherry pick positive examples, e.g. my Editor used to crash multiple times a day, but now I can’t remember the last time I had a crash. The engine is huge, and everyone’s experience will be different depending on what parts we use, what we do with them, target platforms, etc. etc. Individual examples don’t prove anything, and superpig was already clear about the fact that this round of improvements is too recent to have had direct customer impact yet.

4 Likes

This happens more than I can count, since Unity 5, I have tickets, that get no reply or ones that are months later… with finally a replies that are not helpful at all…

2 Likes

It is really difficult to read your wall-of-text posts as they mostly are rambling, with extreme use of punctuation in places it shouldnt be. Its just honestly difficult to read, and I think that is why everyone is mostly ignoring your comments here and in most threads.

I really recommend trying to condense what you are saying down to a few sentences, and use standard grammar and punctuation instead of “…” all over the place and other punctuation just used randomly everywhere.

If this is a second language barrier type issue and english isnt your first language, you would be better off using auto translate.

4 Likes

#thx, high - func autist, think bit in terms of code, or symbols . . .

1 Like

I can see this is in your signature - it used to be possible to display signatures at the bottom of all your posts. I am not sure if the forum still supports this, but if it does that would be a good option to use to increase positive engagement with your posts :slight_smile: Knowing that information absolutely changes the way I would read your post for at least

1 Like

It is visible, providing I understood what you meant.
8867166--1210299--upload_2023-3-10_17-41-1.png
But it is not visible on the mobiles, at least in my case.

Srr for off-topic

1 Like

Or ChatGPT. :stuck_out_tongue:

8867370--1210359--upload_2023-3-10_13-28-57.png

8 Likes

wow that is amazing. I feel like i agree wholeheartedly with the post now that I can read it :slight_smile:

2 Likes

It has been reviewed and closed as wont-fix (back in December) because the team do not agree with you that it’s critical, and they are focusing on other things. I get that it’s not the outcome you were looking for but it’s not reasonable for you to describe that as “completely ignored.” (I don’t really have an opinion either way on whether the bug actually IS critical or not).

It did take about a month for QA to process the incoming report into a bug, which is not good, and clearly a symptom of a place where we still need to improve velocity. I can’t speak to what we’ve done / are doing there as that’s not my area of focus.

The improvements I have been involved with will help the developers get the high-priority things resolved more quickly and give them more capacity for addressing lower-priority items, though, so we should hopefully start to see fewer issues get resolved as wont-fix.

EDIT: Just realised that the incident report itself didn’t get correctly updated to reflect that the bug had been closed as wontfix, so if you didn’t see the bug it was converted to, you might not have realised that it had been processed and it might have looked to you as if it had been ignored. If that’s so, my apologies - that was an automation failure which is now being investigated.

6 Likes

I get people hitting this bug on a daily/weekly basis in my support channels. This is because people who buy MicroVerse often buy stamp packs, which contain hundreds of stamps at 4k each, and install them all into their project. Then clicking on a terrain loads 4gb+ of data or more, often crashing their systems, and they assume it’s my code doing it.

Crash bugs which are easily reproduced in common cases should not be ignored like this. It’s easy to repro, the cause is clear, and it’s very easy to deal with by either virtualizing the control, or virtualizing it and having it generate preview versions instead of loading a 4k texture to render a 64x64 preview.

The work around to this is that stamp packs can no longer include brushes for the unity terrain system, otherwise they will crash users machines. So basically, if you want Unity not to crash, you can’t produce large amounts of content for the built in tools, because they are so badly written that they can’t handle large projects. Again, trivial to fix, but Unity is basically saying they don’t care if their tools work under actual production environment scales.

20 Likes

Actually this is a critical bug. I have no idea who categorized this major bug as not critical and “won’t fix”. The bug makes you literaly run out-of-memory and therefore crashing the editor by selecting the terrain gameobject in an otherwise empty scene. Sorry but classifying this as “won’t fix” is madness.

6 Likes

As I said, I don’t have an opinion one way or the other on the criticality of the bug - in general Unity should never crash, yes, but I also don’t know what other bugs are on the Terrain team’s backlog, or whether it is actually sane for people to be using 4K brush textures in the first place, as I’m not a terrain guy. The best thing to do I think is to go leave comments on the bug and see if we can get the dev team to review the case, as things like the “big pack of 4K brushes” scenario might be the sort of thing they’d not considered.

3 Likes

Great post! You should be the translator for unity’s blog posts. They’re always written in some form of ancient demonic wizardry, I believe it’s called “HR speak”. Often it can incite anger, frustration, and a feeling of estrangement. and these are only some of its more known evil abilities. Extremely frightening.

4 Likes