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.
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.
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 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.
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.
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.”
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.
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.
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
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 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.
> - 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.
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.
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?).
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.
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?
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.
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.
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.
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.
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.
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
> 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.
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.
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?
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.
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”
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++ ...)
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.
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.
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.
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.
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.
[+] [-] Danieru|5 years ago|reply
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.
[+] [-] ortusdux|5 years ago|reply
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.
[+] [-] SaltyBackendGuy|5 years ago|reply
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.
[+] [-] voppe|5 years ago|reply
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.
[+] [-] wokwokwok|5 years ago|reply
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...)
[+] [-] fiblye|5 years ago|reply
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.”
[+] [-] redisman|5 years ago|reply
Godot looks the most promising (and open source) but the lack of console support is not ideal.
[+] [-] stevehawk|5 years ago|reply
[+] [-] tomc1985|5 years ago|reply
[+] [-] fxtentacle|5 years ago|reply
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?
[+] [-] thrower123|5 years ago|reply
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.
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] michaelbrave|5 years ago|reply
[+] [-] hota_mazi|5 years ago|reply
I am tempted to switch over as well but there is no way I'm going back to C++.
[+] [-] hosh|5 years ago|reply
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.
[+] [-] jandrese|5 years ago|reply
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.
[+] [-] Jasper_|5 years ago|reply
[+] [-] Vulphere|5 years ago|reply
It is not truly open source since there are restrictions for commercial purposes.
https://www.gamingonlinux.com/2020/05/cross-platform-game-en...
[+] [-] dak3|5 years ago|reply
[+] [-] justinram11|5 years ago|reply
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?).
[+] [-] DizzyDoo|5 years ago|reply
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.
[+] [-] _bxg1|5 years ago|reply
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.
[+] [-] lux|5 years ago|reply
[+] [-] learc83|5 years ago|reply
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".
[+] [-] jayd16|5 years ago|reply
[+] [-] ngold|5 years ago|reply
[+] [-] sloopy543|5 years ago|reply
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.
[+] [-] enumjorge|5 years ago|reply
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.
[+] [-] TeMPOraL|5 years ago|reply
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.
[+] [-] GuiA|5 years ago|reply
[+] [-] xenreal|5 years ago|reply
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.
[+] [-] hn_acc_2|5 years ago|reply
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
[+] [-] johnfn|5 years ago|reply
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.
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] vicarrion|5 years ago|reply
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.
[+] [-] jamesu|5 years ago|reply
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).
[+] [-] rr_aa|5 years ago|reply
[+] [-] jokoon|5 years ago|reply
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.
[+] [-] gentleman11|5 years ago|reply
[+] [-] mpartel|5 years ago|reply
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?
[+] [-] bullen|5 years ago|reply
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.
[+] [-] klmadfejno|5 years ago|reply
[+] [-] golergka|5 years ago|reply
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.
[+] [-] moron4hire|5 years ago|reply
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.
[+] [-] diegoperini|5 years ago|reply
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.
[+] [-] haydenlee|5 years ago|reply
[+] [-] zelphirkalt|5 years ago|reply
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 ...
[+] [-] minitech|5 years ago|reply
[+] [-] Geee|5 years ago|reply