Looking for input on "Learner Progression" for our future UE community/learning experience

Yeah, it certainly feels like they’ve been picking topics at random. But it shouldn’t be too hard to reorganize an YouTube playlist, lmao

I remember the wiki not being updated as often as the reference documentation is now, and it was also confusing as it was made by a number of different people with different styles. I think a forum is a better format for text stuff where you can reply and discuss, unless it’s official documentation

The wiky was killed in its infancy…

All they had to do was add some official technical writer to review/approve/deny changes. Like Wikipedia does it.

Anyone can write their 2 lines of BS.
And anyone can flag their 2 lines of BS as BS for removal.
Then someone paid to, goes and makes a decision.

Moving forward, hopefully, the forums will work in this simple way…

1 Like

You might want to consider the start in a backwards fashion.
Instead of choosing a start towards everything, create goals instead and break them down into their individual parts.
Example: How to create a huge photo realistic open world. First, we would be introduced to the main parts and then each can be expanded into smaller segments. Each segment could be a very short tutorial, both written, with images, as well as videos. In the accompanying article, links could be provided to the documentation.
Depending on the user’s experience, one could choose where to begin to reach that final goal.

For each path, there could be underlying parts all the way down to how to create an EPIC account, download the launcher and install the engine. Plus, required underlying parts, such as how to use nanite, lumen, quixel and all that realism stuff.

For animations, there would be different underlying parts, and yet, the first underlying part would of course be total beginners; sign up, download, install and from there, enable Control Rig etc.

"The (arguably?) best way is to store the reference to a casted animation instance (mesh > get anim instance > cast > promote to variable) on begin play within the character.
You then set variables directly from the character since there is no need to parse things twice this ends up improving performance slightly too."

Wait, this is news to me. Is it thereby a bad idea to have booleans on both the character and then fetch them in the AnimBP and promote them again in the AnimBP?

Well, you are by definition doing something twice.
Is it necessary?

True that. On booleans, do you now if there is any benefit to using enums instead? I used to have enums for upper body stuff, like weapons and call an event for that enum on the AnimBP from the character. As well as the lower body stuff, crouch, sprint, walk etc. and then in the AnimBP blend by enum.

Likely still won’t work with fastpath, but you’d need to try it out.

Either way, almost all states are mutually exclusive.

Programmatically a switch/case statement would therefore be faster than individualized booleans.

However individualized booleans allow you to play with states too.

Meaning you can gate something up so that it is only avaliable but still toggled from within a different state.
(Example case, dash - locked into sprint, as a ground slide).

And the only reason you have never questioned it at all is that literally all engine examples do it the wrong way.
And yes, it’s wrong.
You double up the memory footprint of the project for no reason at all.

Sure, a PC won’t care. Try doing something like that on a Gameboy game or something with equally insignificant resources…

There’s one thing to consider, and that is the cost of fetching a variable that isn’t directly part of the character from the character for value checking.

Yes, using a localized boolean would be “faster” in theory.

But looking up a boolean (or anything else) has a near insignificant cost regardless of how you have to access it.
Surely, it’s less of a cost to performance than having to keep 2 booleans of the same exact thing in sync across 2 different systems (requiring a lot of calls from one to the other).

So it’s, as always, a give and take.

Except for in this case, since you do calls manually only when needed, there is almost no take, and just sheer performance optimization to do it the “correct” (and fastpath approved) way…

One possible exception would be updating the speed variables. Because they happen on a per tick basis and not in an “alacarte” style.
I have several things running that way. (Updating the animbp speed variable, checking against it, and updating it again)
Never noticed much of a difference.

1 Like

Not to forget the time spent on doing things twice.

1 Like

I am really new to Unreal Engine. I think I started on UE 4.26.2 - I think. My input on this original post is this. I am not a game developer. I am not even an avid gamer. I am a filmmaker, so on Day 1 when I installed UE4 and logged into the learning portal, everything was game, game, game. When I searched for tutorials online, it was all game, game, game, and I get it. UE is a game engine. Not a problem. So, I picked and chose those very basic tutorials first, to learn the basics, and then those that I felt pertained to filmmaking, things like cinematics, lighting, etc., and I learned a lot. However, I’d love to see a better demarcation of individual topics, so that - as a filmmaker - I would find a section that pertains only to learners like me who are not interested in game development. Man, trying to separate the wheat from the chaff was so difficult, and still is. The amount of content is overwhelming, but most of it, 85% is totally over my head. Now, I realize things are changing. With UE5, I am seeing a bend toward Virtual Production, which is in my wheel house. So, right now, I am focusing on learning the major changes first, doing a few sample projects to make it sink in, etc. As for the badges, yeah, they were cool at first, but then I totally forgot about them. I think the best suggestions I’ve read on this thread were about making the tutorial content better, better videos, more in-depth, etc. The last thing I want to write is this. UE5 is free! I am so !@#$ grateful that it’s free, so it’s hard for me to complain. But if you’re asking, and you are, a linear progression through a subject would be awesome. I only wish I knew what I needed to learn - in a linear way, which classes to take, in what order, etc., that’s been my chief issue so far.

1 Like

Unreal Online Learning style badges and quizzes

First I’m only a hobby game dev, for fun n always something new to learn, been playing around since UDk days then moved onto UE4.09 n about to migrate my project over to UE5 and have a play around on there… so when i found the learning hub because of the unreal blueprint ninja change last November 2021 was a big help before then it was youtube n reading unreal documentation…

So i ask were are my skill badgers now??

i know they don’t mean a lot, but it was a simple way for me to keep track of wht course i hav done and wht learning path way i was up to… now i don’t got a lot of time to game dev as i said its more a hobby. I wrk a 9-5 40-50 hours a week, wife, kids, DnD, Other Hobbies Plus TV you Know Life but was still finding the time to lean on the side and was enjoying the fact i was almost done with badge 20… witch wasn’t a fast rate 19 in 5months but i liked seeing the progress

then last April happened n I’m lost… cant find my badges n don’t know wht course I’m up to or which ones i have done… This was a little discouraging

just wanted to put my to bobs in… Enjoy

1 Like

The old learning site is still available. Your progress and badges should still be there.
https://learn.unrealengine.com/home/dashboard

Going forward, the newly created DEV Learning site will mostly feature UE5 learning content. Epic is moving away from UE4 which is what the old learning site’s content focused on.

Thank You… Appreciated

Started at UE 4.26 but I stopped for a while and now that I decided to come back the learning platform completely changed. I miss the achievements, badges and the progress tracker. hope they add it again in the future.