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.

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.

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.

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!

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!).