I hate to say it but again this did not fit well with me… (I am nobody tho)
Just was not presented well at all
All over the board!
I am nobody but i did not like this approach…
I have edited yaml files in the past using flutter (NOT a big deal…)
Why are we sooo spread out… What kind of planning went into this approach…
Just does not set well for me… I am an old nobody who learned planning is key… Just seems to me this was not planned well
I found the yaml lecture fascinating, my experience told me it wasn’t something I would use a lot, but it’s definitely worth knowing. Maybe everything comes down to how knowledgeable the student is, if you already know this kind of stuff it might feel out of place, but for someone that still has a lot to learn it might feel like a great learning exercise that takes the student out of the comfort zone of Unity tools and C#.
I hope others find it useful.!
For me it just seemed unorganized the way it was presented.
Sam’s good but i can tell he does not have the patience Rick does is all i am saying
I have to agree with @Steve_Mudge
I am extremely green to all of this and generally find Sam’s approach very “all over the place” and very hard to follow.
With his videos I find myself having to re-watch multiple times - and then I still end up confused half the time.
He clearly knows the subject matter, but because he changes things 10 times in just as many seconds in the same line of code, switches approaches mid-way and generally doesn’t follow a clear path, it is very hard to follow him.
It’s OK to show multiple approaches, but that is best done over multiple instances or lessons, rather than changing the same element over and over in rapid succession.
You read my mind. What i’ve seen until this lecture was he has not planned about almost any lectures, at least it looks so.He is explaining like he have to catch bus and he have no time for this.İ see that he knows things good but it doesnt mean he can teach us as he knows. İ wish that Sam could prepare the project and Rick explain it.
Second thing i understand all lectures allthough how Sam explaining it, but when i looking after few lectures İ’ve hard times to understand what we have done on the previously lectures.Because everything mix in with eachother. dont take this as an argumentation thats just how i feel during course.
I feel like Sam does a good job explaining things. I like that he shows the reasoning for why he’s doing things, like we’ll come across a problem (often the kind of problem that I would have previously made prior to this course), and then showing how to think around that problem. So yes, while we’re changing here, for example, the Progression class that we wrote in a relatively recent lesson, I feel like this approach shows how a project can change, and how you can adapt those changes based on information you maybe didn’t have before, or due to something new coming up (maybe your lead designer didn’t think they would need X-feature to be adjustable, or maybe a new mechanic was added to the game late in development and now suddenly that changes how you have to handle character stats now). While yes, ideally everything would be planned out perfectly at the start as some people have commented, I also feel like this isn’t all-together unrealistic for how things happen sometimes within game development ( granted I’m saying this as someone not in the industry, but I have spent a fair amount of time studying game development and game design).
I agree with this comment.
I think that a lot of software development is iterative in its process, and Sam is very deliberately going through showing us a “quick solution” and letting us run right into the issues we would face with it and then showing us a way to scale past the issue (often in a challenge format where you can try it solo first.)
Just my experience, came in new to Unity/Gamedev but 4 years industry in C#
Editing the Yaml file is not something that is typically done. It is however a good thing to know and Understand how it works. I do believe that Sam does a good Job at explaining things and that must of what is done here is well planned out. Usually in Game/Software development you start out with the idea, then you implement that idea, then you test to make sure that the feature works, then you refactor for performance/code readability, test to make sure you did not break something by refactoring, then you rinse and repeat until you have all the features implemented. A complete project is Massive and can fell daunting and overwhelming at times. In most of the videos done we start with the concept, like in this case stats. We implement one some feature of this say health, next we add the next feature say experience points as we are working on experience points we have to add the code to some of the previous files that we already have in order to implement the next feature. When we get to the refactoring part notice how we have GetHealth, GetExperience and these are done the same exact way in fact we will be adding more Stats as we go so lets simplify adding new stats by condensing this to one call GetStat so when we start any new Stat this boiler plate code is already there as Generic and allows us to be able to write less code.
There’s a philosophy in programming called “Don’t Repeat Yourself”, or DRY programming. The idea is that if we have the same code pattern repeated twice, then you should find a way to refactor to bring this in once. Here at GameDev, we believe that you don’t start by writing a huge generic to cover something while you are prototyping. When we do find ourselves getting into WET code (“We Enjoy Typing”, “Write Everything Twice”), then it’s time to refactor, either with a simple method, or with a generic.
I have always lived by the rule of thumb once I find myself writing it for the 3rd time It is time to refactor to a simple method or generic.
The only time I break this rule is when after writing it the first time and it works, and I know that I will be doing the same thing later I will refactor after the first round.
There are also times that I am not sure exactly how something is going to work and I end up with a working solution that has code smell. I will refactor and get ride of the code smell (30 lines of code that I can reduce to 3, I know there is a more performant way to accomplish the same task, 80% of the time it’s flipping an if statement to continue in a loop or break out of a method early to reduce the amount of indents.
Personally, I have a bad habit of “overengineering”… I’m more likely than not to write an interface or extract a method/create a generic right away instead of seeing if this is the right direction or if I’ll need it later. Most often, this works, but there are times I create trouble for myself.
I have the bad habit of flipping the If statements and not testing afterwards, this gets me into trouble. Like forgetting to change && to || next thing I know I am why my code isn’t working some place down the road with no Error message, so it’s start at the code I am working on with a Debug.Log, nope that’s not it up to the next level Debug.Log at each step in the path until I find the spot, stare at the code this worked 2 weeks ago when I wrote it, why is it not working now. When I finally spot where I went wrong with my logic kick myself.
I have this exact same issue.
I have quite recently heard someone say:
Make it work. Make it right. Make it fast. In that order.
It’s been hard to follow that philosophy, but I see the merit in it.
Sam tries very hard to introduce us to good architectural principles. That however comes into conflict with the need to rapidly prototype where you don’t care about the perfect architecture and you don’t want to overengineer.
Sam’s trying to show us how to do both and I commend him, Rick, Brian for trying to thread this needle.
My main request is to let students know up front when something is a hack that we plan to undo/refactor and when we’re trying to follow good design practices. Or let us know if you’re showing us something different just for the sake of education. For us beginners its useful to know if some pattern we’re seeing is a short term hack or if it’s meant to be more robust code. We usually won’t have the same intuitions and its helpful for us to learn. The more experienced engineers on here I think can probably pick up the nuances.
My advice for folks who feel like Steve though is to be patient. Everything tends to make sense after more exposure and more practice and the hacky code does tend to get cleaned up over time.
Also - the content on YAML felt rushed. A very useful introduction to YAML but it could be a separate lecture outside the flow of this one.
One thing it also shows is to be careful when refactoring SO’s (and also a touch of their limits and that you don’t want to stuff all the game’s state into a single one) since you don’t want to lose the data you’ve already put into it.
It was a bit backwards going from “this is how I want the data to look like when we’re done” to “this is how I need to define my classes to match”, though…
What I did was to define the new variable stats array besides my existing one I had already for Health (and I also added one for the amount of damage to deal, so a level 3 player would be having stronger attacks than a level 1 player), so I could see my existing data in the inspector while I setup the new lists. It was still a bit tedious to copy each entry over from the old list to the new one (this might have improved with newer versions of Unity though).
Once I had filled up the new stats lists, I removed my old array for Health and Damage.
As for editing yaml files, at work I actually do this quite often (google for “Puppet” and “Hiera”, or “Ansible”, to find out why). YAML is specifically designed to be a textual format that is (somewhat) friendly for manual editing…
Cat_Hill wrote:
My main request is to let students know up front when something is a hack that we plan to undo/refactor and when we’re trying to follow good design practices. Or let us know if you’re showing us something different just for the sake of education.
I agree, some hinting on “this is a quick solution for now that we are going to refactor later” would be useful at times. 
I hate editing YAML directly for the same reason I can’t stand python… While whitespace can make a structure more readable, I hate relying on it to tell the serializer/compiler my intention unlike XML (which I admit is a bit… wordy, but you can clearly define the structure with the tags and closers) and Json (which reads as elegantly as C# to me).
Well, one has to be extra careful with indentations and look out for different people having different editor settings and how those are set in regard to handling TABs…
Otherwise one might end up with some lines of code actually not being part of an if block but being shown as if they were…
Which is exactly why I hate YAML and Python. 
When I first got into coding, long before Nirvana even played their first gig, we had two computers at our school.
One was a Mini computer with 16 terminals. The whole system had like 32k of ram, which was shared between the terminals, and all coding was done in BASIC, as this was considered at the time to be the best language to teach students to code.
The other was a much older system that used a card reader and output results on a printer. We had to program our code using punch cards in something resembling Fortran. Every student made their punch cards with our small programs and we turned them in to the instructor at the end of the day. The instructor would then put the punch cards together into a large stack and place them in the card feeder. The next morning we would get a sheet with our results…
Here’s the part that left me thankful we don’t use punch cards today in the modern lightning fast era: If one punch card was out of place, like “oops, I dropped my cards and put them back together again and one was missing or in the wrong order”, the system would get horribly confused. Not only would that student get a blank page or worse, nothing, but every student who turned in his cards AFTER that student would also be deprived of a grade for the day. Things weren’t sandboxed like modern code. It was, simply put, game over.
So here we are, 45 years later using languages like python and Yaml that can be thrown out of whack by one spacebar or tab out of place. At least the results aren’t nearly as catostrophic.
Don’t get me wrong, Unity using Yaml to serialize actually makes some sense. It is more compact than Json or XML, and since Unity is meant to be both reading and writing the file, there’s little chance of data compromise. I just don’t like editing the files manually if I can help it.
Yeah, rummaging in the internals of any of Unity’s asset files might hit a bunch of probable pitfalls that one should avoid at any cost…
(Until one has to fix a git merge error in a scene file when someone failed to observe the workflow to avoid breakage…)