Brackeys is back... kind of

People were asking who is Brackeys of Godot, turns out it was Brackeys all along.

 

while a tiny part of me sad hes making videos about godot.... im so glad to see him back.. I guess I will learn godot cos i love watching his videos even if i then never use it

 

I will never understand why people liked his videos.

 

Yeah man why would anyone like easily accessible beginner focused videos presented in a friendly manner? Completely impossible to figure out.

 

Entertainment and accessibility.

 

agreed it's not like I was a noob two years ago and needed someone to hold my hand as I made 3d person movement

 

His content had a significant impact, attracting a stream of new users to Unity. He will most likely have a similar impact on the Godot community, offering a clearly defined pathway from Unity.

 

Unity has become increasingly hostile to beginners. Many tutorials are out of date due to package manager fragmentation. And even if you want to follow up to date tutorials or courses, stuff is just broken often.

You couldn't add new Input Actions with mouse input from August 2023 up to mid-March 2024 even in Unity recommended LTS releases. Of course, there's always a workaround for those of us who have to deal with this every day. But for a beginner stuff like that is an impassible brick wall.

And apparently latest Unity LTS release completely breaks shaders, again: https://twitter.com/slipster216/status/1781702128769388589

Schools are starting to diversify in other direction besides Unity as well. They dug their own grave and now have to lie in it.

 

Lol, true. I think it will have effect on some people migrating to Godot, but also on some people searching for Godot content will see his Unity tutorials.

 

Hes a good game dev, and has helped the community greatly. But this doesnt mean switch to Godot because he has. People switch to different engines all the time (be it pro or indie). hell ive used 4 different engines (unity/unreal/in-house) in the last month.

He found a new engine to use and will start a video series on it. Kudos to him, ive tried Godot a few times and even though its open-source doesnt mean its good. Its not... (my opinion).

 

I find his videos to be neither of those though, or friendly, or helpful, or have a pleasant pace.

But it doesn't really need to be about him at all, it can be 100% me.

 

Sorry, but no!
He is not a good game dev. He is a good beginner tutorial factory. His tutorials and examples are riddled with inefficiencies, anti-patterns and problems will bite your *ss later, when he is gone and you're on your own with your problem.

That's true though.

 

That's what he even says in his video

 

Such a kind and lovely chap; learnt so much from his Unity tutorials over the years! Can't wait to watch his next phase!

Accessible, free, very beginner friendly and bitesize tutorials that are straight to the point and delivered in a friendly way. Its obvious why his videos are massively liked and cherished.

 

I think it's the return of the season agreed?

 

Glad to see he's doing well and keeping it fun.

 

can you show at least 2 examples? i find his tutorials very useful, accurate, based on (that time) documentation.

Anyways, i'm glad he is back, i tried godot some months ago but it never got my interest, maybe with his guidance i can try it better

 

I'll take his stuff over whatever has been pushing people to use

Find

and

SendMessage

lately.

 

I am sorry, I do not have the time to binge-watch years old YouTube videos to bookmark things for you this time. You're free to not believe in whatever I say or even disagree with me. Back in the days when his tutorials were more prevalent his corner-cutting (especially when it comes to the code was not part of the immediate tutorial-subject) wasn't exactly a secret. So feel free to investigate it yourself.

With that said, his tutorials helped a lot of people, so I'm glad they exist(ed), the benefits probably outweighed the problems they caused.

 

I've had people ask me what I thought about his video tutorials over the years, so I have looked at some critically. Basically my opinion has always been that his tutorials are excellent beginner tutorials. Some of his solutions are far less efficient than what I would typically recommend for large projects, but that is not bad as long as people realize his videos are simply a good first step. I am assuming most people watch more videos and read more websites and books after watching one of his videos.

His videos are produced well enough, and he does an excellent job of keeping the videos short enough while still covering enough of the topic to get somebody started. He had posted a lot of concise game dev videos that were 8-16 minutes in length.

His new videos will probably be very helpful for a lot of people getting into Godot Engine.

 

His code is very basic. I don't think that's necessarily a bad thing since he's targeting beginners. Since his code is on GitHub I'll just reference that rather than a video. Here's a few instances of singletons he's written. You'll notice that he doesn't actually do anything to verify that it's a single instance aside from an error message in the third.

https://github.com/Brackeys/RPG-Tutorial/blob/master/Finished Project/Assets/Scripts/Player.cs
https://github.com/Brackeys/Sugar-Warrior/blob/master/Sugar Warrior/Assets/Scripts/GameManager.cs
https://github.com/Brackeys/Tower-Defense-Tutorial/blob/master/Tower Defense Unity Project/Assets/Scripts/BuildManager.cs

Here are a couple singleton implementations. Mine (second link) is meant to be placed in a scene while @Kurt-Dekker's spawns itself. Both of these enforce a single instance of the singleton. They're a little more involved but they're not too complex you couldn't teach a beginner. I tend to prefer Kurt's these days over manual placement.

https://gist.github.com/kurtdekker/775bb97614047072f7004d6fb9ccce30
https://forum.unity.com/threads/rep...nd-am-i-even-using-them.1130143/#post-7262689

 

thanks...

 

This is an excellent example. On a large, professional project, I always put a lot of defense code in place. Enforcing a single instance of the singleton is one of those things. The Brackeys code examples are stripped down to the minimum that would be needed to learn the new concept from a specific video. I am guessing that Brackeys chose to skip the defensive code there in an effort to simplify the example for the video.

 

Unity have driven users away with that license shenanigans, this Brackeys return is a bit of a stab.. Still I don't have much interest in Godot in it's current state (however I'm also not going to ignore it and neither should Unity) Unity should be making its roadmap and releases look like Godot or UE for that matter as a poor choice for anyone to waste time on.

Having spoken to other Godot users they do like the faster compile times.

 

I don't think many existing users have been driven away since years of investment and knowledge is still there. It's not easy or straightforward to change technologies, it's added expenses and time commitment no one has right now. Funding is at an all-time low, people will stick with what they know professionally.

Unity are losing potential newcomers, however. All the bad PR, together with package manager fragmentation and combinatorial explosion of settings in 3+ different places for SRPs and other similar madness, is making Unity hostile to newcomers. Unity is not a pick up and go engine anymore and requires increasing amounts of arcane knowledge to use, which most daily users don't feel as much because we're like frogs being boiled alive. Friction is increasing, but slowly.

 

I'd argue that Unity was never a "pick up and go" engine for any serious project. The mini-kits on Learn are great for getting your feet wet as a raw beginner, and the UI is still the best around among the free-to-try engines.

But anyone who wants to advance beyond following 10min tutorials has to put in the effort to learn - whether that's basic coding & art-import, or understanding how to configure & build your project to your desired specs. That's not new, nor is it unique to Unity, but that's what it sounds like folks are trying to avoid when they say it's not "pick up & go". No engine builds the game in your head for you LOL

 

Yeah, because this very idea is absurd and nobody reasonable believes it.

 

You misread the responder message and interpreting it incorrectly.
Just saying.

 

Mini kits weren't a thing when I started so I don't know how good they are but they don't address inherent problems of the engine fragmentation.

And I'm not sure what you mean by UI. If you mean UGUI, then I heavily disagree. And if you mean editor UI - then how is that relevant? All engines have pretty similar UI these days. Pick up and go is meant as download and use as is instead of getting a PhD in package manager and learning which of the 2-4 competing standards has the least downsides and with which other 2-4 competing standards of another system your choice is compatible. No other engine is as fragmented as Unity.

Pick any other engine and there's a single text engine, single UI system, a unified graph framework that's used for all graph tools unlike in Unity, which has 4+ different graph implementations developed in closed off siloes with wildly different UI/UX, performance and API access.

Rendering settings are scattered all over the place in scriptable objects, Player Settings, Camera and who knows where else. New Adaptive Probe Volume settings are scatted in at least 3 different panels. This is actively hostile to beginners.

You can stop claiming things I've never said.

 

lol only just now realized that Brackeys logo is a pair of brackets

 

I've been using Unity for quite a while, and it definitely was easier to 'pick up and go' in past versions, circa 5.0 or so. When I haven't worked in it for a few months, I always run into some mind-numbing combination of packages/renderers that break something and it's like "Oh yeah, now I remember, you can't do this with that, if it's the second week in a month that ends in the letter 'r'"!

What's consistently frustrating is that one finds a new 'feature' that looks useful (particularly with AR, Input or VFX), you install that package and then find out later that the new feature is incompatible with another package. I think there are like 3 or 4 AR packages which are uniquely useful, but incompatible with each other. On top of that, to try out the AR samples, you need to downgrade the engine version to avoid errors. That's just not something a beginner is going to get at all, no other engine does things that way.

 

you can explain a complete system in less than 10 min, of course for 99% of youtubers that's imposible because they need to explain why you clicked to see the video (like if there was not a tittle), give you an history class, of course the 20seg intro, some bad jokes and so on... XD but there are some good youtubers out there:

 

I've been using Unity since late 2015 or so, and have taught it in classrooms a couple times. Getting something running as a beginner is still quite easy. The frustration you're describing isn't really about the software, it's about the process of software development.

Any complex software project requires research, planning, and a thorough understanding of the problem before you jump in coding. Packages are basically library-dependencies, you don't install one unless you know what it does & how it's going to change - or break! - your project. Or you roll with it, and be prepared to debug & adapt.

Feel like a lot of the complaints around Unity in this respect ("too fragmented", "too many options", "unclear which packages/versions to use") are from folks who just haven't formed good software development process skills (esp research, planning, and debugging), even if they know how to literally code. Which is fine, everyone has their own journey & pace, but that's not a software issue.

 

Editor UI is entirely relevant - Unity is basically an IDE, ease of use and its ability to adapt (or be adapted) to whatever devs need for any project is the defining factor for selection, right behind target-platform support.

Having to do your homework to know what is best for *your* needs isn't fragmentation, and it isn't a bad thing. You want a toolbox that is flexible, and covers all the bases, something you can grow into as your skills evolve and your projects grow more ambitious.

Those systems that only have One True Way are fine if you're only ever going to do that one thing, one way. If not, then it's a straitjacket, holding you back from achieving your max potential. Again, your choice, everyone is different, but most folks see more flexibility as a good thing.

Everything in Unity at this point is explicitly marked as either recommended, legacy/deprecated, or preview/experimental - if folks are genuinely still confused even after reading that, well, that's what Google & forum posts are for. It can't all be done for you...

 

Custom editor tooling is not unique to Unity, although it is more powerful than most have without delving into C++ land. Also, not really relevant for beginners. And most engines have very similar Inspector, FileSystem/Project, Hierarchy layouts these days that can be dragged around as necessary.

The problem is there is no best Unity package/system, only the least worst. The unfocused, haphazard approach to systems development and maintenance in Unity has resulted in a situation of balancing tradeoffs, not benefits. They abandon systems as soon as they become vaguely usable in basic use cases on the regular. Animation Rigging being a recent example. And even if properly developed, new systems never reach feature parity with legacy systems they are supposedly replacing while the said legacy systems haven't seen any updates in 5-8 years.

Way to describe focused development with a vision as something not desirable. When an engine has one system for a thing, that system better does everything it should or people leave. At Unity, when a system fails to meet the needs of users, they point to legacy systems or other packages that maybe solve one pain point but introduce five others. UI Toolkit never reaches feature parity with UGUI? Just use UGUI we haven't touched in 5 years, and better write your own Layout groups since the default ones allocate unnecessarily.

Flexibility is when you have a choice between multiple viable options. But very few options are actually viable, especially for our use cases. Unity would benefit tremendously by committing to deprecating legacy systems they haven't touched in 5-8 years besides breaking API on occasion. They would also benefit tremendously by not abandoning packages like Animation Rigging.

Unity call things production ready years before they actually are. Depending on what Unity says is worthless, you have to test everything yourself in all possible combinations since packages are developed in closed off silos and often don't play nice together.

And for some things there still only exist experimental APIs, they still recommend using the "experimental" GraphView for custom graph tools while their new graph API is being developed behind closed doors for the past 4 years.

GraphView will probably get deprecated in a few years so have fun investing in that, it's also generally bad with most things you'd need being internal since GraphView was developed initially for ShaderGraph so not only is it experimental, and has bad UX, it's also next to useless beyond basic use cases.

So you have a choice between experimental soon to be deprecated GraphView API with a weird license, the abandoned GraphToolsFoundations package they haven't updated since 2021 and which can't output working game builds as is or writing your own custom graph framefork from scratch. Flexibility, am I right.

 

A prime example of this being the SRPs in general, but especially URP not having camera stacking for ages after it was declared production ready.

 

I get what you are saying, but I still think Unity has become much less friendly for beginners.

Part of that is the expectations brought about by the Editor. A beginner sees the Editor, things moving around, a few video tutorials and say 'Oh fun! I can make a game!" The environment you are describing is advanced software development. Never have I heard a game-loving student look at a package.json file and exclaim - "Oh great, i get to use Homebrew and command-line again today!" Sorting out package conflicts is the opposite of fun.

When Unity switched to the package manager, it became clear that the programming side of the company won out. We now have multiple, experimental branches for multiple things. A programmers play garden! Lost in the process was a beginner-friendly, useful development tool to try out actual game ideas. In the past, I felt any roadblocks I ran into were my lack of programming knowledge and it was usually fun to try to solve those. Now, I'm blocked more often by Unity itself and the conflicting packages.

As @PanthenEye writes, you can solve one problem with a certain package, only to find it conflicts with another. More than once the solution is to hack a package to fix that one bug, but then of course you lose the ability to update said package. Again, it's just the kind of development worm-hole that some people like, but I consider painful and takes me away from my experience of just making something and having fun doing so!

 

I think it's fair to say that Unity has been an artist/designer-friendly, but clearly programmer-first, tool for at least the 9ish years that I've been in the ecosystem. Every game engine sits at a different spot on that spectrum, but even before they dropped JS for C#/.NET-only, the tacit understanding was that if you want to actually make anything in Unity, you're going to have to learn/use programming - not just some light design scripting, but "real" programming.

Beginner-friendly clearly means different things to different folks. I dig that you and many others want a fast-track to the "good stuff" where everything just works as-intended, and where all the hard decisions about what to use are pre-set. Where even a raw beginner can build a finished project in a snap. But I've literally never known programming to be that in nearly 40yrs of learning/working with code Balancing conflicts & trade-offs *is* software dev, that's the job.

There are good engines that trade "too many" options for a much more straight-forward start-to-finish experience. No branching implementation paths, and maybe you can't "write once, publish anywhere", but people learn to make & publish good games with them! Maybe it's not that Unity isn't "beginner-friendly", so much as every beginner isn't looking for what Unity offers.

 

Soft disagree there - Unity beginners usually get introduced to custom Editor tooling via the built-in field annotations (Tooltip, Range, etc). Can't get simpler than that. Also everyone, incl beginners, benefits from Store assets being able to smoothly integrate into the editor. You're right that it's not anyone's Intro/Unity 101, but the leap is much smaller & benefits much broader than in other engines.

Legacy by-definition means "no more updates"... Literally it's a neon sign saying, "we aren't pouring more resources into this, you can still use it if you need/want to, but eventually it could go away". That's just normal software lifecycle, not "unfocused" at all.

As for new systems & feature-parity, it depends. Greenfields features like Cinemachine & Timeline can do whatever they want, without risking breaking legacy code, or having to meet the moving-target of new specs & expectations. Replacement features like SRP and UI Toolkit don't have that luxury - they're building them essentially "live" and have to both mirror existing functionality as well as keep up with ongoing/newer platform standards. Hard to say how to split the blame on that, as many folks jump to use features in-production even before they move officially to GA-status. It's not 100% on Unity, but not 100% on dev teams either.

I don't work for Unity, and I don't know your use-case, so I'll just speak from general software-dev experience. Ultimately responsibility falls on you/your team to assess what is right in terms of tools, libraries, implementation options, etc. If you have the cash, esp in enterprise, you reach out to the software-company and bring in some experts if you have a really tricky/rare problem. But otherwise, it's all down to in-house resources and whatever you can learn on your own.

I can't even say that you're making invalid complaints - never used any Graph APIs, and while Animation Rigging looks cool, I prefer Blender/Maya and Unity's built-in IK API. But nobody from outside your team can anticipate your needs and make the perfect software tool to suit (unless you have a *LOT* of money , tho even then no guarantees). Unity bills itself as a "One Size Fits Most" sort of tool - they make generic stuff that works for most situations, but if your needs don't fit that, maybe it's just not the best tool for your job. That too is just how software is.

 

Give it a bit of time.

 

Have you seen UE 5.4? I finally watched some videos on the new tech and it's just getting stupid what that engine keeps gaining out of the box. Meanwhile Unity is focused on their own monetization with just an upscaler to show for it. At some point it feels like I'm going down with a sinking ship staying on Unity which is why I'm moving on.

 

Yes I started looking at UE5.4 after seeing that animation stuff aswel, animation/controllers are my least favorite part of gamedev and my favorite part is world building.. Unity is just lagging behind on this now, you're stuck with buying addons for these areas (mainly worldbuilding/terrain/graphic shaders etc and even some animation addons) and even then hindered by the engine especially if you see what jbooth has to say about things on terrain etc. UE's World building tools already handle partitioning the terrain with overview map(an actual overview map you can click on how handy is that) https://dev.epicgames.com/documentation/en-us/unreal-engine/world-partition-in-unreal-engine and then nanite just handles the details, you can get on with world building and making levels without having to waste tons of time just trying to make things performant enough to actually play or compromise on details and spend ages making fake imposter trees etc .. it's sad it has got to this level that sticking with Unity just for the things it did ok 5-10 years ago.

Waiting for Unity 7 or just go learn to deal with UE5 blueprint nonsense and C++. It's not all great on UE and is many things I prefere about Unity ecosystem as a whole. Though personally if UE supported C# and that rubbish blueprint stuff wasn't such a key part of working with UE I'd already be gone luckily for Unity that's not the case.

 

Another community initiative started up for it but it's still too early to be useful.

https://github.com/UnrealSharp/UnrealSharp

 

I wouldn't call Tooltip, Range, etc custom editor tooling, it's also not really relevant for beginners. Mildly useful at best, and unneeded complexity and information overload at worst.

Editor tools in other engines also smoothly integrate, it's not unique to Unity. And if anything, store assets are hurting beginner progression by handing them a massive, unwieldy, hard to understand or extend crutch they might be able to use but it doesn't aid their programming skill, problem solving skill or any kind of relevant gamedev skill. It's a shortcut that taken at a right time can aid some productions, but shouldn't really be something beginners lean into in my opinion

I call them legacy, I don't believe Unity are calling something like UGUI legacy, when they love to point at it for worldspace UI and many other use cases such as custom materials, while the system hasn't received any meaningful updates in 5 years. Meanwhile, UI Toolkit won't receive Worldspace support in the short to medium term. So we're looking at another 2-5 years of UGUI not receiving any updates while it's still the go to UI solution in Unity. UGUI is practically a legacy tech they don't update but still somehow the default for our use cases.

This is not normal software lifecycle when the most used UI solution is not updated at all and it's far from perfect, yet the replacement won't have feature parity for many years if ever.

Timeline still doesn't have OnComplete callback, they might not be risking breaking any legacy code or what ever, but Unity are also not in risk of ever finishing these systems to a production ready standard. Can't say much about Cinemachine, as I don't use it.

I recognize the constraints but it's 100% on Unity keeping a lot of things internal only so we can't extend UI Toolkit to be actually usable, which goes against pre-established Unity conventions of flexibility in everything. It's also 100% on them to decide to not support custom materials, custom font effects from the get go. They are designing UI Toolkit as some end user enterprise app that's supposed to be used in only one way they deem to be the right way. When asked for features, they ask us to wait, it's on their roadmap, then years later we are no closer to those features such as worldspace support. This kind of Apple design philosophy doesn't really fly in the Unity ecosystem, the tool should be open to extreme modification but it just isn't.

Indeed, but would you tell this to a beginner? This was my original point, you now need a PhD in package manager to get started with Unity.

It's not about preference. The point was Unity making something barely useful, then abandoning it immediately, which is Unity's MO as of late as people are let go or climb the corporate ladder and their old projects are left to slowly sink into irrelevance.

Our needs are as basic as they get, but somehow Unity often still falls short of that even with "one size fits most" sort of tools probably because they don't actually use their own tools and studios have resources to just straight up replace them and simply use Unity for rendering and crossplatform capabilities. We fall into the category of users who actually have to use Unity tools, but don't have the resources to fix/replace them and it's not a great experience a lot of the time be it SRPs breaking on the regular and not having feature parity with Built-In renderer, Timeline not being able to perform as basic tasks as raising an OnComplete callback, numerous Graph tools and APIs being terrible to use in any capacity, and the list goes on.

 

As of late being almost the last ~10 years.

 

Obviously they are doing "something" right though since in terms of published games on Steam and itchio they rather won than lost over this period xP
Of course a major thank in that regard goes to all the asset devs who publish and sometimes maintain many useful things.

 

This seems irrelevant to my argument, which is about them abandoning features early, which is true for, say, UGUI and Mecanim which were introduced ~10 years ago, and things can still be bad and "win" if the competition is also doing badly, so... I don't know what your point is. Popular != good.

But also, worse solutions win all the time (VHS vs betacam for example), it's mostly who has the best marketing, in which case, yeah, their marketing was great.

And it did help they had an excellent base to build upon, too bad everything they built on it ranges from bad to "eh". Which admittedly doesn't matter much if you don't ask for much from its features, but if your metric of success is quantity of games out there, creating an engine that falls apart if you want to up the complexity makes sense, you don't want people spending too much time on their games.