Playing With Tower Defense Mechanics

by edo on May 16, 2010

I know, I know, the two and a half readers I have have been wondering "what the heck is going on with your iPhone development work?"

Fortunately, the answer is "more than a little" (not the same as a lot, but definitely more than nothing).  I've been busy playing around with iTGB 1.3.  I spent a good deal of time solving the common problems everyone runs into.

Getting Up To Speed on iTGB 1.3

Over the last month or so, I have been answering these common questions:

  • Why won't my player move? - Oh, turn on physics for it!
  • Why doesn't my text print out? -  Ah, I'm missing the required UFT files.
  • OK, so how do I generate these buggers (UFT files) and shouldn't they get automatically generated when I run this on a PC/Mac? - Oh, that bit is broken, but I can use TGE, T3D, TGEA, TGB, etc. to generate them and then copy the generated files over.  Got it."
  • Why are there two different places where datablocks for images are specified? - Oh, for efficiency, and I have to make new datablock files for each scene?  Got it.
  • How does touch input work for objects? - Ah, just like mouse inputs.
  • How about the accelerometer? - Oh, that is treated like xyz joystick inputs.
  • What about multi-touch, how do I use that? - Hmm, I see, enable it and use the pre-defined callbacks.
  • Hold on, why isn't iTGB tracking my touches in the order I place and lift them? - What? No answer.

When I got to this last question I ended up having to dig a bit and found out that the way iTGB 1.3 implements multi-touch does not specifically track touches as unique events.  The callbacks tell you how many touches worth of data (x and y coordinates) are being passed, but the engine doesn't know which prior touch those inputs go with.  So, I modified the engine to track this data and now instead of a count (for the first argument in the oniPhone*() callbacks) the engine sends a list of touch numbers.

Whereas previously, data for a two finger move might look like this:

oniPhoneTouchMove( 2, "x1 x2", "y1 y2" );

Now, the callback data will look like this:

oniPhoneTouchMove( "1 3", "x1 x3", "y1 y3" );

The old callback tells us that two touches were moved and sends us their respective x and y values.  However, it doesn't tell us which specific (previous) touches these are.  The modified callback does provide  this very important data.  It tells us that touches 1 and 3 were moved and then passes the x and y data for each.

Write A Guide?

So, what have I learned on this journey?  I've learned that some things are still true.  Working with Torque always involves a little bit of labor and some effort hunting for answers to questions.  Also, the forums, resources, and blogs are all still great sources of answers.

I've also learned that there might be an opportunity for me to write a how-to guide for iTGB users (new and old).  However, I'm not quite ready to commit to this effort.

(If you read this part and thought, "Wow!  You should totally do that.  I'd be willing to spend a few bucks (say $20 to $25) on a iTGB guide.", The please comment on this blog entry.  Let me know that you're interested.)

Tower Defense Games?

Right now, instead of writing a guide, I'm going to take some time and explore Tower Defense mechanics.  That is, I'm currently writing a Tower Defense combo game.  The combo comes from the fact that it contains a bunch of mini-games (all tower defense games), but each mini-game implements different mechanics for creeps, paths, towers, etc.  I'm exploring features I've already seen in great games like geoDefense, geoDefense Swarm, Defense Grid, and vs. Zombies, etc.  These features include:

  • Creeps - Slow, fast, ground, flying, various weaknesses (fire, ice, projectiles, electricity, ...)  and strengths( shields, speed, stealth, ...)
  • Towers - Projectile, fire, ice, shock, slowing, laser, resource gathering, ...
  • Paths - Single direction splines (geoDefense), Bi-directional Splines (Defense Grid), totally open, grid-based with and without obstacles (geoDefense Swarm), air and land (Defense Grid), row-only (Plants vs. Zombies), ...
  • Scoring Mechanisms - Limited creeps allowed to make it to end of path (geoDefense), Limited resources which creeps consume/steal (Defense Grid), Single creep kills/ends level (Plants vs. Zombies), ...

I'm also exploring a long list of features I've never seen in a TD (not to say they don't exist, I simply haven't seen them):

  • Color coding creeps and towers to help correlate vulnerabilities.
  • Creeps that attack towers. (OK, Plants vs. Zombies does this, but this is the only one I know of and I want to explore it some more.)
  • Playing the creeps instead of the towers.
  • Head-to-Head (dual player) TD.
  • Towers require research to upgrade instead of simply providing new towers over time.
  • Variable options for upgrading towers. i.e. Focus on reload speed, damage, range, etc instead of having a single upgrade path.
  • Creeps vs. Creeps
  • Towers vs. Towers
  • Turn-based attack/defense
  • Path building a part of game mechanic.
  • Variable tower performance, tied to resources or protected entities (power supplies, etc.)
  • Suicide creeps/towers.
  • ...

At this point, you may be asking your self, "Why? Isn't TD already saturated?"  Sure, it probably is, but I still want to do this because I love TD games and I like the idea of exploring new ideas in this genre.

That's it for now.  I'll post screens and videos as I have them.  Also, don't forget to comment if you want me to write a iTGB guide and feel free to make specific requests.  I am listening.

-Ed Out.

{ 2 comments… read them below or add one }

Brian May 17, 2010 at 2:55 am

I think there’s definitely room for new features in the genre, even if some of them are just mashups with other recent genre innovations. How about an instant replay to fix mistakes, ala Sands of Time? Slowmo, ala Max Payne? Not a recent genre feature, but how about power grid requirements like the original Sim City or Ultrabots (you must place or extend the power grid before towers work). In any case, many possibilities, as long as they make the game compelling and not just annoying. :-)

Brian May 17, 2010 at 3:25 am

I also have to add another comment and say the more I think about it, the more I like the idea of divergent options for tower development. Taken to an extreme you could have a single base tower type and everything evolves from there. I think that’s too much though; you have to keep things fairly simple so as not to overwhelm or take too much management time during game play. Maybe each tower type can diverge once or twice around the second or third upgrade, or there is a single special ability option that can be purchased for one level of the upgrade cycle.

Leave a Comment

Previous post:

Next post: