Progress with Tower Defence has been slow recently, what with moving and the general disruption that brings, but the other day I did manage to settle in and resolve a few long standing and occasionally nasty bugs which brings the game to a highly playable level. As such, I felt it might be prudent to make a demo available so people can actually try this thing out themselves rather than watching my boring videos.
I’m a long way from guaranteeing it’s crash free, but it’s not far off. There are also bugs galore (see full release notes after the break), and a few things are disabled for being either half implemented or inconsistent in performance or reliability, but it gives a reasonable overview of the project. This release is in the form of a Windows binary, although if there’s any interest in OSX/Linux/mobile builds I’ll happily crank one out and you’re welcome to see if it works.
Hello once again!
Today I’m happy to offer some code from my early prototypes of Tower Defence, build 13 from September/October ’12 if anyone is pedantic enough to want to know. It’s super basic: No maze generating algorithms yet, not much in the way of gameplay. A random maze is created (i.e, each map tile is 50/50 whether its walkable or not), start and end points generated and a route found between them using A*, and an “enemy” (green square) moves along the path. You can create a single weapon type – the gun – which fires very slow moving bullets at the enemy.
This code also contains remnants of my quick and dirty collision system, although Box2D is actually running the show.
Within the nme.geom package of HaXe NME you’ll find Matrices, Points, Vectors, Rectangles and… ColorTransform? Yes, it seems a slightly odd place to put it, but that’s where it is, and it can be useful in your project. No doubt, there are endless things you could do, but I wanted to talk briefly on how I’ve used it across my previous Pinball project and now, in Tower Defence.
Simply, sometimes you want the same object to appear multiple times in your project, but with subtle variations. Behavioral changes can be accomplished in code by subclassing, size variations by scaling, but what if you wanted it red in one instance and green in another? Including the same image twice with different colours seems redundant, even if the images in question are quite small, so what are your options? Well, a ColorTransform is an option if the image is a simple, single colour. In Pinball, I used this method to colorize the lights and lighting effects – the image files themselves were greyscaled, and were coloured in code before being displayed – and now in Tower Defence, I’m using it on some UI elements (the slider knob’s that change colour dependent on value).
Let’s step through how this works. First, of course, you have to create a graphic you want to use. Here’s the image of the slider knob in Tower Defence, as it came out of Photoshop…
Hello! Sorry that last post was so brief, but I hope you liked the video! Here’s another one for you, with some loose ends tidied…
Hey all, just a quick one this time. My tower defence game has some graphics (disclaimer: none final) and a few new little features and so I figured it’s probably time to show more of what works.
I’ve been implementing a second thread of execution in my current game project for the last few days. I had tried to do this in my previous set of code, but either had constant crashes or half the game not working because that second thread wasn’t ticking over. At that time there was almost no instruction online as to how threads worked in NME, but that has changed recently thanks to the (always excellent) Joshua Granick, whose blog post, “Using Threads with NME“, lists out some basic scenarios for communication between threads. There’s also some useful nuggets of information in this forum thread.