A demonstration of the proper way to use a laptop for game development.

Sometimes your kids bring things home from school that you really don't want. My daughter brought home the plague. For a week I slept all the time. The next week I managed to work up the energy to make it to the couch each morning so I could watch TV. I was so run down I didn't even have the energy to think about my game.

Up until I got sick I had been working on a new particle effects system which I plan to use for smoke and weapon effects. It uses the GPU to move the particles as well as render them so it should be able to render a whole lot of particles. All the cool techniques to power that came out of the very last chapter of the OpenGL SuperBible Fifth Edition. I bought the latest edition just for that chapter.

All of that is on the shelf for the moment. While I'm feeling better and have been back to work for a couple of days, I still don't have the energy to tackle that difficult a feature.

For the last while I've been focused on the appearance of the game and gameplay has suffered. I do sometimes miss having other people around to help things move forward on more than one front at a time. But it is time to start correcting that so I'm back to working on gameplay.

It's funny how things can sneak up on you. I've been working on adding lasers, fixing bugs, mucking about in Blender, and adding animation to my recent art acquisitions. There have been a lot of evil, evil bugs to fix, and I've been pretty heads down. So today, after I hunted down the last bug in a rather long series, I was testing the fix when I had the sudden and shocking realization that the game I've been working on full time for two years and five months had become a game!

Not a monstrous pile of code. Not a graphics demo. Not an engine. A game.

I could show it to a grandmother and she'd recognize it as a game. People can play it. Quite a few people I suspect. Not as many as I need it to, but a lot.

It's still missing many of its big features, and it has lots and lots of bugs, but it is undeniably a game.

More importantly, it is THE GAME!

The catalyst for this project was the great times I had playing co-op LAN games on Tuesday nights with my buddies. I had a vision of the kind of game I wanted to play. None of the big game companies ever made that game. At long last I can play that game.

So cool! So amazingly cool. Wow.

No, you can't play it yet. Sorry.

Last night I needed a square root function that would work on 64-bit unsigned integers. I have been using the standard library's sqrt, but my first thought was that an integer square root could be faster.

I looked around and found what was said to be a "fast" integer square root on Stack Overflow by Craig McQueen. I used the code as-is except that I changed it to use 64-bit unsigned ints because that was what I needed.

It seemed like a reasonably performance efficient algorithm, but I had always heard that sqrt, even in hardware, was slow. Because sqrt gets used a lot, I thought better safe than sorry, so this morning I decided to benchmark the integer algorithm against sqrt just to be sure.

I'm not much of a gambler. I don't buy lottery tickets. When I went to Vegas, the only gambling I did was with my change from breakfast. But I don't mind if someone else wants to gamble with their money. I've been thinking a bit lately about the growth of gambling in MMO games and whether its an element I want to include in my game's economy.

I took a couple days off for spring break, but I've been working on getting my models to share rendering resources. I'm afraid I have to let you in on a secret: not all MMO development is super exciting. Up until today, each time I loaded a model, I loaded its complete scenegraph including transforms, and allocated a material list, a vertex array and and a set of meshes for every instance of that model. If I had 20 identical objects on the screen, rendering all those duplicated meshes was really super inefficient.

I had a few requirements:

• I wanted model loading to be asynchronous.
• Models should share meshes, vertex arrays and material lists allocated by the renderer.
• I wanted to be able to customize models individually (hiding submeshes, and moving/scaling/rotating model components.)

The asynchronous loading part was the simplest. I used an AVL tree template to build a model cache, then made a quick little task to do the loading when models aren't already in the cache, then schedule it in my task system. The asset system was already re-entrant so loading the model scenegraphs was no problem. Then I added a lock-free queue to put the finished models into and a step in the update to poll that queue for finished models, and Bob's your uncle. No possibility of long frames during model loading.

Once I had the loading working, the really tricky part started. In order to share renderables between model instances I used a super handy shared pointer template.

I generally try to avoid optimization until nearer the end of a project, but my new art showed up a real slow point in my game. I have a serialization system which can read or write most in-game classes into bit-packed buffers. This is super helpful for putting classes into network packets or into files on disk. In addition to bit buffers I also have a database serializer that can use a database as a storage system and an XML one that writes neatly into XML files. Handy right?

I discovered this week that loading the new models which had 5000+ polygons was taking up to 3.5 seconds per model. I already limit model loading to one per frame, but loading up 20 in rapid succession meant a few very long frames in a row and an apparently hung game. Digging in, the culprit turned out to be loading the vertex and mesh arrays.

With my new shield effect last week I've been thinking a lot about the appearance of my game. The art style, what effects I'll need, lighting, what I'm going to do for models. There are a lot of complex art issues. And I'm really at the point where my small volume of art isn't cutting it anymore. So after talking it over with my CG Supervisor nephew over dinner last Sunday, I decided it was time to start spending some money on art.

On Monday I purchased a package of models from 3DRT.com which is when the real fun began.

I like to quest. One of the features Bioware built into The Old Republic is a quest helper. Every quest you get appears as a destination on your map. You go there, do your thing, then the marker changes to wherever you need to go to collect your reward, and the quest is done. There's no exploration. There's no discovery. There's no challenge. You just follow the map. How on earth did this fun-obliterating feature make it into the game?

Fun day! I've been working on a new shield effect the last couple days and I got it working today. The idea was to develop something like this fresnel soap bubble effect. I have to say, WebGL is pretty cool. I never thought I'd be following 3D rendering examples that run live in a web browser. Really nice of them to supply the source code for the shader.

Not that it's a simple drop in...