Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What Unity Is Getting Wrong

garry.tv

Post reply on HN
Print view View original

281–290 of 306 posts

Re: What Unity Is Getting Wrong

#281

Post by kbenson »

drawkbox wrote: post #275
kbenson wrote: post #238

Earlier quoted context omitted.

> More engineers doesn't mean a better product. But it often means higher overhead...

... and alot more communication needs, testing needs and maintenance. It also pulls the company in many directions if there is no clear engineering/product lead at the top and it is all management/business/finance pushing feature based development which gets them into version 2 syndrome. [1] > The second-system effect (also known as second-system syndrome) is the tendency of small, elegant, and successful systems to…

> ... and alot more communication needs, testing needs and maintenance.

Yeah, I was sort of including that in overhead, of a non monetary sort, in my own head. There are valid reasons why FAANG companies are so big on teams and team size and managers and reorgs, etc. I imagine one of them is it makes it much easier to switch expectations and focus and projects easily when stuff starts going off the rails (which you can always expect it too with so many people and departments with slightly, or very, divergent goals).

> let the engineers/product people have power to set this back on course.

Careful about wishing for engineers to have too much say. Some of the biggest (business) blunders have been because the engineers went and built something magnificent (or attempted to), but the market and sales people didn't know how to sell it (or it wasn't what the customers wanted).

Sometimes that comes out okay for the rest of us in the end as it spurs innovations and other companies to (eventually) do the same, but it's bad for companies when it happens.

Although you probably know that, and that's why you said engineers/product people. :)

Re: What Unity Is Getting Wrong

#282

Post by martinpw »

jandrese wrote: post #75
hosh wrote: post #28

I support CI for my team's Unity builds. I don't know much about the engine itself, but I can tell you that the tooling for automating Unity builds really sucks. I had a long list of reasons why, but my impulse blocker cut me out. Oh well. Here's a much smaller list: - You have to jump through many hoops to run Unity in headless mode - I cannot separate out build processes into discrete stages - Linux version is behi…

> - License server is unreliable. It always goes down with a 500 error, every day for most of the evening (California time). That means I cannot easily elastically scale build servers. This should be flooding their support center with open tickets. Completely unacceptable. The worst part is that it shouldn't be hard to fix. The longer it goes on the more the Unity folks look like clowns.

We certainly reported it several times a couple of years ago before we switched to Unreal. Amazing and disappointing that it is still unresolved.

Re: What Unity Is Getting Wrong

#283

Post by fxtentacle »

winrid wrote: post #241
fxtentacle wrote: post #139

Earlier quoted context omitted.

Because there is excellent tooling for C++, while they had to reinvent all the tools from scratch for UnrealScript. I believe that ReSharper C++ alone makes me 10-20% more productive. Their refactorings and inferred constants are amazing and produce real-world performance benefits. Plus having const wherever it is warranted makes code easier to read and easier to debug.

Why ReSharper and not CLion?

Mostly habit. I started using ReSharper long before CLion was introduced.

Re: What Unity Is Getting Wrong

#284

Post by Vulphere »

hosh wrote: post #28

I support CI for my team's Unity builds. I don't know much about the engine itself, but I can tell you that the tooling for automating Unity builds really sucks. I had a long list of reasons why, but my impulse blocker cut me out. Oh well. Here's a much smaller list: - You have to jump through many hoops to run Unity in headless mode - I cannot separate out build processes into discrete stages - Linux version is behi…

> Defold

It is not truly open source since there are restrictions for commercial purposes.

https://www.gamingonlinux.com/2020/05/cross-platform-game-en...

Re: What Unity Is Getting Wrong

#285

Post by pjmlp »

kbenson wrote: post #237
pjmlp wrote: post #228

Earlier quoted context omitted.

That is the old model, the new LTS model is three years. Oracle just extended it due to Java 9 being our Python 3, which is kind of pointless because all the packages that matter have migrated already. But enterprise being enterprise, there are plenty of projects only now migrating to 8, and then there is that little robot that isn't even fully compliant with 8.

Not that I really know much about Java stuff, but it looks like maybe Amazon/OpenJDK are providing longer support lifetimes? [1] And here's an official Oracle doc regarding Java support where they show Java 11 (LTS) being supported until either late 2023 or late 2026 depending on your support level. I'm not sure they provide free support anymore, or maybe that's limited and what you're referring to? 1: https://en.wik…

Yes, free support is only three years.

Java has several commercial and free implementations, so every Java vendor is free to choose their own timelines, I was only talking about the free layer of OpenJDK/Oracle, as that is what many around here understand as Java.

Re: What Unity Is Getting Wrong

#286

Post by pjmlp »

rr_aa wrote: post #90
ohgodplsno wrote: post #61

Earlier quoted context omitted.

>I've also heard that you can't really do everything for an entire game in just blueprints. I wouldn't do networking in blueprints. But for your core gameplay ? It can absolutely do anything you want.

You can do anything you want if you are into managing a huge spaghetti node system. Sometimes its more efficient and especially flexible to be able to write code, and easier to maintain, update and edit.

Same would happen with code if best practices aren't taken into account.

Blueprints provides the tooling to package stuff into re-usable components, exactly to avoid spaghetti code, just like in most graphical programming languages.

Re: What Unity Is Getting Wrong

#287

Post by shafyy »

skcode wrote: post #262
shafyy wrote: post #194

Earlier quoted context omitted.

We're using GDScript and like it a lot. I find that I'm much faster than with C# and haven't had any performance issues yet. The good thing is that you can mix and match languages as you like. So you could write 99% in GDScript and there's something where you really need performance just write it in C++, Rust, Python or any other language you want. It looks like that they're re-working GDScript for 4.0, so that'll ge…

I've used Unity and Unreal Engine 4 for a while I don't think i'll want to switch from UE4 for 3D based things i'm pretty excited for Godot 4.0 and all the new nifty features I've been hearing about. Does it make sense to hold off diving into Godot until 4.0 (for 2D-based things) or will there not be too much to "relearn"?

I'm not a contributor to Godot, but my understanding is that Godot 3.x projects will be mostly compatible with Godot 4.0, and where conversion is needed they will provide tools.

Therefore, I assume that the fundamentals of Godot will stay the same and you should be fine diving in with 3.0 already :-)

Re: What Unity Is Getting Wrong

#288

Post by animal531 »

klmadfejno wrote: post #157

I'm a hobbyist game dev. I picked up unity one day and just started making stuff, learning C# on the fly. I'm not great but I can do what I want. I was really interested in Quixel for Unreal so I spent the first half of today trying to learn it. I think I'll be going back to Unity. Unreal did not feel approachable at all. I'll probably keep trying for a couple days... but yeesh.

You can use Quixel scans and materials in Unity as well.

Re: What Unity Is Getting Wrong

#289

Post by sloopy543 »

johnfn wrote: post #257
sloopy543 wrote: post #217

Earlier quoted context omitted.

I don't actually think it's that hard once you know how to do it. You basically make a cross-platform C library that generates the GPU commands and sounds per frame, then you just plug that into whatever platform you're running on. My Mac Platform code is only like 1500 lines or so. Pretty small considering that it runs a 2D game full-screen on my iMac. Not sure what is meant by 'Herculean'. Once you know how to do i…

> Not sure what is meant by 'Herculean'. Once you know how to do it, you don't lose that knowledge. You literally have the code to use on the next project. No big deal The problem with this is that even if your code is 100% bug free and works perfectly, new platforms are created all the time. The PS5 is coming out in a couple of months - does your crossplatform code target that? Unity does. How about the Switch? How…

I would encourage you to check out Casey Muratori's Handmade Hero. I believe he does a nice job of separating platform-specific code from non-platform specific code.

My engine is based on his. It has a cross-platform library that only handles the game logic itself. Each platform has its own thing called a platform layer that handles the platform specific aspects of the game (things like setting up a window, setting up a sound buffer, getting a basic communication channel to the GPU on that platform, etc)

Once you've got a few basic platform layers for each platform you intend to target, you just update them every now and again as needed.

Also, you don't need to make your thing cross-platform right away. Just do a basic separation, knowing you will come back later and make it work for various other platforms.

At the current stage of my project, I'm just exploring the space and nowhere near shipping. All of the platform porting will come later, once I know I've got a unique product that will sell

Re: What Unity Is Getting Wrong

#290

Post by sloopy543 »

TeMPOraL wrote: post #249
sloopy543 wrote: post #89

I'll just sit back and eat popcorn as I work with my custom handmade game engine. None of this is a concern for me, and it has been refreshing to work directly with the graphics pipeline and in lower level languages that give me direct control. If something is wrong, it's my own damn fault. For those who want to get away from being totally dependent on third-party frameworks and tools, check out Handmade Hero. It was…

I've made a bunch of half-finished engines in C++ and Common Lisp over the years, my problem is that I always end up bikeshedding the architecture instead of writing a game. And since I do it in my time off, life eventually intervenes. E.g. this time around, between a new job and a pandemic, I don't have the headspace to think about my little experimental Roguelike I've been developing over the past year (which BTW.…

I definitely relate to the bikeshedding thing. I like what someone from Nintendo once said.

"You're making a game. The engine is what's leftover when you're done."

I like to think that way as well.

Sure, I have a laundry list of things to do, but it all starts with a gameplay idea that I want to explore. I force myself to justify all development efforts by way of serving the gameplay ideas.

That way, you're making a game first and foremost and the "engine" is the tool you make to make the game.

Post reply on HN