This is appalling.

Not that Hangame lost their data due to botched backups. That happens all the time. It's that they're killing the game over it. What that says to me is that the game wasn't really economically viable anyway and maybe that one of the commenters on the story is correct that "it is a ruse and [they] are taking the money and running."

For the rest of us working on microtransaction games, this is the doomsday scenario.

I've been following Star Corsairs which is an indie MMO being developed here in Canada by Dave Toulouse. (He also wrote another MMO called Golemizer.) A couple of months ago he got laid off (like me) so he decided to work full time (like me) on an independent MMO (like me.) He developed his game in just 4 months (not so much like me) and released it in October.

This weekend he announced he is quitting as a full-time indie to go back to outside employment, just 3 weeks after the launch of his latest game. He got a reality cheque - for $273.31 - his game's total income for the first two weeks after release.

For me that's very troubling, given that this is his second game and at least 100,000 people have heard of Golemizer. This single data point has forced a rethinking of my schedule. Up until now I've been building features based on the theory that all core features are needed equally, so it doesn't really matter what order they're done in. I've been doing them in whatever order is most convenient. That changes today.

I realized I've been making a classic error. One I've been warned about, and to a certain extent, one I recognized I was doing, but one I was nevertheless still making. I failed to recognize the urgency of the situation until I read about Star Corsairs launch. So thanks Dave, for sharing.

I broke 100,000 lines of code this week! 100,223 lines in 642 files. This doesn't include libraries I'm using that I didn't write - Berkelium alone is 40 times the size of my game code. My game isn't a million lines like some of the games I used to work on, but the build times are sure a heck of a lot shorter.

A Chrome UI Part 1 & Part Deux.

I've been working on adding a more-complete user interface to my game. The UI screens I've done up to this point have been static pages (splash screen) or simple forms (login screen.) This week I've really gotten into it. I've been adding a HUD. The HUD is tricky because it needs to interact with the game, as well as update its internal state and display based on user input. It needs to be slick looking and responsive.

Ready for the acronyms? I'm building the HUD with HTML, CSS, Javascript and AJAX. Just one out of those four isn't borken.

EA is banning players from all of their games because they're (perhaps unknowingly) playing on pirated servers.

Tobold got himself banned from Facebook for not using his real name. He has put money into Facebook games, now he's looking to get some of that money back.

That got me thinking about the funds attached to game accounts when they are banned. Should a company refund them?

I spent yesterday coding up the screens and code to create new characters (I don't really have characters, but characters gives you the idea what I'm working on while I remain vague about what I'm actually doing.)

When I added a delete character button to the screen, it occurred to me that I was working on my first official microtransaction feature. Because no matter how many times you ask the user "are you sure?" a few of them are going to barrel right through the red text and blinking lights and delete something they didn't mean to.

In the old days, you'd add the delete button, have it nuke some files and that'd be it. There was no reason to build an undelete feature into most software.

But with an MMO with microtransactions, you have an opportunity to earn some revenue by adding a user-friendly feature.

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!