Who would you prefer finishes this section?

Unreal Courses Talk
#21

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:

  1. Make it really fancy only in Blueprints with explosions, power-ups, using cover etc.
  2. Less complicated but 90% in C++ code.
    Either way it would be really awesome.

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.

1 Like
#22

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.

#23

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.

2 Likes
#24

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.

1 Like
#25

@shadowmint

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.

#26

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:

  1. Re using your existing code in multiple projects.

  2. Change the ‘internals’ of a component without breaking the whole project.

  3. Build new small features that contribute to the whole.

  4. 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:

  • build modular components
  • OR build small games where the complexity doesn’t spiral out of control~
  • OR build a ‘template project’ and actually show how to modify it.

The first rule of gamejams is don’t be overly ambitious, or you’ll never finish what you’re working on.

:slight_smile:

…but, like I said, just my opinion. I trust Ben & Sam to flesh out the rest of the course with cool stuff.

1 Like
#27

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.

1 Like
#28

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.

2 Likes
#29

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:

  1. Create the game entirely in C++, with hard-referenced assets.
  2. Recreate the same game in Blueprint (this one could even be a challenge!).
  3. Take the C++ project again and:
  • Expose some Variables to Blueprint.
  • Soft-reference the assets using Blueprint.

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! :slight_smile:

3 Likes
#30

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.

#31

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.

#32

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.

#33

@ben & @sampattuzzi

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 :confused: >

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!

#34

Hey folks, give us your input on what you would still like to see covered in this section:

#35

Thanks for mentioning that @Marc_Carlyon. I will try and get the sound sorted for future lectures.

1 Like
#36

@sampattuzzi also worth bumping on existing lectures.

Privacy & Terms