GameDevMike

I attempted to login one day some time ago only to discover that I was unable to pull up any of my admin pages for the blog. This is not an uncommon problem with Wordpress, apparently, but some Gooling showed me that there can be more than one cause. I put off finding a fix and it gradually slipped off my radar. Today, I logged in to CPanel and used Fantastico to upgrade to the latest version. Now, I can access my login pages again. Nice. A shame that it took so long for me to get around to it, as there has been quite a lot to blog about over the past couple of months.

At the end of 1993, I was serving in the United States Army at the 121st General Hospital at the Yongsan military compound in Seoul, Korea. I didn’t own a computer at the time and wasn’t doing much gaming at all. But working mostly on 12-hour night shifts in the ER, I had a lot of time on my hands in the wee hours of the morning. Initially, I filled the dead time by playing Indiana Jones and the Fate of Atlantis (the only computer game I owned) on the ER computer. But one night in the winter of ‘93, a stroll over to X-Ray opened a door to a whole new world. Sgt. Campbell, the X-Ray tech who usually worked nights, was intently, and frantically, playing a computer game. After I positioned myself so that I could see over his shoulder, I was blown away.

I had been in Korea since 1991 and had served two years as a medic in a tank unit near the DMZ prior to transferring to the hospital in Seoul in June of ‘93. Over the course of those two years, I really fell out of touch with a lot of American pop culture. I rarely watched TV, never bothered with the radio, and had little interest in computer games other than those one of my roomies picked up from the PX. I spent the majority of my off-duty hours off base getting drunk and chasing skirts, like the majority of my mates. So although Wolfenstein 3D had been out for more than a year, I had never heard of it and had no idea that such a game was technologically possible.

I can think of two other times in my life when I felt the way I did that night I watched Scott Campbell play Wolfenstein. The first was when I stumbled across a shiny, new Space Invaders game at a local 7-11 in the late 70s. It was the first video game I had ever seen. The second was around 1999 when I first logged in to Ultima Online. I had played a few MUDs in the mid-90s, but this was my first experience with a graphical virtual world. Those three experiences, to me, mark the major evolutionary stages of computer gaming. The fact that it’s been a decade since my last blown-away experience with a computer game makes me wonder if I’m just jaded or if there’s really nothing out there that radical anymore.

The point of all of this setup is that Gamasutra have reprinted an article from the January 1994 issue of the magazine. The article focuses on id software, their success with Wolfensein 3D, and the development of the Doom game engine. At the time this article was originally published, I knew nothing about Gamasutra magazine and the idea of developing games was just a long dead dream that I had given up on as a child. Reading it now, it reminds me just how little I knew about computers at the time (although I turned 22 in ‘93, I had very little experience with computers overall). Had I read the article then, I wouldn’t have understood much of it. But I can look back now and say that seeing, and subsequently playing, Wolfenstein 3D rekindled a long dead flame inside of me. It took a while before I would act on it, but I’m almost certain I wouldn’t be programming in any capacity had I not played that game.

One of the things I love about reading older tech articles is how they talk about the tech of the time. This caption from an image in the article is a perfect example:

By writing in ANSI C on NeXTStep, Id Software is able to develop and test in a true programmer’s environment. Then, using a network, developers are able to send the code to a test PC running DOS and recompile what they are working on to run the game on its natural environment.

And then my favorite paragraph:

Although it has often been theorized that Id uses a lot of assembly language in its development, the main language used is ANSI C. “Assembly language is almost dead,” declares Carmack. “Doom has only two assembler routines: one to vertically stretch a column and the other to horizontally texture-map a row. Everything else is in C.”

I came to game development just as C++ was starting to make inroads in the late 90s. Then the assumption was that a game was using C, because C++ would be too slow. These days, we’ve got people assuming games are made in C++ that are actually written in C# or Java.

Anyway, I look forward to reading more reprinted Gamasutra classics.

I’ve not been checking the Project Darkstar forums as often as I once did, so I missed the announcement that version 0.98 has been released. One major change that should make it more accessible is in how Darkstar apps are deployed. I’ve not tried the new system yet, but anything would be better than the old one.

Another bit of news of interest to Java game developers is that version 0.3 of Ardor3D has been released. See this forum post for the change list.

If you follow the Indiegamer forums at all, from time-to-time you’ll run across some sales stats. Some of them popped up in a recent, rather lengthy, thread and are summarized in a post at the Grey Alien Games blog. This deals with dollar values and mentions nothing about man-months of development time. But it gives insight into a good range of indie sales results, from the inspirational to the disheartening.

Josh Slack announced on his blog the first public source release of Ardor3D, his new Java game engine. You can checkout the source or browse it online at Ardor3D.com.

In a post to the SDL mailing list, Sam Lantinga, the originator of SDL (Simple DirectMedia Layer) has “founded a company to support and license the new version of SDL.” That version, currently known as SDL 1.3, will become SDL 2.0 upon it’s release. He says in the same email that all future versions of SDL will still be available under the LGPL, but a commerical license can be purchased to allow more options. To see just what those options are, you can take a look at the front page of the Galaxy Gameworks website.

Apparently I wasn’t the only one curious about the decision to use double precision floats for the math in Ardor3D. So Josh gave some more info on it in a new post. The gist of it is summed up in this paragraph:

As I mentioned, our math package currently uses double precision. This includes our Vector, Quaternion and Matrix classes. Actual mesh data is of course not part of this, nor is ColorRGBA. The reason for our move to use double is simple: current customers of Ardor Labs want higher accuracy. (Yes, we want to make money from our work and we want others to as well.)

He also touches on memory and performance.

Also, he mentions something else I was curious about. The implementation of immutable math objects is based on a boolean check.

On the subject of immutability, we’ve taken a rather simplistic approach that “works”. Basically we’re using a final boolean mutable field and hiding other member fields behind accessor methods that check for immutability. Nothing fancy, and a new better way may come as a collaborative community starts participating.

Given that the field is final, it appears that immutability is decided during object creation. It also means an ‘if’ check for in the set methods, or any method that affects the object state (which, for all I know the JVM may optimize away given that the field is final). Another way to implement this sort of thing is to use a common interface with mutable and immutable implementations. I have no idea which approach would be better. This is one of those cases where Java’s lack of proper const support is painfully obvious. In the in-development version 2 of the D Programming Language, any class or struct instance (or any variable) can be made immutable with the immutable keyword. It would be nice if Java had something similar.

Joshua Slack left the JMonkey Engine team some time ago and announced that he would be starting up a new Java 3D game engine called Ardor3D. So he teamed up with another JME monkey and got busy. Since then he hasn’t given any details about the engine, other than a few teasers. That has changed with his most recent blog post.

In his post, Josh describes the architecture of Ardor3D. Most of the details he gives are in how it differs from JMonkey. He starts out describing how they started with the JMonkey trunk and ripped out a bunch of stuff. He then gets into major changes and new features, before wrapping up with information about the license and the forthcoming first public release. The gist of it is that the Ardor3D will look very little like JME (even though it started from the same source tree), it will be released under the zlib/libpng license, and we can expect to see something of it in the next couple of weeks.

One bit that stood out to me was this:

All of the basic math objects were rewritten as double precision and include the ability to be immutable.

That’s an interesting decision. The game engines that I’ve seen are either written to support single precision floats exclusively or both double- and single-precision (usually through templated parameters or the preprocessor). I’ve not yet heard of one going exclusively for double precision. I’m curious to see how that pans out. I’m also interested in seeing how they implemented immutability. Vector immutability has come up periodically in the Java Games Forums. Considering that there’s more than one way to implement it, I wonder which path they are taking with JME.

I was mildly curious about Ardor3D when I read Josh’s first announcement about it. Now, I’m on the edge of my seat waiting for the first release. Can’t wait to play with it!

The last few times I’ve upgraded my other blogs to the latest Wordpress version I’ve run into a problem. Having learned to work around it, I didn’t anticipate any problems updating this one. The actual update itself went well enough. But a major oversight caused me to lose a large chunk of the database. It was a stupid mistake and one I’ll be careful not to make again.

I have all of the data for the first few dozen posts I made back in 2006, but I’m not going to bother importing them. I’ve decided instead to start over from scratch. My regular readership here is relatively small and all but a couple of the posts that were repeatedly attracting hits through links and Google searches are lost in digital purgatory. I was never really happy with the direction I wound up taking here, anyway. I had drifted far from my original intent and had fallen into a rut of posting extremely infrequently.

So now the slate is clean and I have another chance to make this blog what I wanted it to be in the first place (yes, I’m trying to put a positive spin on my stupid mistake!).