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.

Well, what I’m going to talk about today isn’t really magic, but it does illustrate some things you can do with C++ templates that, while certainly not uncommon, may not come immediately to mind. We’re going to use templates to implement some code for dealing with byte-swapping (endianness issues). I originally wrote this content as part of an upcoming post, but that post was already getting to be several pages long. So, I’ve pulled the info out into this post, and will finish that one soon. Read more

Well, I gots me a MacBook Pro. I have to admit, any tears I had been shedding about my poor little old iBook dried up quickly as soon as I turned this new puppy on. Let’s just say I am happy with this purchasing decision, and leave it at that.

So, now that I have a computer again, I started looking into D some more. One of the first things that struck me is that, at least on the Mac, the tools just aren’t really there yet. There is no native debugging support, for example. There are patches for GDB that add support for D, but GDB doesn’t quite build out of the box on the Mac. I’ve applied the patches to the version of GDB in Apple’s CVS server and built it successfully, but it doesn’t appear to work. Maybe one day soon I’ll give it another go, but to be honest, I’m hoping someone else will get it working first. I’m just not enough interested in making a debugger work just so I can mess with a new language. Read more

keep looking »