The author starts with a pre-made game based on what is taught in the beginner-level course. It’s a 2D shoot'em up where you control your character with the keyboard and aim with the mouse. At this stage, the game is fully functional but flat and boring. The author's thesis is that by adding small, specific details, you can make the game incredibly engaging and appealing. Almost all these details revolve around the idea of providing feedback to the player, visually reinforcing their actions. If the player shoots, the camera should shake slightly; if they throw a grenade, the camera should shake more intensely. If the player moves, their character should sway in the direction of motion and kick up a slight dust trail. And so on, with a long list of examples, each one used to demonstrate a different Unity feature.
For camera shakes, the course briefly introduces Cinemachine impulses. Dust trails and explosions serve as an excuse to overcome the fear of particle systems. The main character is given the ability to fly with a jetpack, which serves as a way to configure a Trail Renderer. The course breathes life into the game environment using Unity's 2D lighting capabilities in the URP, and gets unexpected mileage out of HDR colors with a simple Bloom post-processing effect. Sound isn't overlooked either, providing an opportunity to use Unity’s AudioMixer for the first time (at least for me).
As a result, the course touches on a lot of features. All of them are presented through examples, none explored in great depth but with enough detail to get comfortable with Unity tools and mentally map out where they might be useful. When the time comes to use them, you'll have the chance to dive deeper.
I diverged quite a bit from the course at the coding level. I'm not saying the author writes poor code—far from it—but their organizational style didn't quite resonate with me. It's a matter of personal preference. For instance, they tend to use events to subscribe methods within the same class as the event, while also leaning heavily (in my opinion) on direct component references. I usually work the other way around: using direct method calls within the same class, references to components below the caller, and events to communicate upwards in the hierarchy or between components at the same level. I'm not claiming my way is better, but I feel more comfortable with it than the author’s approach. In the end, I implemented the code in my own way, and as I progressed through the course, my version of the code became increasingly different from the author’s. It’s not a big deal. I'm mentioning this because if you take the course and find the author's coding style doesn’t work for you, don’t be afraid to do things your way. You'll probably learn much more that way than by just copying the instructor’s code.
It’s also true that GameDev.tv courses give you room to do things your way. A hallmark of their approach is the frequent challenges they present. In each one, the instructor describes what they want you to achieve functionally and then asks you to pause the video and try to implement it yourself. When you resume, the instructor explains how they solved it. If you get stuck, their solution helps you out; and if you manage to solve it, the instructor’s approach might reveal new options you hadn’t considered. Either way, it’s a much more interesting, fun, and rewarding way to learn than just following the instructor’s steps.
The only thing to keep in mind is that with this method, it’s normal for your implementation to gradually diverge from the instructor’s. By the final chapters, it’s not uncommon to spend extra time adapting what the instructor does to your own code version. This means you often spend much more time than the course estimates per chapter, but I think the learning process is much more effective.
In conclusion, I don’t regret taking the course. I found it entertaining, interesting, and I finished it having learned a lot of Unity features I wasn’t aware of before. For a course to give you that is not bad at all.
