Finally! After months of scrabbling for time, competing with the pressures of too many ambitious projects at my day job, I feel I’m making decent progress. That said, I still can’t quite shake the sense that, no matter how much progress I make, the road isn’t getting any shorter.
I’m also sorry to say the course I’m taking isn’t helping as much as I’d hoped.
Anyone who’s been on a long hike or climb probably knows the feeling. You set your sights on some goal, some waypoint or plateau that represents the next major step on your journey. The moment you finally round the last corner or crest that final hill, there’s a rush of achievement that’s followed quickly by a renewed sense of just how much further you have to go. It’s a great feeling, but it’s humbling, too.
Which brings me to a slight problem. The Unreal Engine course I’m taking on Udemy is becoming more and more frustrating. Some of my gripes are just nitpicky: I wish the course went deeper into some topics & just skipped over others. Refactoring is good, but the instructor is a tad fastidious and spends too much time explaining every little change. Most of that just boils down to personal preference, though, and isn’t a real criticism of the course.
My bigger concern is that the course isn’t doing the one thing I hoped it would do: It isn’t accelerating my Unreal education.
I took this course for the same reason you might hire a tour guide: To stay focused, on track, and make the best use of limited time. You want someone who’s been there, someone who can keep you on the surest path, point out the great stuff, and breeze past the tourist traps.
This course isn’t doing that. By analogy, this course has been like a guide who, despite a deep well of enthusiasm, can’t seem to stop fiddling with his backpack. He spends so much time making sure your gear is just-so, you can’t help but wonder if maybe you shouldn’t just head out on your own and check back later.
So that’s what I did. Right about the time the course presented a lesson where we would be implementing timelines using Blueprint instead of C++, I decided I’d just go figure some things out on my own. Blueprint isn’t bad per se, but it’s not what I signed up to learn. I also didn’t buy into the instructor’s claim that it would just be “better” in Blueprint. I figured there had to be a good way to get the best of both worlds: Use the graphical timeline editor in the Unreal Engine UI, but keep all your component’s code in one place, in one language.
And there was. Turns out you can manage “float curves” as assets, which can then be loaded and assigned to your timeline component at runtime. I implemented the same features and functionality presented in the course, but I did so using C++ instead of Blueprint, and in the process learned about Unreal’s component model, delegates, and a few other topics. I learned enough that, when it came time to implement some sound effects, I was able to keep working in C++ and skip the lesson entirely (which was in Blueprint again anyway).
So if I learned so much, what’s the problem?
The first problem is time, and my lack of it. Figuring out the C++ timeline implementation took the better part of a day. The solution wasn’t difficult, but when you’re bumbling about on your own, time is just the price you pay. That’s precisely what I hoped this course would spare me.
The other problem is that I’m now far less confident the course is teaching me what matters most. For C++ programmers, understanding Unreal’s component model seems a rather important topic, but after 100+ lessons, everything I know about it I figured out on my own. What else is being glossed over?
And yet, it’s still better than going it entirely on my own, so onward I go.
I think my solution is probably worth sharing. I’m out of time today, but I’ll see if I can post it later this week.