Steel Penny Games

We've been doing Spousal Playtesting. So far so good. They haven't played the game significantly, so this was their first chance to sit down and dig in. Positive reviews, although the easy puzzles for one person are sometimes the hardest for another. Smoothing out the spikes is proving to involve not only the puzzle but the player--some folks will not do as well as others. The sense of accomplishment that comes from finishing the game will apparently carry some real weight. Most of the art is done, we're just lighting and tweaking cameras and so forth. One last model to put in, and a heap of Nintendo requirements for the programmer (hi!) to get straight.

Today was good. I removed a handful of screens that we didn't have a real need for, which brought our package down a bit. Some content will just be moving from a splash screen to the intro banner, so it's not a total win, but any improvement is noteworthy. We haven't turned on texture compression yet, which is probably what allows us to ship.

Current memory footprint: 61mb. 40mb looks sort of do-able.

Some of the puzzles are too hard. A couple of them took Alina, our junior artist, over 50 attempts. A little minor shuffling of puzzles and it's no longer blocking story mode for weaker players. Some of the puzzles may be too easy--hard to judge with such a small sample. It may be a good idea for us to put up spoilers on our web site every week or so, allowing stuck players to continue. Although that kind of defeats the intellectual purity of a puzzle game, I would be sad if there are players who love the game and the characters, but are precluded from enjoying the story. Then again, I don't want to dilute the sense of accomplishment that comes with finally defeating that level that you find really challenging. It's fun playing with a group, surprisingly, because in any crowd there will be someone who immediately sees a solution to any given puzzle, but can't figure out the next one.

I shared a bunch of textures across levels today, which brought our package size down a bit. Also trying to get the Home Button menu to work.

Current memory footprint: 68mb. Marching down to 40mb.

Yes, it's finally happening! We have our first game, Bruiser & Scratch in Case of the Puzzling Paw so close to shipping that we're starting to implement the Nintendo required screens and esoterica, and try to compact the game assets to fit into a WiiWare download. Being that no publisher is telling us not to, I figured I might as well share our experiences and try to keep a log of our progress. Something I say may be of use to other developer teams, or to the curious gamers looking for insight into the day-to-day life of stressed-out developers.

A little background: As far as I know, out of the 20+ titles released on WiiWare, I'm pretty certain our team is both the smallest, with 1 programmer and 2 artists... one of which started as an intern a year and a half ago. And we're probably the only one completely self-funded... and no, we aren't independently wealthy! Just passionate and slightly crazy.

We are looking forward to releasing our game. Nothing would make me happier than to be finished and able to talk with people who have played it. It's been a tough job getting it all together, getting the game difficulty balanced so casual players will not be too put-off, but challenging enough so even the hardest of hardcore puzzle players are blown away. Yes. It's all in there. And it's taken a small piece of my soul to do it.

So, the status at the moment is: implementing the wrist-strap screen. Yes, it's a glamorous job, but as chief cook and bottle washer, I get to do them all.

Current memory footprint: 87mb. Target: 40mb. Can we make it? Stay tuned! I know, it's riveting.

Recently, I was putting together a nice tool that takes in any TrueType font and rasterizes a set of glyphs (symbols) into an image at a specified size, to make extremely crisp-looking text for a user interface screen. Won't bore you with the details, but suffice it to say, I liked how it turned out. Unfortunately, mapping a texture exactly to the screen is a little tricky. You see, the texture coordinates and vertex positions together describe an area of the screen to draw to, and in order to make the texture unit draw exactly and precisely the values from the texture, some hardware knowledge is required and some thought must go into "tricking" the texture filter unit to find exactly the color you want in each pixel. Otherwise, you get a blurry mess! No kidding.

So, to make a long story short, I did everything that I was supposed to. Along the way, I found multiple tiny, niggling bugs that would have prevented my text from looking crisp and sharp. But when I exhausted all the possibilities, I tried something that is not mentioned on the sites I looked to for help. I forced my texture to be an exact power of 2 in width and height. And suddenly, it's perfect.

Why? Well, it's pretty simple, really. In order for the texture unit to figure out where to sample from within a texture, it's essentially taking the coordinates U and V and multiplying them by the width and height of the texture, to figure out which texel to fetch. If it's not exactly an integer (1.0 versus 1.0004), you will get a slight amount of filtering. With floating point precision, though, the only way to be really sure this math works out on a pixel-by-pixel basis is to have a power of two texture. The way I understand floating point math, which is quite possibly erroneous, powers of two have zero in the mantissa so are guaranteed to multiply and divide cleanly without introducing errors in the result. In other words, they are invertible: x * 512.0f / 512.0f == x, for all x. At least, within the limits of floating point math.

Ahh.. and I thought allowing the texture take up a bit less space by being odd-sized was a good thing. I hope this eventually helps somebody.