Untangling What's Happening with WaveConfig/waveConfig

For anyone else who is having difficulty following this video, here’s some advice:

Take an hour or so after the video is done and walk back and forth through the code, following the logic of everything that is happening, until you can look at a single section and know what’s going on there without having to think much about it.

I think some of the confusion comes from the video itself. Hearing Rick say “Wave Config” over and over and over again was starting to make me feel dizzy! It’s hard to follow verbally, and I think there was some semantic satiation going on there.

After the video was done, I took a break, then came back to the code and walked through every single aspect of it step-by-step multiple times and from multiple different directions. After doing this, it makes considerably more sense, including why we’re using waveConfig and WaveConfig over and over again, across different scripts and scopes. It is the name that makes the most sense, it’s just the logic that is confusing at first.

I found it especially helpful to have Unity and Visual Studio pulled up side-by-side, so I could (in my mind) run my various Game Objects through the scripts, refer back to the Serialized Fields in Unity, etc. I tried to visualize every single step and make sure I could refer exactly to what object, script, or input was being referenced at any given step. It took some time, but I think it’s time well spent.

I say “in my mind” but I actually did most of that talking out loud. I found speaking out loud, as though I was trying to explain the code to someone else, was great at reinforcing my understanding of what was happening.

Just my two cents for anyone else who struggled with this section of the course, especially if you’re newer to programming.

4 Likes

The part that makes it confusing is when we’re using the global waveConfig variable to set the local waveConfig parameter variable in the SetWaveConfig method. For my own sanity I had to rename to local variable to the one Rick suggests in the video (waveConfigToSet) because it’s too easy to lose track of which one is which.

Parameters get confusing enough for me as it is, so I don’t think there’s anything wrong with being a little more explicit with the local variable.

I’ve been doing a fair bit of renaming, myself… for example, I’ll suffix any GameObjects in the Hierarchy with “_GO”.

So now if I create an “EnemySpawner” GameObject with an “EnemySpawner” script attached to it, then this becomes an “EnemySpawner_GO” with the “EnemySpawner” script attached. If they’re both called “EnemySpawner” it puts me off about what I’m actually referencing (the GameObject, or the script attached to the GameObject).

I did experiment with suffixing the script with “Behaviour” - because the GameObject class extends MonoBehaviour - but when the name of the script is used as a noun it doesn’t feel right (e.g. you might have a “Ball_GO” with a “BallBehaviour” script attached, and then you call BallBehaviour.Bounce() or something, when it feels ‘clearer’ to call Ball.Bounce().

With method parameters I try to make them short and sweet:
public SetWaveConfig(WaveConfig wc) { waveConfig = wc; }

As opposed to re-using class property names and trusting myself not to get them the wrong way around, or worse!:

public SetWaveConfig(WaveConfig waveConfig) { this.waveConfig = waveConfig;  } // Good!
public SetWaveConfig(WaveConfig waveConfig) { waveConfig  = this.waveConfig; } // Bad!
public SetWaveConfig(WaveConfig waveConfig) { waveConfig = waveConfig; }       // Ugly! ?!

There’s a thing called ‘hungarian notation’ where you can indicate some properties of a variable/object in its name - for example, all class properties might start with ‘m’, so “waveConfig” would become “mWaveConfig” to indicate it’s a member of the class - which would make the above method:

public SetWaveConfig(WaveConfig waveConfig) { mWaveConfig = waveConfig; }

However, hungarian notation isn’t typically well thought of, and you end up with stuff indicating that it’s an int (iNumDaysInWeek = 7) or a float (fPI = 3.14159f) etc. Just prefixing member variable names with ‘m’ is fair enough, IMHO - but your mileage may vary.

Further reading: Hungarian notation (Wikipedia)

2 Likes

Very true, i think its important to do this and dont rush the videos.

I like this method, glad it’s not totally taboo, it’s the only way I can stop my head imploding :slight_smile:

Very good advice, I found myself laughing so hard at Rick typing out the SetWaveConfig method… that was a lot to take in.
I’m still trying my best to grasp all of it by doing something along the lines of what you are suggesting, and I keep telling myself that it will get easier and make more sense the more I do it. I’m brand new to this myself, but I’m very excited and so far still very motivated and really enjoying this learning experience.

:sweat_smile: