Versus Software   game + free time = duck

We’ll it took a while, but I managed to finally finish reading Michael Abrash’s Graphics Programming Black Book:

In some ways I feel ashamed to say that I ‘read’ it because it’s a behemoth of knowledge spanning over 1200 pages. Of course I learned a lot from it but it’s the sort of book I’ll read again and again and again until I can finally grok it. It’s a collection of over 10 years of Abrash’s papers and I doubt one can absorve it in a matter of months.

You see to learn programming concepts in a self taught manner I think it’s crucial to not only read the code in the book, but also write it down, play around with it, to truly understand what is being taught in its finer details. With my current project I intend to do just that, since it’s a FPS and the last chapters on the book concern directly with Quakes development at id Software, where Abrash worked.

What’s more interesting is that the author doesn’t focus only in the development aspect of programming, but in the general mentality of it. Not as one solves a problem, but the mind that solves it. As you become better in development I think you ask yourself less “how to solve this problem” but more of “what is the best way to solve this problem”. Abrash shows us several ways to solve a problem in the book, be it linked lists, spatial visibility or making a faster game of life, each one consistently faster than the other with either assembly optmizations, algorithm optmizations or rethinking the whole approach to the problem. The idea is to not expect that there is only one way to handle an issue. In his own words : “Assume nothing”.

The book is also quite pleasant to read, since the author narrates the development cycle more as a journal than a tech book. It’s quite interesting to read the last chapters where he focus on making a faster rendering back-to-front polygon rendering approach to Quake. Almost goes like this:

March 14, 1941. We begin our approach to the BSP tree, were still having heavy losses on how to figure out a way to make the spatial visibility problem faster. The worlds we want with Quake  feature at least 5000 polygons and in the worse case scenario we redraw each pixel 5 times. It’s too slow, we must take a better approach.

May 22, 1941. We sucessfully managed to create a potentially visible set (pvs) that managed to break into enemy lines. We will now proceed to use it to flank their defeneses.

June 10, 1941. We have now conquered the enemy’s battlefield. I’ve reduced the inner loop of the rasterizer to 2.5 cycles per texel. We decided to use z-buffering for drawing the enemy meshes, since it’s faster and not that big of a problem as we expected. Victory is eminent.

And so on. Overall the book can be divided into 3 parts:

• General assembly optimization techniques
• 3D rendering done via software
• Common 3D engine development problems and solutions.

I recommend it to anyone that’s interested in taking game development or programming in a seriously yet elegant manner. I learned a lot from it, and still intend to learn more.

Few days ago I got fan mail from a game I developed, Solis.

The e-mail I got basically complemented the game, saying he liked the style but thought it had too much text hahah. Always good to get feedback from my projects.

Solis is sort of a special project to me. It was the first BIG project that I developed and every now and then I check how many downloads it managed to get (5000+ and counting). It`s not a big project and it ain`t no RPG Maker killer but it was a fun game to make.

With this game I learned 3 very important things:

1. No matter how close you are to finishing a project you will only, and only after you finish it, be able to learn and truly take a critical perspective of it. This is the sort of thing you can’t really explain why. Basically you know why when it happens to you and after that you understand why it can’t really be explained.
2. Different games take different amount of resources. Quite obvious, but it’s the sort of issue that gets commonly overlooked. Solis was a 2D rpg game, and with it came hundreds of sprites, tiles, images, maps, sounds… The list just kept getting bigger and bigger and I was soon to find that I needed an artist.
3. Know your user base before doing the project. During halfway through developing the Solis tool set, I thought I had actually found a development niche. You see, people make RPG maker maps and images all the time, write tutorials about it, etc. But most of them use pirated versions of it. I thought an open source RPG maker would fill that need and actually be able to create a community out of it.
   Boy was I wrong heh. The RPG maker community is mostly of artists and script writers and since Solis was written in C++ that didn’t really appeal to them. Maybe if I kept investing into it I could have pulled that one off. But after such a long development process, I felt I wanted to do something else.

And I guess that`s it. There was one interesting side effect of developing this game though… and hasn’t faded yet:

I never managed to play a JRPG again. Ever. I finished Solis and could not stand looking at JRPG…. Pretty weird heh.