In Chrome, if you try to use event.dataTransfer.getData("Text") in the dragend event handler, it returns "undefined". In the drop event it works fine. Huh?

Workaround: replace event.dataTransfer.* with dataTransferString as follows. This has the added benefit of also working in all other drag events.

    var dataTransferString;

    function onDragStart(event) {
        dataTransferString = this.id;
...

    function onDragEnd(event) {
        var sourceId = dataTransferString;
...

    function onDrop(event) {
        var sourceId = dataTransferString;
...

Read more... (1 comments)

I discovered Screenshot Saturday on the weekend. What a cool idea to promote progress on your games. So I've decided to participate.

The first step for me was to get some of my screenshots up on the site. You'll note there's a new [Gallery] link at the top of the page. I have a bunch of older screenshots in there now - no spoilers - but it is going to grow.

I think the Gallery is pretty cool, what do you think?
Read more... (0 comments)

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


Read more... (0 comments)

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.
Read 3311 more bytes... (0 comments)

One of the biggest problems for a single developer is how to get all the models, textures, sounds, music and other content goodness that goes into a game nowadays. There is a temptation to find your textures on Google image search, or download music from one of the free music sites, or sound effects from a free sound effect site. But here there be dragons.

What got me thinking about this was that I was reminded today of Golgotha. Back in 1998 Crack dot com went out of business, but before they went away, they posted the full game source code, music, textures, models, sound effects and more for their game and put it in the public domain. There are a rather impressive collection of assets an indie developer can use for free there.

Read 2533 more bytes... (0 comments)

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.
Read more... (2 comments)

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.
Read 433 more bytes... (4 comments)

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.
Read 3434 more bytes... (2 comments)

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.
Read 4527 more bytes... (0 comments)

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.
Read 758 more bytes... (0 comments)