GameDevHQ Intensive Training Program — 03 — Camera Movement and Tower Placement

Week Two of the Intensive Training Program certainly showed why it’s called “Intensive”. I feel that Week One sort of lulled us into a false sense of security. This week was far more full-on in terms of the complexity of what we were doing.

The first part of the task was relatively simple: allowing the camera to move around within the boundaries of our game space. The only gotcha here was that I had the camera tilted at a 45-degree angle to look down on the playing field. This meant that while movement left-and-right worked as expected, movement forwards-and-backwards acted more like a very clunky camera zoom. The fix was simple though: put the camera in an untilted container and move that. Everything then worked as it should and I could implement a real camera zoom using the Field of View setting.

Then it was time to start work on placing the eponymous towers in my Tower Defence Game. The big new concept we were encouraged to explore this week was that of events and delegates. I’d seen them used before in some tutorial series I’d watched on YouTube in the past, but it had never really been explained what they were or how they worked. They were just this magic “thing” that did… something. What was that something? Who knows? It’s magic.

I struggled for a good part of the week to get my head around the idea. (Actually, I lie — it wasn’t a good part of the week at all!) Course Mentor Dan was kind enough to schedule an extra catch-up meeting with me so that we could talk through some of the problems I was having, and this was extremely useful. I came out of it feeling like I had a much better handle on how events worked in Unity, why they worked, and when to use them. So much so that I was able to rewrite my original brute-force implementation to be entirely event-driven and I feel really good about where my code is right now. I feel it’s in a good place to take on Week Three’s challenges.

The other “fun” challenge of the week happened when I created a translucent prototype of the selected tower to follow my mouse around while in Placement Mode. People with sensitivity to flashing lights probably should shut their eyes and count to 4 after hitting play.

It turns out that the problem occurs when one or more objects in the prototype has a collider attached. The raycast that is used to track where the mouse is tells the collider “hey, you’re hitting something!” The collider then does what it assumes is the right thing and bounces off the object it hit, in this case the ground. Once it gets behind the camera, it resets, at which point it bounces off the ground again.

Thankfully Unity provides a very simple solution in the form of the “Ignore Raycast” layer. This does what it says on the tin, and makes any colliders ignore the raycast telling them they hit something. Now the tower prototype follows the mouse as planned and can snap into the defined placement spots.

A hectic week all up, but I feel like I’ve made some real progress both in developing this game and in furthering my understanding of events in Unity. Bring on Week Three!