Let's Make A Game! Episode 14: Agile Programming Development

Yes, this is Agile. No, he is not a programmer.

I'm taking time to learn some more about programming theory. I figure, the more I understand about HOW things work, the more I'll be able to put them together.

My programming mentor Matt led me to agile program development. My first thoughts turned to one of the antagonists from Mega Man X2, but after some gentle prodding and rolled eyes, it turns out it's a very useful method for getting things done.


Let's use a normal program as an example. In a normal programming environment there are a lot of dependencies. For example, let's say Gordon Freeman uses a shotgun. In order to make sure the shotgun works the right way, we have to make sure Gordon Freeman works first. Then we test the shotgun.

What if there's a problem with the shotgun, like, say, it doesn't fire properly. It could be with the programming for the shotgun, but it also could be a problem with Gordon Freeman. For example, what if the Gordon Freeman part of the program is having problems firing weapons? Now you have to dig through not only the Gordon Freeman method but also the shotgun method.

You can see how quickly this can spiral out of control in a very complex program. After a while, with so many dependencies layered on top of each other, everything can become intertwined in a really nasty way. A change to one part can have a ripple effect on a whole host of other methods and objects.

That's where agile program delevopment can help. It's a way of making the program work from the very beginning, and it's what all the cool kids are using.

Let's use our shotgun example again. I want to make sure the shotgun will fire when someone sends the command to fire. I'll take my method of shotgun.Fire and narrow it down to a binary value: Did it fire, or didn't it? Then, I'll subject the shotgun.Fire method to a script that tests it out. If my value comes back as true, then I can slap shotgun.Fire into the program without incident. If it doesn't, then I can figure out what's missing and go from there.

You can see the benefits of this technique. It doesn't require you to do as much code repetition. It means that you're not so much programming as snapping together very complex Legos.

There is a downside, though. It's not as easy to do as typical programming. It requires you to build a script to test out your chunks of code. It's also a little complex for someone just starting out like myself. Still, this may be the route I should go once I get more experience under my belt.