Allar's Dev Diary #16: Day 7, Tower Defense Side Project

Day 7 (11/24/2010)

12. Getting Towers to Track Their Targets

Today I decided to switch gears back into actual tower development, as that is the real nature of the game isn't it? In any case, we need a way for our enemies to be registered as enemies for our towers. We don't want our towers to be attacking every actor that is within its range, it should only track and attack enemy targets. To do this, I've decided to make another Interface that way I can make any class an enemy instead of having all my enemies derive from a single class. Right now there is no actual use of the interface than to register a class as an enemy, but I've decided to throw in a function that could be used to allow for classes implementing this interface to decide that a particular instance of it is not an enemy. Today I haven't created that checks this or requires this, but I think it might come handy in the future.

Allar's Dev Diary #15: Day 4, Tower Defense Side Project

Yesterday I spent most of my day eating pizza and working on Warm Gun over at Emotional Robots, Inc., but I managed to put a little time in this morning to this side project.

Day 4 (11/21/2010)

9. Setting Up Basic Interaction Logic From Mouse To Towers

While our towers are just shell Pawns that aren't doing much, before I give them more functionality I wanted to tackle how the player is going to interact with the unbuilt towers so that they can build their own. The first step is getting some sort of simple detection going on that would let the towers know if they were currently the target for the players mouse and then to figure out if the player was within an 'interaction radius' with the tower. Doing so, the player will only be able to interact with tower building zones when their Pawn is close enough to the tower, causing the player to have to run to wherever they want to place their towers for a bit of a fun challenge. If this proves to not be fun, I can just either increase the interact range greatly or remove it all together. Also, I wanted this detection logic to be able to be applied to any actor I choose instead of having every actor derive from an interaction actor. To do this, we have to use an interface. Interfaces are kind of like sub classes, but they list a series of functions and delegates (no local variables) that each class using it must implement. To implement an interface, you just use the keyword 'implements' in your class declaration. More information about interfaces can be found on the UDN page.

The interface is really simple for now, it has a function that returns what type of interaction it is, functions to show/stop showing the player that the object is interactable, and then finally an actual interact function.