I love doing too many things. My interests cover such a wide gamut that I wonder if I’ll ever settle on a career path. But that’s not why I decided to write this blog post.
This opened up worlds of possibilities. I had heard many wonderful things about what one could do in an object-oriented environment. I was excited to dive in and try it.
Then, last weekend, I was sitting on the couch with my family watching Chitty Chitty Bang Bang (written, apparently, by Ian Fleming, with a screenplay co-written, oddly enough, by Roald Dahl), and the idea seized hold of me again. It was the scene where the children raid the castle toward the end. They rushed the adults, and I pictured it from a bird’s eye view as dozens of little dots moving in and attacking other little dots.
Not an hour later I was writing code. I started by defining an Army object, then I wrote the Warrior object constructor. It was complex, with dozens of little stats to track, and several complicated functions for thinking, targeting, moving, attacking, defending, and more (nearly 300 lines of code just for the Warrior object). I wrote code to define the starting position boxes for the armies (bases, essentially), code to draw the objects as stylized DIVs on the page, and I wrote an HTML page with a basic framework to display it all. I’ve been learning to use the CANVAS element for drawing, but I wanted to stay away from it as this was going to be a project I could play around with at work where they still have us using IE8 and the CANVAS element isn’t recognized.
Surprisingly enough, when I first ran it (about five hours after I wrote the first line of code) everything worked (kind of) as expected. I had to rework the rendering code (I was trying to redraw everything each frame, and with hundreds of little HTML objects that initial approach was impractical). After fixing the rendering issue it ran smoothly and most of the behavior was exactly as I had imagined it.
I’ve tweaked several of the systems since then, but the essential framework hasn’t changed. You can try it here if the link doesn’t get overloaded (who am I kidding – I couldn’t possibly generate enough traffic to take down a dropbox link). The one item I re-worked the most was the targeting code. In fact, I’m still not happy with a lot of things in this project, but there are even more things that I love about it.
First, it’s the very first time I’ve made something visual with what I would consider emergent behavior. I wrote a primitive chat bot (I cannot be held responsible for anything Jimmy says) once that had some pretty unpredictable responses (many layers of code analyzing your input and outputting based on more criteria than I could keep track of), but that “emergent” behavior wasn’t always contextually appropriate (Me: “Hi there! How are you?” Him: “You’re not being very nice.”). My little battle simulator behaves very much like a little battle. The winner is determined by a mixture of attributes (leadership scores, strength and number of warriors, amount of supplies available, location of base, etc.) and circumstantial happenings. I’m just as incapable of predicting the winner as anyone else, yet there is very little variation between the armies in the way of random number generation.
If you do check out the link, I apologize in advance for some of the Leader names. The idea of giving each army a leader is credited to my co-workers, but the names for those leaders were also their ideas. I made some slight modifications to a couple of the names, but one of them I left in a fairly inappropriate state simply because changing it would have taken away from the effect. Some of the names are not child friendly, just so you know.
The thing I’m least happy about with this is the targeting code. It’s limited, inefficient, and doesn’t accomplish all the goals I had for it. I realized yesterday that what I really wanted was a collision detecting framework. I imagined a centralized process being aware of everyone’s location and allowing any one of the Warrior objects to perform a simple query to get his nearest neighbors. I was unfamiliar with actual collision detection methods for software, and was pleased to learn that what I had devised wasn’t too far off from reality.
In my current system each individual on the screen has to scan every other army’s soldiers and rule out targets that are outside of his visual range. This takes a lot of processor time, and whenever anyone was selecting a target there was an awful performance drop (especially at the very beginning of the battle when nobody had selected a target yet). I did a couple of things to mitigate this: any time around half of the soldiers in the army’s array are dead it clears out the dead from the array, shortening the amount of time it takes enemies to scan for a new target (since they no longer have to process dead people); and I spread the search function out over several frames rather than attempting to do it all in one rendering cycle (I also learned how to make recursive or pseudo-recursive functions this year).
Obviously, with each and every dot doing his own collision detection and targeting it’s still pretty inefficient. I need a centralized collision detection system.
But now I have to learn how to implement something like that. I might implement it in my current project, but I think starting a new project would be better. I want to redo a lot more than the targeting. Perhaps version 2.0 will be rendered in the CANVAS element with animated graphics, explosions, terrains, etc. I wanted to incorporate tanks and other vehicles, other soldier types (archers?), goal oriented behavior (capture the flag), stealing supplies from enemies, communicating with each other when in proximity (“hey, watch your back”), and other behaviors that would require something like “sight” to be implemented. But most of all I want their movement and behavior to feel just a little more deliberate. As it is they inexplicably fail to engage each other sometimes, their movement isn’t very confident looking or smooth, and there are a lot of undesired artifacts that come from the fact that I’m still not all that great at writing code that does what I want it to.
One final, and related, note. A good friend of mine shared a post on Google+ recently (yes, some people actually use that – though I almost never use anything but Notepad++ lately) and she reminded me of one of the primary reasons I love programming. I used to want nothing more than to program robots. You can see the video from her post here.
In the video they mention a piece of software they created called Robot Virtual Worlds. It looks like something that should have been made twenty or thirty years ago for me! The other link from the conversation at right is for a website where you can register for their Robotics Summer of Learning. In conjunction with the Robotics Summer of Learning, it appears as though you get a limited (Summer only, I think) license for Robot Virtual Worlds when you buy(?) ROBOTC. I’m not going to pretend to know which version of ROBOTC you need (poking around on the site for a minute didn’t give any answers, but I plan to return on May 20th as they suggest on the website to find out more), but even just playing around with Robot Virtual Worlds for one summer could be super fun. I’d have to learn C, but how hard could that be? Right?