Context menu key is kinda essential for navigating without a mouse. I don’t use it all that often but I am very glad it is there.

Yep, it is mostly apparent in big companies I would say. I could go on and on, but basically your work is so disconnected from the final output that what end up actually “mattering” is a bunch of made-up bullshit. Putting in quality work and improving your product/service does not benefit most of the people you interact with directly, unless of course you’re working on the popular thing that will get people promoted.

Anyways, I also left the corporate world to start my own business. Life is so much easier when all you need to care about is the quality of your work and not political points. I like my hard work to rewards me, and not just some guy spending his days in meetings claiming credit for “his” “initiatives”. Some of those folks would never survive a job that isn’t a mega corp paying them to improv all day in meetings.

Why bother with NP++ if you already own sublime, which is arguably equivalent or better, is my question. I use Sublime and I am wondering what feature could be missing to justify still having NP++ installed.

Genuine question, why use both Sublime and NP++?

This but non-ironically.

Who on earth would rely on a game engine in bankruptcy?

They aren’t nearing bankruptcy first of all, and I as I mentioned even in this doom-and-gloom scenario they would likely just get acquired and operations would continue as normal. Is that what you think? That Unity is about to go bankrupt? I am not sure what we’re arguing here.

Engines need a constant conveyor belt of new games to sustain their revenues and I don’t see this happening.

What are you basing this observation on? Unity never made money from the volume of games released using their engine. Also, the part where everyone is suddenly dropping Unity is mostly just a narrative here on social media, and the bulk of the reason why it might not be happening is that there is no true alternative.

And yes there is pain and a learning curve to moving to other engines though I think most programmers would be able to cope with change and if they’re that incurious and inflexible that they can’t then maybe it’s time to find new programmers

It is not about coping and being incurious. Changing engine means trashing a part of your team, trashing your content pipeline, trashing your internal tools. It costs a lot of money, money which most studios don’t have. It would make sense if there was a true alternative to Unity for those mid-sized studios, which there isn’t.

As for Godot, I am sure it is not a 100% feature for feature replacement for Unity. But it sure as hell is capable of powering 95% of indie games out there no trouble whatsoever and I daresay some more challenging titles

Again, not sure what you’re basing those numbers on. Godot can’t even do consoles natively so there is definitely some troubles and headache in using Godot in 2023. I would agree that Godot is perfectly fine for solo devs and very, very small teams, but it is not a serious alternative for even mid-sized productions. It is still pretty much a toy compared to the bigger engines, and it lacks commercial support to really attract those studios.

I get it. The popular sentiment here is that Unity is doomed to fail, and the internet as a whole kind of wish it did. I am not gonna gather sympathy and votes by saying otherwise, but I just don’t see it. Godot is not ready, switching to Unreal does not make much sense since it is the same proprietary “garbage”. It is easy to make big statements here on Lemmy and claim how easy it would be for game studios to get rid of Unity, and how this would improve their business, but to be honest I don’t think you guys have a clue. If you are actually a developer or own a game studio then I am sorry for assuming.

Unity is not going anywhere, even in a bankruptcy it would get acquired by the likes of Microsoft or Meta. The “good guys startup” Unity is long gone, and it’s been replaced by the same corporate structure you would expect anywhere.

Tying yourself to Unreal would be just as naive, and Godot is nowhere ready to fill the niche Unity is filling. I would place the opposite bet as yours, the vast majority of actual game devs are not rich enough nor care enough about corporate drama to ever switch engine for possibly worst. Also, experienced C# Unity devs and experienced C++ Unreal devs are not that interchangeable. Unity made this move to survive and they know there is no true alternative.

This is my pov, I worked in the industry for over a decade and I am an Unity ex-employee.

The only thing that is more water than water, Cors light. But now, really I’d prefer to drink my own piss, since coincidentally enough, Cors Light is also one of the few liquid that is more piss than piss.

I read the Tweet, it does not “show” that the account had purchased games. This has been Ubisoft’s policy for years and there is no record of deleted account, except for a random tweet.

This is misleading and ragebait. They only delete old-ass accounts without purchased games, and this is a compliance thing with European laws.

It certainly adds up, and it makes maintaining the databases more complex and costly as a whole.

Imo this is just lazy, they could at the very least “archive” old accounts and move the bare minimum data out of the main DB, as to make it possible to reactivate the account later on. Why can virtually every platform keep old account arround, but not Ubisoft?

What you seem to be describing is one big module with lots of responsabilities, and not circular dependency. Personally, I don’t think it is ideal, and I don’t know about your specific case so I could be wrong, but I have never seen a legit case for bloated classes. That being said, making a big class is still much better than splitting it into inter-dependant classes. Classes that know each other are so cohesive that they might as well be the same module anyway.

To add onto the circular dependency problem, it is not just about readability and cognitive load (though there is some of that), but cyclic dependencies actively break things, and make it much harder to manage the lifecycle of a program. No dependency injection, poor memory management, long compile times. It is a huge hack, and I understand that you think it can be the proper solution sometime, but it is really just a bad thing to do, and it will bite you some day. And I am assuming here that you’re using a language that is friendly, in some languages you won’t even compile past a certain point, and good luck cleaning up that mess.

It does not get more complicated to split your example. What gets more complicated is giving all sort of unrelated responsabilities to a single class, simply because it is the path of least resistance.

In your example, all you need is an extra module listening for configuration changes and reacting to it. This way you leave your context-specific logic out of your data model, no need for cyclic dependency. There are so many downsides to cyclic dependency, to justify it because splitting your logic is “too complicated” really isn’t a strong argument.