Saturday, June 26, 2010

More Kaitron, More Chess

Wizards of Kaitron, now with more tiles! We've made three decks like this one, each with about 22 playing tiles.



The unusual tile in the center is just a helper: it's to remind the player which kind of element beats which other kind of element.

On the WP7 front, my Chess Club program is starting to look pretty sweet. I've finished the watch-others-play and watch-lectures sections, along with the solve-chess-puzzles for FICS (ICC support on the latter is forthcoming). That last part was tricky because I finally had to teach the thing to let users move the pieces, not just watch what's happening on the server. Still lots of UI work to do, but for sheer functionality the game is nearing completion.

Thursday, June 24, 2010

WP7: Word Wrapping in XNA, Made Easy


In Silverlight, formatting text is about the easiest task of all. Boldface? Different colors? HTML markups? Word wrapping? Bah--all these are trivial.

In XNA, though, there are no primitives for any of these features. Instead there are exactly two tools at your disposal: SpriteFont.MeasureString() and SpriteBatch.DrawString(). Neither of these know anything about formatting at all--and they're certainly not going to accomplish any word-wrapping for you.
XNA isn't the only environment that lacks this basic text manipulation toolset. After running into this wall several times, I've eventually settled on an approach: a CompiledText class that turns a plain string into a formatted, word-wrapped, ready-to-draw array of individual text segments. Each segment lives on a single line and has the same formatting options--italicized, boldfaced, color blue, whatever.
One of the nice things about this approach is that you can do the hard work of constructing the CompiledText object infrequently--only when the text to be displayed changes--and in your calculation time rather than while you're doing the actual frame rendering. Once you've built the object, actually rendering the formatted text is accomplished by a very tight loop that just iteratively makes SpriteBatch.DrawString() calls--minimizing CPU cost while drawing a frame.

The CompiledText class I've uploaded needs a second file to run: AnimationUtils.cs, which exports a SqueezeText method. This thing figures out exactly how much text you can fit onto a line, by calling the primitive SpriteFont.MeasureString() and running a binary search across the string. (For better performance, you might want to refactor this thing to only test at word-break boundaries; it's currently doing the measuring first, then finding word-break boundaries afterwards.)

By the way, those who take a look in AnimationUtils.cs will discover an HslColor class that allows you to convert an XNA color to hue/saturation/luminosity values, then change them and convert back to RGB. Great for fades and color-shifts and such. Also in there is a C# version of probably the oldest method I've ever written: a method for moving sprites from one square of a chess board to another with a nice pretty motion that speeds up at the start and slows down at the end.

Monday, June 21, 2010

Resurrecting Chess Club

A long, long time ago I wrote a program called Icarus. It was a chess game, but it didn't know how to play. Instead, it was client software for interacting with the Internet Chess Club. You'd fire this thing up, and next thing you knew you'd be playing chess against someone else over the intertubez.

Fast-forward about ten years and Icarus had long since been sold to ICC for parts, and I didn't really care since the world had moved to mobile phones anyway. And there was this nice company called Danger that sold a Hiptop cell phone (T-mobile's Sidekick), and I could write programs for it. And naturally I wrote yet another client to talk with ICC--this time from your mobile phone. It was actually a pretty slick piece of technology and a well done little game. But Danger refused to sell it, for reasons they never really explained well.

(Every time you read in the news about how developers are all up in arms about Apple being too opaque or restrictive about their App Catalog, I laugh. Heartily. Danger was so insanely protective of their app catalog--which pre-existed the iPhone by years, mind you--that they made Apple look like a porn starlet eager for her first Big Flick.)

Anyway, fast forward a few more years, and Microsoft is just a few months from entering the smartphone market itself. And here I am, once again writing a chess client for a mobile phone. But (insert Monty Python swamp-routine accent here) this time, it will stay up.

For all that internet chess is an old story, I'm actually doing something kind of novel here. Microsoft, in its wisdom, has decided not to provide a sockets API with their phone--and that means there will be just about zero online games happening in the first release. Well, one: mine. Because I'm damned well connecting to the chess servers anyway, even without sockets. Woot. I'll post about how that's working after I've had a nap.

WP7: Primitive Cool

Imagine this: you've got a cool new mobile phone coming to market, and you want to compete on the world stage against the iPhones and Androids of the day. What do you need?

Slick multi-touch screen, check. Good MP3 experience, check. Um, telephone stuff I guess, check. Mmm... what about a gaming experience? Well, turns out it's Microsoft's turn to come out with a new phone, and since they've got this Xbox product line, they've got a bit of entertainment reputation to uphold. So, the new toy better have a heavy 3D processor or six built in. Check.

Picking up with WP7 (that's "windows phone 7" for those who aren't yet in the know) development kit, the first confrontation I got was from the language: everything's written in "C#". Which I do not know. This is kind of embarrassing, since I (a) used to work for Microsoft, the company that eventually came up with C#; and since I (b) am used to knowing all about any programming language I need. Whoops.

Fortunately, picking up C# was really just a day or two of effort (thanks in part to a C# pocket reference, which really summarized the language quite nicely). What proved harder was teaching the stupid phone to draw a line.

No shit. There literally is no graphics primitive for drawing a freaking line on the freaking screen. So when the first trick I wanted to do was take an image and kind of draw it slanted in a 3D-like-way, I had to do some serious experimentation to even get the ball rolling.

Which is the point of the post, dear reader. I submit to you now two blobs of C# source code:
  • PrimitiveRect.cs - a class that lets you easily draw lines and filled rectangles on the WP7 device; and
  • TexturedQuad.cs - a more complex class that lets you take an offscreen bitmap and stretch it onto any four-pixel-defined-rectangle on the screen.

Since I'm a mobile phone veteran, both of these classes are strong on the ability to precalculate early in order to keep the actual render cycle CPU-light. And since I'm a WP7 and C# newbie they probably look a little weird. But they're working great for me, so maybe they'll be useful to you too.

Wizards of Kaitron

First post at the new web site, and just to keep everyone guessing, I'm not even going to talk about computer gaming for once. Instead, it's time to show off the new OTB game that my son and I put together.

Wizards of Kaitron is a tile game that's at least vaguely like Magic-the-Gathering: you and your opponent both have a main character (a Wizard here), and your MCs each have some amount of HP, and your goal is to do damage to that guy until he dies. Poof, you win.

The novel part is, Kaitron uses the topology of playing tiles. To attack the enemy wizard you have to work your way over there, with your tiles and his fighting as you go. Each tile has its own health and special abilities, like being able to rotate in place or heal neighbor tiles and so on.

Each tile has different attributes, one for each side. There are four elemental attributes (earth, air, fire, water) and four ethereal attributes (light, dark, spirit, death). And there's a rock-paper-scissors-like system where this-beats-that to decide which tile wins in a given combat.

The mechanics of playing a game are a little more cumbersome than I'd like, but it's definitely turned out to be an enjoyable game, with a lot of strategy and a little luck involved.

My 13-year-old son and I plotted out the game a few days ago and play-tested using carboard tiles to see how it would work. That led to some rule tweaks, following which I ran out to Home Depot and a craft store. I picked up a set of 36 2"x2" kitchen tiles, some stick-on felt for backing, self-adhesive clear inkjet labels and a bunch of colored rhinestones. And poof, we've got some lovely playing tiles.

Before moving to this site, my blog was "Game Programming 101"--but I've renamed it to "Game Development 101" since the "programming" part has been getting too much attention. Developing a game is more than just writing lines of code, even if you're working on a well-understood game like checkers. The rename is to help me remember that. :)