Wow thanks for this guys, we had a meeting about our 2020 course portfolio structure yesterday and I’d like to present it to you guys for feedback as hardcore fans, ideally during a live-stream in a week or so.
If we did that, can you suggest a few good times of week for you guys so we can pick something that works for most of you?
During school hours or after 9pm neither of which is particularly convienant to anyone -.-
With the view to the cours ebeing too large in its sections and nothing really complete i tend to have to disagree in part. I am on the road to making a fully FPS and althoguh its only one game out of the entire course applying the entire course means i can add my own customisations.
For example i have doors on player triggers, Doors on pressure triggers, Doors that wont trigger with and NPC but will with a Player. This works on cupboards,windows,trapdoors,draws or anything you can possibly imagine opening on a trigger.
The information is there to find in the course and a little googling but its all there to make what Unreal Engine was focused to which is an FPS.
Its not a hard stretch to see from the unreal course how to make an RPG in Unreal from the course as it is, Damage for melee is simply applying the animation and adding the notifier at the right time to apply damage or if you prefer do it via the collision system but simplier is better.
I’ve already started thinking about modifying the current damage system via tags to see if the enemy is armored or if other attributes are in effect.
The only thing really i feel has to be part of the course is we used the sense system with sight and hinted on sound but footsteps to be detected when moving at a certain speed (Ie not detected when crouched/sneaking) in combination with the speed at which the animation and sound plays.
I can understand what people are saying that they prefer smaller chunks of learning with more complete small projects but i feel thats more what unity was designed for and unreal is designed for these bigger projects.
The topic has got a little sidetracked i think in the sense the problem people have is with the course structure and not the people that teach it so the vote may be a little bias.
Maybe i am a little bias towards unreal but i dont know how many of the above have completed the VR course and so are used to Sam’s methods of teaching.
(Darn it guys i used to get yelled at for walls of text so i stopped doing it until you guys made me!)
Don’t apologise for this useful and detailed feedback, thank you.
Both are really great and enthusiastic teachers however I’m more worried about the “Spaghetti practice” going on with this section. Blueprints and C++ should not be mixed without a good reason. Now we start with C++ templates and most of the stuff is made in Blueprints. It gets confusing to find something even in a small project.
My suggestion would be to finish Testing Grounds in one of two ways:
Overall I don’t get the complaints about game choices for tutorials. One is about building a Pawn from static meshes and using physics (Battle Tank), while the second one (Training Grounds) focuses on characters with skeleton meshes. Regarding variety it’s perfect (IMHO). Multiple small games would not cover the cool mechanics available in UE4.
Thank you for this feedback. @sampattuzzi and I complete agree about keeping things simple, and separated. This is hard with Unreal at times, and it’s tempting to prototype in Blueprint then cement into C++ later.
I disagree. From my point of view, I appreciate the depth of the Unreal course and the complexity is exactly what interests me. Short, easy tutorials that aren’t complex are easy to duplicate and probably can be found elsewhere in a similar fashion.
One of the essential difficulties of software engineering is complexity and Unreal API has a tank load of it as well as designing games in general as a paradigm. The way Ben/Sam go into the iterative aspect of game design while showing the more complex ways to do things with Unreal is in my opinion a lot more alike to what someone would experience in the real world designing a game that someone would actually want to play.
Thing is, some of the concepts taught here indirectly cover a lot of important aspects from any university computer science degree such as iterative design processes, importance of refactoring when and how to do it, many C++ concepts including polymorphism and inheritance as well as an in depth view of how to use VS2015. I have to say, I did not know about enabling the experimental feature of extracting a function. That blew my mind. I honestly could go on giving more examples but I think you get the point, I think he hit most of the essential difficulties of software engineering in ONE course.
TLDR: Making games is hard, I truly appreciate the level of complexity in the Unreal course. If anything, CRANK IT UP.
Thanks for your candid and honest feedback. We really appreciate having such a great community.
To address your concerns Ben is going to be reviewing the new content I have been adding in the next couple of weeks. We will then create tweaks and rework the learning structure where necessary.
As a result of that process we will decide whether Ben or I should finish the section and the course as a whole.
Hey man I feel the same way about the tank project, but I figured I could use that knowledge to do something slightly different like try to do strange ‘submarine game’ with some fast models.
In the game you’d barely see your opponent unless they are right next to you and you can activate sonar to see them briefly but that would reveal your position to them… in addition, unlike tanks you are pretty much floating in space/water.
so its still FPS-like but slower paced
TL;DR take that idea and change it somewhat to make it your own or make it work towards something you are interested in.
Can’t please everyone, and totally, I’m just putting my opinion out there, so it’s great to see what other people think; I’m just one lone voice in the crowd.
Basically what it boils down to, for me, is: Software projects are hard not because coding it hard, that’s just a technical challenge, any one can do it, really; the reason software is hard is because managing complexity is hard.
Once you do any software beyond a certain size, the biggest challenge isn’t writing new code; its managing the complexity of what you’ve built.
One of the key principals of software engineering is building modular reusable components that allow you to manage this complexity by:
Re using your existing code in multiple projects.
Change the ‘internals’ of a component without breaking the whole project.
Build new small features that contribute to the whole.
Lets you try different things quickly and easily.
So… if you’re not going to use modular components (and unreal plugins are a pain to work with), then trying to build a big game isn’t really a good idea, because you can hack away at it, day after day, but all you end up building is a nasty tangled mess of blue prints you can’t reuse for anything ever again. More and more layers of complexity until all you have is a pile of bugs. You can do it, but it’s bad practice, and it’s a bad thing to teach people.
I’m not suggesting that the course focus on making trivial games…
…but, either:
The first rule of gamejams is don’t be overly ambitious, or you’ll never finish what you’re working on.
…but, like I said, just my opinion. I trust Ben & Sam to flesh out the rest of the course with cool stuff.
Thanks again for all your feedback guys, we’re really excited about how much better we can get despite the fact we’re already great. This conversation, the RPG Kickstarter and feedback in other courses is really helping to steer our long term vision.
Thanks again.
One of the major skills we want to teach is how and when to refactor. So introducing complex projects that need managing is intentional. We hope that with this we can show people how to take a project from working but nasty to working and well architected.
I’m at 75% of both the Unreal and the Unity courses. I started the Unreal course as pretty much a complete coding noob, and moved to the Unity course after BattleTank. While I do like the complexity of the projects of the Unreal course (BattleTank was perhaps a bit too long, but I would definitely love Testing Grounds to be even longer), I think they feel nowhere as rewarding as the Unity ones because none of them is a complete game, and most importantly, the course doesn’t provide you with the necessary knowledge to finish those games on your own.
Bulls & Cows was IMO a fantastic introduction to C++, but after that the course introduced Physics Handles, Ray Casting and other ‘scary stuff for beginners’ too early. I’ve also had some trouble to understand the Blueprint initialising done in BattleTank. While I never got stuck at any lesson, I never felt myself confident enough to stop and try out new stuff on my own, which happened very early in the Unity Course.
My suggestion would be to add a new short section before Building Escape, where you get to learn how to create a very simple but complete game (a Tic Tac Toe, or something like that?), so that by the end of the next sections you can stop and finish those games on your own by adding some menus and win/loss condition code. It could be structured like this:
I think level management and creating menu systems should be covered as early as possible in the course, and asset referencing could perhaps be taught as a specific lesson instead of throwing it in the middle of other stuff.
In spite of the criticism above, I’m still having a blast with the courses! Keep up the good work, guys!
Hey guys - really love the course, I’m almost done with the current content available but I’m curious if there was a conscious decision to switch more to Blueprint and away from C++ for TestingGrounds.
I would have really liked to see how to hook up the AIPerception system in C++ by creating the NPC AI Controller in C++ rather than in Blueprint. I’ve been trying myself and it’s quite tricky and won’t work right yet. Blueprints are great, but I can’t transfer that knowledge to anywhere else besides UE4.
Hi Kensai, it’s just that we’re still prototyping the behaviour and it’s somewhat faster to do that in Blueprint. Once the behaviour is settled, @sampattuzzi may well move to C++ as we have done before for performance, maintainability and clarity.
Hi Ben!
I’ve been working on learning how to do the AI Perception system myself in C++ and making good headway relying on all things learned in the course. Thanks for the reply, it’s great to hear that more C++ may be incorporated in the future. Have a happy new year.
Something i forgot to mention is that sound levels vary greatly between Ben’s microphone and Sam’s microphone.
I use a tv for my pc on a hdmi lead and at volume 8 (my normal listening volume) i can hear ben fine, Sam however i have to turn up to 30 to get the same volume level.
Its a minor irritation and i understand that previous recordings would be a major upheaval to correct now but maybe for future videos we can get sound in balance (Maybe Sam needs mic boost or just a better mic 
>
Sorry for posting it here as we really dont have a general feedback section for things that dont fit anywhere else. (Or maybe i missed it)
Thanks again for the great courses!
Hey folks, give us your input on what you would still like to see covered in this section:
Thanks for mentioning that @Marc_Carlyon. I will try and get the sound sorted for future lectures.