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

291–300 of 306 posts

Re: What Unity Is Getting Wrong

#291

Post by johnnyanmac »

sloopy543 wrote: post #218
enumjorge wrote: post #103

Earlier quoted context omitted.

Once you know how to do something, it’s easy to forget how much time and effort it took to get there. Making your own engine comes at a cost, and if you’re an artist or new to development, it’s a pretty high barrier of entry. Unity initially presented a good value proposition. You lose some control, but the engine will do a lot for you. Even for experienced devs this meant saving time. And I think Unity got this popu…

For context, it took me about a year of learning in my spare time to get to place where I could do my own cross-platform game engine, and some of that time was spent doing the code for the game itself. What exactly is the expectation here? Would it have taken that much less time to learn the little nuances of Unity that folks here are complaining about? Also for context, my full-time job is demanding, and I have a lo…

big difference is teams. If you're fine working by yourself, then an engine where you have 100% knowledge scope is great.

The moment you introduce another dev or artist or any individual that needs source access to work on your game, you'll probably have them hitting every pain point mentioned in the article and more. Why's your UI buggy (or does it even exist?), why's rendering this thing slow? So time is spent teaching them (and there's likely zero help on the internet unlike Unity/Unreal), or making tools/bugfixes to accomadate for them. i.e. less time on the actual game.

Hence the mantra: make games, not engines. If you like making engines, that's a good reason in and of itself to ignore that mantra. But if your goal is to make a game, then you shouldn't have to worry about the nitty gritty until it needs to be addressed.

Re: What Unity Is Getting Wrong

#293

Post by pharke »

stevehawk wrote: post #133
VHRanger wrote: post #128

Earlier quoted context omitted.

League of Legends, DOTA and so on all come from a Warcraft 3 mod as well.

I guess I was just clarifying that the OP makes a comment implying "Epic made a game engine and blockbuster game all with smaller staff".. but the blockbuster game kind of.. takes away from the point because it already existed. the comment stands stronger simply on the fact that Epic made a better game engine with a smaller staff.

I think the point is that software development is generally a continuous process. I highly doubt they've completely stopped all active development on Fortnight.

Re: What Unity Is Getting Wrong

#294

Post by pastrami_panda »

diegoperini wrote: post #198

Curious question: I have a few years experience with Unity. When I first grabbed it, I assumed the engine having C# scripting would give me rich tools to make game state serialization (save games, streaming open worlds etc) a relatively easy task, thanks to its reflection capabilities. This turned out not to be the case due to my false expectations, the programming model game objects use and the asset pipeline needin…

> they also broke the entire authoring workflow by effectively deprecating `GameObject` in practice

I've not yet worked with ECS, but I've read the docs and remember there was an emphasis on GO -> Entity conversion. So authored GOs can be converted to efficient entities runtime. Is this not the case anymore?

Re: What Unity Is Getting Wrong

#295

Post by voppe »

hnick wrote: post #260
voppe wrote: post #56

Earlier quoted context omitted.

I agree with the first statement. I'd go as far as saying that Unity is the JavaScript of game development. Sure, when you start out you get out results FAST, but then you run into limitations, weird behaviours and quirks that have to be worked around, and soon everything becomes a mess. Mind you, I'm a hobbyist in this field so maybe you could chalk it out to inexperience, but I shiver to think to what professional…

Do you have any pointers towards good tutorials for a hobbyist on UE? I dabbled with Unity and want to see the other side and it wouldn't hurt to get back into C++ after all these years.

Sorry, I don't have a solid reference, I'm mostly watching snippets of random youtube videos and trying stuff out on my own and putting the pieces together as I don't have the patience to sit through a course.

Also, I'm working with blueprints as the C++ side lacks any kind of docs or tutorials. Initially I was repelled by them, but after getting used to them, they're not as bad as they seem at first glance.

Re: What Unity Is Getting Wrong

#296

Post by sershe »

kbenson wrote: post #147
bluescrn wrote: post #124

Earlier quoted context omitted.

They really do need that reminder. The people making money from Unity-based games are primarily mobile/F2P devs, and smaller indie developers. They need stability and ease-of-use/very-rapid-development much more than they need performance or the latest shiny high-end graphics features.

I thought I remembered there being some bigger games, but looking at a list[1], they are all pretty indie, or at least small. Not sure I saw a AAA game on the list (which doesn't mean there aren't any, but they seem rare). The equivalent list for Unreal Engine[2] does contain quite a few big titles (along with a plethora of less well known ones). I'm not sure if that's cause, effect or marketing. It could be that usi…

There are a bunch of AAA-ish? RPGs and strategies on Unity, like Pillars of Eternity, Pathfinder, Endless Legend, Endless Space. They may not have the player numbers of Heartstone but they are basically what top notch equivalents like like Baldurs Gate or Civ are, and more.

In my experience Pathfinder for example suffers from poor perf compared to e.g. Tyranny, but Endless Legend doesn't compared to recent AoW or whatever non-unity game equivalent.

Re: What Unity Is Getting Wrong

#297

Post by pydave »

cecilpl2 wrote: post #239
haydenlee wrote: post #100

Earlier quoted context omitted.

We are a tiny dev team using Unity on a non-gaming project and we basically have to dedicate 2-4 weeks of the year to updating Unity and all the mess that it entails. But if you don't update then you have to spend even more time the next year catching up. Then we end up being too scared to use their new features cause they aren't supported well or cause bugs. Its lose-lose.

I'm in game dev and have been responsible for doing Unreal Engine updates for medium-sized teams (50-150) on AAA games. Our updates have taken one full-time engineer for 2 weeks plus an additional 2 weeks total of various people's time for each upgrade. It's worse if we skip a version. We dedicate probably 3-4 person-months per year to staying updated, but it's well worth it. As an investment its ROI is easily 100x.

Do you make changes to Unreal's source? Or have middleware that makes changes (Havok and Fmod)?

Your effort estimates line up with mine, but I'm not sure about the ROI (but it's been a few years and I was pre-fortnite).

We made limited changes to Unreal source, but I think we made more changes than we had to. We had our middleware, we fixed bugs (none upstreamed via github due to company policy), but we also introduced new features varying from necessary for the project (instanced mesh rendering) to unnecessary (fancy logging). Every upgrade, I regretted most of the changes we made.

But also, it seems like every upgrade our data assets and blueprint script would get less stable and cause weird infrequent crashes in the blueprint/uscript interpreter.

Do you use bleeding edge features? I recall being wary of anything that hadn't been around for a few updates.

Re: What Unity Is Getting Wrong

#298

Post by xenreal »

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 can't agree more. Unity was a good way to do games because it provided visual editor and unified API between all platforms including mobile if you use unity only as a renderer, it's pretty good and stable.

The only problem, to use unity with comfort, you need to code some base for networking, asset loading, bundle management, caching, localization, visual scripting, and UI (using NGUI and happy with it). It's the way how large companies work with unity (blizzard for example)

Getting rid of all those layers of abstraction stacked over the generation and writing code using modern C/C++ much more satisfying. Especially now, when we have a nice minimalistic cross-platform layer SDL, not to mess with video card/sound directly.

For those who want a slightly higher level OOP API, I want to recommend to try out https://oxygine.org/. It's using modern C++ to provide API similar to MonoGame.

For those who like unity like editor experience I recommend trying https://www.duality2d.net/. It's free, stable, and extremely fast engine width C# scripting similar to the unity MonoBehaiours system.

Re: What Unity Is Getting Wrong

#299

Post by cecilpl2 »

pydave wrote: post #297
cecilpl2 wrote: post #239

Earlier quoted context omitted.

I'm in game dev and have been responsible for doing Unreal Engine updates for medium-sized teams (50-150) on AAA games. Our updates have taken one full-time engineer for 2 weeks plus an additional 2 weeks total of various people's time for each upgrade. It's worse if we skip a version. We dedicate probably 3-4 person-months per year to staying updated, but it's well worth it. As an investment its ROI is easily 100x.

Do you make changes to Unreal's source? Or have middleware that makes changes (Havok and Fmod)? Your effort estimates line up with mine, but I'm not sure about the ROI (but it's been a few years and I was pre-fortnite). We made limited changes to Unreal source, but I think we made more changes than we had to. We had our middleware, we fixed bugs (none upstreamed via github due to company policy), but we also introduc…

Yes, we make a significant number of changes to Unreal source, probably on the order of 1-3 per day across the team.

All changes to the engine are required to be wrapped with a special comment tag indicating the author and explanation of the change, so that it's evident in a 3-way merge window how to resolve if there's a conflict at engine-upgrade time.

At a previous company we used Enlighten and Simplygon both of which made changes to engine source, and those were a nightmare to deal with. We had several source branches set up specifically to deal with 3-way merging at all steps of the way.

We also implemented things like instanced skeletal meshes, an improved navigation system, and additional shader passes. Those were all very complex to upgrade especially when Epic had refactored the underlying systems.

We don't use features that are experimental in shipping code.

Re: What Unity Is Getting Wrong

#300

Post by diegoperini »

pastrami_panda wrote: post #294
diegoperini wrote: post #198

Curious question: I have a few years experience with Unity. When I first grabbed it, I assumed the engine having C# scripting would give me rich tools to make game state serialization (save games, streaming open worlds etc) a relatively easy task, thanks to its reflection capabilities. This turned out not to be the case due to my false expectations, the programming model game objects use and the asset pipeline needin…

> they also broke the entire authoring workflow by effectively deprecating `GameObject` in practice I've not yet worked with ECS, but I've read the docs and remember there was an emphasis on GO -> Entity conversion. So authored GOs can be converted to efficient entities runtime. Is this not the case anymore?

> Is this not the case anymore?

It is but it has some drawbacks:

1) Play Mode inspection/modification capabilities are harshly reduced. Unity is years behind re-implementing those.

2) Not all subsystems speak ECS yet. Many of them are still essential.

3) There is now a distinction between what you see in Edit and what you get during Play.

4) Serializing ECS is easy but de-serializing is still a pain. You have to keep track of GO's that hasn't finished their async conversion to defer de-serialization.

5) Yes, GO->Entity conversion is async so you need to manually wait for all conversions before your game can start playing.

Post reply on HN