From the time I originally envisioned this project until today, I have been dreaming of a fully persistent world. It's time to let that dream go.

Lately I've been finalizing my game design. Refining the big picture feature set. Taking the features I've decided to do and figuring out how they are actually going to work. That has involved a lot of navel-gazing, competitor research, and reading an unbelievable amount of game criticism, armchair design blogs and game theory.

No matter how I slice it, I just can't think of a way to build a purely persistent-world game where the no-lifers don't eat the newbs for breakfast. You can help out new players, give them extra powers, add safety nets, but at some point, they're going to have to sink or swim in a pool full of pirahnas. This isn't the ideal scenario for retaining a healthy volume of mainstream players.

Up until now I've been working with a subset of my world data - only 1/9th of the final size. The world builder program which processes that subset of the world data uses about 3.5GB of RAM and takes 35 minutes to run to completion. With my porcupine rendering bug fixed, I decided it was time to load up the full world data set.

I knew my 32-bit world builder wasn't going to do the job. I needed the additional address space a 64-bit application offers.

Never mix data from more than one code path.

I've had a problem with my lighting for a while - I get ugly bright streaks where world blocks are stitched together. I knew there had to be some problem with the normals (I'm using simple n dot l lighting for the world) but when I looked at the code, I just couldn't see the problem.

Some of the lighting normals are precalculated, some are calculated at runtime. I did this to keep the size of the data down. With all the normals in the data, the size of the world data grows from 363MB to a whopping 1.46GB. Way more than I wanted to have to pay for people to download. Precalculating some of the data ahead of time and some at runtime shouldn't be a problem, however I had two different code paths that calculated those normals. Hmmm.

I've had a rendering bug that has persisted for a long time. I've tried a number of times to track the bug down, but no matter what I did, after my game had been running for a long time, the scene geometry would freak out with polygons poking out all over the place. It kind of made the game look like a crazed porcupine.

I use VBO's for my rendering. They contain either indices or vertices. I only had one VBO for each and had coded my renderer so that the VBO's would reallocate and expand whenever they needed to. The expansion code was sort of slow since the VBO's needed to be repopulated with vertex and index data and then transferred to the GPU whenever they grew. My thought was that I'd find out how big they needed to be during development, then set the starting size to that so they would never actually need to expand at runtime.

For a long time I had known that the graphical corruption always occurred shortly after a VBO grew so I figured there was something wrong with the code that did the expansion. I debugged and checked and checked, but no matter what, I couldn't find a problem.

Finally last week I had a breakthrough. I set the VBO's to huge sizes so they wouldn't have to ever grow, and to my great surprise, after a long time running, the porcupine came out to play. My assumption was wrong! It wasn't growing the VBO's that was the problem!

I had reason to revisit the games I worked on at EA this week. EA has a policy that defines who gets into the credits for a game. While you can see my work in all of these games, I didn't get credit for all of them. (My first official game credit was FIFA Street 2 - Woo!) Anyway, here's the games I worked on:

The summer is a challenge for a home-based entrepreneur. With my daughter home from school, I don't get the several-hours-long block of uninterrupted time I need to focus on development each day.

We did two trips this summer. Since I'm feeling the pressure to get my game out the door, I felt I needed to work through both of these "vacations". That didn't really work out.

Today I had my first ever working multiplayer session. Up until now I've been testing all my technology with just one client hooked into the servers. But today, I logged two clients in, then I had guys moving around on one machine perfectly synchronized and moving on the other PC. It is so awesome to finally see it all go. Networking is working, time synchronization is working, replication is working, camera's working, I still need to do some work on interest management, but it finally looks like a real game. Making a 2, 4 or even 32 player game work is challenging, but it is an entirely different thing to see the technology I've built to support 100,000 players running. Whee!

Tonight I got invited to a Microsoft Studios party for a new studio starting up in Vancouver. They're recruiting, and the way they describe what they're doing, it sounds like a whole lot of fun. It seems the new studio is largely populated by my old buddies from Fusion, so it was great to see so many of them. Fusion was one of the most enjoyable periods in my career, so that they seem to be doing the same thing again is really interesting. I also saw a lot of people I know from EA (and who are still working there.) It had an open bar and I got a nice new 343 Industries branded 2G USB drive and a Microsoft T-shirt. They're not saying what they're working on, but I'll bet you're going to play it.

Now if my ears would just stop ringing…

I haven't really talked about networking at all on the blog. That might seem a bit odd given that I was a 'networking guy' at EA. There's no conspiracy here though, the simple fact is that my networking code was done and dusted before I tackled the blog in earnest and I write about what I'm thinking about. Networking is a big topic, so there'll probably be other articles later.

One thing that bothers me about writing a MMO is that one day, it will be gone. SOE announced they will be shutting down Star Wars Galaxies yesterday which got me thinking. So much effort went into developing that game, players played it for years, and as of December 15, it will all be gone. Just like The Matrix Online, FIFA Online, Tabula Rasa, and so many others. Sure, from time to time a MMO comes back, Hellgate, APB, but usually once they're gone, that's it.

I have programs I worked on 25 years ago that people still use today. And nothing is preventing them from running another 25. A MMO is a different beast.

People ask the developers to open-source the servers, but often that isn't practical. The company might be closed with nobody to do the work to get the program ready for distribution. The servers might use licensed code or components that can't be made available and are expensive to strip out and replace. Perhaps the game technology is running other games and security is an issue. In many cases the servers are simply big and complicated and require experienced people with a lot of game-specific knowledge to build and maintain.

I do think its cool when people decide to write their own replacement servers like SWGEmu which brings back the old Star Wars Galaxies.

I'm not sure what I'm going to do about the inevitable future of my game. Something to think about.

Four weeks. Four-freaking-ever. That's how I'm feelin'. Tooooooo long. But pathfinding is running! It is glorious to finally see things move!

I implemented the A* algorithm which works really well for finding optimal paths. Here are some things you should consider if you are implementing A* pathfinding: