What Unity Is Getting Wrong - <AUTHOR> https://garry.tv/unity-2020 <comment><USER3> Unity has gotten so painful I've sworn off ever taking another Unity project. Since mid last year I am 100% exclusive on Unreal Engine.

Unity wants you to think this instability is temporary. It is not. Unity has been unstable since at least 2014 when I first worked with it. Every year there is a new-new thing, "please stop using the old-new thing". Meanwhile those upgrades are always painful, not sometimes painful, but almost always.

Back in the Unity 4 to Unity 5 transition the studio I worked at had a contract to port a single game screen from NGUI to UGUI. NGUI being a plugin which used to the de-facto UI framework. UGUI being Unity's inhouse clone. No upgrade path, just a rewrite required.

You want to know the juicy fact? Unity has more engineers than Epic. This despite Epic developing both a cutting edge game engine + Fortnite. Unity makes noise about needing price increases and extra revenue sources, yet that high headcount is not showing us as quality for the gamedevs.

With Unity you are paying for the "build a bear" of game engines; while Unreal is selling a batteries-included solid foundation.

<comment><USER4> 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 developers have to deal with if the small prototypes I cranked out got so convoluted.

I'm trying out UE4 lately and although it can be daunting at times (and with horrible documentation), it feels much more comfortable to use in the long term.

<comment><USER5> > 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 developers have to > deal with if the small prototypes I cranked out were that painful.

Careful adherence to best practices (often discovered the hard way), banning certain code pitfalls with a linter, and many workarounds :(

It took me months to make something semi-usable out of (a subset of) UNET, and I can clearly see why nobody at Unity wanted to maintain it. Still, something half-decent and mostly backwards-compatible could have been made of it with enough work, but again they chose to chase the new shiny :/

<comment><USER6> If you haven't already, take a look at Mirror - open source reimplementation of UNET with hundreds of bug fixes and improvements

<comment><USER5> My main complaints about UNET could be summarized as "the order in which things happen is very chaotic" (in unbelievably many ways!). I've not checked to what degree Mirror has improved on this.

Based on a superficial look, I'm worried it might have been more concerned with adding features than fixing and simplifying the fundamentals, but I don't really know.

</comment></comment></comment></comment></comment><comment><USER7> 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 behind. Windows is slow. Macs require you to use specialized cloud (such as MacStadium)

\- 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.

\- WebGL target means running emscripten, which means running a compiler in Python. It is slow. We sped it up by using a really expensive AWS instance size to run it.

\- We built our own pipeline because Unity Cloud is even slower

I think it is like this because:

\- We're not Unity's core market. We're a team that can afford expertise on CI

\- Unity doesn't dogfood their own tools and build a game with it. They don't fix the bugs that come from having to build a game.

\- Unity Cloud probably cheats and uses a special version of the binary that does not talk with their license server. So there is no pressure to fix their license servers, and make it reliable enough to run elastic loads. (They probably don't run it elastically because they use Macs for their build servers)

I look enviously on the folks who work with Unreal Engine. I also hear that Defold is now open source. Maybe people can use that instead.

<comment><USER8> > \- 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.

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

</comment></comment></comment><comment><USER10> I'm a full-time independent game developer who's been using Unity for the last 6 years and sadly Garry's very correct. The render pipeline debacle has been painful to watch, Unity announced that the Universal Render Pipeline (what is still planned to replace the default renderer) was 'production ready' in early 2019, and it was lacking... so much. No ability to use multiple cameras (one for the game, one for the UI, for instance - a common use-case), they've rewritten the post-processing stack multiple times. Having more than one Directional Light was supported only very recently. Some of these have been and are being addressed, but it feels like Unity is in this odd no man's land, grey-area between the old legacy parts of the engine, and the new ones that just aren't ready for prime time, with many glaring gaps in the functionality. You would expect something as straight-forward as SSAO to be available out-of- the-box, it's hardly cutting edge tech, but two (three?) years into URP's development and it's not in the Standard Assets yet.

I do sympathise, it must be very difficult to bring an old engine up-to-date, but it's quite infuriating for developers like myself to work and know when to upgrade and when not to.

</comment><comment><USER11> I'm so frustrated that Unity and Unreal are the only two real options. And it's all because of console vendors.

Unreal is just way too inaccessible, as an individual, non-C++-veteran (used it a bunch in college, but modern C++ looks nothing like what I've seen), non- games-industry-veteran. It's also fairly opinionated towards first person/third person action games.

And then Unity is of course a dumpster fire. It's much easier to get started and hack something together with, but you'll be hacking and fighting with the engine for the entire project.

Open-source libraries/engines exist, like Godot, but none of them properly support consoles because console APIs are apparently proprietary (??) because the console vendors are apparently stuck in backwards, draconian software practices from 2002.

The whole state of indie-accessible tooling is just deeply depressing.

<comment><USER12> While it might not be a good fit for a some people, Monogame is still active, still ports to most systems, and it's totally free. I ported my old XNA/Xbox 360 game to that pretty much in one night (since it's based on XNA) and have been working on remaking it for desktop/mobile/eventually console.

It's still being used for some pretty mainstream Indie games, like just- released Streets of Rage 4, Flinthook, Celeste, Bastion, Fez, Axiom Verge, Stardew Valley, TowerFall, etc.

Doesn't have all the mess or constantly moving target that everything else has, either. I mean it changed so little from XNA 4 that I could easily port a game designed for Xbox 360 over to it (shaders and storage took some extra time).

[https://www.monogame.net/showcase/](https://www.monogame.net/showcase/)

<comment><USER13> That's an extremely impressive list of titles.

As a hobbyist game dev I'm looking at moving to a multi-platform 2D game engine (last few games were done for the web using Phaser). The two engines that seem interesting are Monogame and Godot. My limited understanding is that you get more tooling and ready-made things with Godot compared to Monogame. I'll have to do another deep dive of these two engines soon.

<comment><USER12> Godot looks impressive too from a casual look into it, and is also free, and definitely has more included. Monogame is more of a framework rather than a toolset, except for a Content Pipeline tool you're going to be writing just about everything in code.

Monogame has the advantage that it has been used for commercial games, so you can get a good feel of what it can handle. Most of what I've seen showcased from Godot are more toy games, not really commercial. Now granted someone has to be the first to do it on Godot, but part of the reason you don't see it might be because it has some limitations you'll run into (but probably won't as a hobbyist developer).

XNA also had a really large community at the time, and a lot of questions you have with Monogame, if you can't find the answer noromally, you can just look up the answers to for XNA and it will be the same answer, so there's a good amount of history to reference there as well.

The important thing is just to pick something and start. After XNA died out, there was several years where I didn't make any progress because I kept going back and forth on what platform or tools I should use. I do recommend picking something open source and free, though, because I've had games get stuck on old proprietary platforms in the past and have had to port them to other platforms (i.e. Flash, Cocos2d iOS).

</comment></comment></comment></comment><comment><USER14> This has been a cultural problem at Unity for a long time. They introduce half-finished features and then never improve them. A great case in point is their VideoPlayer component which can't open a video without dropping frames because 4 years on it still can't load things asynchronously. Where's the dev assigned to that component been and what have they been doing all this time? People have been complaining for years and there's zero attention to detail.

</comment><comment><USER15> > They hid all the hard stuff in c++ so we didn't have to think about it. The > more time has gone on, the more bullshit has crept to the forefront. The've > gone from hiding the hard stuff to moving more and more stuff into C#.

I love that they are moving more and more stuff in C#. It's a good thing. The C# code is available for developers to view and modify, but no one is forcing you to.

The problem is that a lot of Unity's early choices that made it so accessible to novice game devs making simple games, made it to inflexible or slow for bigger or more complex projects.

If you were building a high performance procedurally generated game, you were already fighting with all of the "easy stuff".

<comment><USER16> I agree. Moving things to C# reduces interop overhead and I think it's the right direction. If you don't want to look at engine code, don't. Why does anyone care it's in C# if they're not looking at it anyway?

<comment><USER17> > Why does anyone care it's in C# if they're not looking at it anyway?

Garbage collection probably. Some games have noticeable stutter. But I assume there are ways around that, similar to using Java in HFT.

<comment><USER18> A lot of effort goes into making sure allocations are avoided though. You also have DOT's High Performance C# which is a blazing fast subset of C# (Burst Compiler). I like the idea of using a language for everything, then restrict to a subset where performance is critical. You don't have that wall between scripts and (C++) engine code. And as mentioned above, less glue code is appreciated.

</comment></comment></comment></comment><comment><USER19> 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 life-changing for me, the difference between making a game I'm happy with vs. not.

I also have a YouTube series discussing how to get setup on a Mac, if that's that platform you're starting with.

[https://youtu.be/M5l6CvHwWsc](https://youtu.be/M5l6CvHwWsc)

I'm not really sure why more people don't do their own thing. It has been really satisfying for me. Overall, the process of making games is way more rewarding, and I think I'll have something better on the other end of all of this.

Plus I'm getting better as a programmer, which helps with other aspects of employment.

<comment><USER20> Building your own thing is fine if you're solo. When you start having to collaborate with e.g. artists who expect their assets to render the same way they do in their editor, or a game designer who needs to edit levels in the engine, etc., then you introduce a bottleneck due to the fact that some people are working on the engine, and others on the game that depends on the engine.

<comment><USER19> I've found that making a custom engine is more amenable to teamwork, not less.

I can build a simpler level editor that I can give to a totally nontechnical person (a.k.a. my spouse), and they can go to town making levels.

They don't need to know anything about Unity/Unreal. They just need to know about my game.

My game already includes levels my friends have designed using tools I made for them.

</comment></comment></comment><comment><USER21> 100% agree with this.

Everything they've done in the last 5 years I've been using Unity has felt half baked. You'll try any number of the things they've released recently (networking, 2d animation, and vector graphics are the ones that come to mind for me) and they'll work fine for their demo case but then fall apart with so many cases that you need to actually ship a game. I think one of the bigger problems with the company is that they're not actually making games themselves and eating their own dog food.

<comment><USER22> Promote engineers for big launches, and you'll get big launches. Lots of them. Fire and forget style launches.

</comment></comment><comment><USER23> I got stuck into a few unity projects recently, and I've been surprised how poorly documented and undiscoverable things can be.

Why is the whole rendering pipeline stuff such a mess? I've bumped into far too many unexpected gotchas because a pipeline doesn't support a particular feature, or it renders stuff in such a way which isn't clearly documented. And whats worse is there is no real easy way to debug it since there seem to be no in-built debug tools for rendering.

Also their webgl implementation is terrible if your doing anything more advanced. Often I'm scratching my head trying to figure out why something suddenly doesn't work, only to find out for some reason it's still using old resources. And I'm often working around yet more undocumented implementation details like render targets getting their alpha channels wiped somewhere in the spaghetti code rendering pipeline.

It strikes me that there is a real big gaping hole in the market for something like unity but which has a flatter, more comprehensible system. I think there is some hope godot will be that, but I don't think its quite there yet for some scenarios (like their webgl implementation being even worse than unity).

<comment><USER24> Unity does have built-in debug tools for rendering, I'm not sure what leads you to affirm the contrary? Or do you consider the exisiting tools to be unsufficient for your needs?

<comment><USER23> My main issue at the moment is they don't work in webgl, where the rendering is sufficiently different enough that it differs from what generally happens when you run in the editor.

The built-in "Frame Debug" tool for me is very glitchy and doesn't really give very good information.

So 99% of the time for me, it's basically as good as having no tools.

</comment></comment></comment><comment><USER25> A great demonstration of how unity is bloated: [https://www.youtube.com/watch?v=tInaI3pU19Y](https://www.youtube.com/watch?v=tInaI3pU19Y)

Unity is targeting students and gamedev wannabees. You don't make a game with a framework. Programming is not simple. Same debate of framework vs libraries.

I'm even against Godot, which you cannot even use as a rendering library. You end up being too dependent on those platforms and all their assets and plugins.

Of course if you intend to make a game that's not too ambitious, if it revolves around the graphics, unity might be ok, but it's just a sophisticated RPG maker 3D.

I strongly advise against learning unity or godot. A huge problem is that unity/unreal made it difficult for classic engines/renderers to keep thriving, and it's hard to find a good engine nowadays. There are some, of course, but their community is non-existent, which makes things much harder in open source.

<comment><USER26> ok but can you please recommend some decent alternative engines for xbox development? i am having so many issues with unity i am running out of hair to pull out!

<comment><USER25> Turn to c++ maybe if you can.

Godot would seem like a wiser solution than unity, too.

You can also ask and search in various gamedev communities, on gamedev.stackexchange, reddit, etc, and ask around.

I know I'm trying Urho3d that seems like a complete modern engine with everything included, and many samples. It's inspired by many other other engines like Ogre3D and seems to support modern graphics api like vulkan.

If you're on 2D, stay on things like SDL or SFML. If you want better effects, I don't really know.

I really depends on what you want to do, what are you skills, if you want to release quickly or not, if you have large assets, etc. Do not neglect the tools and libraries you use so that the code you write today will still work on the same libraries in 2 years.

If you're indie and you don't have a lot of money, skills or experience, AIM LOW.

<comment><USER26> Ok, thanks for this! I have the resources for assets, and my game is a Mars Colony Sandbox game like space engineers and empyron galactic, solo dev, still learning tho - but seems like i am making progress. I struggle a lot with memory issues tho i spend loads of time in the profiler, and there are many issues with unity itself. Will read more on the ones you sent.

</comment></comment></comment></comment><comment><USER27> In February, Unity changed their asset store license retroactively and took away our rights to let our freelancers use our assets. Their support was apparently telling users their freelancers could use their purchased assets only days before the change. It was a massive abuse of the "we can change these terms at any time clause"

<comment><USER28> That reminds me of Unity-Improbable debacle [0] few years ago when Unity changed their TOS without announcement.

[0] [https://www.gamesindustry.biz/articles/2019-01-10-spatial- os...](https://www.gamesindustry.biz/articles/2019-01-10-spatial-os-games- under-threat-as-unity-claims-improbable-has-breached-terms-of-service)

<comment><USER27> I've never seen a company use their "these terms are whatever we want them to be" clause so aggressively as unity has at least twice now. How are you supposed to trust them as a partner?

</comment></comment></comment><comment><USER5> As a Unity user emphatically sharing these frustrations, I'd be really curious to hear from long-time Unreal devs whether the grass really is greener on the other side.

How's Unreal's

\- API stability?

\- Editor stability? (I have some old experiences of it being quite crashy too, and you know, C++ ...)

\- Backwards compatibility and upgradeability?

<comment><USER29> I am also curious to know. I have no Unreal experience but some Unity experience. Have only made a few hackathon level games and plugins.

Unity seems amazing to me. It's like a game engine editor creation system. Every game needs custom tools and they are relatively trivial to create in Unity from small, just create a struct and get a UI in the inspector, to add a few lines of code and get a custom control for your data, to entire plugins with multi-window UIs etc. And, at least for my use cases I can do this live. I don't need to exit the editor, recompile the editor itself, and then re-run which seems to be the Unreal way?

Unreal devs tell me they don't need any tools. They just use what's built in. That makes no sense to me. Every game I've ever worked on (15 shipping AAA games over 30 years) required custom tools unless you wanted to subject your designers to lots of rote data input.

I'm sure there are some subset of games where you just fill out a world with 3d objects and use the built in systems as is but that seems like a very limiting subset.

What is that experience like in Unreal?

I know at least one indie dev what was on Unity, switched to Unreal for one project, and is now switching back to Unity. I know another that was on Unity and switched to Unreal. They haven't shipped yet so not sure what their experience is. Both are small teams, 5 to 10 people. Neither has shipped a hit title.

<comment><USER30> I think when people say they use what's built in, they mean they don't have to purchase anything from an asset store, and possibly mean they don't have to use any external free or open source libraries. Writting tools specific to your game probably counts as using what is built in.

</comment></comment></comment><comment><USER31> There are two main reasons to avoid Unity:

1) As your project grows, it becomes unmanageable because the resource pipeline is hidden and you want to be able to improve that.

2) Skin mesh animation, which is the main point of using Unity in the first place, uses a compute shader which means they send all meshes from the CPU to the GPU every frame!

On the other hand Unreal takes 5 hours to compile and even Godot takes the same time as Unity ~30 min.

The only option is to fold your shirt sleeves up and build your own engine. It's not that hard really.

<comment><USER32> > Skin mesh animation, which is the main point of using Unity in the first > place,

That's an odd thing to say. I've never used it personally. Even if it's used in the majority of games saying it's the "main point of using Unity" is overstating things. It's simply one feature out of many that Unity provides.

> The only option is to fold your shirt sleeves up and build your own engine. > It's not that hard really.

Maybe for you. I wouldn't even know where to start. And I wouldn't want to - that's not the level that interests me.

<comment><USER31> The only thing that Unity provides that has any chance of saving you time is the skin mesh animation = FBX or Collada to Mech Anim pipeline.

If you don't need that you should _never_ even consider using Unity.

If you are not interested by the underlying tech of any category of computing, you are not a programmer.

<comment><USER33> > If you are not interested by the underlying tech of any category of > computing, you are not a programmer.

I don't know much about Unity, but this gatekeeping ruins your credibility. It might very well be that writing your own game engine is faster than using Unity, but I actually believe that _less_ now after reading your comment. Your argument seems more pride-based than fact-based.

Programmers specialize based on their interests, and that's a _good_ thing. If we didn't have specialization, nothing useful would ever get done. Mistakenly choosing not to leverage prior work in design space[1] can come at a very high cost.

[1] Borrowing a term from "Darwin's Dangerous Idea" by Daniel Dennett ([https://en.wikipedia.org/wiki/Darwin%27s_Dangerous_Idea](https://en.wikipedia.org/wiki/Darwin%27s_Dangerous_Idea))

</comment></comment></comment></comment><comment><USER34> 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.

<comment><USER35> You can use Quixel scans and materials in Unity as well.

</comment></comment><comment><USER36> The are all primarily organizational, not engineering problems. Like many other tech companies, I feel that product managers at Unity are rewarded for launching new shiny features (that quickly fall apart outside the scope of beautiful demos), not maintaining and improving existing ones.

But despite that, it still stays a very good choice for many different scenarios, and definetly the best for mobile 2d games. The original design choices are solid. The most important components are in good enough shape. And it stays just in the right place between being too complex and too primitive. So, from a business perspective, when you want to build your match3 or hyper casual title, there's no much of a choice in terms of engine.

</comment><comment><USER37> I've spent the last three years working in Unity. By the time I've learned enough to make honest-to-goodness good quality games with it, I've reimplemented so many things that are supposed to be core features of Unity, that I would have just been better off starting from scratch on my own.

So that's what I'm doing now. There is a .NET Standard 2.0 library called Veldrid that gets you open source graphics code. There's another netstandard2 library called NAudio that will get you most of what you need for audio. Xamarinn will get you the platform-specific stuff for user input. Networking can be done with just regular, ol .NET sockets. If you care about VR (which I do), there are C# wrappers around all of the major VR APIs; you'd have to do a lot of platform specific and conditional compilation wrangling to get good VR working on Unity anyway.

And you can use a sane build system, with a sane dependency management system.

It's just so much better than constantly fighting Unity's stuff that was all designed for demoing at Unite and then never finished.

</comment><comment><USER38> 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 needing too much plumbing. Official ECS packages made it easier later but they also broke the entire authoring workflow by effectively deprecating `GameObject` in practice.

I've never used Unreal Engine but if serialization is a solved problem there, I want to try.

Does anyone here have experience with similar use cases?

Are there other AAA-ready engines good at this? Giving value types first class support, promoting data oriented design and building the artistic authoring tools around these priorities is what I will appreciate the most.

I don't care if the high level scripting language is non-existent, C++ heavy or Brainfuck. That can be circumvented by building muscle memory in a few months.

<comment><USER39> > 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?

<comment><USER38> > 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.

</comment></comment></comment><comment><USER40> I'd add this the lack of a solid 3rd party developer ecosystem on their Asset Store. The fact that they don't have a subscription model for assets or any support for managing per-seat licenses is ridiculous and is the direct cause of multiple popular assets ending support. It doesn't make sense economically to sell any kind of service on their store.

</comment><comment><USER41> I once tried using Unity for creating a little game during a game jam of approximately 8h. The team wanted to make a small game, where one could mix ingredients and create magic potions. Initially I suggested we could simply use some JS and make it a web app, specifically, because I anticipated problems, if we relied on some software like Unity, but no, unfortunately the team majority decided they wanted to use Unity.

For the Windows users it apparently worked. However, one friend and me, this choice excluded us. Here is why:

Unity did start the first time, but then crashed, resulting in some lock file being there, so that I could not start it again. Took a while to figure that one out. After figuring that out, I was able to remove that lock file manually, enabling me to start Unity again. That alone in itself already seems ridiculous. However, I could still not use it, because it kept crashing and not working. So my friend and I could not participate at all. She was running some Mac laptop, where it also had issues. I tried reinstalling multiple times, updating graphics card drivers, switching between proprietary and Nouveau, all kinds of shenanigans, I tried for at least 2 hours to get this stuff working before giving up. Of course I searched online for solutions. None to be found.

This was a few years ago, so the situation might have changed, although many comments here lead me to thinking, that it might be just as bad. However, that is why I stay clear of using Unity. What I've seen of Unity makes me think it is a huge bloated thing. I'd rather choose some small 2D game engine and write a lot of code myself than trying to use Unity again. Once bitten ...

</comment><comment><USER42> This blog has a looping, resized background video with a CSS blur filter. For anyone else experiencing performance problems because of it, I recommend reader mode.

<comment><USER43> I removed the video element from the background. I thought it was some sort of crypto miner.

</comment></comment><comment><USER44> There is also Amazon Lumberyard. Which is totally free, you only have to pay if you use AWS for multiplayer. It is a fork of CryEngine. It looks really nice.

<comment><USER45> As someone who was on a AAA team making a game on Lumberyard, I'd caution against it. The tooling, support, and community just aren't there (and it doesn't seem like Amazon is investing much in making it happen.)

</comment></comment><comment><USER46> Overall I love unity, but one thing that drives me insane is how many weird UI quirks they just don't fix, like how incredibly primitive editing arrays in the inspector is (its a nightmare to reorder anything) or dealing with asset imports that take forever. They take these huge projects on, the great rendering features and such, and theyre impressive, but somehow they won't fix small things that are seriously aggravating in day to day use.

Also while I do love c#, I think it was the wrong language choice, because you end up having to write code in a really constrained way to get around garbage collection issues. Its getting better, but for games id prefer a non gc language

<comment><USER47> At a previous job, one of my colleagues didn't have the best vision. And had to run his computer at a really low resolution to compensate for the tiny text in the UI.

There's an open issue that has been on the Unity website for years asking for font size support in the editor. But it has never been addressed.

</comment></comment><comment><USER48> I spent so much time figuring out stuff in Unity (physics _cough_ ) or implementing stuff I thought were subpar (a remoting stack based on LiteNetLib) that I simply got tired of it. And every new feature adds more complexity on top of an already huge engine, which takes insane amounts of time to keep up with.

In anger I drew this comic [1] and really, my relationship with unity kinda broke as soon as they introduced dots and the new rendering pipelines.

[1] [https://www.zubspace.com/comic/unity-vs- godot](https://www.zubspace.com/comic/unity-vs-godot)

</comment><comment><USER49> I have been using Unity since 2008 version 2 before the Unity iPhone even and I have to agree. It is a mess.

There has never been a time in Unity where systems aren't changing.

APIs should be simple facades to ugly systems underneath, abstracting away the pain, but Unity puts it right in your face. Their editor is pushed over code first solutions.

I thought when they went subscription that it would calm down, as before that it was a mad rush to justify you upgrading to the next version. It has only gotten worse. From the dual particle systems (which Shuriken wasn't even code accessible for a time), killing off simple legacy animation APIs, the UI years and years of delay and still not really as good as NGUI in terms of simplicity and mobile performance, the multiplayer systems have never been great they should have just kept RakNet/enet based reliable UDP and been done with it only Photon is worth it, the bulky editor first solutions that really should be code first and then editors that use that and on and on.

Compare that with Unreal that is wonderful in terms of networking/replication, solid platform that is C++ first, decent platform support, Unity has more but lots of issues.

Unity is what we develop most games on but Unreal starting to become more regular. Unity is caught in a pickle. Unreal is winning high end, Unity wants to be them, but they are leaving their smaller developers that do mobile/2D/simple 3D and making everything overly complex, while Godot is out there taking that space. I'd be worried if I was Unity. They still win on platforms available and they are making good efforts, but right now, and many times in Unity's history, there are so many systems now that it isn't simple for the low end, and high end you'd be amiss to not go with Unreal. This is coming from a Unity developer since 2008 Unity 2, before they even had Unity iPhone, back when it was just WebPlayer (which I miss the simplicity) and Desktop.

Unreal is doing high end much better than Unity [1] and Unity is losing what made it hit huge, mobile, web and desktop games and simplicity. At this point Unreal is more simple because the systems work and there aren't these one direction only changes or dual system problems. So much of the Unity API is in flux right now and you never know if they are going to drop them. UI was worked on for YEARS and now they are doing UIComponents and don't even try trusting a Unity networking solution.

Back in 2013 Unity was going to go C++ [2] and I wish they had, it was when Apple forced AOT on everyone and they backed off but Unity went into IL2CPP just a year or so before Mono was bought by Microsoft and had AOT baked in. They spent so much time not wanting to pay Mono's license but later it was all moot and not needed fully. Since that time Unity has been a constantly changing beast, and not for the better, painful wholesale updates with little or no benefit, only to see that system disappear soon and on to the next.

Unity needs to calm down, lock down API signatures/facades, focus on atomic operations, make simple APIs as abstractions and change the underlying systems when it evolves. They do parallel changes which is good, but the surface changes quite a bit. Unity has become one big leaky abstraction. I have used it almost everyday since 2008 and it would be fine if they made things more simple, but even the transition is painful. Like when they removed their legacy particle system (which had a decent API) and one day just pulled it from a new build, every old game just crashed on open, no warning. They are getting better at that but it should not be like that.

I am in the middle of a bunch of NGUI to UnityUI upgrades and that is already going to be replaced with UIComponents ... UI constructs (types, textures, fonts) really don't change that much and they spent years on that UI update. Why are users having to concern themselves with surface changes?

A major difference between Unity and Unreal is Unity doesn't build games on their engine, Unreal does. While that sometimes makes Unreal solutions more FPS/BR format and closer to their games, it makes for a solid engine.

Another difference is leadership, Unity was extremely simple and small before, once they got John Riccitiello it become a management/business focused company over engineering leaders in terms of power and direction.

Unreal has Tim Sweeney, and old school guy that understands how to make a game engine and has done it over and over. They learned alot from Unity, and are now doing it better than them once they turned towards simplicity over complexity.

When Unreal 4 swapped out UnrealScript for C++ it went into overdrive in terms of performance and clean. Unity is nice that it is C# as well, but the extra weight of constant changing systems that seem half done and not code first is tiresome.

I love Unity, I make a large part of my living from it, I hate to see them not understand that breaking changes constantly, gets a bit old and it essentially offloads technical debt to every user of the system. I am using Unreal more because of some of these issues.

People use a market engine to offload the engine team. That engine team should do whatever it takes to make transitions easy, and when difficult there needs to be immense benefits. Some of those are questionable in recent years. The desire for Unity to want to be Unreal is losing the mobile side and web is essentially not even a focus anymore which is more the whole market not Unity's fault. Unity started really as a better Flash, now they want to be Unreal. Right now Unreal is winning that and the Unreal 4 rewrite with C++ backed is really clean. Unity still more simple but with the new DOTS/Rendering Pipelines it is not.

Unity, let the engineers/product people lead over the managers, you are losing a good thing.

[1] [https://www.youtube.com/watch?v=oDQl9gw_fRM](https://www.youtube.com/watch?v=oDQl9gw_fRM)

[2] [https://blogs.unity3d.com/2010/07/02/unity-and- ios-4-0-updat...](https://blogs.unity3d.com/2010/07/02/unity-and- ios-4-0-update-iii/)

<comment><AUTHOR> There is another factor to consider which is that the 2017 gold rush when Valve opened up Steam to anyone with $100 is absolutely over.

The median game launching on Steam now will make only $1,400 (5 year gross revenue): [https://twitter.com/greyalien/status/1227557601786912769?lan...](https://twitter.com/greyalien/status/1227557601786912769?lang=en)

Unity's business model was selling $100 worth of starter assets to wannabe- developers then taking a 30% cut on that.

Now, browse gamedev subreddits and all you will hear are tales of financial misery. Who would want to get into that as a paid hobby or quit their job to do it?

<comment><USER50> Gold rush has been over every couple of years, when developers flock to a new platform, dumping a couple of remakes during the first waves.

Game development is like any other art form, be prepared to jump from failure to failure and one day one might hit gold, or maybe not.

<comment><USER49> Lots of Unity games are what Flash games used to be as well, promotional games, advergames and other things that are part of a larger campaign or system that isn't one off. Most people making money with Unity are building games for shows, promotions, events and others that are marketing mostly.

You can still make money with indie games but more in terms of certain categories or niches.

To make it in games today it is quantity of quality, both are needed.

Unity is making that harder by doing breaking changes waaayy too often. They are making it harder for the smaller/medium game studios with all this technical debt offloaded.

</comment></comment></comment></comment><comment><USER50> Looking at its adoption by Hollywood and TV channels for 3D based animations, Unity is getting lots of stuff right.

I guess there is always Godot for those that don't feel the same way.

<comment><USER51> And yet Unreal has the nascent real-time in-camera VFX market completely locked in.

<comment><USER52> Agreed, I think Unreal Engine is much more suitable for VFX than Unity. Most people here on hn probably already seen the Mandalorian use of the engine.

I have also recently watched this video [0] of an independent film maker using some of it's features for virtual production which I found truly mind boggling.

[0] [https://youtu.be/cOI-cjdULmk](https://youtu.be/cOI-cjdULmk)

<comment><USER51> Clicked expecting a Matt Workman video...was not disappointed :D

<comment><USER52> I didn't know the guy before this, just came across his video somehow after the recent UE5 demo and was thoroughly impressed by it. That mixed reality camera and lighting demo at the beginning of the video was seriously cool.

</comment></comment></comment></comment></comment><comment><USER53> Godot Engine [https://godotengine.org/](https://godotengine.org/) is much more user-friendly in my experience.

</comment><comment><USER54> What do folks here think of Panda3D ([https://www.panda3d.org](https://www.panda3d.org))?

Its just a game engine without any IDE. So the typical workflow would be to build your assets and scene in Blender (or Maya, etc.) and then code up the game mechanics in Python or C++. I am tinkering with it for non-gaming (Reinforcement Learning) use cases and I was curious what game devs think of it.

<comment><USER55> Now there's a name I haven't heard in a very long time... I'm not in game dev right now, though, so grain of salt and stuff. But I did play around with Panda a long time ago, and thought it was fine for getting some 3D stuff going quickly without dealing with the headaches of OpenGL. Similar to PyGame but for 3D. It's neat that it's still seeing development.

Besides the old Pirates of the Caribbean game, which I can't even find mentioned on their site anymore, have there been any commercial games developed with it? I was always under the impression that it was primarily targeted towards CMU students in their game design curriculum. (DigiPen, a school most known for game programming, has in its main degree program students building their own engines from scratch, but there are at least 3 in- house engines that have been developed over the years meant for freshmen and game design students.)

I tend to treat the "commercial use" barrier as the key one to initially evaluate "niche" engines. Like, Ogre3D is fairly "niche" too, but it's been used in many commercial games. That says nothing directly about the relative quality, but it does imply some good things if people were willing to risk a business product on it.

Personally I'd consider Panda again for a game jam or as you mentioned a non- game-but-3D-needing thing, but where for both I'm also expecting to use Python. But I'd want to check out Python bindings to Ogre and whatever else is out there now these days too. (Godot has been top of my "if I ever want to just make a game and not spend time in the weeds doing things from scratch in a non-mainstream language, use this" tools.)

</comment></comment><comment><USER56> What's the primary draw of Unity? Valve, Epic, and id learned a long time ago that the real money to be made is in engine licensing rather than actually making games (unless the goal of said game is to show off your engine).

What is it that Unity has that these companies have been so unable to replicate? Surely they don't want another player in the scene to compete with their engines.

<comment><AUTHOR> Unreal requires C++ and runs poorly on mobile devices and Nintendo Switch.

Unity uses C# and runs pretty well on weaker devices (dev and client side). It also crashes a lot less.

Freelancer Unreal Developers are approximately double the cost and 1/20th as plentiful as Unity developers.

And no, you can't develop a complete project in Blueprints:

[https://blueprintsfromhell.tumblr.com/](https://blueprintsfromhell.tumblr.com/)

Unity had no choice but to split into HDRP and URP, because the gulf between next-gen consoles (high-end) and mobile (low-end) is going to become enormous. High-end will be completely dominated by raytracing, replacing traditional lighting, for example.

However it looks like Unity have really mismanaged this division and have totally siloed the two teams working on each pipelines.

They also require their Asset Store creators to provide more long-term support than they do for their own official Demos:

[https://forum.unity.com/threads/please-stop-with-your- madnes...](https://forum.unity.com/threads/please-stop-with-your-madness-srp- updates-should-be-syncd-to-unity-releases.869479/)

<comment><USER57> > Unreal requires C++ and runs poorly on mobile devices and Nintendo Switch.

Interestingly, as someone who started playing Fortnite on Switch, one of the pros I enjoy listening to has said that he actually would prefer playing on mobile to playing on the Switch, because the mobile version is more streamlined, so it actually performs better even though the hardware is weaker.

All I know is that it's way, way nicer on PS4, but I would expect that of course.

<comment><AUTHOR> Its down to the implementation by the developer. The typical developer will do a much worse job than literally the same company who developed the engine.

Look at the crashes and performance problems of Industries of Titan on PC, or the visuals of Mutant Year Zero on Switch for examples from regular devs.

</comment></comment></comment></comment><comment><USER58> I've been reading Garry's blog for about 15 years, good stuff.

</comment><comment><USER59> This resonated with me: " If you're searching how to do something, the first 5 answers you find are going to be out of date - and they're usually from Unity's own documentation. " Unity seems to be going in too many directions at the same time.

</comment><comment><USER60> It often feels like if Godot hired one really, really good documentation specialist, they could run away with things, especially in the mobile, indie, and lower-spec spaces.

Unity's documentation is bad, but unlike Unreal's, it exists.

</comment><comment><USER61> In my brief time trying out Unity (as a non-game-developer) I found the programming paradigm very frustrating. I wanted a more object oriented approach. But what I found was to get things to work in a performant way, you'd end up with very leaky abstractions. At the core, my thinking is it has to do with everyting coming down to handling on a per "tick" basis rather than as an event. Maybe I just did things wrong... but this seemed to be the direction you're guided in. If you do try and build a good quaility event model, the performance was terrible.

<comment><USER24> You can use the built-in event system to achieve what you were trying to do. Its really straighforward to use

</comment></comment><comment><USER62> Just try doing basic rendering with Unity and you will understand how bloated it is. Try to do some kind of fast line drawing / loading fbx / etc. Anything that a basic engine does pretty good.

</comment><comment><USER63> DOTS is in fact a major step up. It can't be done in engine code the same way you can't handle say oop to functional programming conversion in engine code.

<comment><USER5> I'm not so sure that would have been impossible. Nothing fundamental seems to prevent the compiler+runtime from:

\- laying out instances of the same Component next to each other in memory

\- Burst.Compiling their Update() functions

\- adding backwards compatible APIs to do parallel loops etc over multiple components

Given the culture of constant rewrites Unity has displayed (and I'm sure they have lots of techdebt to make rewrites feel appealing), its seems far from certain that they explored avenues like this sufficiently.

Or maybe they felt their earlier modification of Mono, which kept them on an old version of .NET for so long, was too painful to even consider touching the runtime ever again.

<comment><USER64> > _Nothing fundamental seems to prevent the compiler+runtime from: - <USER2> > out instances of the same Component next to each other in memory - > Burst.Compiling their Update() functions - adding backwards compatible APIs > to do parallel loops etc over multiple components_

And if those Update functions reference other objects and do something with them? If the engine automatically realigns the order in which Update is called on objects then you can't do something like that, you'd run into weird behavior. Or do I somehow misunderstand?

From what I understand, the whole point of DOTS is to get people to write code that uncouples the data from what operates on the data. Once they have that they can shuffle these calls around.

<comment><USER5> Of course you'd still have restrictions on the code if you want it magically optimized, just as with DOTS.

But you're right to be skeptical, this is not something I've thought through that thoroughly :)

<comment><USER63> The point of ECS is that your mental model is very close to the GPU. Some sort of rewriting process would just add additional costs to this.

</comment></comment></comment></comment></comment><comment><USER65> As I had mentioned in a previous thread that has come up recently with regards to UE5 and being open sourced, one of the greater sins of Unity is that it is mostly closed source.

In reading through the blogs of some of their developers, they seem to have a contrived idea that people "shouldn't have to know how it works", which, while it's a noble gesture, is bullshit because by prohibiting reading the implementation you can't know how it works anyway, whether or not you want to.

The domain model in Unity is fundamentally broken because it forces you to tie a lot of logic to a Component. People end up embedding all kinds of unrelated bits and pieces of functionality to the Camera because, well, where else are you going to specify it? This is a batshit crazy way to write software. Yet here we are.

Lastly, engines are leaky abstractions. Most software is a giant leaky abstraction as bugs and other things tend to creep up from beneath you, and knowing how something works down to the minute details is a huge advantage when it comes to not only debugging, but developing (architecture, style, optimization, whatever).

<comment><USER50> Unity source code is available to anyone that actually wants to have it.

It just isn't available in FOSS sense.

<comment><USER66> This is correct, they released the source code a couple years ago under a reference license.

[https://blogs.unity3d.com/2018/03/26/releasing-the-unity- c-s...](https://blogs.unity3d.com/2018/03/26/releasing-the-unity-c-source- code/)

[https://github.com/Unity- Technologies/UnityCsReference](https://github.com/Unity- Technologies/UnityCsReference)

<comment> squeaky-clean This is only the C# source code, the internals of Unity is a closed C++ codebase which you can pay $1800/yr for access to

<comment><USER67> That number sounds like BS. If it was that low (per-seat even), every serious team would have source access.

</comment></comment></comment></comment></comment><comment><USER68> Lol that Unity ECS ends up in a 'getting wrong' article considering that ECS style programming has been the direction that game development has been moving for a good while now.

At some point sooner than later people will be complaining about how they can't do ECS in Unreal.

</comment><comment><USER69> The multiplayer thing is my biggest gripe. It is unfathomable to me that Unity has seemingly ceded multiplayer functionality to Photon, considering the most valuable games on the planet right now are all multiplayer-first.

</comment><comment><USER70> Smells a lot like a continuous second system syndrome.

[https://en.wikipedia.org/wiki/Second- system_effect](https://en.wikipedia.org/wiki/Second-system_effect)

</comment><comment><USER71> At this point, Unity is a WIP engine with a boat load of alpha packages.

<comment><USER67> The problem is, there's 2 Unitys now, mixed up in one product, in various states of development.

There's 'Unity Classic', and 'New Unity'.

Almost everybody is using Unity Classic, but Unity is very focused on building 'New Unity' (DOTS/ECS, SRPs, Shader Graph, UI Elements, new input system, etc), which is intended to replace practically all of 'Unity Classic' one system at a time. It should probably have been a separate product, really.

</comment></comment><comment><USER72> Unity does miss on a lot of things, but I'd like to point out one of its best qualities: the pricing model. Compared to Unreal, Unity is a steal. Despite Unreal's recent changes to not collect royalties on the first $1m of gross revenue, its license can get quite expensive if you have a successful game.

* Unity: $1800 / year, no royalties. (Unity Pro)

* Unreal: 5% of gross revenue.

<comment><USER27> If you have a 10 person team and your game makes $10M after roughly 2 years dev, with Unity you spend about $2,036,000 but with unreal you pay $2,500,000, just taking development and licensing costs into account.

If unreal gave you 20% more productivity due to being more stable, I think even successful games come out ahead by being able to release sooner (saving money on dev time), or by better sales from having a more stable and visually appealing end result.

Unity is costing me days per week right now fighting with flickering terrains or line renderers that throw errors, all stuff that ends up in the ever growing "known issues" list

<comment><USER72> Curious how you're getting $2m? Are you the Enterprise plan?

</comment></comment></comment><comment><USER73> Pretty much everything. Godot is where it's at.

</comment><comment><USER74> Your webpage, in particular the barely visible animated background of it, consumes 100% of GPU on my 2012 Macbook Pro. This is bad website design from an energy point of view.

</comment><comment><USER26> No mentioning of the asset store - almost got scammed by the author of a popular terrain shader author. Fortunately Unity issued a refund, but the person has been quite bullish on their forum and is still selling there. As a fee forum admins told me - stay away from the asset store, or at least buy from companies you can hold accountable.</comment>


Incredible pictures from the Redbull Photography Contest - <AUTHOR> http://www.theatlantic.com/infocus/2013/08/winners-of-the-red-bull-illume-photo-contest-2013/100583/ <comment><USER2> I need to find a good periodic reminder that if I ever find myself in need of inspiration on branding strategy, to look at Red Bull first.

<comment><USER3> But unfortunately it takes lots and lots of money to apply Red Bulls branding strategy.

<comment><USER4> It takes a lot less than you might think. It's the same branding strategy that outdoor sports companies follow, and they are generally not rich companies. There's far less money in the outdoor industry than the tech industry (I've worked extensively in both.)

Adventures sports are cheap. The athletes don't need much money to be happy, and the main cost of sponsorships are transportation.

But, that doesn't mean adventure sports are the right brand strategy for every company. It works for Red Bull because that's their business. It would not work so well for Uber.

<comment><USER5> >It works for Red Bull because that's their business

Red Bull sells sugar water. How is it their business?

<comment><USER6> Branding is their business. Caffeinated sugar water is their product. Red Bull's target market is presumably males aged 13-26, who respond positively to sports and testosterone-driven imagery. This positive response means more sales of said sugar water.

</comment></comment></comment></comment></comment><comment><USER7> Beautiful - but I'd like to also see all the pictures before photoshop.

<comment><USER8> Why? It's part of the creative process - a good photographer will consider all tools available to them, including post-processing, in order to achieve the shot they envisage.

<comment><USER9> It's two different forms of art. You have photography and post-processing. Both are arts and doing both together is even more difficult.

<comment><USER10> Post-processing in digital photography usually denotes the process equivalent to developing the film in film photography (which can be a complex process where multiple choices can be made that affect the result). Sharpening, noise reduction, brightness, contrast and so on. These are an integral part of the workflow - nobody would simply publish raw images straight from the camera (turning the raw sensor data into a JPEG involves multiple choices that _someone_ has to make - it's either the photographer or the engineers that wrote the default conversion algorithms built in the camera.)

<comment><USER9> There are various movements in photography. You still need to use some techniques while doing some photographies but usually for straight photography, it ends when you press the shutter.

But I suppose that Henri Cartier-Bresson expressed it in a better way:

"Of all the means of expression, photography is the only one that fixes a precise moment in time. We play with subjects that disappear; and when they're gone, it's impossible to bring them back to life. We can't alter our subject afterward.... Writers can reflect before they put words on paper.... As photographers, we don't have the luxury of this reflective time....We can't redo our shoot once we're back at the hotel. Our job consists of observing reality with help of our camera (which serves as a kind of sketchbook), of fixing reality in a moment, but not manipulating it, neither during the shoot nor in the darkroom later on. These types of manipulation are always noticed by anyone with a good eye." Henri Cartier-Bresson - "American Photo", September/October 1997, page: 76

<comment><USER10> Post-processing in the sense I referred to usually has the goal of _replicating_ , not altering, the moment of firing the shutter. Cameras (film OR digital) do not see the way the eye sees; the image straight from the camera (which, as I said, does all sorts of automatic processing to be able to create the image in the first place) is rarely a faithful presentation of what the photographer saw -- not to mention the subjective _mood_ of the moment that the photographer is trying to capture.

I think it's a very small minority of photographers indeed that are purist enough to consider things like cropping, levels, and white balance "altering the subject" in some reproachful way.

</comment></comment></comment></comment></comment></comment><comment><USER11> Here's a video from that ship wreck BASE jump site: [http://youtu.be/YSuo0j2xsj8](http://youtu.be/YSuo0j2xsj8)

</comment><comment><USER12> Awesome pictures! But Kelly Slater[1] didn't win the US Open of Surfing this year. Alejo Muniz did[2]. I find it odd that someone from Surfing magazine would get this wrong. Perhaps this pictures from 2011 not 2013?

1\. [http://www.theatlantic.com/infocus/2013/08/winners-of-the- re...](http://www.theatlantic.com/infocus/2013/08/winners-of-the-red-bull- illume-photo-contest-2013/100583/#img17) 2\. [http://en.wikipedia.org/wiki/U.S._Open_of_Surfing#U.S._Open_...](http://en.wikipedia.org/wiki/U.S._Open_of_Surfing#U.S._Open_Champions)

<comment><USER13> The photo contest actually picked photos from the last three years. Some of the snowboarding photos are also from 2011.

<comment><USER12> Ahh I missed that, thanks

</comment></comment></comment><comment><USER14> Redbull? Pay for injuries at your advertising functions. Yes--even during practice. If you didn't dangle money in front of these kids; they wouldn't be "pushing the envelope ".

<comment><USER15> That's not true. I never got paid and I pushed the envelope all the time.

<comment><USER16> He was talking about "those kids".

You might have "pushed the envelope" unpaid, but a lot of those go the extra mile for the Red Bull pay/fame, including trying BS stunts that don't end well.

<comment><USER17> And that is their choice.

<comment><USER16> Only if you're a hardcore "all is personal choice" type, that denies psychology, fame and money as lures, peer pressure, people with reduced capacity to resist to such things (especially immature early 20-somethings), etc.

People don't make choices in a vacuum, and they don't make perfectly rational informed choices either. People make choices influenced by tons of BS input, in which a lot of that input is designed to dupe them and lure them out of their money or use them in some way.

</comment></comment></comment></comment></comment><comment><USER18> Infocus tip: You can easily scroll through the images with the keys 'j' and 'k'. And seriously consider checking out the other infocus galleries; Alan Taylor curates well.

<comment><USER19> Don't forget The Big Picture from boston.com for similarly awesome content: [http://www.boston.com/bigpicture/](http://www.boston.com/bigpicture/)

I really wish all news sources provided high resolution photographs with their articles. This is 2013, I should not have to squint at a 250px wide photo.

</comment></comment><comment><USER20> I don't want to sound bitchy - but this is the second time today I see content here where my first impression is: This doesn't belong here. Please post this to Reddit.

What's comming up next? HN AdviceAnimals?

<comment><USER21> my thoughts exactly. posts like this make me wish for a downvote button. Or are there for users with very high karma, like there are for comments?

<comment><USER20> From the FAQ: "There are no down arrows on submissions."

:-)

</comment></comment></comment><comment><USER22> Wow the Bouldering is amazing. So much fun and so dangerous!</comment>


Trusted Types Help Prevent Cross-Site Scripting - <AUTHOR> https://developers.google.com/web/updates/2019/02/trusted-types <comment><USER2> I'm a little skeptical. The example in the post, where you validate a URL against a regex before string-interpolating it into an HTML fragment, is essentially an anti-pattern. It's too easy to screw up the regex and end up with an injection vector, especially in cases (probably the majority of them) where the thing being validated is less inherently constrained than "alphanumeric". Instead, it's best to use APIs that are safe by construction - in this case, using DOM APIs to create elements, without ever going through the intermediate string representation of HTML. See also, "Never sanitize your inputs!":

[http://blog.hackensplat.com/2013/09/never-sanitize-your- inpu...](http://blog.hackensplat.com/2013/09/never-sanitize-your- inputs.html?m=1)

But if you use DOM APIs for everything, this "Trusted Types" API seems largely unnecessary. It would be enough to expose a switch to disable innerHTML and similar APIs entirely.

On the other hand, DOM APIs are rather unergonomic to use raw. Many wrappers exist, but React's JSX takes the cake by letting you write code that _looks_ like string interpolation, yet compiles down to type-safe node creation. (Kind of like what parameterized queries do for SQL.) If we're looking at browser- based approaches to solving XSS… how about standardizing something like JSX as a built-in browser feature? That way it could be used by everyone, even those who want to minimize dependencies or code directly for the browser.

(Yes, I know it's been tried before, in the form of E4X. But that was a very different era…)

<comment><USER3> Trusted Types are definitely designed with safe-by-construction APIs in mind. A primary use case is to write a safe-by-construction library that internally declares and uses a Trusted Types Policy that your CSP headers declare that they trust.

If none of the policies in your CSP headers declare a createHTML method, then you can be confident that innerHTML can't be used anywhere in your app.

You still want the other policy methods because there are other unsafe sinks in the DOM. For example:

        const scriptElem = document.createElement('script');
        scriptElem.src = someUntrustedInput;
        document.body.appendChild(scriptElem); // arbitrary code execution!

There's a number of these sinks, and they have legit important use cases, but you want to be able to sustainably review all such uses. For example, you could make a Trusted Types policy that will only accept a small number of constants for script urls. That way you can still create script elements to e.g. implement lazy loading of code, but you're certain that those APIs will not be used by an attacker to load unknown code.

</comment></comment><comment><USER4> I am surprised more programming language research hasn't focused on problems like this. Perl had taint mode back in the day (presumably it still exists), but it didn't quite do enough to really be helpful. I am glad to see this idea resurfacing because I think it can solve a lot of problems, not just security- related.

A long time ago, I remember people having an insane amount of trouble with character handling; when you read binary data from a TCP socket or UNIX file, you're reading bytes, not characters. But many people would treat the bytes like characters, causing all sorts of trouble. My favorite was the double- encoding, where you read UTF-8 encoded characters as bytes, treat the bytes as Latin-1, then encode the Latin-1 characters as UTF-8. This was a perl quirk because Latin-1 was the default, but the same bug happens in other languages. Anyway, a good tainting system could prevent this sort of bug. The language can say "hey, this is a TCP socket, you can't treat those bytes as characters!" But it doesn't. And the bug occurs again and again.

(The corner cases that people don't think about are the real problems. What charset are those bytes in your URL? What about filenames? The answer is: it's often undefined. So rather than hope for the best, a compiler error would be ideal.)

The state of the art, as far as I can tell, is to just treat everything as UTF-8 these days. Since everyone seems to love UTF-8, it just works. Maybe that was the real solution. But I know there are a lot of Japanese-speakers with names that can't be encoded as UTF-8. I wonder what they're doing about that.

<comment><USER5> I feel like Python 3 has largely resolved the bytes vs characters problem. Byte arrays and strings are different classes in Py3. File and socket I/O deals only in byte arrays which are treated more like lists than strings. To perform a lot of string-like operations, you have to explicitly decode the byte array into a string. If you get it wrong, you'll likely get either a TypeError.

<comment><USER4> This is good, but I'd prefer the error to occur at compile time. Consider the case where you do something like creating an error message because you can't open a file, and want to include the filename. The filename is bytes, the error message is a string, so instead of being able to print the error message, you instead throw an undebuggable exception.

Dunno if that in particular is a problem in Python or not... but it is the sort of thing to watch out for.

<comment><USER5> In Python, filenames can be either bytes or string.

Also, I made a mistake in my previous post. File I/O can deal with bytes OR strings depending on the parameters sent to the `open()` function.

      file_handle = open('somefile.txt')

This opens the file in text mode (so `file_handle.read()` returns strings) using a platform-dependent encoding. On Windows, this will probably be CP-1252. On Linux, UTF-8. Of course, you can always explicitly choose the encoding:

      file_handle = open('somefile.txt', encoding='utf8')

If you know you want to only deal with bytes, you can explicitly set that:

      file_handle = open('somefile.ext', mode='rb')

I agree that it'd be nice to be able to see bytes vs strings errors at compile time, but this is difficult or even impossible with a duck-typed interpreted language like Python. IDEs and linters can make a good attempt at it, but they're not perfect.

</comment></comment></comment></comment><comment><USER6> How about just don't use innerHTML? It's slow, insecure and lazy. We don't need Google pushing more proprietary fake web standards in their IE6 browser. They should fix the existing issues in CSP (like WebAssembly being completely broken) before adding new crap to it.

<comment><USER7> There's a lot more XSS sinks than innerHTML, and "just don't do it" isn't helpful security engineering. Mike Samuel published a great post with lots of context on the design of Trusted Types at Google and why they think it works well:

[https://github.com/w3c/webappsec-trusted- types/wiki/design-h...](https://github.com/w3c/webappsec-trusted- types/wiki/design-history)

<comment><USER6> It's a lot of handwaving. So Google improperly saved HTML into database string fields and now needs to figure out how to safely render it in a template. We don't need a new web "standard" to help them wallpaper over their first-party bugs.

For the longest time Firefox add-on developers were prohibited from submitting extensions with eval or innerHTML precisely because it is ~not safe~! Adding a bunch of browser-enforced regex checks to your strings is the wrong solution here. The solution is to not write code that writes itself.

<comment><USER8> > So Google improperly saved HTML into database string fields and now needs to > figure out how to safely render it in a template.

FWIW, "store anything, sanitize at render time" is the preferred approach for some popular web frameworks, including Rails.

<comment><USER6> And that's fine. To the extent that stored data represents a security risk, sanitization can and should be done on the server side.

</comment></comment></comment></comment></comment><comment><USER9> Am I reading this correctly.. creating a regexp introduced into a template, then applying that template to a value in the web request?

<comment><USER10> Pretty much. Interestingly it is a very similar approach to Perl's "taint mode". The intention is obviously that you can't blindly use/output values that are user-provided. Instead you must validate, and convert them to a "trusted type", at which point you can use them in your DOM tree, or wherever you wish.

The big difference is that if you forget a place here you'll get a type error - rather than the current situation where if you forget to validate/sanitize you get an XSS attack.</comment></comment>


How The Kernel Manages Your Memory - <AUTHOR> http://duartes.org/gustavo/blog/post/how-the-kernel-manages-your-memory

<comment><USER2> That's a must read for anybody new to programming in some compiled language. If you're scripting (perl/python/php/p*) then it is probably less applicable but still useful.

Amazing the amount of work that must have gone in to writing that article.</comment>


Capistrano help for PHP deployment - <AUTHOR>

Hey All, I'm asking for help w/ capistrano.  I've installed the latest version which I believe to be 2.1.0.  First, I have zero experience w/ rails so please bear w/ me. I'm using capastrino cuz I've read in blogs that you can use it to deploy php applications, which is what I'm trying to do.
After struggling w/ it all weekend, I have it working and its deploying my app from subversion which is on my own linux box, to another server that I'm paying for.
Here are my questions:
1. In order to modify the deployment process (ie. symlink different file paths), I ended up directly editing the deploy.rb file located in the recipes directory under the capastrino install.  Is this the only way to modify the deployment process? I do have another deploy.rb file located in the config directory of my app.  But it is my understanding that this file is to setup your subversion server, the production server, username, etc...
2. This is more of a linux question, which I'm also new to...The way I have it deploying now requires me to keep entering in my password.  I do have my servers setup w/ ssh keys, so I'm not sure if I've done something wrong there or if the current process is what I should expect.  Anyways,  below is a transcript of the deployment:

 [halbertn@linux config]$ cap deploy:update
 You are running Ruby 1.8.6, which has a bug in its  threading implementation.
 You are liable to encounter deadlocks running Capistrano,  unless you install
 the fastthread library, which is available as a gem: gem install fastthread
  * executing `deploy:update'
 ** transaction: start
  * executing `deploy:update_code'
 Enter passphrase for key '/home/halbertn/.ssh/id_dsa':
 firstname.lastname@example.com's password:
  * executing "svn checkout -q  -r121  svn+ssh://my.linuxbox.net/var/svn/ah/trunk  /var/ah/releases/20071224212935 && (echo 121 >  /var/ah/releases/20071224212935/REVISION)"
    servers: ["xx.xxx.xx.xxx"]
 Password:
    [xx.xxx.xx.xxx] executing command
 ** [out] Enter passphrase for key  '/home/halbertn/.ssh/id_dsa':
 ** [out]
 ** [out] email@example.com's password:
 ** [out]
 ** [out] Enter passphrase for key  '/home/halbertn/.ssh/id_dsa':
 ** [out]
 ** [out] firstname.lastname@example.com's password:
 ** [out]
    command finished
  * executing `deploy:finalize_update'
  * executing "chmod -R g+w /var/ah/releases/20071224212935"
    servers: ["xx.xxx.xx.xxx"]
    [xx.xxx.xx.xxx] executing command
    command finished
  * executing "rm -rf /var/ah/releases/20071224212935/log  /var/ah/releases/20071224212935/public/system  /var/ah/releases/20071224212935/tmp/pids &&\n      mkdir -p /var/ah/releases/20071224212935/public &&\n      mkdir -p /var/ah/releases/20071224212935/tmp &&\n      ln -s  /var/ah/shared/log /var/ah/releases/20071224212935/log &&\n       ln -s /var/ah/shared/system /var/ah/releases/20071224212935/public/system &&\n      ln -s /var/ah/shared/pids  /var/ah/releases/20071224212935/tmp/pids"
    servers: ["xx.xxx.xx.xxx"]
    [xx.xxx.xx.xxx] executing command
    command finished
  * executing "find /var/ah/releases/20071224212935/public/images /var/ah/releases/20071224212935/public/stylesheets /var/ah/releases/20071224212935/public/javascripts -exec  touch -t 200712242130.47 {} ';'; true"
    servers: ["xx.xxx.xx.xxx"]
    [xx.xxx.xx.xxx] executing command
 ** [out :: xx.xxx.xx.xxx] find: /var/ah/releases/20071224212935/public/images: No such file or directory
 ** [out :: xx.xxx.xx.xxx] find: /var/ah/releases/20071224212935/public/stylesheets: No such file or directory
 ** [out :: xx.xxx.xx.xxx] find: /var/ah/releases/20071224212935/public/javascripts: No such  file or directory
    command finished
  * executing `deploy:symlink'
  * executing "rm -f /var/ah/current && ln -s /var/ah/releases/20071224212935 /var/ah/current"
    servers: ["xx.xxx.xx.xxx"]
    [xx.xxx.xx.xxx] executing command
    command finished
  * executing `deploy:symlink_photos'
  * executing "rm -r -f /var/ah/current/public/photos && ln -nfs /var/ah/shared/photos /var/ah/releases/20071224212935/public/photos"
    servers: ["xx.xxx.xx.xxx"]
    [xx.xxx.xx.xxx] executing command
    command finished
 ** transaction: commit

 Any help would be much appreciated.
Thanks! <comment><USER2> 1) I highly suggest NOT changing the deploy.rb file in the Cap gem. You can override any task in your own deploy.rb file. For instance:

namespace :deploy do

      desc "Custom stop task"

      task :stop, :roles => :web do

        #My custom "stop" command

      end

end

(as a side note, does anyone know how to do code formatting on here?)

2) I think from what you're saying- it is deploying correctly, but you're confused as to why it is asking for your password three times? This is common, and I think it is a bug with Subversion. I deploy using svn+ssh as well and get the same thing. If I remember correctly, you only have to enter in your password correctly for the first one, and can just hit enter through the other 2. Alternatively, you can make sure you have your SSH keys set up correctly.

</comment><comment><AUTHOR> Thanks for the response guys!

I followed carpal's suggestion and all modifications to my deployment are done in my own deploy.rb script. I guess I have no choice but to deal w/ the numerous password requests.

My only question now is what 'user:group' should I assign to my app? My app is a website that I want publicly accessible so my first inclination is to set the app directory as 'root:root'. However, if I do this, then the deployment script must be run under the root user. Is this a good idea? I was under the impression that deployment should be handled by a separate user other than root.

For example, I want my app to be deployed to the following directory:

/var/www/app

Then, I would set the document_root in my appache setting to:

/var/www/app/current/

It is my understanding that if I want to be completely secure, than that whole directory should be set to the 'root:root' user:group ownership property.

Jd, I look forward to your write up!

Thanks!

</comment><comment><USER3> I'm writing the chapter on Capistrano deployment on non-Rails framework for capify.org. If you can wait for a week or so maybe I can help you. Or maybe also post to a more readable copy of your error and comments off-site?

</comment><comment><AUTHOR> sorry...i didnt know that my formatting wouldn't stick. if you do look at the transcript, you'll notice it asking for my ssh key and password a couple of times.</comment>


Ask HN: Where to work in NYC? (I'm a fresh comp sci grad) - <AUTHOR>

Dear Hacker News,
I am graduating this Fall from NYU, bachelors in computer science, near perfect GPA. I want to stay in the city and with Silicon Alley and all, where is a good place to work?
My choices are
1. Google 2. Hot shot startups - Foursquare, Stack Overflow etc 3. Pivotal Labs
How do all these stack up? And what is important to keep in mind for the first job? I trust HNers more than my NYU career counselors!
Feedback/comments/suggestions please! <comment><USER2> Jane Street Capital - these guys are _the_ place to be for doing ML/functional programming in the real world.

</comment><comment><USER3> If you want to start companies yourself, then start/co-found a company is the way to learn it.

If you want to start companies in future but you want to see at first hand how to run a startup, join any startup that you are interested in.

If you want to dig deep into technologies, probably Google is the best for you.

Then you still have all financial megacorp, Bloomberg, Two Sigma Capitals, D.E. Shaw, SAC and other hedgefunds if you just want to have a financially stable life.

You said you want to stay in side NYC. Otherwise, I recommend you to try companies in Seattle and SF and Silicon Valley.

The most important thing in any first job is to learn your stuff quick.

</comment><comment><USER4> Bloomberg LP - Interning there right now, they are a hot spot for new hires. Ridiculous expansion plan and awesome benefits.

Edit: Also, as mentioned below all the financial powerhouses and banks (I'd personally stay away though).

</comment><comment><USER5> If you have any interest in rolling the dice with a fresh startup, I am looking for co-founders to take my site to the next level and raise funding. Am definitely open to launching the new version of the company in NYC, so message me if interested (or if you know folks who might be).

</comment><comment><AUTHOR> Yes I forgot. Applied there too ;-)

How about Pivotal Labs? There is nothing on HN about them.</comment>


Kicked out of uni – internships, jobs? - <AUTHOR>

I'm not sure how to spin the fact that I was kicked out due to a low GPA. Do I lay everything out in front and aim to get rejected early by those to whom it matters? Do I put "attended" without indicating that I'm no longer a current student?
I'll retake some classes and get back in via a readmission contract, and in the meantime I'm being treated for depression, which likely was a factor in my poor performance as I've felt this way for years. However, I doubt employers would care about such details. So, how should I move forward? I have some projects to show off, but they're not amazing to the point of making up for my situation.
Thanks in advance. <comment><USER2> 12 years ago I was kicked out of college due to a low GPA. I just listed the college on my CV as attended, but never indicated any type of degree.

For me, having a portfolio of work was more important than the college I attended. If you don't have a portfolio, do some free work for a local business in exchange for a testimonial.

Don't go for internships, look for Jr. positions, find something that pays.

</comment><comment><USER3> I am not sure where you are geographically so and some of my advice will depend on your location and, more specifically, how many potential positions there are.

First off, if you have some programming skills, and it sounds like you do, do not go for internships. Internship positions seem to be very specific to students. They may want to check with your University and such, which is a no go in this situation. Instead go for "Entry level" or "Junior" development positions. A lot of these will be very junior and won't expect a huge level of skill. Make sure to set your salary expectation accordingly, to make yourself marketable.

Second, if you are planning to continue to go to school put down the fact that you are attending. You probably won't be asked, but if you are asked about your current status say you are on hiatus. I would be intensionally vague. A lot of us had rough times in school for a lot of reasons! Talk about how much you enjoy school and how important it is for you to be successful at it and how the real world experience you are gaining will help in your education. These are all true statements. I would not come right out and explain that you were put on probation for academic reasons.

Next, and this is probably the most important part, apply for a lot of positions. A lot of people really mess this one up. They read the perfect job description. It fits them just right. They apply and wait. Don't fall into this trap! Getting a job really is a numbers game. Apply for as many positions as you can find in your chosen field and area. I have often said, and have yet to be proven wrong, that is you apply to 50 jobs, you'll certainly get one.

Finally, on a personal note, chin up! School and this time of your life really are hard. That's nothing to be ashamed of! You have not ruined anything and you have a lot of great days ahead. It's great to hear that you are seeking help for depression. Keep going. You'll find your way and this will all work out.

</comment><comment><USER4> I would put "attended" on the resume. Do not volunteer information about depression in an interview. Start sending out resumes and discuss your projects in your cover letter.

</comment><comment><USER5> I started my academic journey when I was already working and during that journey, that lasted over a decade, I was ex-matriculated more than several times.

I kept going back and I finally graduated.

I think that an academic education is important, but you should make clear for you what you are after - you should look at your program and make up your mind about what you want to get from university.

More importantly, you should make sure that you actually are willing to put all your energy at given moment into your education.

From my experience, it will not get any easier over time.</comment>