Well, in about 2 years I have written a grand total of 15 posts here. With the baby and everything else sucking up my time, I simply don’t have time for this blog. So effective January 3, 2009, programmicon.com is going away. I know all 3 of you who read this will be very disappointed, but I assure you, it’s for the best.

Soooo, goodbye for now.

In my last installment, we added the ability to create new steering behaviors to Bayts using the Lua scripting language. Unfortunately, the resulting implementation was horribly slow. So today we’ll explore using a very important tool: the profiler. For this article, I’ll be using Shark, Apple’s free profiler. These techniques apply just as well to profilers on other platforms. Read more

Before I start, I want to share some pretty important news. On January 8, 2008 at 7:45 PM Central, my son Sean was born. He was about 3 weeks early, but is nonetheless a healthy and (apparently) happy baby. You can read more about him at my wife’s blog, yellowpop.

Lua is a very popular scripting system for games. There are a lot of very good reasons to use Lua in your game. It’s fast, lightweight, and free. Embedding the Lua runtime in your application is supposed to be very easy. Today, we’ll take a look at doing just that. We’re going to embed Lua into Bayts, making it possible to script new steering behaviors in Lua. Read more

It’s time to introduce another 3rd party library that some of the code we work on here will depend on: Boost. Hopefully, many of you are already familiar with Boost, and already have an up-to-date version of it installed. For those of you who don’t already know about it, I strongly suggest you check it out. It’s basically a collection of very useful, well designed and tested utility libraries, such as regular expressions, filename/path management, and serialization (which I discussed before in The Un-Fun Stuff). Many of the people who develop the Boost library are also heavily involved in designing the C++ Standard Library, and many of Boost’s sub-libraries are on track to be included in future versions of the C++ Standard Library. Read more

Pretty well any major game needs some sort of scripting ability. You may be able to get by without it in some very simple games, but even, say, a classic shoot-em-up could benefit. Think, for instance, of scripted boss battles. You may well disagree, and that’s fine, but I’m going to leave it at that.

Read more

The code base for any given modern video game is a huge, complicated beast. There are countless code paths, and many actions are deferred, so the code that acts on a piece of data may well be far removed, both in space and time, from the code which created the data.

So, we’re not going to be creating a game engine, at least not today. Instead, I decided to start with something smaller, and simpler, upon which we can more easily add new features, the sorts of features that a modern game engine will need.

With that, I’d like to introduce you to Bayts, an implementation of flocking behavior. The name was suggested as a joke by my good friend Matthew. A joke it may have been, but it stuck. Read more

As I mentioned in Where’s The Code, I will be posting code from this blog up on a Google code svn server. You may notice a new sidebar, which contains the information you’ll need to retrieve the code.

I’d also like to point out that all of the projects I’ll be presenting here will be using CMake for its build system. Even if you have no plans to download the code I present here, I strongly recommend you check CMake out. It’s very powerful, but much easier to deal with then plain Makefiles, and definitely less of a hassle than the GNU Autotools, especially for Windows users. In a nutshell, you create some build configuration files, just like with every other build system. Then you run your project through the CMake tool, and it will generate a project for your native build system - be it make, Xcode, Visual Studio, etc.

The creators of CMake strongly recommend that you perform “out-of-source” builds. In other words, your build results, intermediate files, and anything else that the build process generates goes into a totally separate directory from your source files. For people used to using an IDE, this is probably nothing shocking. But, while Autotools and make and allow you to do this, it’s not necessarily obvious how, and it seems that few people do it. Since CMake makes it so stupidly easy, I don’t see a reason not to follow the recommendation, and tons of reasons to follow it. For one thing, it just keeps your source directory nice and clean. Just check out the Running CMake documentation.

One final note. Most all of the code I post here is cross-platform, and I’ve tested it on OS X, Windows XP, and Linux. There will be exceptions, which I will note when I post.

With all that said, I’ll be introducing our first project shortly…

It has been said that laziness, to a point, is a virtue for programmers. Actually, most people leave out the “to a point” part, but I’m guessing it’s implied. As I’ve mentioned before, I take this philosophy pretty seriously. If I can avoid writing code well, by golly, I’ll avoid writing it. Read more

People who are interested in game programming typically have one or two specific areas that they consider The Fun Stuff. For many, it’s the graphics stuff, trying to figure out how to push more polys, with more detail while maintaining a reasonable framerate. For others, it’s AI, building smarter, nastier opponents for the player to face. There might even be a handful who love nothing more than hacking low level network code, so even a player on a gimpy dial-up connection gets to enjoy the action. But I don’t believe I’ve ever encountered anyone who’s said “I want to get into game programming because I just love figuring out how to serialize data to disk!” or “If only I could get a job dealing with localization code in video games!” Maybe there are a few of you out there, but for most of us, this sort of thing falls under the category of The Un-Fun Stuff. Read more

Most of the code I talk about here can be found at the The Programmicon Google Code page under the Source tab. You’ll need an SVN client of some sort. All of the code is released under the New BSD License.

keep looking »