Who would you prefer finishes this section?

@Ben, I think my previous suggestion of having Introductory, Intermediate, Advanced courses may help with some of the ideas/feedback, I mentioned it ages ago, although I forget whether it was via email / pm etc…

No one solution is ever going to fit for all, not perfectly. The community is so vast and varied, such a mixture of development, gaming and creative experiences and abilities.

I think the courses so far have been very good at creating something which leaves enough scope to then build upon it ourselves. Just my personal view on it, but I fully appreciate for other people they may want a full game from a course. I guess this could get a tad tricky, from the perspective of what functionality you include, and what doesn’t make it. What is “full” for someone maybe “missing a bit” for someone else. A line has to be drawn somewhere, a trade off between more functionality and a longer course before you get to the end of the game, or less functionality but a quicker result, even if some of it is bare-bones for you to add to.

With an introduction, intermediate, advanced (or something similar) approach, you could potentially have a small series of games at the introduction level, nice and straight forward, quick, simple, easy win for the student and covers getting used to the environment, some development principles all whilst keeping things fun.

Intermediate could perhaps go one of two ways, either taking a couple of the previous games from their completed state and then building upon them further (but without the requirement of having to have done the first course, e.g. you get a set of files to start you off, which then allows the student to choose their own level), but then covering more advanced topics, techniques, principles and at the end you have more of the fully signing/dancing game. Alternatively, to focus it on one of two full games, but again, I would strongly suggest that this still needs to leave enough scope for the students to go off and still make it their own, anything less would just mean there are thousands of clones… and when people share their works, it’s a bit like, “erm, yeah, seen this a thousand times already, and it doesn’t stand out”. I believe that one of the best ways to learn is by trying things yourself and the courses currently leave good scope for that.

Advanced I think should perhaps not actually cover making a specific game at all, but cover much more advances techniques/topics. You still end up with a working model of that functionality, but in its most minimal of states. By doing so you could cover quite a few more advanced techniques and, for anyone who had taken any of the previous courses they could perhaps consider going back to those games and progressing them further with the additional knowledge, or just applying it to something that they have started working on themselves.

I think it’s quite difficult to put together material that will please everyone completely, the number of times I have bought books in the passed just because there was a section that covered what I was really interested in, but I had to go through all of the rest (or skip it and still pay for it) just for that bit… It’s not really the authors fault, they couldn’t really write one book that covered everything for everyone, it would never be finished or, by the time they were half way through the first half would be out of date!

Just my two cents, to add to all of the other fab feedback above.

2 Likes

If you want to finish off the course with a bang, maybe build a prototype, and then put the whole thing up on github, and have the last section be; take this and make something of your own which is fun out of it, as part of the course, instead of getting to the end of a section and being like ‘now go finish this yourself’.

In the blender course its like, here’s how make a chess piece. Here’s a bunch of pictures. Now you go, make your own chess piece, or whatever, add some crazy style to it and show everyone. People really seem to like that; I certainly did.

The last few sections of the course haven’t seemed very interactive to me; I can’t speak for anyone else, but I’ve just been idly watching a lesson here and there like, eh, that’s interesting.

There’s been nothing that particularly draws me in to clone the git repo, open it up and try modifying it to do something different; if I had to put it in a nutshell, I’d say it felt like:

The lessons are covering making game mechanics not making games.

You want a suggestion? My suggestion for the final section: create a set of super basic mechanics, like re-using the pickup and trigger stuff from the escape room, and create an Incredible Machine style physics puzzle sandbox; where people get to:

  • Walk around, pick things up, interact with things. (ie. super trivial scope)
  • Have a library of pre-made components (eg. conveyor belt, ball, goal post)
  • Stick it all up on github and start off having people downloading it and building a level.
  • Add a mechanic to ‘win’ a level when you solve the puzzle on it (eg. put ball in goal)
  • Add a mechanic to ‘goto the next level’ when you solve a the puzzle on a level.
  • Actually have people add their own levels!
  • Show people how to make a few new sandbox components (trampoline, fan, whatever)
  • Get people to make their own components and show people what they’ve done~

It doesn’t have to be complicated; it doesn’t have to be that. It could take a starter kit of a racer game and making custom cars, or an fps with custom collectables and enemies, but the point I’m trying to get across is, I feel like after the time spent in the course so far, I think maybe its time to encourage people to make things of their own, show them to people, experiment and share.

If you focus in so closely on the detailed mechanics of every single game system, you’ll be there forever before you build anything interesting.

Obviously everyone has an opinion, so take mine worth a grain of salt, but those are my thoughts.

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!)

1 Like

Don’t apologise for this useful and detailed feedback, thank you.

1 Like

I’ve created a new post here I’d love your feedback on… Our 2020 Content Vision

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

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.

2 Likes

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

@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.

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

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

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

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

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.

@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!

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

Privacy & Terms