I'm pretty tired. Yet another day working myself into oblivion. My good fortune for being able to work on Hack Mars continues. I spent a few more hours and was able to get Hack Mars to finally compile under Windows using MinGW (SEE yesterday). It runs. It gives an Error with load(): Invalid Operation. Everything loads correctly. It's strange, but it happens. I'll fix it on Monday or so.

Then Hack Mars will be truly multi-platform. It's quite important that Hack Mars run in Windows considering the market share Windows has of gamers. The lack of games in Linux is depressing, but more and more games are being written for Linux or usable under Wine. Except certain games that are working in the opposite direction (Counter-strike 1.6 with Steam for example), there is a serious motion toward gaming in Linux. I have purchased two games for specific use under Linux: Neverwinter Nights and UT2003. I've gotten Half-Life and Counter-strike 1.5 to work using Wine (not easy, but worth it). I used to play Enemy Territory often.

So what's the deal with multi-platform software? A person writes a program and wishes people on a different platform to use it. How does one start on that journey? There are a bunch of interesting ways to do it. My way was evaluating all the software that existed. Since Windows and DirectX dissatisfied me so thoroughly, I looked for open-source, multi-platform alternatives. There are pitfalls to this path, but bare with me. My first attempt was just to write OpenGL code in Linux. I immediately saw that examples could propel me through the roughness of GLX. It worked well. But then I thought a bit about porting it. Really, games written using Linux-centric libraries alone are silly. They can be ported, but this involves more work than a person should be interested in. It's best to use a developer-friendly library designed and tested thoroughly on multiple platforms. I compared GLUT and SDL. The choice was very simple. SDL compiled easily, used modern systems, and actually conformed to my GLX code perfectly. It took me less than one day to have a perfect clone using SDL. I gave GLUT a try, but difficulties compiling, testing, poor experiences with others' work in GLUT, and ugly systems made me give up before creating a working version. Others may have different experiences, but that is mine. I like SDL very much. I use SDL_mixer which is quite convenient to play sounds. Considering it was built on SDL, it is a good choice for audio. That covers audio and visual.

What about data loading? Early versions of AltSci3D used c++ ifstream ascii space-delimited data file. I thought: structured, extensible data should be easy to put in text. Boy was I wrong. Any error in the text or structure and it was totally awol. I thought the problem was ifstream and switched to fscanf() which worked, but wasted a lot of time and ended up not working. There are ways to make this rock-solid, but it takes work to do that. I decided to try XML. I knew that libxml was interesting. I tested it and immediately fell in love. I once wrote an accounting package with xml and have liked it since then. While many will criticize my choice of xml over a relational database (mySql), I stand convinced that xml has very good uses. Hundreds of applications are using xml as config files. XML works wonders over space-delimited data. It buys a lot of stability. The structure is amazing, attributes work perfectly for data. Tags works excellently in hierarchies and lists. So AltSci3D uses XML for loading and messaging from python (two-way communication in Python embedded in c++ is not very easy, btw, but it works for AltSci3D). I have used Xerces before and it works quite well. I decided to use libxml because it is a standard in Linux. It works fine in Windows, but obviously not very easily considering the pain I went through to get it to work yesterday. The solution was to download the win32 binaries from Zlatkovic.com which was down yesterday. That's a good reason to have reliable web hosting.

So the next system that AltSci uses is Python. Python is multi-platform and works incredibly well. It has a large base of support (tutorials and books abound), good support in tools, incredibly versatile, and has many complex things built-in. One python library that has made a revolution in file sharing is SHA1 hash. This small library allows BitTorrent clients to ensure that they are getting the correct data from their peers (within 99.999% or so). Bit Torrent has other important factors, but written in Python, it has been able to establish massive acceptance. So what do I use Python for? Python is my AI in the Sky. It started with an article on Gamasutra long before I had a good grip on Hack Mars. I needed a way for Hack Mars to have 40-80 missions. That's a lot of coding. But if I could reduce it to scripting, it would become simple. With Python, I could even test it interactively or on the command line in parts before it ever became 3d. That saves a lot of time. Since Python compiles as it runs, it has no wait for compile time. That's a serious gain in development, debugging, and testing time. Seriously, Hack Mars could not advance beyond an arcade game (or FPS, bleh) without Python. It's seriously revolutionized the way I develop. I expect that soon there will be a bunch of games written with Python (at least in part) which are super-sophisticated. That is what I am betting on with Hack Mars. With the tools I have available, nothing but algorithms are hard coded. Hack Mars is generally AltSci3D which simply a state-machine that responds to commands from Python. That's pretty cool.

The last library I employed was ILUT aka OpenIL aka DevIL. It loads textures. It's simple and it beats my hand coding by a mile. Really, I only need a PNG loader, but I had a problem loading from string. I do use two other libraries, but I wrote them both myself. The first is Tar Archive interface. It allows me to load from tar archive. I don't hardly use it, but when I release Hack Mars, all the data should be in archives. The second is cpp_arg interface. It's just a silly system to turn char **argv into an object. So I say:
if(pArg->getBoolArg("V", "version")) return usage();
And that is that.

Now that I think of it, I use a few more libraries: I convert files from Milkshape3D to AltSci3D Data Format. That's so I can use Display Lists which the MS3D format is unkind to.

So the lesson today is obviously about writing an original engine from the ground up. It involves finding the right libraries and putting them to work. If you're allergic to other people's code, you've got a long road ahead. Use what you can. I don't especially like the idea of canned engines, but really one can say that AS3D is a canned engine at this point. Open source 3D do-everything engines seem to be too limited for most people. There have been some good games written using canned engines (AIWars was written using Blitz3D, I believe). The end lesson, I believe is write your game for multiple platforms because there happens to be a core group of people who want to play your game using a different operating system. If you want to write your game for XBox and/or PS2, get an 3D library that will do OpenGL and Direct3D side by side. In the end, you'll be happy you did.

For me, I'm going one massive step further than developing for Linux. I'm going to open the source of my video game (I already have opened up an old version of AltSci3D Manga Director). To make money, I will sell the data along with the binaries for normal shareware price. Anyone who wants to port it or change it can feel free. If they distribute it, they share under the GPL.

Considering that the libraries, tools, and OS/Kernel I am using are under the GPL, it makes sense that if I can earn the same amount of money and give back to the community, then open source it shall be.