Small Suggestion for the Intermediate RPG course

Unity Courses Talk
,
#1

First off, I’m taking this course and its really really good, but i think maybe a small thing happened in the progression of GamedevTV that kind of messes up part of this course. its an easy fix with a warning at the beginning…

TLDR: i think you should add a warning to the beginning of this course basically saying “if you have done our beginner+ courses or intermediate courses you may notice a lot of coding issues in the beginning of this course. Don’t Worry! a big part of this course is making you understand WHY these are problems and how to find them and fix them! when we start this course we will be starting with a rough prototype. Throughout the course, we will continuously be refactoring and improving with real examples that you will find in many projects”.

if you made it past the TLDR…sorry but bear with me for a second here.

when this course starts the code is really sloppy. it isn’t something that we start to clean up until over 3/4 the way through it. also, though partially updated, the course was written a long time ago. Sure Unity is a bit different. the real change since then is your catalogue, and courses created by other instruction platforms. I think the expectations for intermediate course code level have changed because of this

stop reading now, it wont offend me, this is way too long and you probably get the point already_

To put it into context i have done all of your beginner, and beginner+ courses, as well as the code architecture course prior to this( i have also done stuff from other people, but i don’t think that effects this much for me at least). I’m also doing the course in 2022LTS.

when i started this course i was a bit taken aback by some of the code level. here were some of the things that drew up as red flags for me…

  1. using start and awake haphazardly
  2. lack of use of events or the observer pattern in general
    3)limited use of scriptable objects
  3. using quite a few string references what felt avoidable
  4. using tag == instead of Compare Tag
  5. using tags where maybe layers would be safer
  6. the teleport system in general but especially with the fader in place.

many of these things i was already confident with but now i was second guessing myself. i asked @Brian_Trotter about some of these( you know after self gaslighting all my confidence right out the window). After speaking with him i decided to stay the course and keep all my code the same as the instructors for a bit with two exceptions 1)the style guide and 2) the teleport fade which was driving me nuts(half the time when i faded in i would have an error and the fader would be at full alfa in the next scene so that had to go).

While waiting waiting to get to some of the big refactors, I plenty of time to think about if it was an issue or if i was just being an idiot.

image
image1280×720 79 KB

I think when this course came out there were so many less resources available that the expectation for intermediate was probably a bit lower. Additionally the course catalogue of GDTV didn’t have those great beginner+ courses by @Stephen_Hubbard . even stuff like the scriptable objects. the big unite speeches had happened, but most of the major content developers derivative videos on it all came out AFTER this course. we go through i think more than 20 hours of this class before we even start to get to the code level up to what is used in the beginner+ classes. to be clear i don’t think those classes should be intermediate instead, when i went from beginner to the code architecture course it was clear to me i was not ready for intermediate. they are a perfect transition.

i think you might want to put a warning like the one in my TLDR just to prevent people from deviating too much or wondering if they should even bother taking the rest of the course. Had i ordered this on udemy and taken some of the non GDTV intermediate courses on there first, i would have likely thought your course was outdated or was just another course teaching bad habits( there are a lot of them) and considered returning it.

P.S. I think i got all of the issues shown in the 3 refactor videos on challenges. You guys must be teaching me a lot, cause i defiantly didn’t know any of that when i started taking GDTV courses.

sorry for the diatribe. i promise im not crazy my mother had me tested.
image

1 Like
#2

Appreciate the feedback. I don’t take these things lightly! Stuff like this is also a good barometer for when we’re considering re-mastering a course to be a bit more up to date both with other course curriculum we provide as well as externally being up to date with common Unity standards and all that!

2 Likes
#3

Thank you for your honest feedback! We take these things to heart.

A number of the issues in your list are eventually covered within the full course (as in the four course series). Some things (and I’ll use Start() vs Awake() as a great example here) were intended to create the opportunity to create the very race conditions that we work to solve later in the course. (That may seem counterintuitive, but if we’d have started everything, especially the Fader Start(), correctly, we wouldn’t have had the opportunity to go through those issues when we got to the Saving System and the complete portal structure). The Fader’s fix (and it sounds like you’ve cleverly figured this out already) is to simply change Start() to Awake() so that we are caching the reference to the CanvasGroup before it gets called in a game start.

The Observer Pattern is one area that I definitely think that once we taught it, we should have immediately challenged students to convert the Hud to get rid of that horrible Update code and to implement the OP. This reinforces the Observer Pattern lesson, which is a good thing because in the later courses, we will be utilizing the Observer Patter a lot. In fact, I’m going to work up a Text Slide after the Observer Pattern lecture to issue just that challenge!

It’s a bit more nuanced than that… When we put out this refactor of the course, we told the students at the time that it was an Intermediate course, but the course was released in real time, as Sam and Rick recorded the lessons, they would be released within just a few days. (I was actually a mere student at the time, I was brought in when the Inventory course was released). So while the lessons were coming out, there was quite a bit of feedback, and unfortunately a rather large number of students weren’t even familiar with Unity or C# before taking the course. This meant that some things that were planned to be introduced earlier in the course had to wait or we risked leaving the beginning students behind altogether (and many of those students were in the original crowd sourcing campaign!). Originally, there was only one section on Saving (the harder one where we do the deep dive under the hood), but it left a lot of students behind so the decision was made to create the Asset Pack version of the saving system lectures. I’m not knocking the students here at all (or even Sam). At that time, finding an intermediate or advanced course on Unity anywhere was a bit like hunting for bigfoot.

You will find that the remainder of the courses are quite a bit more in the solid Intermediate category. A big focus in the Inventory course is learning to read and complete code that others have written, which is an important skill. All three of those courses dig much deeper into Scriptable Objects, the Observer Pattern, and more.

I’m looking forward to more discussion and questions as you work through the courses, and as always I’m here to help, and even work through ideas for improved refactors.

2 Likes
#4

thanks very much to both you. i know its weird getting complements from a stranger but you guys really have helped me a whole lot.

#5

Indeed, some sort of preface video which gives a bit of background on the course and possibly an overview of differences between a more recent version of unity (which new students are more likely to be familiar with than the older 2018) and what to expect as well as a hint that at some points the code isn’t perfect (for simplicity or for teaching reasons) could be useful.

As for updating the content as such, I would think what Brian said about improving the UI handling to be more event driven (and possibly introducing events sooner) might be a good start.

Also, updating the save system to be using JSON right from the start would be great.

Some hints on the outline of the sandbox level and what to watch out when creating one to avoid some of the technical errors I did would help. Especially the terrain layout for a good starting position and setting up the camera…
One issue I have is that my starting point (and when added the position of the portal) are too close to the edge, so I have issues with the camera showing off-terrain parts. And it really doesn’t want to follow well when going downwards (towards the camera), so going back is really working badly…
Also, with the camera dollies for the cut-scene pointing to a patrolling guard, the camera’s view during the cut-scene can vary a lot depending on the delay between entering the scene and hitting the cut-scene’s trigger. What this needs will be a total rebuild of the scene and I would need to follow some rules that I wasn’t aware of at the challenge’s time (and that weren’t actually addressed in the lessons either).
So, what I need to redo is

  • have some generous starting area for the player with room for the portal and also for placing equipment to grab as well as some enemy to fight
  • this area needs to be before crossing the bridge (or whatever one sets up to trigger the cut-scene)
  • include one or two guards that patrol a small area (for example just covering the front row of 2-3 houses, or moving from one side of a road to the other and back) so a camera following from the side works well, unlike my setup with stationary guards in front of the houses and the patrol doing a big circle around the houses with the camera being somewhere to the enter which makes the camera cover a wide angle over that area from all sides…

So maybe setting up a level that’s not working so well in these points and then going through how to improve it might be a good addition…

1 Like
#6

That doesn’t need to be a full deep-dive into level design of course, just covering the most important technical issues (like I mentioned) would be great.

Another thing that I just hit the other day is how there are no (or at least not always) openers and closers for the sections. I’m about to start the polishing section now, and (as with the previous section) it seems to jump right into the next topic…

Privacy & Terms