Lecture structure

[Stopa]

Hi, maybe it’s just me, but compared with all the previous lectures this one felt much more convoluted and complex and there were multiple points throughout the lecture where I just stopped and said to myself “No, not like that”. It feels to me that we have added just too much dependence between the classes, a Unit has a reference to its GridObject, GridObject has a reference to all its Units, they communicate via singleton LevelGrid object. Overall, the “clean code” architecture developed in previous lectures seems to be disappearing.

However, the biggest problem of the lecture is probably in the challenge. The student is prompt to make their own implementation of methods SetUnitAtGridPosition, GetUnitAtGridPosition and ClearUnitAtGridPosition only for the lecturer to completely overhaul this implementation and replace the methods with AddUnit…, GetUnits… and RemoveUnit… later on in the lecture.

Moreover, I had a feeling that most of the progress in this lecture was presented without much explanation on why it is happening or what we aim to achieve with each step which resulted in thoughtless copying of the steps into my code without much room for my own implementations, tweaks or changes.

Don’t get me wrong, I really like this course and even this lecture was well made, it is just that I felt there’s a noticeable difference to the previous lectures and wanted to provide this feedback.

[CodeMonkey]

The goal with clean code isn’t to make everything fully decoupled from everything else, the extremes are never good, you should decouple as much as it makes sense but depending on what game you’re trying to build it’s perfectly fine to couple certain things.

For the design that I was going for in this course, Units and LevelGrid and GridObjects are all essential to what I’m trying to build, so making them slightly coupled isn’t an issue at all.
If you have a completely different design where you want Units to be completely decoupled from everything to perhaps support later on making the game non-grid-based, if that’s your goal then perhaps it makes more sense to keep things a bit more decoupled. It always depends on what exactly you’re trying to build.

The goal with the challenge isn’t necessarily to end up with final production ready code, it’s to attempt to learn how to build something, refactoring is absolutely part of game development. In fact that specific scenario is exactly what happened to me while building the course, I first made it work with just one Unit per GridObject, then realized that approach would cause issues so I refactored it to support a List instead.
So that’s an excellent example of exactly what game development is like.

What part of this lecture did you feel the “why” wasn’t clear?

[Stopa]

Thank you for the answer, I see the reasoning for the coupling between the classes.

I guess my issue with the challenge is that I immediately realized the issue with multiple Units in a single GridObject, I thought about having a list of Units instead but the naming of the methods suggested only a single Unit allowed, so I have solved it already during the challenge by checking if the GridObject is empty in the set method.

The following change of the code into a list of Units and Add/Remove instead of Set/Clear felt like one of those “I told you so” moments.

I watched the lecture again today and I was probably just in a bad mood yesterday because it seemed OK on a second watch.

Looking forwards to the next ones!

[Brian_Trotter]

Each of our instructors (and our TA’s) have their own specific style of design, and their own threshhold for how coupled a class can be, whether or not Singletons can be used, etc.

Myself, for example, I abhore Singletons, because they have gotten me into trouble in the past. The debate on whether Singletons are good, bad, etc, has been raging since the dawn of Object Oriented programming. Neither answer is “right” as long as the code is working, which in this case it is working.

I refactored the Singletons out of my project, but that may not be the right answer for everybody. Whether you like them or not, it’s good to understand them.

It happened when I did this challenge with the Set and GetUnitAtGridPosition, that I saw the problem (in a game where a unit can move through another unit, it’s possible to briefly have multiple units), so I’d already arrived at @CodeMonkey’s solution, but that’s years of experience at spotting these sorts of things. I can definitely see that it could be missed by most students as the challenge methods are singular.

As CodeMonkey said, Game Development (programming in general) often involves a lot of refactoring, backing out experimental code, and revisions. Often our first thoughts are not quite what we need to solve a problem, and sometimes our solution to one problem creates three more problems somewhere else.

Keep at it, you’re definitely on the right track.