I attended the Full Indie Summit today along with 399 other indie developers at the Rio theatre in Vancouver. With a mere $10 admission for 12 talks ranging from 5 minutes to 30 and including snacks, it put those other big name developer conferences to shame.

I needed a way to deliver my game to players, but I have a fundamental problem: the game is really, really big. That means that it is completely impractical for players to download the whole thing in one go, it needs to have a streaming installer.

I did a lot of research on patching and installers over quite a few months. There are so, so many approaches you can take. Windows installer is a great tool, use it if you can. I tried really hard to find an existing solution, but I'm sad to say, I didn't find a solution that would suit my game.

The biggest roadblock to using an existing solution was that I have a lot of files. My test world has around 18,000 files and the full dataset will have many, many more. With that many files, a regular single-file self-installer would be gigantic.

I was listening to Chris Hecker's talk No One Knows About Your Game this week and he makes a good point. It is a big risk to not talk about what you're working on and then hope that your press strategy all comes together for the game's release. I haven't talked about my game because I don't like to talk about things that aren't done yet, but that changes today.

I was hugely disappointed when I learned that the developers of Natural Selection 2 lost $30,000 in credit card charge-back fees on 1,341 Steam keys bought fraudulently via the Humble Store. I had a bit of a warm spot in my heart for The Humble Bundle, but indie devs can't afford to take that kind of hit.

I don't know what sort of arrangement there is between The Humble Bundle guys and the developers, but The Humble Bundle is making good money, I'm really shocked that they haven't spent some of that money on effective fraud prevention.

When choosing a payment processing service for your game, don't just look at the discount rate, make sure you look at what they do to prevent fraud and read the service agreement carefully. Credit card fees can bankrupt you if you aren't careful.

A while back I put together an audio system which I have been using to play music in the menus. While I had the ability to play any sort of sound, it was kind of inconvenient to use -- each sound had a handle that needed to be managed.

I needed something that would run the audio system and manage things for me. With the number of complaints I've heard from audio folks over the years about the general lack of attention to audio in games, I was surprised by the lack of solid information on what kinds of features you would want in an audio system. I looked around on the web, then went through all the Game Programming Gems books until I found Creating an Audio Scripting System. Quite a few of the ideas I implemented came from that article.

If you're an audio person and there's important stuff I'm missing, or if this is all just wrong, by all means tell me in the comments.

So that last blog post was picked up by gamasutra.com which was pretty cool. It was tweeted to over 70,000 people, hit the front page of Gamasutra and stayed there for three days, was featured, and made their news feed. I got 15 comments, saw 22 new followers, traffic on the website was 8 times normal the first day (almost 25% of those iDevices!), and it has now settled at twice what it used to be.

Between checking out the comments and web stats, I've been working on a bunch of different things.

I saw this post on Gamasutra yesterday, and I thought "maybe people wonder what programmers do all day." So here it is.

8:12am Wake up.

8:26 Hug the family goodbye as they head out for the day. Cover head with blankets, not ready to get up yet.

9:02 Roll into the office. Check on onemanmmo.com, then Twitter. Gamestop says that 60% of the people it surveyed wouldn't buy a game console if it wouldn't play used games. Yeah sure.

Singletons get a bad rap from programmers. Just go do a search for "singleton problem" and read any of the first 100 results. From all the anger you'd think they cause disease, or burn books, but no. They're globals, and programmers hate globals.

The recommended "solution" to the singleton problem is to pass the potential singleton to every class that needs it as a parameter so that you can see it is used in the declaration for the class. It's only one variable, or one parameter to a function call, so what? That's the approach I took for my entity system, dutifully passing it to every class that needed it, and having them store it internally if needed.

The problem that developed is that the ES is the central database of my game and it is used by dozens of different modules. Over time, the standard approach had amounted to a few ugly workarounds, hundreds of lines of code to maintain, tens of thousands of instances of one variable, and hundreds of thousands of function call parameters - every frame.

I'm extremely pragmatic and I've always taken other programmer's grand pronouncements on code purity with a large grain of salt. That was clearly an unacceptable trade-off just to avoid a global. Singletons are tools, use them appropriately.

I'm writing this up because of the unbelievable pain I went through to get it working. It seems like something that shouldn't be that difficult: getting a model to follow terrain by adjusting its up vector to match the up vector of the terrain mesh under it and to face in a given direction, but try and try again, I could not get it to work. Rotation matrices are my bane. Nothing else I do is so unbelievably frustrating. If they worked or didn't work that would be fine, but as I went along I found a lot of variations that would almost work and it wasn't always easy to tell what was wrong. My favourite variation worked perfect when going north or south, but squashed the model into a diagonally tilted pancake as it rotated through east and west.

I found a lot of information on the topic on the internet, but all the detailed examples were for DirectX, the OpenGL ones were all brief, too brief evidently.

My game's environment is 300km by 300km. In real world terms, that isn't all that big, but for a game world, it is sizeable. Once a rendered scene becomes larger than a couple of kilometres in size, you start running into severe problems with floating point accuracy. Even with my test terrain which is only 20km by 20km, I had very noticeable problems with props on the terrain appearing and disappearing as the camera moved. The graphics card thought the terrain was alternatingly in front of, or behind, the prop.

Luckily there is a fairly simple to implement workaround for this issue.