Word Duelist has now hit beta. This means no new features, no new polish, no new content. I’m starting a “test then fix bugs” cycle which will repeat until, well, there are no ship blocking bugs. I expect this will take less than a week, and I’ll have another game in peer review. This one’s a fair bit more impressive than See the Light, having actual art and much more content and all. I’m toying with the idea of making some fun promo videos while it churns through peer review.

Speaking of See the Light, it’s doing OK I guess. I never expected to make much. In a little over a week it’s had 1600+ trials and 110+ purchases with nearly a 7% conversion ratio. It’s seen a positive review from at least one site (GayGamer.net) and has been mentioned on a few other sites, and it’s sitting at a steady three stars in the Marketplace.

It’s probably off the New Arrivals list by now, which is going to slow it down, but it’s had a decent start. If you haven’t bought it yet, you definitely should.

If it feels like I’ve been talking 95% about game development lately, that’s because it’s taken up the great bulk of my time. This post is just going to rattle off things that have been going on - game dev related and otherwise - for all your pleasure.

(1) See the Light shipped. I have no frame of reference for how well it’s doing. It’s been submitted to a few review sites, but to my knowledge no reviews exist yet aside from the star system the Marketplace provides.
(2) Word Duelist’s alpha is approaching its close. I’m cleaning up some rough patches and adding some more colorful dialog; the target for Beta is Monday, and the target for submitting to review is Friday.
(3) I’m home for the holidays. Not for too much longer, though, so if you want to see me you’ll have to act fast.
(4) Saw Sherlock Holmes. Pretty good; not quite as witty as I was hoping, but it made up for that with some good action sequences. I’ll probably trek over to see Avatar today or tomorrow.
(5) New beard trimmer! Now I don’t look like such a vagrant.
(6) Laura got me a cowbell a few days ago. Now I can finally satisfy that fever I have. My office is a mess of drum equipment and makeshift stands and barely qualifies as an office. Maybe my next game will be purely percussion based.
(7) Still dabbling with scripts. Nothing I’m quite satisfied with. Alas, it looks like the Carrboro film festival passed recently. Also toying with making some fun promo videos for Word Duelist.
(8) L.A. Ink is an awful, awful show. And yet I watched the entire first season. Sigh.
(9) Not been playing a lot game-wise. Playtesting a large number of XNA games.

My first XNA Indie Game, See the Light, has been approved in peer review. It should be up to purchase within 48 hours. Just visit the Game Marketplace, go to Indie Games, and it’ll show up in the new releases.

If you’re a good friend you’ll buy it. If you’re a great friend you’ll tell your friends to buy it. If you’re a really great friend you’ll blog about it and put it up on your review sites. If you’re an amazing friend you’ll stand in the center of a crowded street with a banner advertisement. If you’re my best friend you’ll announce it on TV.

Months upon months after its first mention, Word Duelist has finally picked back up and has moved into the alpha stage.

This means that it’s feature complete (and actually has very few bugs). I’m waiting on one music track from the musician and for Laura to add some gradients to one screen (or whatever artists to do make things look shiny), and it will be content complete.

The stats come out like this: 19 characters. 9 locations. 17 word games. 3 songs (+3 battle tracks that overlay onto the base songs). I don’t even want to think about how long it’s taken.

See the Light is still chugging along in Peer Review. Word Duelist might be in there before StL ever gets out.

In 1781, Stonewall Jackson wrestled an alligator and threw it at the moon, destroying it.

Allow me to qualify: trying to multithread an algorithm can make the algorithm faster. But at best the speed gain is minimal. I wouldn’t say four core machines are common, and even with those the absolute most you can hope for is a four-fold speed increase. Good luck getting that - between overhead, synchronization, and many problems just not parallelizing well, you’ll be lucky if you get half that in most cases.

No, multithreading is about making work non-blocking. It’s about allowing things which can “go off and do their thing” to do so. It’s about starting something that isn’t immediately needed so that by the time you do need it, it’s ready to go.

Let me give you an example: resource loading. You can make resource loading fast; you can tightly compact your data in a nice binary format and minimize hard drive hits, but at the end of the day, a 4 GB file is a 4 GB file and it takes time to load.

The wrong way to go about loading this data is to multithread it such that your loading is faster. Oh sure, you could try. You could break your file into smaller files and make different threads responsible for reading each file; then later you can assemble the data. This is counter-productive for multiple reasons, not least of which is that your hard drive latency/bandwidth is limited.

The better way would be to load the data all in one thread but start that loading early. Or if you can’t start loading early, start it when you normally would but don’t do anything that relies on the data until the thread is complete. The goal here is not to do anything faster. It’s just to do *other* things while you’re doing something that isn’t going to go any faster.

Sure, cases exist where you just need to split something up to just go faster (ie: scientific simulations), but that’s not where I find multithreading most useful.

Let’s come right out with it. The garbage collector on the 360 sucks. If you’re not careful, and I mean really careful, every few seconds your game is going to come to a screeching halt for a quarter second or more. Nothing will make your game seem less professional.

And I mean really careful.

Why? I don’t know. I don’t know why the garbage collector sucks on the 360 but not on the PC. I know that the PC has a generational garbage collector which is quite happy to gradually remove garbage over time, whereas the 360 starts garbage collecting after about a megabyte and doesn’t stop ’til the sun come up.

I’m a lazy programmer. Whenever I have to implement a new feature, the first thing that enters my mind is, “How can I get this done with the minimal amount of work?” I’ll choose the three line solution that solves my problem over the eighty line version that’s super optimized any day, and I’ll only go to the harder solution when the easier is causing problems.

Drawing quads is pretty useful in UI development. Message boxes have backgrounds. An easy way to fade is to draw an alpha-blended quad over top of everything.

There’s no native “draw quad” in XNA. SpriteBatch doesn’t have it. Quads aren’t even a valid primitive type for rendering in 3D. If you want a quad, the “right” solution (as far as I can tell) is to stick four vertices into a VBO, create an IB that references those vertices, apply some matrices to get the quad in the right location, and render with an effect.

Which has a number of problems. If your UI is using SpriteBatch everywhere, you then have to throw some 3D rendering in the mix, which your project may not even need. A VBO and IBO aren’t really all that valuable when you’re drawing a single quad and mostly just suck away memory - you could just as easily use DrawUserIndexedPrimitives, but you still have to create a vertex and index array. And it’s ugly.

So here’s what I did:

I created a texture called “whitepixel” that is, as its name implies, a single white pixel. I then used SpriteBatch.Draw to draw that texture, passing in the appropriate position,scaling, and color. SpriteBatch takes care of scaling the texture and coloring it, and I never have to know what it’s doing under the hood. It takes up about two lines of code, and it’s swell.

Professional developers don’t just develop until things ‘feel’ good and then put the game out. That would be silly. Professional developers develop to certain milestones and then change development focus until everything is thoroughly tested and tweaked and polished and completed.

Here are some common milestones:
Alpha - the game is feature complete; there’s still some polish to be done and a considerable amount of bug fixing, but generally the game can be played. Focus shifts to wide testing, debugging, and adding small features.

Beta - the game is ‘complete’ but not quite finalized. You can play through the entire game. Bugs probably still exist, though Alpha should’ve cleared out the bulk. Focus is testing and debugging. No new features. Period.

Release Candidate - hopefully all the bugs are gone but not necessarily. Testing is narrow. Any fixes are kept as local as possible to avoid repercussions. Every build is a candidate to go final.

Lot Checking - you’ve declared the game ‘final’ and now it’s up to someone else to verify this such as a console manufacturer.

The definitions are a little transient between studios along with when the game should be ‘code complete’ and ‘content complete’, and this list excludes internal milestones which are a reality everywhere. But the general gist is there.

I’m of the opinion that even small studios should adhere to this paradigm for a number of reasons:

(1) It gives a good indicator of progress and allows for better estimates. If you can say your game is feature complete, you have a rough idea of how much longer is left in development. This idea may not be exact, but it’s a lot better than if features are still going in.

(2) It help avoids feature creep. It’s too easy, especially with smaller games, to go back and repeatedly add little touches to make things better. If you can be disciplined about declaring Alpha, you can pretty much set a stopping point for new features and focus on getting the game out.

(3) It reduces moving targets. You can’t do quality heavy debugging while new features are going in. The general rule is this: every feature is going to break something. If you’re still adding new features up until the end, you’re breaking something else up until the end, you just haven’t realized it yet.

(4) It manages cost, which goes hand-in-hand with reducing moving targets. Having a bug during Release Candidate or Lot Check is a Bad Thing. The fix necessitates a heavy amount of testing and verification before the game can be cleared to move on again. The goal then is to make sure that doesn’t happen, and being focused during your testing/debugging facilitates this.

(5) It creates a sense of urgency. Nobody likes beta testing. You want to get out of that as fast as humanly possible. Trust me. Release candidates are even worse.

(6) It sets aside time to really focus on polish. Alpha is a great time to add in those little tweaks that are necessary for real games but which you might forget if you go straight from normal development to release.

(7) It forces you to not polish sometimes. When you get into beta or RC, every change imposes risk and cost, and you have to be critical about which changes are necessary versus which are ideal. If your goal is to release a game on a schedule, sometimes you just have to ignore an issue that isn’t a deal-breaker.

I went through all of the phases for See the Light (it’s currently in “Lot Checking”, or as XBLIG calls it, “Peer Review”), and I think my game is better for it. It’s not a perfect game; there’s only so much I can do as a one-man-band with limited time, but it’s certainly cleaner and more polished and more bullet-proof than the large majority of my previous games. And if (big if) it makes it through Peer Review without any issues, I credit the end cycles for that.

See the Light has finished its testing and debugging. With no further issues found, I have declared it RC1 (Release Candidate 1 for those not In the Know).

It has been submitted to XNA Indie Games and is now awaiting peer review. I don’t reasonably expect it will pass the first round - my eyes have been the only eyes looking for some time, and a fresh set of eyes are almost guaranteed to find something I missed. I’m quietly optimistic, but I won’t be surprised if someone finds a Code 4 error hidden in there somewhere.

If you happen to be an XNA Creator’s Club member, I would kindly appreciate a peer review.

Once everything is finalized, I’m going to see about packaging up Trial Mode for the PC and putting it out there. The keyboard controls are a little awkward and would need refining, but I think I can figure out something? Who knows. The on-screen UI elements are also wrong.

So now that leaves the question: “What’s next?” Well, Word Duelist is getting closer and closer. Once the art’s finished I’ve got some issues to fix, but it’s very close to Alpha. There’s also the successor to Penguin Push (to be renamed to avoid any trademark conflicts); I coded that up probably a year ago, but it needs serious reworking to even meet the most basic of XNA Indie requirements. And I’m toying with the idea of bringing over Heart Stream as a Valentine’s release. That one probably won’t happen though.

But this is all getting a bit speculative. Let’s see how See the Light does in peer review, OK?