Just thought I’d share some silly fun stuff. The Angry Video Game Nerd (James Rolfe) and Mike Matei of cinemassacre.com signed a promo card of our retro Mac game El Ballo! Retro gamers…UNITE!!

– Casey

As expected, delving deeper into SDL yielded the next step. I present to you, a white square bouncing off of a white line! Behold the cross-platform compatible miracle:

Actually, I’m pretty excited about this, since it is the first time I’ve ever made a cross-platform game demo, even though it’s a tiny one. It works! Woohoo! As planned for the main recipe, this uses OpenGL, GNU make, and SDL on all three platforms. Additionally, on Windows, I use MinGW to provide a common Unix-like build environment, to help match what I use on OS X and Linux. Seems to be working out pretty well so far!

Now that we have basic windowing and graphics up on all platforms, it’s time to get to work on the engine, 3QuadX, so we can do something a little more sophisticated.

– Jake

It’s not much, but I finally managed to learn how to use GNU make well enough to manage a cross-platform project successfully. All the project does is create a small library, which I call libFoo, and a main executable, called HelloWorld. I’m sure you know what an executable is, but for those who may not know what a “library” is, it’s basically a pre-made “sub-part” of the program. The engine, which you may recall is titled 3Quad, is designed to be built as a stand-alone library if needed, so it was necessary to make sure I could build it as a library on all platforms.

All the program does is output the string, “Hello, World!” from the main program and “Hello from libFoo too!”, to prove that the library is being called correctly. HelloWorld is notably simple, but it’s the traditional starting point for just about any new programming adventure. Here are the screenshots from each desktop platform:

(I named my Windows and Linux installations, beavis and butthead ;-P)

HelloWorld on Mac OS X

HelloWorld on Linux

HelloWorld on Windows 7

So there it is in all its glory (and about as exciting as dirt), our first truly cross-platform compatible program 😀

What’s really cool about it is that, as planned, I use only one set of source files and Makefile for all platforms, as opposed to an IDE project for each platform. To actually build the program on each platform, all I have to do is boot into the appropriate OS, then navigate to the project folder on the command line and type “make”, and it magically spits out the appropriate build for that platform. Yes, it is that easy!

That said, figuring out how to set it all up to be automatic like this took quite a bit of effort. Writing the Makefile itself, which manages the build process, took lots of trial and error and reading/studying/etc. Once I got it working on the Mac, it was trivial to get it running on Linux. Windows, on the other hand, was not as easy, but I managed to figure it out too, as you can see.

So the first step is accomplished, woohoo!

Next up: Make it a proper application on each platform, instead of a little command line executable. I’ll probably delve into SDL for that.

– Jake

Last week I talked the talk about “going cross-platform”. This week I started walking the walk. As expected, it’s been mostly up-hill so far. There is a reason the vast majority of games aren’t available on multiple platforms, and that is because it is less than easy to do. In this entry I would like to describe a few of the nitty-gritty details I’m dealing with to get this cross-platform idea off the ground.

I think one of the major misconceptions that non-programmers have about game development in general is that all this stuff is pretty standard right? Should be easy to do right? I mean, games are everywhere! Heck, you already have Ace1 running on iOS, so can’t you just “port” it? Unfortunately, that’s easier said than done, which is why a lot of developers go with a third-party “game engine” like Unity3D. We very seriously considered going that route ourselves, but for several reasons, which I may get into in another entry, we decided against it. So I’m on my own trying to figure this one out, and it has been quite the challenge!

First, let’s talk about the basic tool needed to construct a game (or any app for that matter). On the Mac (and for iOS), the main tool everyone uses is called Xcode. It is what we call an IDE (Integrated Development Environment). There are other IDEs which you will find on other platforms, for instance, Visual Studio on Windows. The main point to realize is that they’re all different, just like word processors are different, even though they do the same thing. To make Ace2 work on Windows and Linux I would have to know how to use three different IDEs and set up the project on each one, which is a lot of work. Fortunately, there is an alternative, called “GNU make”, which I will refer to as make for short. make is available on many platforms, including Mac/Win/Linux, and can be used for iOS and even Android too, which is exactly what we need. Unfortunately, learning how to use make isn’t something I’ve been able to pick up very easily. make is completely text-based, and is a command-line utility. If that sounds user-unfriendly to you, then you understand the situation perfectly.

If I were to describe make in one word, that word would be: esoteric

esoteric :
adjective
intended for or likely to be understood by only a small number of people with a specialized knowledge or interest

In my years of experience I have observed that the majority of programmers tend to avoid using make. Most prefer to manage projects in a more graphically visual way, using an IDE. There are good reasons for that, and I would suggest that I think the main reason is because it seems a lot more difficult to read through the bewildering amount of gobbledygook that command-line tools, such as make and gcc, tend to take in and spit out, much less just trying to learn to use them in the first place. That said, most of the good software you’ll find out there is managed with make. If you’ve ever downloaded an open source Unix program, you’ve probably seen all the funky files, one of which was probably titled “Makefile”. If you drag that Makefile onto Text Edit you can see what’s inside it, and chances are, if you’re like me, you probably had no clue what all that garbage meant and promptly closed the window. Well this week I spent some more time studying up on what that junk means.

make looks for a file called Makefile or makefile or GNUmakefile when you type “make” in Terminal in that directory. It opens that file and reads the junk written in there to figure out how you want it to build your project. Basically a Makefile is just a fancy script, containing recipes for how you want each part of your program made. When writing a Makefile, you’re basically programming the computer to make your program. The language used in a Makefile doesn’t have a proper name that I know of. It’s a combination of keywords and syntax, mixed with shell commands.

Simple Makefiles are not a big deal to learn how to do. Unfortunately, what we’re going to be doing with Ace2, including it being cross-platform compatible, means we’re going to be needing some non-trivial things done with the build system, and that is taking me some time to sort out by learning the voodoo Makefile incantations needed to automate the build process for that. Mostly this week I’ve spent lots of time reading and studying about make, gcc (the compiler), and SDL. It’s been one of those back-to-school weeks for me.

In closing, I’ve started to become fond of how make works. I think I like it!

– Jake