What Unity Is Getting Wrong | Hacker News Reader

What Unity Is Getting Wrong

garry.tv

362 pointsReticentVole297 comments

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.

> Unity has more engineers than Epic.

It's funny. I see it (anecdotally) all the time. More engineers doesn't mean a better product.

In fact at my old shop, things (product, quality) really started declining once we 'rapidly' scaled the team. Communication and consistency really suffered from lack of solid processes among other things.

I think it comes down to power in the company. 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.

I recently read that Tim Sweeney still writes code for UE, something absurd - 80% of the codebase is his?

That's awesome. Lead from the front. He does it becomes he loves it and knows what he is doing. I really admire those kinds of leaders.

I don't know if this is true but I don't see why it would be absurd. The man is pretty much an absolute gaming and coding legend and from what I've read about him, he's genuinely interested about code and tech so if that's true I find that actually pretty awesome.

Absurd would be if he had to just stick to management and bureaucracy just because he has a few billions on his bank account. You do you Tim!

Source? 80% of such a massive codebase seems like a stretch. Ue3 alone had over 3 million lines

I doubt that's true now, but it could've been something like that when UE4 released. The story went that he'd started work on it almost a decade before the release of the engine.

I think UE and Unity has complete different markets. Unity is focused on small mobile game developers, those small shops don’t have expertise to work with UE C++ source code and most of them are new grads themselves.

I’m not sure what is the overall strategy of Unity but I don’t believe they care much about the PC/Console space and frankly at this point I don’t believe they will ever manage to capture it from UE.

> Unity is focused on small mobile game developers

Someone remind Unity of that.

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 using Unreal Engine results in a smoother process and is more likely to result in a AAA target game being AAA. It could be that AAA studios area already predisposed to use Unreal Engine. It could be both. It could be that Unreal Engine is just better at marketing to larger studios given their pedigree.

1: https://en.wikipedia.org/wiki/List_of_Unity_games

2: https://en.wikipedia.org/wiki/List_of_Unreal_Engine_games

The OP article is written by Garry Newman the developer that did Rust in the Unity list from 2013. Previously he was the developer of Garry's Mod on Valve Source engine.

I'm not sure what you're trying to communicate. That Rust is a AAA title? It's not, as I understand it. AAA is not a designation of quality or popularity, it's a designation of resources that go into it. Large company with lots of resources putting lots of money behind it means AAA. It's less a designation of the end product than of the process going into that product.

Just mentioned that it was on the list of games in terms of popularity, never said it was AAA.

However, Garry has lots of pull in games including towards AAA developers. I did not say that game was AAA but on the notable Unity list that everyone knows about.

Rust is much bigger than most Unity games, so Garry's opinion on this is highly relevant and influential. Facepunch studios and their forums were also a gamedev spot for a long time.

Garry Newman is also someone speaking from shipping experience in another engine that is for AAA studios, Valve Source Engine. Eventhough that was a mod, and yes not a massive budget or team, it has pull at the AAA level in terms of influence as well.

Rust competes with AAA titles on Steam in terms of playtime/playercount all the time, was top 10 for a while and quite often. [1]

The point is Garry's opinion is more valid than most, even at AAA probably about Unity. A developer of a top 10 Steam game has some pull and is someone to listen to, hopefully Unity hears it. Rust is clearly one of the biggest games in terms of playtime/playercount than most Unity games at least on Steam with the popularity only rising since release in 2013.

Rust is AAA level in terms of playtime/playercount with a small team, that is exactly the market Unity wants, in fact it highlights the benefits of Unity clearly. They should listen.

[1] https://steamcharts.com/app/252490#All

I think you misinterpreted my original comment (which is why yours seemed like a non-sequitur to me).

I wasn't saying Garry doesn't have any big games, I was saying that the list of games made using Unity doesn't include many big/AAA games. I also wondered why this might be.

To clarify, I'm not saying there aren't AAA Unity games, just that I didn't immediately see one. Nor am I stating that Rust is not as good as a AAA game, I made my position clear that AAA is more to do with resources. I would even go so far as to say it's more of a marketing term. What I am saying is that is seems like (from the lists I saw) a lot more large and AAA titles are made using Unreal Engine, and I wondered what specifically leads to that.

> The point is Garry's opinion is more valid than most, even at AAA probably about Unity.

I'm not sure why that's the point. It has absolutely nothing to do with what I was talking about. This thread was about Unity being better targeted as small/indie/mobile developers, and I was responding in that context.

Ok yeah we were talking past each other initially, I see what you are saying now.

I never really mentioned AAA and the reply I made about Rust was also saying that they said "Not sure I saw a AAA game on the list" which is true in terms of budget/team size but not playtime/playercount for a few games on the list.

The biggest games in Unity are probably Rust and Kerbal Space Program merely in terms of playercount/playtime and they do compete with AAA on those metrics, not team or budget size. Both teams have complaints about Unity, as everything, as long as those are addressed things progress.

That is the problem though, Unity is chasing AAA/more licenses when their main target is mobile/smaller scale games and doing that simply. That is the reason both Rust and Kerbal started using Unity, simplicity.

Garry picked Rust in 2013 for the simplicity as he says

> "Unity was about that when we first started with it. 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#."

With Unity Rust is competing at the level of playercount/playtime with AAA. That is literally the thing Unity wants the most and their selling point. Unity you can have smaller developers, able to make games that can compete with less team, with a focus on simplicity and being the engine team that makes transitions easy. It is also ok if they are hard transitions if there are major improvements. Unity is many times asking you to update to a new system that is the same or sometimes less than what you need in terms of benefit, and then only to be half complete and then changed again.

As Garry said

> "So while other engines have been trying to catch Unity up in terms of developer friendliness, Unity has been going the other way by making itself more unfriendly."

They are losing the simplicity selling point.

Unity can make games that compete, they should be taking these critiques to heart strongly as teams/games like Rust and Kerbal are exactly the target they should be going for along with smaller games/mobile games etc.

Unity has so many internal developers now, that requires alot more communication needs, testing needs and maintenance. It also pulls the company in many directions if there is no clear engineering/product lead at the top and it is all management/business/finance pushing feature based development which gets them into version 2 syndrome or the "second-system effect".

> The second-system effect (also known as second-system syndrome) is the tendency of small, elegant, and successful systems to be succeeded by over-engineered, bloated systems, due to inflated expectations and overconfidence.

If the second-system effect doesn't describe Unity I don't know what does.

Get back to simplicity Unity, let the engineers/product people have power to set this back on course. Stop catering to big developers, they make their own engine for this reason, consistency and simplicity of their own process. Dogfood Unity with an actual game, the problems will be clear today. If you aren't doing that, listen to people like Garry who are.

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

Yeah, I don't disagree with any of that. :)

AAA studios have a millenia of C++ experience in-house so it just doesn't make sense as a product to them.

Unreal is for people who get games financed. The demos looks great and the execs don’t play games anyhow so what do they know. That’s why it’s all FPSes, it’s stuff non-game-playing adults can understand just by looking at it. They will fund the most photoreal looking pitch for the Star Wars IP.

Unreal as an engine product is competing with Frostbite and Source Engine (the various engines Star Wars appeared recently) not Unity.

However EA and Respawn won those bids for a variety o reasons, mostly related to the mechanics of royalties and their support commitments.

It’s complicated. There are many forces at work, only somewhat related to engineering, that funnels the engines to one kind of game or another.

Jedi Knight: Fallen Order uses UE4 (I can't tell from your phrasing if you meant otherwise, but I figure I'd clarify.)

Escape from Tarkov might be the biggest Unity game on Twitch right now. Thanks to Unity you get game stutter and freezes during tense action. Escape from Tarkov devs keep promising every year that thanks to the close cooperation with Unity team 'this next update' is totally going to solve the problem! year after year it doesnt.

Game stutters and freezes during tense action sound like GC related problems. In theory it is solvable but I doubt that anyone is going to bother and actually put in the work. Lots of popular games have known flaws and unless there is a direct competitor nobody is going to switch games.

Hearthstone is the largest that comes to mind, I'm not sure if it qualifies as a AAA game but it's from a large studio with a lot of experience and earns AAA money.

So a virtual card game where most of the complexity is server side?

Hardly a complex product compared to some, yes, but time to market and speed of iteration are still important. I don't like the game but the presentation and feel was good when I tried it.

I don't know how well it worked out for them overall though, and I don't recall seeing them use Unity again on another game.

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.

But it's more fun to work on 5 different rendering pipelines! They're definitely trying to please everyone without really catering greatly to anyone. Like the official 2D capabilities are still about as hacky as what I implemented 5 years ago myself in about a month of work at a mobile games studio.

A lot of mobile game developers who use Unity aren't small at all. They are huge companies with lots of experienced engineers. The baby devs don't generate the $ for Unity.

Mobile games in some sense have taken over gaming. They're not as flashy, but the amount of money some of them seem to generate is obscene. Just take a look at NCSoft's income and how mobile Lineage crushed all of their other offerings.

> A lot of mobile game developers who use Unity aren't small at all. They are huge companies with lots of experienced engineers. The baby devs don't generate the $ for Unity.

Even if they are large companies, the teams are still small and the point of Unity is simplicity.

Unity wants to be AAA for console/desktop but mobile is their bread and butter as you say. Companies and indies chose it for simplicity and there are lots of Unity developers. They are messing up the simplicity angle and going after new markets but causing pain for their existing customers. I get they want to grow and sell more licenses, but I'd argue most of their paying customers are indies, smaller mobile studios and larger mobile studios the have many small game teams.

Unity also make lots of money from the asset store. All these constant breaking changes also break many assets.

Unity just need a more consistent surface level API/signature/facade, and move the hard stuff down below that for most cases with advanced modes accessible with more setup/work. Their changes now are making people that don't need AAA level output, more cartoony mobile games, do unnecessary work losing out on their selling point of simplicity.

this is very interesting -When Unreal 4 swapped out UnrealScript for C++ it went into overdrive in terms of performance and clean.

why do you think this happened?

why was C++ so much better

Because there is excellent tooling for C++, while they had to reinvent all the tools from scratch for UnrealScript.

I believe that ReSharper C++ alone makes me 10-20% more productive. Their refactorings and inferred constants are amazing and produce real-world performance benefits. Plus having const wherever it is warranted makes code easier to read and easier to debug.

Why ReSharper and not CLion?

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

C++ is very common in gamedev largely for the performance, less learning another language and more direct. UnrealScript in previous Unreal versions was simple but so is the necessary C++ for Unreal 4. Developers can make pure C++ games, or they have a simpler way using Blueprints that you can add into C++/Blueprint mixed games [1][2], or purely Blueprint that helps for non programmers though they are slower. There was lots of work to keep UnrealScript synced with the engine. Without that middle layer of a DSL, going direct is also important since everything needs to perform on mobile but also be native/AOT compiled. Helps for consoles, desktops and web as well.

Fun fact: Unity was going to go to C++ in 2013 during the Apple blocking Flash and other JIT tools, Unity thought they were going to be blocked from mobile publishing. [3] Since you can't run interpreted code Unity was going to go C++, I wish they had with C# as a scripting language maybe. Instead Mono had AOT compiling around that time but since the Mono license was expensive they built IL2CPP which takes byte code and makes C++ from it. About a year later Mono was bought by Microsoft and it would have been free for Unity to integrate. Though I still wish they would have went C++ with C# scripting that creates C++, would have been an easier route. I believe much of their problem is all these complicated legacy/translation systems at the base of the engine, which just going direct C++ would be easier with scripting on top of that that directly converts to C++.

Godot you can also use C++ and other languages including C#, GDScript. [4]

Early days of Unity you could use C#, Javascript, Boo (Python flavor) or anything that Mono supported.

[1] https://docs.unrealengine.com/en-US/Resources/SampleGames/AR...

[2] https://docs.unrealengine.com/en-US/Gameplay/ClassCreation/C...

[3] https://blogs.unity3d.com/2010/07/02/unity-and-ios-4-0-updat...

[4] https://docs.godotengine.org/en/stable/tutorials/plugins/gdn...

It comes down to a truism about generally anything: it's inefficient to figure out how to do a thing without some amount of doing a thing.

It's not a huge surprise someone building games makes a better game engine than someone building a game engine. Because they solved the problems they ran into!

You see this time and time again with businesses. Dogfood, and you'll have a lot better idea of where the warts are in your product. (And most importantly, waste less time fixing things you're convinced are warts, but nobody ever noticed)

> More engineers doesn't mean a better product.

But it often means higher overhead...

... and alot more communication needs, testing needs and maintenance. It also pulls the company in many directions if there is no clear engineering/product lead at the top and it is all management/business/finance pushing feature based development which gets them into version 2 syndrome. [1]

If the second-system effect doesn't describe Unity I don't know what does.

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

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

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

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

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

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

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

In my opinion, studios using Unity were always the ones too cheap to hire external freelancers to help their development, but instead going with copy&paste from (outdated) internet tutorials. I mean with Unity's deprecation speed, a tutorial from 2018 is basically unusable now.

So effectively, my work was mostly UE, because that's where the customers were.

But just out of curiosity, can you give me a hint where you found OK-paid freelance Unity work?

I'm Tokyo based so bunch of local multi-billion dollar companies doing Unity. Mobile games for the most part. A good chunk of their developers or either outsourced to smaller local studios, or contractors themselves.

Unreal contracting is even better. Most of the AAA studios switched from in-house engines to Unreal. Thus constant unmet demand for expertise and production on big console projects.

Granted what counts as okay money here might not match what you are hoping for. With the up side that Tokyo is never going to run out of gamedev work.

One of my on-boarding tasks at my first tech job was to evaluate the merits of upgrading to a newer version of unity. I installed the new version, imported our code base, fixed a few bugs, and everything worked. We gained a few niceties, we could remove some of the hacks we had to program in to bypass unity weirdness, and we could start keeping our product up to date. I gave a presentation, we went over the pro/con list, and decided to move forward.

It was awful. Every other programmers' attempts to upgrade failed, and each in a unique way. We had to pause releases to untangle everything. I felt terrible for derailing production my first week on the job, but after a dozen or so people took me aside to tell me some variation of "it's not you, its Unity" I learned a valuable lesson. You said it perfectly: the instability is not temporary.

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.

Just get to the LTS release and stay there.

The LTS is only supported for two years. That doesn't really solve this problem.

I think it is telling that in Unity world, 2 years is "Long Term". I wonder what cutting edge is? Building your entire game on the unstable weekly branch and crossing your fingers?

Most software products LTS are between 2 to 3 years actually, even stuff like Java.

Java SE 8 (LTS) March 2014 December 2030 Java may have a new LTS every few years, but they support their LTS releases for much longer.

That is the old model, the new LTS model is three years.

Oracle just extended it due to Java 9 being our Python 3, which is kind of pointless because all the packages that matter have migrated already.

But enterprise being enterprise, there are plenty of projects only now migrating to 8, and then there is that little robot that isn't even fully compliant with 8.

Not that I really know much about Java stuff, but it looks like maybe Amazon/OpenJDK are providing longer support lifetimes? [1]

And here's an official Oracle doc regarding Java support where they show Java 11 (LTS) being supported until either late 2023 or late 2026 depending on your support level. I'm not sure they provide free support anymore, or maybe that's limited and what you're referring to?

1: https://en.wikipedia.org/wiki/Java_version_history

2: https://www.oracle.com/java/technologies/java-se-support-roa...

Yes, free support is only three years.

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

There's how often LTS releases are released, and how long they are supported.

Ubuntu cuts an LTS release every 2 years, but they support them for 5 years.

It appears Oracle supports Java LTS releases for 8 years.

Java LTS model has changed for 3 years for releases past Java 9. We are on 14 already.

There's a difference between end-user software and software that you're going to produce things in.

2 years is a reasonable time to expect that the user will move on to the next LTS browser version. 2 years is not a lot of time to release a game without having to upgrade the engine mid-project.

Not just unity unfortunately. .net core LTS is 3 years, Firefox "extended support" is 12 months, some random library from cargo/npm/nuget probably not at all. "Long Term" is becoming a meaningless buzzword.

Companies cling to 40 year old COBOL because there's nothing stable enough to migrate to.

Java 8 EOL is 2030. There are plenty of stable options that are not COBOL.

Java has been one of the few that are more stable but I get the impression that's coming to an end. The support lifetime for the current LTS will finish 4 years earlier than Java 8 (according to wikipedia: https://en.wikipedia.org/wiki/Java_version_history) so it's trending down fast (although still good). It also looks that 2030 is only for people paying oracle, which isn't necessarily bad but it's something to consider.

There's also a lot more to consider than just how long an LTS lasts, like the degree of backwards compatibility and the rest of the ecosystem. It was my understanding that project jigsaw broke a lot of that, but I'm outside the java world so i didn't really keep up. .net for instance was great until recently because they had decent support lifetimes and kept backwards compatibility, so updating to the latest was at least simple and painless. Even trying to do those upgrades was like pulling teeth inside corporate environments though.

Honestly I've never seen this problem solved well for any game engine short of in-house engines(which obviously wouldn't break titles they were supporting).

It's been a while since I've been in the industry so maybe things have changed but last time I was there unit tests weren't even a thing. Smoke tests where if a set of levels loaded and didn't crash was considered success from an automation validation standpoint.

Well, things haven't really changed...

Last year's Unreal conference had a couple of talks related to engine migration and how teams managed to do them, which some mentioned they rather do it between projects than jeopardizing an ongoing game development cycle.

Middleware migration headaches are everywhere, regardless of the chosen stack.

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.

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.

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.

> 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 :/

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

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.

Mirror is amazing :) But it's a big shame for Unity that you need to use it in the first place, because they don't ship a working networking stack out of the box.

See - exactly like Javascript!

The more you can avoid the "nice" stuff the better your project will be. All those shiny things in the UI that look easy will be painful in the long run once they start disappearing (I swear component references just disappear sometimes) and breaking and making the life-cycle of the application confusing.

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.

What limitations does Javascript result in after initial FAST results as you say? All of the web is running on JS. It’s not without its faults but I resent the analogy.

Mmm... how’s that unreal engine version upgrade going for you? break your plugins? break your blueprints? can’t actually tell because they don't fail until you run them? :)

Just saying; A lot of people say this kind of stuff, but unreal isn’t all roses either.

(don’t believe me? read about it yourself https://forums.unrealengine.com/development-discussion/c-gam...)

Great, nope, nope, and nope.

I've been continously upgrading a couple months behind new releases on commercial projects since 2015. I've upgraded about 17 times so far. Unreal's update story is light years ahead of Unity's half-hearted "automated" mess.

Worse bug I had was back in 2016 when an upgrade lost reset the scale on weighted bones to 0.

Really depends on your code base and project. Unreal upgrades can be painful if you're using APIs that can or are rewritten, and if you have made engine level changes.

Unity often feels like rolling the dice with upgrades, basic things can break from version to version, but I've done many Unity upgrades with no or minimal issues, and seen extremely painful Unreal upgrades

It’s true that you really, really want to avoid making changes to the engine. Even for AAA studio source licensees in prior UE generations this was widely agreed upon. The good news is, you really shouldn’t have to.

In my mind, the big win from having the Unreal source code is understandability. But also, in contrast to Unity, if you should for some reason need to—say a critical bug that’s stopping your game from shipping at the last hour—you at least have the option.

Every AAA source licensee that I worked at made large changes to the engine source. There are many AAA titles both shipped and in development that change fundamental things about how the engine works. Look at the GDC presentation about Mortal Kombat rollback network, or its predecessor about running UE3 at 60 fps on console for some good examples. Completely avoiding engine changed isn't the reality for AAA, and I imagine it's only true for small indies. Good news is it's pretty easy to merge small engine changes.

Sure, I didn’t say changes don’t happen. Plenty of teams gutted UE and made it into something unrecognizable. But it shouldn’t be your first choice.

How about this... stick to small changes, freeze your engine upstream version, or hate your life: pick one? ;)

God, and whenever something is deprecated, they don’t update the documentation with new info and sometimes they remove pages of older info that’s still usable.

I also had a free edition installed on an old laptop and wanted to make a quick edit to an old game to send to someone. But nope, needed to update my license first to open the engine, but the version was old enough that the reactivation button somehow became invalid and rendered it unusable. Basically had to tell the person “I know exactly how to fix the issue with the game but Unity won’t let me.”

by comparison, ue4's documentation is just almost absent. Even lumberyard has better docs than ue4

Yeah a friend of mine tried to get into UE4.

When he came back asking questions that I would have expected to have been answered by the documentation, turns out... there just really isn't any. And the stuff that's there is various stages of incomplete or out of date.

When he got the point where he was like "Okay, I have to take this year old tutorial that doesn't work anymore, review the documentation to see if it's out of date as well, then grep the change logs for all the things it references to see where and when breaking changes were made and then go off on another Google-journey and hopefully find some sort of reference on how I'm supposed to use this new thing..." he just gave up. It wasn't interesting or fun anymore.

I can imagine UE4 is fine if you have an existing codebase and are just staying up to date with each new release. I was pretty flabbergasted that the documentation for a project of that size was so poor. I can't imagine how anyone would jump into a new project now.

It's not just the instability but it seems/feels like every cool new feature they implement is then never updated again.

I tried to write stuff in Unity as someone with a working knowledge of C# and who wrote code in it professionally in the past. No environment was as infuriating as Unity as seemingly everything I wanted to do was overridden by the Unity API, and their given alternatives both didn't work as advertised and were barely documented

It's not really necessary to say `This despite Epic developing both a cutting edge game engine + Fortnite.`. Fortnite as most people know it is Fortnite Battle Royale. FNBR was essentially a weekend game mod project to an already existing, but floundering, multiplayer game. Most people that play Fortnite today have probably never even played the original game mode.

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.

DOTA was a WC3 mod but the rest are new games built from the ground up in that established genre.

> Most people that play Fortnite today have probably never even played the original game mode.

That might be strictly true, but I think a lot more people got interested in and played Fortnite: Save the World than you think. My 10 year old son came in about 6 months ago asking to buy it, because some of his friends that were playing FNBR had gotten it and were talking about it (playing together? I assume it's multiplayer).

Due to Fortnite's massive usage, "most people" not playing it still could result in an absolutely huge number of people that have, dwarfing all sort of other games that might be considered popular, so I wonder.

Are you working in C# with Unreal Engine? How is it?

I am tempted to switch over as well but there is no way I'm going back to C++.

I used Unity professionally for 5 years, then I took a 15 month break from game development and went to work on a hobby project and the latest version has completely changed to the very core. Made me give up and I'm currently looking for a game engine that's basically what Unity was 3-4 years ago. Pretty simple with a robust multiplatform support.

Godot looks the most promising (and open source) but the lack of console support is not ideal.

Godot is less featured, but it is so much simpler to work with.

For indie game devs Godot [1] is huge. Great scene graph, scripting and debugging inside the editor, wonderful 2D tools (animation, physics and tilemaps are really great). It does not come with as many features as Unity or Unreal, but actually this is an advantage, because you don't have to learn a new way of doing things over the years. And you even have a dark theme out of the box! [2]

[1] https://godotengine.org/

[2] https://www.zubspace.com/comic/unity-vs-godot

Console support is not there by default due to licensing, but I heard that one of Godot developers runs a company which provides console builds for Godot.

I'm not sure why larger headcount would ever be indicative of higher quality.

It's usually a negative signal. If you tell me a team of a dozen worked on a product, it is almost always better than if a gross of developers had their finger in it.

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.

I too support CI for some teams using Unity and the licensing server is a horror show.

> - License server is unreliable. It always goes down with a 500 error, every day for most of the evening (California time). That means I cannot easily elastically scale build servers.

This should be flooding their support center with open tickets. Completely unacceptable. The worst part is that it shouldn't be hard to fix. The longer it goes on the more the Unity folks look like clowns.

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

Requiring Mac OS to build binaries is unfortunately an Apple restriction. Apple has a large number of both technical and legal barriers allowing cross compiling.

Mozilla cross-compiles Firefox's macOS (and Windows) builds on Linux. Build times are much faster on Linux and build scripts for macOS, Windows, and Linux can share more common code.

https://bugzilla.mozilla.org/show_bug.cgi?id=921040

This doesn't account for all the Mac-specific graphics tooling like the Metal compiler, metal-al, metallib and such.

Firefox for Mac OS uses GPU acceleration though, so are they doing something fundamentally different than a game would? They need to expose WebGL, and they hardware accelerate page rendering too if I'm not mistaken.

Cloud Mac builds do suck. With how required a cache server is it's honestly easier to just buy a macpro and make some VMs.

You can try juggling offline license files but it's super annoying as well.

>- I cannot separate out build processes into discrete stages

Not sure what this means. You can try exposing different methods if you need external steps.

Has anyone been able to get decent performance for Unity Builds out of VMWare Fusion VMs on MacOS?

We are using 2018 Mac Minis which (AFAIK) cannot install VMWare ESXi without a bunch of trouble, but Unity builds within VMWare Fusion take 2-3x as long as running on bare metal (I assume because there is no 3d acceleration support for MacOS?).

> Defold

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

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

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.

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.

I'm looking forward of what becomes of the Jai programming language.

It looks well and good, but the point remains that it won't help you build for consoles out of the box.

It apparently already builds for Switch: https://www.reddit.com/r/NintendoSwitch/comments/cixsoy/jona...

Let me clarify: Unity gives you high-level APIs for things like graphics, audio, input, networking, that work across all supported platforms automatically. There may be some platform-specific quirks, but roughly speaking, you can just click "build for X" and get a working X build. There's a huge gap between compilation and that.

I don’t know how Jai will do this. But my gut feeling says that the meta programming capabilities will could help doing this sort of thing. My understanding is that it enables one to say „build my program in this particular way“ expressed within Jai itself.

Please correct me if I‘m completely off.

I honestly think this is outside the scope of a language; it's really a library/framework/toolset thing. I'm sure it will be possible to do this with Jai (maybe it already is), but you'd still have to do it with Jai as opposed to Jai doing it.

I'd love for there to be some way to start experimenting with it. I understand it still has a long ways to go, but I'd like to get more of a feel for it outside of Jonathan Blow's 4 hour+ work sessions on Youtube.

I understand the likely reason why he isn't, because he doesn't want to have people bugging him for support on it, but if I could sign a "I promise not to email you any questions about it and I'm using this at my own risk, pinky swear" and get access to download the latest version of it, I would.

For Godot, there are actually some companies that you can work with who will make your game playable on consoles[1]. It's a pain that it has to be done that way, and the devs said it isn't a trivial amount of work, but I remember seeing at least one game on /r/godot that was launching on PC and Switch.

[1]http://www.lonewolftechnology.com/

Yeah. Sounds expensive though, which makes it a tough sell for many indies. Maybe if your game makes it big on PC first that could make sense, but that won't apply to everyone.

It all depends on what you're planning to do. Godot is a fantastic engine for 2D stuff, with the ability to publish pretty much anywhere. And it does support consoles, in a way: https://docs.godotengine.org/en/latest/tutorials/platform/co.... It's not cheap, I agree with that.

I'm surprised at the idea that Unreal is inaccessible though. Especially as an indie, UE4's blueprint system will do absolutely anything you need to do. And, for extending the editor itself, Python is available.

I'm a programmer, who feels most comfortable writing code, so that was the route I took, and that route ended up being inaccessible. I've also heard that you can't really do everything for an entire game in just blueprints.

Unity's C# scripts on the other hand - despite all of the engine's problems - are incredibly straightforward to write, set up tooling for, build, plug into a project, and you can use them to control everything from game logic to the editor to the rendering pipeline. This is Unity's greatest strength, IMO.

>I've also heard that you can't really do everything for an entire game in just blueprints.

I wouldn't do networking in blueprints. But for your core gameplay ? It can absolutely do anything you want.

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

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

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

Godot is also great for 3D, and increasingly so. We're already making great VR games with it, and it's only going to get better with Godot 4.0 which will support Vulkan (to be released this summer).

I've switched from Unity ~7 months ago and never looked back.

Curious - is your team using GDScript, C#, or C++ primarily? It seems like GDScript is still the happy path for compatibility, but I have mixed feelings about it as a language (though I've written enough Python to be relatively productive in it in my little Godot experiments).

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

It looks like that they're re-working GDScript for 4.0, so that'll get a lot better, too.

I've used Unity and Unreal Engine 4 for a while I don't think i'll want to switch from UE4 for 3D based things i'm pretty excited for Godot 4.0 and all the new nifty features I've been hearing about.

Does it make sense to hold off diving into Godot until 4.0 (for 2D-based things) or will there not be too much to "relearn"?

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

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

Has anyone ported to a console? The wording here is a bit confusing, I thought they meant you have to pay a 3rd party to port your whole game (from scratch?) but maybe it means they'll have to compile a special version of the engine for you instead with the devkit or something?

It's the latter. A third party provides you with the stuff you need to export to consoles, e.g. export template(s) and such that for legal reasons can't be included in the normal version of Godot. Here's a recent thread about having a Godot game built for Switch: https://twitter.com/monolithofminds/status/12599133551769272...

Pygame?

I was always ruling out Unreal as an option due to C++ because I'm no good with C++ and it seems scary.

But in the end I got so frustrated with Unity that we did do the switch to Unreal. So far I actually had to do a lot less coding in Unreal than in Unity. There's almost nothing you can't do in blueprints.

The only thing I had to write C++ for is some JSON parsing because the existing JSON blueprint libraries (from the marketplace) are terribly slow. What little C++ I had to write is fairly simple. Just using core APIs form Unreal itself (FJsonObject). It's just creating structs and calling APIs. Easy enough even for me.

Everything else we implement in Blueprints. No C++ required.

How much C++ you need depends on what kind of game you are making. You probably wont make a game like Civilization in blueprints.

Which Civilization?

I'd say a lot depends on how much stuff you're doing every frame. From what I've seen, Epic is emphasizing you should avoid running blueprints every tick, and instead use event-driven programming heavily (or "steal" ticks from input handling), and then flip appropriate switches to remove anything that doesn't need updating every frame from even being issued a tick by the engine.

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/

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.

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

Interesting, I remember messing around with XDA years ago when MS was making a huge push for it (before Unity was fit for anything but prototyping). It was a reasonably pleasant experience.

Does it support 3D? I don't remember whether that was the case back then.

Edit: There's a 3D game right on its home page :)

Monogame is really nice as a hobbyist.

I also like that you actually have near full control of what is happening, rather than poking at a black box engine and hoping the bits you plug into it work correctly. Of course, I'm of the age where you had to write your own Windows message loop and wrangle OpenGL or DirectX yourself to do much of anything.

I saw something the other day about using godot with the switch, it's more of a licensing problem than a technology one and there is a way to do it.

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

This is by far the best it has ever been in my 25 years in the game business. If you are daunted by making a game in Unity or Unreal today, you would be without hope twenty years ago.

Perhaps somewhat ironically, I've started feeling like Game Maker Studio is a far better choice if you're looking to make a strictly 2d game. Despite being someone who works primarily in C#, I try to avoid Unity like the plague nowadays for all of the other reasons outlined in the thread.

Unity keeps rebuilding the core foundation of the engine which means at any point the work you did could be invalidated. So now everyone's operating on a different version of the engine, trying to solve bugs related specifically to that version and it means if you actually need something from a later one you're SOL.

Whenever I've worked w/ Unity I've felt like I spend more of my time struggling with tooling than actually making a game. From a more skeptical point of view I understand why: It's because it means they can create a marketspace where you have to buy additional tools to make game creation more robust. From a developer point of view though, it results in a nightmare.

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.

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

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?

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

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.

This is going to sound insane. But I am developing a perfectly good putt putt game with unity 2018 lts on a 12 year old laptop with 128 Meg video card. It's slow but builds work great. So far. For learning and small games it works well so far. And has a load of tutorials made recently by youtubers. But it is a bit confusing to work out what to use and what is to old to use code wise.

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

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.

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 popular because they largely delivered on that promise. It seems the problem is that they’re butchering the evolution of the platform. Judging by the comments here, if Unity we’re doing a better job of rolling out and documenting changes, and stabilizing the product I think people would be happy choosing it.

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 lot of outdoor hobbies like snowboarding and mountain biking. I bet if I were even more focused, I would have learned it faster.

It's not a big deal. You're already expending effort learning Unity/Unreal. It's only a little more effort to do your own thing. You might enjoy it

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.

It's funny because I have the same mantra. Make games not engines.

I focus on making the game, and the engine is the thing left over at the end.

But in so many ways, I have learned that a really productive game engine programmer should be spending his/her time building tools for the team. That's kind of the point.

You're making these tools that unlock the creativity of others, so they can help you with the team's creative vision.

I would expect any programmer I hire to be a problem solver, first and foremost, the kind of person who wouldn't need hand holding to modify the engine. I would hire people who I expect to make sensible decisions.

That's going to rule out a lot of people, and that's fine. When it comes to hiring, I select. I don't instruct.

> I'm not really sure why more people don't do their own thing.

I've certainly considered it, but one thing holds me back: cross-platform targeting. I'd love for my game to eventually run on the Switch, to say nothing of more basic targets like MacOS, Windows and Linux. Targeting those platforms would be a herculean effort.

Yeah the cross-platform ease and great VR support is what keeps me there. I've done my own game engines in the past and really enjoyed it, but that was when I was purely focused on PC gaming.

I don't actually think it's that hard once you know how to do it. You basically make a cross-platform C library that generates the GPU commands and sounds per frame, then you just plug that into whatever platform you're running on.

My Mac Platform code is only like 1500 lines or so. Pretty small considering that it runs a 2D game full-screen on my iMac.

Not sure what is meant by 'Herculean'. Once you know how to do it, you don't lose that knowledge. You literally have the code to use on the next project. No big deal

> Not sure what is meant by 'Herculean'. Once you know how to do it, you don't lose that knowledge. You literally have the code to use on the next project. No big deal

The problem with this is that even if your code is 100% bug free and works perfectly, new platforms are created all the time. The PS5 is coming out in a couple of months - does your crossplatform code target that? Unity does. How about the Switch? How about VR? How about Webassembly?

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

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

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

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

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

I have watched quite a bit of handmade hero. As a fun hobby, it looks great, but using that strategy to make an actual game... well, let's just say it doesn't surprise me he's multiple years in and hasn't even gotten to gameplay yet.

He hasn't gotten to gameplay because it is meant to be an educational series, which means skipping the parts that don't serve the educational purpose.

I've followed Casey's approach but taken a different path. Instead of focusing on covering anything an engine could do, I started making my own game.

And I discovered that once you get the basics of a platform layer and some GPU communication down, it's pretty easy to start throwing together a real game.

I'm doing it. I've got a real game with real gameplay, actual levels, real things you can do. All of this after a year or learning.

I definitely support making your own game engine if you enjoy it as a programmer.

But it shouldn't be a surprise that it's not the best choice for the most developers. Every moment you're debugging and improving the engine is another moment you could have been working on the game itself, because almost all engine improvements are orthogonal to improving the game experience.

So given a limited amount of time, you will always end up with a better and more complete game if you start with a batteries-included engine than if you roll your own.

Also the fact is most peoples' game ideas are very derivative and it would be overkill to reinvent the wheel by implementing your own engine for, say, a game that'd easily be made in Game Maker Studio

In my experience, it was easy... until I got to the part of my game that makes it unique. Then it went from easy to very very hard.

That's the thing about engines. They'll get you up and running quickly for basic stuff, but you'll be tearing out your hair when you need to do anything non-basic.

The way I put it is, "the engine isn't really done until the game is." So many polish features in games lead to new categories of assets, which in turn need new methods of rendering.

This is one of the multitude of reasons that so many older game devs reach for the C++ compiler; they don't know what the game will need, but they do know they can make the necessary modifications to ship if they approach it bottom-up.

Making your own game engine requires experience as well. If you've already used other engines, you'll have some idea of the "shape" that a UI library or texture loading system should take.

I had pretty much no experience when I started mine. "Shape" is an arbitrary thing. The shape of the tool should match the shape of your problem, and if you don't know what your problem is yet, you don't know what the best tool for it will look like.

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.

This is the big bottleneck, plus, for shipping jobs (say <2 month timespans), writing some of the basic stuff eats up more time than you want.

I've been doing an engine on the side (c++ underneath, javascript on top) for pc,Hololens,magic leap,Mac, android, we , pi/Linux (finally) for about 4 years now. I can churn out tools (editors, daemons that run for months, hot-reloading remote-assets, vr apps&overlays, ML tools, streaming point clouds) and demos, but it's still missing rigid body physics and a lighting engine (outside ray marching)

I still have to resort to unity or unreal to get jobs out, because there's too much to do for one person. (Although this is finally starting to change :)

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.

I've made a bunch of half-finished engines in C++ and Common Lisp over the years, my problem is that I always end up bikeshedding the architecture instead of writing a game. And since I do it in my time off, life eventually intervenes.

E.g. this time around, between a new job and a pandemic, I don't have the headspace to think about my little experimental Roguelike I've been developing over the past year (which BTW. mostly took the form it has from me bikeshedding the ECS pattern).

So when the other day I thought it's time to test out the few things I wanted to test about VR, I eventually decided to screw writing my own code, and now I'm just poking around UE4 and doing everything in blueprints.

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

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

I like to think that way as well.

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

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

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.

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.

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

The message about eating their own dog food is spot on. I will say, though, that their new asset addressable system works very well and is quite a sane design. One of the better new things.

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

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?

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.

A great demonstration of how unity is bloated: 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.

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!

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.

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.

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”

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

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?

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?

For having used both Unity and Unreal, Unreal does crash often.

Unreal can also become very frustrating very fast if you are going for anything different than a standard fps or third person game, and I percieve it as being extremely bloated compared to Unity. The force of Unity lies it its modularity and flexibility, in my opinion.

I hear that sometimes but what stops people from using unreal with just actors and custom components and pretending it’s unity with c++? Lack of documentation? Does the engine actually get in the way?

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.

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.

I've used both Unity and Unreal in a professional capacity. The best way to describe Unreal is that is has a specific way that things should be done and once you stray from that, it gets painful. But a lot of the time, you don't know what that way is.

Unreal is extremely powerful, but horribly documented. You know the blueprint editor? The same APIs are available for your own use if you want to make a similar graph editor, but you're on your own. You're best bet is generally to look at the editor source or a plugin that uses the APIs that you're interested in. That really applies to most of the API. If you want to use it, the documentation is generally of little to no help.

Blueprints can easily call C++ functions, but the opposite is extremely painful to the point that you shouldn't do it if you have any other options. But it's incredibly annoying to see that there's a blueprint function that does exactly what you're looking for when you're working with C++. If you're lucky, the BP function will actually be implemented in C++ and you can figure out the actual class name and call it directly. If not, then you'll either have to rewrite that functionality in C++ or attempt the aforementioned horror of trying to call into a blueprint from C++.

Blueprints are powerful, but they quickly become convoluted when doing non-trival things. If I have a blueprint function with more than ten nodes, I'm itching to rewrite it in C++. Doing things like loops and complex flow control is just so much easier and compact in C++. Need to set a couple of variables? Enjoy having that take up half of your screen.

Did I mention the lack of documentation? It took me an embarrassingly long time to write some code to figure if a targeting reticule widget is over a specific point in the world. The relevant functions were vague on exactly which coordinate space they use. It took a while to figure out that when one function projects a world location onto the screen, it actually means the viewport. While the widget absolute positions are actually relative to the overall window/screen, which matters in the editor because the viewport doesn't take up the screen and there's UI scaling on top of that.

Unity's documentation is great compared to Unreal. It also has the benefit that searching for most things will generally bring up a relevant forum post somewhere. There's also only one way to do things in Unity. You don't have to deal with trying to find out something for C++, only to have all your results be about blueprints.

Unity editor is more stable. Unity editor is more performant.

UE4 is easier to work with in the long run. I find that Unity is just missing stuff, or has half-baked solutions that change. UE4 already has this stuff included as core product.

Unity is more approachable, has better docs, but slowly falls apart. UE4 is less approachable, has worse docs, but becomes better to work with over time.

But, it all depends on your use case, and what you need out of which tool. I have worked in Unity 4/5, UE4, Source, and Source 2 as of recently with the HL:Alyx tools.

Unrelated side not: Source 2 tools are pretty slick! But they don't have general licensing yet... if they announce that, my next project might be in Source 2 instead of UE4. Something about that Quake/HL legacy code that is always more comfortable than Unreal.

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.

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

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.

> The only thing that Unity provides that has any chance of saving you time is the skin mesh animation

Unity has saved me a lot of time and I don't use the skin mesh animation system.

> 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)

The problem with writing your own engine is cross platform support. The grunt work that goes into that is something only a big studio can afford.

That said It has been done, see Heaps[0].

[0]https://heaps.io

If you take a long-term perspective; console and mobile are going away, you can't have a computer that you cannot produce on.

That leaves Windows on Intel and Linux on ARM. That is two platforms to support, not that hard really!

And really long-term Windows on Intel is going to go away too because of energy prices.

Another thing to consider is that CPUs and GPUs are not improving that much, so the engine you build now will probably last very long, if it's made well probably forever!

That is an interesting and certainly very long term perspective.

I want a device I can also produce on but do most consumers really want that? I think they want something simple that does one thing. This is one of the reasons I think the switch has been so successful. I can't see my portable tablet / laptop / workstation incorporating joysticks. Also with GPUs stagnating as you mentioned high end games will still need to run on high power devices like consoles.

Why would using a compute shader mean mesh data is sent every frame? Compute skinning is mostly the same as doing it in the vertex shader but you don't have to skin again for the different passes, instead you store to some GPU memory (so up the tradeoff is extra memory bandwidth on the GPU). No extra CPU/GPU traffic should be used here.

Well if you analyze Unity you'll see they send all meshes every frame. It might be because they want to be able to apply the same shaders on characters as on objects, but still vertex GPU skinning is the way to go and Unity does not. So you can't build a MMO with Unity!

I suspect that you're analyzing the frame trace wrong and thinking that since pre-skinned data is showing up in the draw it's being sent from the CPU, but feel free to send me a renderdoc capture or something and I'll take a look. Compute skinning and vertex skinning are both competitive; for games with many passes, zpre, multiple shadow passes compute skinning can beat vertex. Compute skinning is used by Frostbite and most other large engines too.

> So you can't build a MMO with Unity!

This has nothing to do with the skinning method, and I agree with the other poster. It should retain the same vertex buffer in GPU RAM and simply deform it in the shader.

Skinned mesh performance isn't a big issue for many developers.

I guess it's a problem if you're making a zombie game with hundreds of skinned zombies active. But the bigger problem in that case is that there's no easy way to LOD the animation or GameObject hierarchy.

I compile Godot in ~3 minutes. -j 8 on a 4770k (? 2015 cpu)

Unity offers so much beyond your narrow experience.

I’ve made tonnes of games in Unity and never experienced either of these concerns.

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

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

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.

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.

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.

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

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.

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

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.

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

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.

It might be good, if... you can manage to install it. https://www.youtube.com/watch?v=j271YAjW5wA tldw: The download and install process can easily take an entire workday. Then there's the plugin system...

It's UX is ... not great. I couldn't even figure out how to open a project from a folder on disk. Not joking. I really tried.

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

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

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.

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

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.

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

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

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

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?

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.

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.

I am not sure what this is supposed to prove. Obviously, there were tons of games that weren't on Steam before that. You should compare apples to apples, i.e. games that got accepted in the past to games that would get accepted in the past.

Looking at their market share across Switch games, first party support from Google, Nintendo and Microsoft for their gaming platforms and AR/VR devices, ongoing Hollywood adoption, I would say they are doing quite alright from business point of view.

I agree, Unity strength is their platform support. They will always be viable. However the simplicity and speed are taking a hit.

This is coming from someone that got companies to switch to Unity because it was so good for a time and in many ways still is. I got the game studio I was working at to buy our first Mac back when it was Mac only in 2009. I have put up the warning to them many times but it seems to be getting more complacent to the external view, they seem content on internal view only which screams management culture over engineering/product culture, same type that dooms companies. There is still time to fix it.

I would like Unity a lot more if I was allowed to avoid the buggy new pipelines. But as soon as something more shiny comes along, they stop supporting the old and working way. By now, the "universal" render pipeline has know bugs, but they are considered "won't fix" because you could circumvent that specific bug by using HDRP, which of course will bring with it lots of other bugs.

I have no doubt they are doing "quite alright" but I always look at these types of posts as the canary in the coal mine. There are far fewer developers than players and the players don't care about Unity vs Unreal vs Insert other engine here. If developers are frustrated then it will take a long time to migrate off but once someone is burned they aren't often willing to take a chance on the same thing for their next project.

I am not a game developer but I know there are pieces of software/frameworks/languages that I've been burned/extremely frustrated by that I won't go back to if I can at all help it (As in I would never take a job that used it unless I was desperate).

I usually only see these type comments in forums like HN.

In game development communities, it is another universe.

And what is the word on Unity in game development communities?

My biggest grief with Unity is that they only made the C#, but not the C++ part of the engine open source. So there can be release-blocking bugs that you cannot fix yourself, due to lack of source code. And when I tried to purchase Unity source code access, I was just ignored.

Unreal Engine on the other hand has source code available for everything, so you can be sure that if such a bug hits, you can just patch it yourself and continue working.

None of that is open source

Part of it is. It's not free software, but part of the source code cab be accessed by the game devs.

That is correct. But since I'm in the business of selling my source code, I don't find that problematic. Actually, it kind of helps me that my customers know that the engine is not free.

I need access to the source code to understand hidden magic and fix bugs, but I don't need a license that would allow me to redistribute the modified source code.

Most people are quite happy to have something like Unity instead of dealing with Ogre3D, SFML, Allegro and similar old frameworks.

In most game development schools it is one of the official game engines that one gets to choose.

Check Gamasutra articles or watch GDC postmortems and the vibe will be much more positive than around here.

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.

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

There is more to Hollywood than those kind of movies, even if that is actually the case, which I very seriously doubt.

The winner takes it all is Octane Render.

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

Clicked expecting a Matt Workman video...was not disappointed :D

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.

Can you give specific examples? I've only ever heard of this happening with Unreal.

Yes,

"Unity wins its first Technology and Engineering Emmy Award"

https://blogs.unity3d.com/2018/11/21/unity-wins-its-first-te...

"Creators pushing the boundaries of storytelling in Sundance's New Frontier 2019"

https://www.youtube.com/watch?v=XhHuqvnAzyo

"Unite Los Angeles 2018 - Films Made with Unity"

https://www.youtube.com/watch?v=gbYX8PXX8qc

"What's ahead for film and animation with Unity 2020 - Unite Copenhagen"

https://www.youtube.com/watch?v=wrc3R-BoDGs

How does timeline animation work with uneven terrain? You set these key frames but you lose your navmesh so you end up needing a million key frames

Godot Engine https://godotengine.org/ is much more user-friendly in my experience.

What do folks here think of Panda3D (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.

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

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.

Each of those studios started with a game. There are 10x many more small companies that rolled their own game engine around this time that are now dead, or bought for their engine.

The best tools grow first alongside a real product. Building a tool without a target product almost always misses the mark.

I am curious, which companies were bought because of their game engines?

https://en.m.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp

Naughty Dog by Sony

> In all honesty, the biggest reason we're not using GOAL for next-gen development is because we're now part of Sony. I can only imagine Sony's shock when they purchased Naughty Dog a few years back, hoping to be able to leverage some of our technology across other Sony studios, and then realized that there was no way anyone else would be able to use any of our codebase. Sony wants us to be able to share code with other studios, and this works both ways - both other studios using our code and vice versa. Add this to the difficulty curve of learning a new language for new hires, lack of support from external development tools (we had our own compiler, linker, and debugger, and pretty much had to use Emacs as our IDE), etc, means that there are clearly a lot of other factors involved. Note, however, that these issues aren't really technical problems, they're social ones.

— Scott Shumaker

> Building a tool without a target product almost always misses the mark.

There is no evidence to back this claim up. There are > 10000 shipping games made with Unity, maybe 100000. And there are many hit games made with it as well. I'm not claiming they are or are not as good "technically" but they shipped, made lots of players happy, made their developers proud and successful so no mark was missed just because Unity started as tool without a real product alongside.

If fact I'd argue the opposite, most teams that make their own engines have the worst tools because they have a limited budget and limit time and they've given themselves 3x to 10x the work. Instead of making a game they have to also make a game engine, tools, importers, converters, and tons of libraries.

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/

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

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

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.

Mobile and C# are probably the biggest points. Another one is the community. Unity has a very large community which makes getting help easier.

Tooling, a deep belief that there is more than C and C++ as means to develop games and being able to target low end devices without turning them into frying pans.

I'm a solo indie developer in the late stages of developing a small 2D game for PC and mobile. [1]

Unity enables you to double dip on your engine knowledge to work on anything from simple 2D games for WebGL or mobile devices, to large AA productions, yet remains relatively lightweight as a tool, even on the large scale end of things.

It uses C# for scripting as the one true way of doing things and not some second class citizen. C# is just incredibly good. It's performant, exactly in the right spot on the rigid-flexible axis, and has fantastic tooling and learning resources.

I'm keeping a close eye on Godot and will be trying it for some tiny projects after I'm done with my current game, but it doesn't look like it's quite there yet.

[1]: https://store.steampowered.com/app/1142080/Pawnbarian/

I've been reading Garry's blog for about 15 years, good stuff.

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.

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.

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.

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

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.

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.

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.

>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

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.

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 :)

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.

what are you talking about?

DOTS is even more of a dumpster fire than the URP/HDRP.

They have an unstable base layer that is constantly changing (eg. SystemBase and for each is literally what, two months old and the old stuff is depreciated now?), a version control system for packages that doesn’t work at all (see all the threads on why don’t my packages work?).

...and guess what? They’re using that as a base to build the physics, audio, networking, animation and visual scripting on.

No wonder its taking forever... those poor other teams are royally screwed, because every time they make any progress, the DOTS guys go and re do everything from scratch.

codegen? nah. we’re giving up on that too now, it was too hard.

...I mean, the demos are great and all, but DOTS is a mess.

Its not a “step up”, its a vague pie in the sky idea, and a bunch of people making a big old mess.

Its not even part of the 2020 roadmap.

Yet the support for it still sucks. I spent a few hours trying to set it up the other day and still couldn't get it working. (Unity developer of 6 years here). Maybe I just had one setting wrong.. but this shouldn't be that hard to anybody, and as rightly Garry points out its not necessarily a lack of documentation but the fact that the documentation is so out of date OR correct but only with one unique combination of versions from 2 years ago.

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.

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.

Smells a lot like a continuous second system syndrome.

https://en.wikipedia.org/wiki/Second-system_effect

At this point, Unity is a WIP engine with a boat load of alpha packages.

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.

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.

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.

Recently changed so it only kicks in after $1M in revenue. For the vast majority of game developers Unreal is 100% free now.

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

Curious how you’re getting $2m? Are you the Enterprise plan?

Pretty much everything. Godot is where it's at.

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.

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

Unity source code is available to anyone that actually wants to have it.

It just isn't available in FOSS sense.

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://github.com/Unity-Technologies/UnityCsReference

The reference source is pretty much useless for anything directly under namespace `UnityEngine`, because it consists mostly of forwards to C++, and the C++ was never released.

At least that was the case around 2018. It might be getting better as Unity is migrating away from C++.

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

If you can't afford $1800/yr you weren't serious anyway.

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

Especially not in the F sense of FOSS, because unless something's changed very recently I believe you need to pay for access.

Some companies think that it is only fair to pay for the work of others.

I don't see an issue requiring commercial access to the source code.

Reply on news.ycombinator.com