Mandible Games

Aquaria

Developer: Bit Blot

Completion level: Main ending, not 100%

This is NOT a spoiler-free review and I'm not going to be making any attempt to keep spoilers out of this one, or flagged before they show up.

Aquaria is going to be a tough game to talk about.

Let's start with the easy stuff: the art. Aquaria is fucking gorgeous. I described Layton as "clean", but Aquaria can only be described as "lush". The game takes place almost entirely underwater, and Aquaria has done a fantastic job capturing the feel of tropical reefs. Colors are bright and saturated, schools of fish dart between reeds which sway gently in currents, and nearly every movement causes ripples to wash out from your character. When I had a difficult time seeing it was because I was in an intentionally badly-lit area. The only creatures I had trouble recognizing were the ones who were camouflaged. The animations are very well-done, with sprites deforming appropriately to create realistic-looking movement. I found this game to be even prettier than Odin Sphere, and that's saying quite a bit. The music is probably the weakest part, as none of the tracks are particularly memorable or exciting, and even it sets the mood quite well. The controls are fluid (once you switch to a gamepad, at least – I personally couldn't stand the mouse). To put it simply, the game's pretty, and it feels good to play it.

The game itself is an exploration game, similar to Metroid or Castlevania. The main character, Naija, has a collection of songs she can sing that do various things. The majority of these songs transform her into another form, giving her a new set of powers, from "ability to shoot fireballs" to "ability to make plants grow" (which is moderately more useful than it sounds.) The bulk of the game involves you exploring new areas to unlock new forms which you can then use to explore more areas. It's not a game design that's particularly popular right now, but it's certainly a classic and it's one I've always loved.

So there's the easy stuff. What Aquaria does well, it does really well, in an excellent way but not one I'm really going to talk about. I want to make it clear, before I move onto the rest, that Aquaria really is a good game – this isn't a review, it's a dissection, and the parts I want to talk about most are the ones that Aquaria got wrong. And that's why I'm going to spend the rest of this talking about Aquaria's problems.

The writing is . . . dubious, in places.

Naija starts out alone with amnesia. It's a cliche, but a common and useful one. She spends a lot of time moping about how alone she is, and how she doesn't know where she came from or where anyone else is, and – pretty quickly – the player actually ends up resigned to being alone. It's a lonely game. It's just Naija, and a huge sea of water, and a lot of aquatic creatures, and it has a certain stark beauty.

And then Li shows up. Li is a human. Naija meets Li and instantly falls completely in love with him, despite the fact that they never communicate in any way. Not just love – dedication and devotion. It comes out of nowhere – she quite literally falls in love with the first living sentient creature she meets. It feels like a high school romance. "Oh! Boys exist! And I LOVE THEM. Forever." There's no courting, there's no romance, there's absolutely nothing besides the game informing you that, oh, by the way, you're now in love with this dude.

Li proceeds to follow you around the game. The stark solitary exploration is gone. Instead, there's this random guy following you. He shoots things occasionally. He's not particularly useful (his firepower is extremely limited) – largely he just serves to make you feel less alone. Unfortunately, the loneliness was, for me, one of Aquaria's great strengths. Before I met Li, I felt like I was exploring a huge, uncaring and yet beautiful world. Li didn't make me feel cared for and didn't make me feel like my quest was either more or less important. He was just a guy, following me and distracting me from the ocean's beauty.You can tell Li to knock it off and stay at home, which I did. But eventually you need him. You could claim this is making a statement about human social behavior, or the problems with trying to be self-sufficient, and maybe it is, but honestly I just felt irritated by him.

I don't actually believe it's a statement about human social behavior, though, because the plotline is unambiguous and blunt. It's about how much gods suck. This is a recurring theme in the game – every time you find out about a destroyed race, it was destroyed because a god decided to destroy it. Maybe it was the god that created the race. Maybe it was a different god. But every time a god is mentioned in the entire game (and this happens frequently) the god is described or shown destroying things.

It's not clear whether this was an intentional decision or not because it's never explicitly mentioned. If there were good gods involved in plotlines I wouldn't have had trouble with the plurality of evil gods. If Naija had, at any point, mused about how all the gods she encountered were evil, it would have at least shown me that the writer was aware of the evil-god fixation. But neither of those things happened. I'm left not knowing whether it was an intentional theme – perhaps it was meant to be a recurring plot issue, or perhaps the writer is just an obsessive atheist and hates the idea of benevolent gods. I don't know which and I quickly ended up feeling very disconnected from the plot thanks to how out-of-place this recurring element felt.

Let me set the stage for the last part of my playing. I was perhaps 3/4 of the way through the game. I'd found Li, and been annoyed by him. I'd started to notice and be sourly amused at the recurring Evil God issue. I still loved the smooth gamepad controls, and I was still enjoying the sheer beauty of the game. The game was annoying me slightly, but largely I still loved it. I entered a new area called The Abyss.

The Abyss is dark. There is no light. The only light in the level comes from you, in your Sun Form, which coincidentally means you can't attack. You're either reliant on Li for attacks or you're switching forms like a madman for any kind of combat. Or you simply run away from everything, which is what I did. Down down down in the bottom of the Abyss is a large door, marked with symbols that I recognized from Li's cave. I checked it out, ran into it a few times, tried playing Li's song, tried shooting it with fireballs, growing plants on it, and using all the forms I could to get it open. Nothing worked. Eventually I gave up and went looking for another area I hadn't yet explored.

Two hours later I went and asked for help on the forum. It turns out that the door can't be opened using the game pad. You have to click on it.

Yes, that's right. One of the supported control methods leaves the game completely unbeatable. There's no way to realize this on your own, there's no sign that this is the case. If you haven't been using the mouse to get around you're simply not going to think about clicking on it. It is not something that comes to mind. I'd just spent literally two hours swimming around pointlessly because it hadn't occured to the game designers to maybe, you know, trigger the door script when I moved close to the door.

Saying I was annoyed would be an understatement.

I wandered through the next area, solving some (admittedly pretty cool) puzzles, and then Li got kidnapped. Remember that Li just showed up out of nowhere perhaps five hours ago, and I was told Naija just spontaneously fell in love with him. Well, Naija went on this huge emotional tirade, ending with the following line:

"I knew that I would hunt down that dark creature . . . and kill it. I would not be alone again."

Naija. Come on. You've known this guy for less than ten hours. I know this because I've been playing for less than ten hours, and I met Li midway through, and then I had him stay in a cave for a good chunk of time. On top of that, you have literally not spoken to him once. There has been no period of time in this game where you could have had a long heartfelt talk with him that I couldn't see. I have had conversations with strangers that lasted longer than your entire romance. Stop being such a drama queen.

I continued on to rescue Li from whatever had kidnapped him, entering a new area in the Abyss that had previously been closed off from me. Now, a lot of previous puzzles had some kind of hint attached to them. Naija had feelings about the solution, or hunches, or said things like "I decided to check out the X and see if it was important", which is usually a good sign that maybe X is important. But the first puzzle I ran into was spelled out. "I found the X. And I knew that it would do Y." Somehow, Naija wasn't guessing anymore. How did she know? No clue. If she'd said that the knowledge came out of nowhere, okay, fine. If she'd said a memory returned to her, I can buy that. If she talked about writing on cave walls, great, we've got a reason. But no, none of those. Another glaring issue, on top of a lot in quick succession.

And then the end boss turned out to be . . .

. . . oh come on, you can guess, right?

Yeah. It was an evil god.

Okay. Deep breath.

I've written the last few paragraphs to demonstrate how annoyed I was getting at the game. Any one of those issues would have been a relatively small issue. Any one of them would have resulted in me sighing heavily, making a note, and then probably mentioning it in this dissection. But four big issues, back-to-back, starting with a seriously frustrating one, did more to knock me out of the game than nearly anything I've seen before. The first 3/4 of the game was deep and immersive and fantastic. The last 1/4 of the game left me annoyed and laughing at it. All the drama, all the suspense, all the beauty it had built up? Gone . . . and largely because I had to click on a door, instead of just bumping into it.

Summing It Up

The game's beautiful, in more ways than one. The gameplay is well-done. The plot is dubious and somewhat cliche, and unfortunately written in several places. And the interface is great and fluid . . . except in one unfortunate location.

Suspension of disbelief is an incredibly precious and fragile commodity. If you're lucky, your players will forget they're playing a game and just enjoy what they're doing. That's the ultimate goal of virtually all games. You have to be agonizingly careful to avoid squandering that, and once it goes away, it's difficult at best to get back. Once that first problem hits, even things that wouldn't normally be an issue can throw the player right back out of the game over and over again.

I've talked about "fighting the villain" vs "fighting the game" before, and this is the textbook example of the latter. The door wasn't hard to open. Figuring out how to tell the game I wanted to open the door? That was deadly. And I've never had it demonstrated quite as thoroughly as I did in Aquaria.

Aquaria is going to be released on Macintosh shortly. The forums say that a PC patch will be released along with the Mac release that, among other things, fixes the door bug. It is a good game, and it's very worth playing. But if you buy it before the patch, and you find yourself stuck, and you're using a gamepad . . . try clicking on things.

I play a lot of games.

That's a huge understatement, of course. I've got a stack of four DS games sitting in arm's reach, I've got a stack of six console games sitting over my by TV, I've got at least four games on the PC that are queued up to play, and if UPS would show up already I'd have three PSP games also. (And another DS game, and three more console games.)

Partly, of course, I play games because they're fun. This should go without saying, considering the focus of this journal, but even in this industry it's untrue surprisingly often. (I can't help but think that anyone in this industry who doesn't really love games is insane to be here, judging by the work hours and the pay. That's another post altogether though.) But I also play games for research. I can tell you what PN-03 did wrong. I can describe, in detail, why I think the Halo series was such a success, and only part of that is Microsoft/Bungie marketing. I can really ramble on at great extent on why save points are both irritating and absolutely crucial for any kind of suspense, and, in fact, at one point I was considering writing a Gamasutra article on that subject which never actually got finished.

It's sort of hard to figure out where to start with all of this.

Finally, however, I've figured out where to start. Ironically, I figured this out about one day before Greg Costikyan talked about people producing something similar to what I intend to, which makes it hard to take credit. But it's simple.

I play games partially to learn from them. As I play games, I'll write about what I've learned, what I'd do differently, and what I thought was fantastic.

These aren't reviews, so I'm not calling them reviews. I'm not going to say, at the end, that a game's score was 74.3% which places it at the top end of "Mostly Good Games" but not quite into "Games That Are Slightly Better Than Mostly Good, But Not Quite Really Good". I might, at most, recommend that people play certain games and avoid others, but these recommendations won't be based on how good the game is, they'll be based on how interesting the game is from a design perspective. Sometimes the worst games teach us the most. (Oh, how you'll get tired of me talking about PN-03.)

These also aren't criticisms. They're probably closer to criticisms than reviews, but I'm not entirely sure what critcism is. It doesn't seem that anyone really knows – Metacritic should probably be called Metareview, if we assume the two are different, but they're hard to separate. When I think "critic", the first thing that comes to mind is the hideously stereotypical French modern art critic, and I really don't want to be associated with any part of that.

In the end I've settled on calling these dissections. It's the most appropriate term. I'll be taking these games, pulling them apart as best I can, and describing all the interesting little squishy bits I encountered on the way. These are not guaranteed to be spoiler-free, though I'll try to mention when a major spoiler is coming up. Still, if you hate spoilers and plan to play the game, I recommend just skipping the dissection entirely (or rather, bookmarking it and coming back to read it later. Sending it to your friends would be appreciated also.) I will mention this at the beginning of every dissection, just to make sure it doesn't get forgotten, and I'll give some basic facts on the game at the beginning as well.

So, for my first dissection, we have . . .

Professor Layton and the Curious Village

Developer: Level 5

Developer's other notable games: Dark Cloud, Jeanne D'arc

Completion level: 100%

And, of course, the obligatory Penny Arcade strip.

THIS DISSECTION IS NOT A SPOILER-FREE ZONE. Read at your own risk.

Professor Layton is a puzzle game. Phrases like "primarily" or "first and foremost" simply don't apply, because Professor Layton is purely, 100%, a puzzle game. The gameplay is simple. You walk around the town of St. Mystere talking to people and examining suspicious objects. As you do this, you are shown puzzles. You solve them. Once in a while, someone advances the plot, unlocking more puzzles, more locations, and more plot. There are no action sequences, there are no time limits, there is nothing whatsoever to interfere with your contemplation of the puzzles. It is a very pure game, in that sense.

Art and Feel

The art style reflects this beautifully. I inevitably end up comparing art of this style to Tintin – it's clean and innocent, and while you may get the sense that there is evil lurking beneath the surface, it will certainly be vanquished well in time for tea. Layton himself is the perfect wealthy, honorable, British explorer archetype that never actually existed, with a mansion in the country that he rarely stays in, traveling from city to city in strange lands with a plucky assistant, having wild and yet somehow simultaneously sedate adventures that never leave you doubting who will eventually prevail. (It's the good guys, of course. But don't worry. The bad guys will escape and return again, and nobody will actually end up dying, ever.) This archetype may have started with Sherlock Holmes and I feel certain that Professor Layton and Sherlock Holmes would be fast friends within five minutes if they were ever to meet.

The game includes some FMV, and I was going to say that I didn't consider it particularly necessary, but thinking over it more closely it's actually just as understated and perfect as the rest of the art design is. Dialog-heavy console games can have issues providing a sense of how characters move and talk – Phoenix Wright gets around this by having extremely expressive sprites with exaggerated gestures and animation, Disgaea does much the same thing with equally-exaggerated single-frame pictures during dialog, Advance Wars: Dual Strike fails at this and honestly suffers for it, and Professor Layton pulls off a victory with its careful use of FMV. You never feel like you're watching a movie (or a recent Final Fantasy game, burn) but it sets the scene and the tone for each segment of the game wonderfully.

Tone is important for a game, and Level 5 nails this brilliantly. You're given the feeling that this entire town exists solely to provide puzzles for you and that it exists, in some sense, outside time. (I'll be revisiting this point, so don't forget it.) There's rarely any pressure on the player, and when there is it's gentle at best – people requesting your presence at your earliest convenience is about as pushy as the game gets. To make things even smoother, the game carefully leads you through the plotline. Whenever you're not actively in a puzzle the map screen contains a line of text telling you what to do next, from "Visit the park" to "Talk to Dahlia". I did run into a few cases where I forgot my goal and the text wasn't quite specific enough ("Talk to Beatrice" is unhelpful when you can't remember who Beatrice is) but even knowing that I'm supposed to be talking to a specific person is enough to narrow down your search significantly. You simply can't get lost in this game, and if you're stuck, it's because you're having trouble solving puzzles, not navigating.

That point is worth emphasizing, actually, as it's something I'm going to be bringing up frequently in these dissections. The player should never feel like he or she is fighting against the game. The player should always be fighting against the challenge, or the villain, or today's group of bad guys. There are cases where the interface is part of the challenge, but the controls should always feel smooth – there is a huge difference between "it's difficult to control my player" and "the player doesn't do what I tell him". Take a look at Steel Battalion for the first, and PN-03 for the second – Steel Battalion was difficult to control because you were controlling a giant robot with a three-foot long controller that had no less than five axes of movement, PN-03 was difficult to control because you couldn't jump left or right. (Why not? I still don't know.) It's a crucial difference, and Layton's interface does a fantastic job of staying out of the way from you and the puzzles.

The Puzzles

The puzzles are kind of a mixed bag.

It's nearly impossible to summarize the puzzles in any kind of useful way. There's 135 of them, and they range from matchstick puzzles to spatial analysis puzzles to word problems to the classic 8-Queens problem and many, many more. Whatever you're good at, it's probably in there, and whatever you're bad at, it's probably in there too. The vast majority of puzzles are technically unnecessary to beat and if it wasn't for a few points that require you to have solved a specific number of puzzles, you could likely get through the game with less than two dozen puzzles solved. You don't have to tackle the hard ones, unless you want to solve everything.

Unfortunately, some of the puzzle designs interact rather badly. First, a significant number of the puzzles are of the "Gotcha!" type. They reward you for thinking out of the box and finding the hole in the problem description rather than solving the puzzle as given. This isn't a problem intrinsically – puzzles of this type are fun. The problem is that some of the other puzzles are ambiguously written. When you've been trained to find loopholes in the problem text, and then the problem text starts having ambiguous segments in it . . . things get bad, quickly, and I failed several puzzles because I was thinking too carefully and not choosing the "obvious" correct answer. I wasn't having trouble solving puzzles. I was having trouble interpreting puzzles.

Worse, failing a puzzle gives you a permanent, irrevocable penalty. Each puzzle is worth a certain number of "Picarats", which they say is currency but which you could easily describe as "points". Answering a puzzle wrong reduces its worth by a certain amount – usually by 1/10 of its base value, but for multiple-choice puzzles it's often up to 1/4. There's no way to get these points back, besides starting the game over or saving before every single puzzle. You can replay puzzles as many times as you wish, but since they contain literally no random component, repeatedly solving them gives no extra bonus. (I eagerly await the first Professor Layton speedrun, as it will be moderately hilarious due to how predictable each puzzle is.)

What this means is that each time you interpret a puzzle incorrectly, due to ambiguous phrasing, the game penalizes you quite harshly. And, as someone who likes being able to perfect games, this is frustrating. The game does provide a hint system that you can check to get suggestions for puzzles (each hint costs a hint coin, which are available in limited quantity throughout the game, though profusely enough that I never felt worried about running out) but the hints are frequently either unhelpful or too blatant, and there's no way to know what sort of a hint it will be before purchasing it. In either case, they rarely cleared up the ambiguity without practically solving the puzzle for me. I'm not sure if there's a solution to all of this, besides semi-randomized puzzles and some ability to retry puzzles and reclaim your points, but it's probably the most irritating thing I ran into in the game.

There's little more to say about the puzzles – they're puzzles, they're (mostly) well-constructed and they seem to give the right number of points for their respective difficulties. Despite being the core of the game, it's oddly hard to talk about them, due to how diverse they are – any real in-depth discussion would be pages long, and I don't have that much to say. So I won't get into depth there – for the purposes of this dissection they're actually the least interesting part.

The Plotline

Back on a lighter note, though, the plot is almost perfectly suited for the game in more than one way. The plotline is, in many ways, a puzzle itself – you can go through the game without thinking about it if you wish, but I suspect most people who play the game treat the plotline itself as another optional puzzle, and it holds up quite well. Plot is delivered by people's discussions and by clues found in the village, and occasionally by Layton himself, who reveals villains in a manner Sherlock would indeed be proud of. (It's a little unclear where the player stands in all this, as the player is clearly not strictly either Layton or his protege Luke, but this never really gets in the way.) Most of the plot can be solved, by the player, before the denouement, and any fan of mystery novels knows that this is both crucial and surprisingly difficult.

Major spoilers begin here. Skip down to where I say they end (it's also in bold) if you don't want to read them.

Better yet, all of the major plot points are delivered very early on. The tower is clearly important, the highly-suspicious murder of one of the village inhabitants happens practically in scene 2, and every single suspicious point is laid out clearly near the very beginning of the game – and the vast majority of them are resolved, in rapid-fire, at the very end. The game pulls you in and doesn't let you go until the last threads are finished. In a brilliant stroke the developers included a section of the interface that lists the major unsolved mysteries, easily showing you everything that has not yet been answered.

I mentioned above how it felt like the entire village existed solely to give you puzzles, and as it turns out, that's exactly what the situation is. The village is a collection of puzzle-providing robots, built to test potential caretakers for the Baron's only daughter, Flora, who they have been taking care of for years. (Obviously anyone good at puzzles will be a proper caretaker. That's just how things work in Layton's world.) Besides Flora, the only human in the town is Bruno, the Baron's old mechanic and the designer and maintainer of the robots. Once Layton arrives, Bruno traps him there, along with Layton's archenemy Don Paolo who we end up knowing essentially nothing about, and that's why Layton is stuck in a town with a bunch of robots answering puzzles.

Clear?

Good.

The game ends up with "To Be Continued" and at least one giant mystery, namely who this Don Paolo person is and what he has to do with Layton. The game series is apparently designed as a trilogy (the second game in the series is now available in Japan and will doubtless be ported to English rapidly) and I presume its plot will be laid out in more detail in the future, but at the moment Don Paolo is a bizarrely loose thread in an otherwise extremely tight story. It almost feels like, at the last minute, they decided they needed a villain and so they grafted Don Paolo in. Similarly, Don Paolo's plotline really isn't a puzzle in any way. Don Paolo is masquerading as a detective, and very early on you think the detective is merely a jerk – there's no sign that he's a fake – but quickly it becomes clear that something is very wrong with his behavior, and the plot simply isn't subtle enough for him to be anything other than a villain. When he unmasks himself (thanks solely to Layton calling him out, and a small amount of evidence, most of which showed up after his villain status was clear to anyone who understands plot) it's just not a surprise, and it's far too late for you to feel clever for solving the puzzle quickly.

Why is he here? What's his connection to Layton, if any? We just don't know.

Major spoilers end here. Welcome back!

So in the end, the plot is good. Definitely good – we're well past the "there's a guy, and he's evil, so go kill him thanks" stage. But it's not perfect, and there are dangling bits that should not be dangling. I'll have to see if and how those are tied up in the sequels.

I'm running out of things to say, and I think it's time to finish this.

What Worked

I can't say enough good things about the atmosphere in this game. I think I may actually make tea for myself when I play the sequel, just to get more into the mood. The game is beautiful in a fashion which does not draw attention to itself – the art and town designs exist solely as a backdrop to the puzzles, and they support the puzzles magnificently.

What I'd Change

The weakest point is the puzzles – and that's really saying a lot, considering the quality of the puzzles. However, some of them are just a little too ambiguous and irritating to feel satisfying. I don't know if they got a serious game rules-lawyer type to go over the puzzle descriptions in agonizing detail or not, but if they didn't, they should have. Few things are more irritating than being seriously penalized for something that could have honestly been taken multiple ways. Just shouldn't happen.

The first thing I'd do is hire someone truly obsessive and anal to go over the puzzles and find every single point of ambiguity. As a programmer, I think a programmer would be perfect for this. Each of those points need to be squashed, and completely, unless it's actually the key to the puzzle. The only ambiguity left should be intentional ambiguity.

If I had more time, I'd figure out some way to partially randomize puzzles, and rig up a system where you could reclaim points by retrying puzzles. It should be possible to get a perfect score with sufficient skill, even after you've "beaten the game" with an imperfect score.

What I Learned

If you're building a game around a single concept, make sure the entire game revolves around that concept – the main gameplay, the supporting interface, and the plot. A game based around timetravel without an insane self-referential plot just isn't right, and if you're writing a game about puzzles, every part of the plotline should be a solvable puzzle. Layton got that about 90% right, which leaves the remaining 10% surprisingly glaring.

But honestly, I can't fault it too much, and I'm eagerly awaiting its sequel.

For quite some time I've been trying to figure out my plans for my current project.

A bit of backstory. D-Net began about three and a half years ago. I was visiting a friend's house, playing video games, and he broke out an old gem named Destruction Zone that I'd played before. Destruction Zone – and this may sound familiar – was a top-down tank game, multiplayer, with tanks blowing each other up in an arena. We played quite a long game, occasionally cursing the interface, and eventually I said "Hey! This game is pretty cool! Someone should make a modern version of this, with support for gamepads at the very least."

And, well, here we are. I spent two and a half years coding it part-time, while working at Google and getting distracted by other projects, and now I've spent about a year on it full-time. D-Net has taken several truly unexpected turns that distinguish it from Destruction Zone (enough that I'm no longer worried about copyright infringement – the most similar thing at this point is the name) and has grown into a distinct and truly enjoyable game on its own.

The tough part turned out to be the very interface I grumbled about the first time. Supporting multiple players on a single system is hard, and you've seen me rant about this at great length. The end result is a game which, to be honest, isn't immediately impressive at first glance, since much of the effort has gone towards things that the user simply isn't supposed to notice. (Like the fact that it's not a horrible pain to play.)

But more importantly, as much as I want this game to be complete and done, there's much of it that doesn't interest me. There are people who love multiplayer games, who buy Supreme Commander and Half-Life 2 and World of Warcraft and then never touch the single-player segments. In many ways, that's what D-Net is targeted towards – and, sad to say, I'm not one of them. I've enjoyed my work on it quite a bit, and it's shaping up very well, but I am fundamentally a single-player gamer. I love story, I love plot, I love drama and emotions and the fact is that D-Net doesn't have any of those.

So what I'm doing right now? In some ways, not tenable long-term.

There are solutions. I could sit down and rework D-Net into a singleplayer game. D-Net would make a very interesting squad-based combat game, and I've been quite, quite, intrigued by all the things I could do with this within the D-Net framework. But this is problematical. First, it would require a huge rebalancing, a huge re-tuning, and a lot of changes to the engine. D-Net is not designed for sprawling landscapes, it is not designed for running firefights, it is not designed for static guards or NPCs or indeed any of the things I would need. Second, it would mean I would no longer have a multiplayer game. D-Net is a fun game and it's played frequently at game parties with my friends. I don't want to lose that, because I do truly enjoy the thing I've built. And third, I wouldn't be building a game and a story together. I'd be desperately retrofitting, and either the story would suffer or I would have to write effectively a full engine.

Alternatively, I could splice a singleplayer game into the existing D-Net. This eliminates one of the above problems but keeps two, and adds an even nastier third problem: when you try to make a singleplayer game and a multiplayer game at the same time, at least one of them ends up suffering. There do exist games which, without modding, have been excellent singleplayer and multiplayer games – Call of Duty 4 is the best recent example that I know of. But they have to be designed for this from the ground up, and obviously, that has not happened.

I think it's important to explain why I kept writing D-Net.

Originally I was writing it because I thought it would be a neat and fun project. Later, though, I started thinking about what I would want to write for commercial release, and I came up with a plotline and a game that I felt had a huge amount of potential. I'm currently calling that game MV. I ended up designing it for the Nintendo DS, and I have quite a few files full of design and plot that I've built up while thinking about it.

In order to develop seriously for any game console, you have to buy a development kit. In order to do that, you have to convince the publisher that you deserve one, and that you won't just walk away and sell it to the highest bidder. Development kits are rather closely guarded, and as I understand it, you never actually own one – you're merely "renting" it. So, in order to get a Nintendo DS devkit, I would need to convince Nintendo or some other publisher that I was a competent game developer.

Thus, D-Net.

From what I've gathered since then, Nintendo DS devkits are much easier to get ahold of than I'd originally thought. On top of that, it sounds like having a mostly-working game is even more of a draw than I thought – so even if I can't get a DS devkit, I can do most of the work on the PC (keeping the DS's hardware specs in mind) and almost certainly get one with that. To put it simply, D-Net is no longer needed.

And thus, I think it may be time to retire D-Net . . . for certain definitions of retire.

D-Net isn't finished, but it's close, in many ways. I have plans for networked play, for singleplayer mode, for good AI. I have plans for many game modes, for a neat ending cinematic, and for many things that would be fantastic to finish. If I scrap all of those, or most of those, I really have very little left to do.

My todo list, at this point, contains three major tasks.

• Make a public demo release
• Finish all the weapons
• Improve the graphics

And so that is what I am going to do. I'll do those things (and then make another demo release), and then I'll shop it around, and try to sell it, because I do truly want this thing to be sold and to show up on XBLA or PSN or Steam or Gametap. But if nobody is interested, then I suspect I'll end up GPLing it, because it's more important to me that D-Net gets played than that it makes money. And once I'm done with that, I'll get started on MV.

D-Net has been a large part of my life for quite a while, and I've enjoyed working on it, and I've learned a lot from it. But I think it's time to move on . . . after giving it those last few touches.

GDC, the Game Developers Convention, is coming up next week. It's the first time I've gotten a full access pass for GDC, and it's going to be kind of crazy – five straight days of game development discussion, from 9 AM to 5 PM every single day. Yeesh. In some ways I'm glad GDC only happens once a year – I'm not sure I could stand more than five days a year of this.

It's also gotten me thinking about the other major gaming conventions and why they exist. A few years ago there were three major conventions, and today there are arguably four.

The Game Developers Convention has been around for all of modern gaming – the first meeting was held in 1987 in a living room. Now it rents out all of Moscone Center in San Francisco. GDC is focused on, as you'd expect, game development, including lectures on everything from design and story to the business, finance, and legal side of things.

The Penny Arcade Expo takes the other side of things, as it's focused entirely towards the players. While it's only a few years old, it's been growing spectacularly, literally doubling in size yearly. This year it has most, if not all, of the Washington State Convention Center in Seattle. It's three days long and approximately thirty times cheaper to attend than GDC. While there are many conventions where gaming occurs (practically every major anime convention, just to start with), PAX is the only one I know of where computer and video gaming is the focus.

And then, of course, there's E3.

The Electronic Entertainment Expo started as a business convention. E3 was where you went to find venture capitalists, to sell your game, or to see what Microsoft, Nintendo, or Sony had in mind for their next console. It certainly didn't stay that way – it quickly turned into a marketing and PR extravaganza. Business deals still went on behind the scenes, but the "focus" of the convention was glitz and glamour. Companies spent resources putting together "E3 demos", flashy and impressive demos that would be shown during E3 and never again, even when the overall quality of the game suffered thanks to the wasted effort. "E3 booth babes" were hired by the dozens, girls in skimpy outfits (that rarely had anything to do with the game or company) simply for the purposes of attracting a small amount of extra attention.

It was not a good situation, and virtually the entire industry eventually realized this.

About two years ago all of the major exhibitors at E3 withdrew. E3 was canceled and the owners revamped it thoroughly. What emerged is now known as the E3 Media and Business Summit, preserving the original business focus but eliminating all the glamor and glitz that plagued E3. The new E3 is invitation-only, instantly cutting attendance by over a factor of ten, and it has gone back to its original roots.

That's not completely the end for old-style E3, however. There's a new offshoot of E3 known as Entertainment For All, an attempt to make a fourth major convention based around what E3 used to be. There's little I can say about this because it's only a year old by now, but the focus appears to be, again, marketing – providing a place where the common gamer can show up and be advertised at. On their website there's very little on what to do besides the expo floor – it's entirely concerned with, hey, come to E for All! We have new games! And people who want to sell you new games!

This is something that we don't need.

First off, the publishers don't need any help advertising. There are already plenty of ways that you can buy people's attention with money, and we certainly don't need more of them. You could argue that we need more ways for smaller games to carve themselves a market share, but a huge convention like E for All simply isn't going to provide this unless they subsidize smaller developers heavily. Floor space costs money, and smaller developers can't afford that money – even the big publishers generally try to cram as many separate games as possible into their space, frequently managing to squeeze several games into the size of the smallest purchasable floorspace.

But second, and most importantly: a separate "marketing convention" is counterproductive. The largest group of gamers are going to be at the conventions which are fun in their own right. That's PAX. Nobody says "hey let's go down to the advertising center and see what they want to sell us", but people will gladly go to PAX and, once there, they will visit the expo hall. That is where they should be attempting to get people's attention.

Unfortunately, just moving the advertising to PAX doesn't fix the problem. The huge downside to E3-as-it-used-to-be was the sheer cost. If you had a major game coming out in the next year, you had to be at E3, you had to have an impressive booth with booth babes and free stuff and a flashy demo available. All of these costs, plus all of the effort needed to get a demo ready for that day no matter what, was a significant money drain. While PAX thankfully hasn't been allowing booth babes much of the rest could still apply.

Worse, I'm honestly not sure how useful, from a pure marketing standpoint, talking to gamers is. The gamers will no doubt generate some of their own publicity when they see new and exciting games (this is, after all, the point of marketing, right? Showing things to people who might buy them? Not just showing things to everyone, loudly and repeatedly with flashing colors?) but the unfortunate fact is that it's hard to beat the sheer advertising factor of having your game shown on every gaming news site. There's some risk of the PAX expo hall turning into a self-contained incestuous glob of marketing – despite how bad that situation is for everyone involved.

Fundamentally, the idea of an "advertising convention" is broken. Conventions are for large masses of people, when what marketing wants is for their products to show up in magazines. That doesn't require a large number of convention attendees at all, that just requires a few phone calls. Combining the two just leads to nastiness, where the publishers and game studios go to more and more expensive extremes in order to attract the few "important" people.

PAX serves an important purpose as it is now, and GDC certainly does as well. But we don't need another old-style E3.

One of the trickiest issues with designing any novel game is the interface. If you're putting together a first-person shooter or a MMORPG it's easy – you just do what everyone else has done before, unless you really think you have a brilliant new idea. (Chances are good that you don't.) Any game more complicated than that and you're going to need to invent something new.

One of Katamari Damacy's (many) charms was its two-axis control system. While that control scheme wasn't new (Virtual On's twin sticks come to mind, and I'm certain VO didn't create it either) it provided quite a lot of control over your Katamari – not the most precise control, but you never found yourself saying "if only I could move to the left". You didn't fight with the interface. You fought with the Katamari sometimes, but the player ended up saying things like "man, a large katamari is really hard to maneuver", not "this interface is terrible and I think the game designers should be shot."

I've played games where the latter happened. They aren't fun.

For any game with novel mechanics, you're going to have to make certain that the player can pick up on the key assignments quickly. Fighting with your controller isn't fun, even when fighting with the monsters can be. The game industry is littered with games where the interface hurt what could have been a great game (PN03, Red Steel) and where a well-built interface sent a game from "good" into "great" (Abe's Oddysee, Guitar Hero).

Interface design in Devastation Net has been problematical since the very beginning.

First off, D-Net is meant to be played with game controllers. This isn't a problem on an actual game console. A PC, however, is not a game console. When you plug a controller into a conventional game console, the console knows which button is which. Your PS2 has no trouble distinguishing between the "circle", "square", "triangle", and "cross" buttons. On a PC, a game controller shows up as a pile of axes and buttons. A PS2 controller, as far as my computer is concerned, is four axes, twelve buttons, and a hat switch.

There isn't standardization on which button is which. The buttons are in a random order, depending on the manufacturer of the controller or adapter. Even the axes might be mirrored – you can rely on the first two axes, but when you have a dual-stick controller (like all the modern standard controllers) the remaining axes might be in any order.

Partly, I could avoid this problem simply by not using gamepads. I admit I'm taking a more difficult position on this one than necessary, and of course I do support keyboards. But D-net is designed so that you can support a dozen players on a single computer – and for that, you fundamentally need gamepads.

Making those gamepads useful has been a problem in itself.

In most areas, you can find UI experts who will do excellent jobs of designing an interface for you. This is because the principles of UI design are mostly understood by now. We know where to put buttons, we know how to lay out screens so humans can comprehend them.

Games are tougher. The only time a game needs a serious amount of thought on the controls is when the game is trying to do something new. If I was writing a first-person shooter on the PC I would just duplicate Unreal Tournament's controls. There just aren't many top-down tank games, though, and there are even fewer that work with game controllers.

I ended up with a few different control methods. The standard mode was the obvious one – one axis for turning your tank, one for moving forward and backwards. Next I had a more automated mode, where you would move the stick in the direction you wanted your tank to go and the computer would try to figure out how to do so. And finally I had a mode inspired by Katamari Damacy, where you would control each tank tread separately. With each of these modes, each axis could be chosen separately by the player.

The computer-controlled mode quickly proved a dismal failure. The computer would happily drive into walls, and trying to write enough intelligence into it to not do so was difficult at best. On top of that, I didn't want the player's tank to be controlled by a computer. It's a player-vs-player combat game – not a computer-vs-computer combat game.

Katamari Damacy mode was a failure as well. With D-Net style tank combat, you spend a lot of time rotating in place trying to aim, or moving directly forward and backwards when you're aimed properly. Doing this with two treads was simply difficult – it was fun, but it wasn't particularly intuitive.

Standard Mode, as people usually set it up, was surprisingly ineffective as well. Most people would make a single stick do both turning and moving – move the stick left to turn left, move the stick forward to go forward. But those two, again, are things that people want to do separately.

It turns out the best control method (at least, the best we were able to find) is to have "forward/back" on the left stick, and "turn left/right" on the right stick. In fact, it's so much better than the others that everyone quickly started using it.

As a result, that's the one D-Net now suggests. In fact, I've removed all support for the computer-controlled mode and for Katamari Damacy mode. To a large extent, more options is just confusing – adding dubious control methods doesn't make a difficult-to-manage game any easier.

At the beginning of this project, the controls were hardcoded. In the middle I had more options than anyone wants. Now, I've got a control scheme that's simple and very effective.

I've had a few people ask me why this journal spends so much time talking about minutae of business (like server setup and mailing lists) and so little about, you know, actually writing games.

This journal is fundamentally about starting a game studio. Sometimes that's game design. Sometimes that's coding. Lately, it's been about setting up a server and getting some people reading this journal (yes, this one that you're reading right here) so that people actually play the game when it comes out.

So that's what I've been doing lately. The server's working and (finally) is requiring no tweaking. The mailing list is up and works as well. And now, I even have a company logo. It's a lot of small things, but it's small things that have to get done, and nobody is going to do them besides me. The next step, from a non-coding perspective, is PR – and I'm going to have a lot to say about that as well, because PR is a horrible pit of morality issues.

The reason I haven't been posting about what I've been coding is rather complicated and entirely uninteresting. I've been on a vacation for the last week, and now we're moving into the holidays, and so I haven't been getting as much work done as usual. On top of that, I've been coding things which are about as dull as it gets – interfaces. And not even interesting interfaces. For example, now you can hit Escape and get a popup menu allowing you to quit the game, return to the main menu, or change the resolution. Necessary? Absolutely. Interesting? Not in the least.

Unfortunately I've got a lot more uninteresting before I can get back to the interesting. What I'm trying to do is release a stripped-down demo version of the game for all to enjoy (and, for those of you who don't run Windows, I'm hoping to do a Windows/OSX/Linux cross-release. We'll see how well this works.) The game right now suffers from a few major flaws, however, such as essentially requiring someone who's played before to navigate the menus. This is pretty bad. It works great when your goal is "make sure the gameplay is fun and balance things", but it needs to be fixed, and it needs to be fixed now.

I'd love for game development to consist entirely of designing giant guns and aliens and making explosions look awesome. Unfortunately, that's just not the case, and I've got a long, long slog before I can get back to that.

This is what I woke up to four days ago.

By now, anyone reading this entry – and thousands of people who aren't reading this entry – have probably seen my Double-Boiling Your Hard Drive article. I wrote that one up because I thought it was fascinating, and submitted it to Slashdot, Digg, and Reddit just for fun. I got a small pile of hits off those submissions, but not many, and I went to bed assuming those posts would simply fade into oblivion.

While I was sleeping, a friend of mine made a Reddit entry that, to say the least, did quite a bit better. I woke up and my site was so hammered that even I couldn't access it.

Since I spent a lot of time trying to figure out what the issue was and (once again) ended up finding a solution myself, I'll explain the problem and eventual solution here along with a lot of technical garbage that most people probably don't care about. I am, however, going to try to make it understandable to non-geeks – so if you want a bit of a view into how webservers and performance works, read along.

The entire problem stems from the basic method that you use to do communications across the Internet. Here's the simplest way you can write an Internet server of any kind:

Repeat forever:
  Wait for a connection
  Send and receive data
  Close the connection

This seems reasonable at first glance, but there's one huge issue – you can only process one connection at a time. If Biff connects from a modem, and it takes me 20 seconds to send a webpage to him, that means there's 20 seconds during which nobody else can communicate with the server. Can't download, can't even connect. Worse than that, even the fastest browsers are going to take a few seconds to load a large complex webpage like this one, and that would kill performance completely.

There are many many solutions to this. The most common web server, Apache, seems to have two main modes you can run it in – prefork and worker – which implement two of those solutions.

First off, prefork. In prefork mode, Apache forks the webserver process into a larger number of processes, which means that there are actually, say, ten copies of Apache running simultaneously. This isn't nearly as bad as it sounds. Any modern operating system is going to realize that most of the data Apache loads, like the program itself and likely all of its configuration data, doesn't change – and if it doesn't change, there's no reason to make one copy of it for each Apache. It's shared among all the processes. If it's shared, you only need a single copy. Low memory usage and everyone is happy.

Unfortunately, Apache isn't the only thing that goes into a standard webserver now. The journal software that I'm using on this site – WordPress – is written in a scripting language called PHP. Scripting languages need an interpreter to work, and so Apache runs the PHP interpreter – one copy per process. The interpreter code itself gets shared in the same way Apache does, but all the temporary structures it builds and all of its working space isn't shared.

It actually gets worse from here. As part of their normal function, most programs allocate and deallocate memory. If they need to load in a big file, they allocate a lot of data, then deallocate it when closing the file. When they allocate, they first check to see if there's any "spare space" available that the program has already received but isn't currently using. If not, they request more space from the OS. However, most programs will not return space to the OS at any point. They'll just return that unused space to its local pool, the aforementioned "spare space". This means the OS can't know exactly what the program is or isn't using at any one time. The process eventually stabilizes at whatever its worst-case is – if you have one horrible page that takes eight megs of RAM just on its own, and you have your program load pages randomly, your program is going to reach eight megs and then sit on that eight megs forever – even after it's done dealing with that nasty page.

As a result of this, if you're running ten Apache processes, you will eventually be using ten times the maximum amount of RAM that Apache+PHP could use on any one page on your site. That's painful.

In my case, this site is running on a virtual server with 256 megs of RAM. My average Apache process was eating about 12 megs, and MySQL was consuming another 50 megs, and the OS was taking another chunk. I couldn't get more than ten processes running without absolutely killing my server. (When MySQL crashes due to running out of RAM I really don't care that I can serve error pages 50% faster.)

And this is why, despite the fact that the CPU load was negligible, the site was still completely inaccessible. I had plenty of CPU to generate and send more pages with. I was swimming in spare CPU. But no matter how much CPU I had, I couldn't possibly service more than ten users simultaneously.

Now, back to those Apache modes! What I've just described up there – with one process per connection – is "prefork" mode. There's another newer mode called "worker" mode.

In worker mode, Apache spawns one thread per connection. You can think of threads as sub-processes – they run inside the same process and all have access to the same memory and data.

Remember all that stuff I wrote about programs returning data to the OS? They don't return data to the OS – but they'll gladly return data to the process. Every copy of PHP that gets run can reclaim the exact same memory and re-use it, even while its siblings are sending and receiving data.

By default, worker mode spawns 25 threads per process, with multiple processes if it needs more connections than that. Under heavy load, each thread spends most of its time sending or receiving data (Biff's crummy modem again). In reality only one or two threads will actually be running PHP at a time – so the memory usage for this single process is, at most, twice that of the prefork processes. But we can now handle 25 times as many connections.

I finally got this mode up and running, and suddenly my site was not just usable, but 100% responsive. No slowdown whatsoever. However, you'll notice I haven't given any kind of detailed instructions on making this work, and there's a good reason for it. This is a terrible long-term solution and I was crossing my fingers the entire time, hoping it wouldn't melt down.

Here's the issue with threading. Imagine you have a blind cook in a kitchen. (I'm avoiding the classic car analogy.) He can cook easily, because he knows where everything is, and he knows where he may have moved things – he can take a pot down, put it on the stove, chop an onion, toss it in the pot, and the pot is still there. He's blind, but it doesn't matter, because nobody is mucking about with his kitchen besides him. No problems.

Now imagine that we have a huge industrial kitchen, with fifty blind cooks, all sharing the same stovetops and equipment. The cooks would get pots mixed up, interfere in each other's recipes, and there would probably be a lot of fingers lost. Threading, unless you're careful, can be equally catastrophic – all the threads work in the same memory space and they can easily stomp all over each other's data.

PHP, in theory, is threadsafe. Some of the libraries that PHP calls are threadsafe. Not all of them. It worked, for a day – but I wouldn't want to rely on it long-term.

There is a solution to this. It's just a horrible bitch.

There's a module called FastCGI that you can use with Apache in worker mode. FastCGI is threadsafe. FastCGI can be set up to call a specially-built version of PHP, and do so in multiple processes so PHP doesn't even have to be threadsafe. To make things even better, FastCGI keeps a small "pool" of PHPs – perhaps three or five – but nowhere near one per connection. This does mean that you can only have five PHP sessions running at once, but remember that PHP processing is fast on our server! Apache is smart enough to read all the input, do all the PHP processing quickly in memory, and then sit there waiting for Biff's modem to acknowledge all the data. Five PHP instances can easily service a few dozen connections.

Unfortunately, Debian Linux (and likely others) doesn't have particularly good native support for this. All the modules do exist in one form or another (apache2-mpm-worker, libapache2-mod-fastcgi, php5-cgi) but just installing them doesn't do the trick – you need to hook them together. Luckily, the FastCGI FAQ does mention everything you'd need for this (look under "config"). It's annoying to set up, but it's not really difficult – just irritating.

FastCGI on its own doesn't solve all the problems. WordPress is, actually, a CPU-hungry beast. Five PHP instances might be able to service a few dozen connections, but not hundreds – WordPress pages involve a lot of database queries and a lot of work. But solving this issue can be accomplished nicely by installing WP Supercache – it will cache pages as they're displayed and it hugely decreases CPU usage, meaning that those same five PHP instances can now serve well over a hundred.

Before these changes, my server couldn't handle more than ten simultaneous connections. I've used website stresstesting software since – I've managed up to 400, and the server doesn't even break a sweat. I can't do higher because my connection starts dying horribly.

There's no real excuse for any modern server to have trouble with this sort of load, unless it's doing extremely heavy noncacheable processing or getting hundreds of simultaneous connections. Computers are fast, and getting faster all the time – at this point I'd love to see this site get Digged or even Slashdotted, because I'm truly curious what it could stand up to.

I'm hoping that someone with this same problem will find this page and be able to fix it quickly. It's not that hard – it's just kind of annoying.

First I'm going to show you a picture, just to get your attention.

I have a rather old computer case that I've been lugging around for years. It's a Hush Technologies Mini-ITX. I don't think they even make these systems anymore – I got mine many, many years back, and it was one of the first they produced.

The Hush Mini-ITX was a near-silent computer, before silent computers were anywhere close to as easy to build. It used a Mini-ITX board, a small quiet low-power motherboard that frequently had a small fan for cooling, but instead of the standard fan it used a heat pipe connected to the side of the case. The case itself acted as a large heatsink and radiator for the CPU. The hard drive was enclosed in a heat-conductive but noise-silencing frame. Overall, a clever design.

It's been a hardy case. I can't say the same for components put inside of it. It runs hotter than I really want – so far it's on its third hard drive, its third motherboard, and its second power supply. Last time I swapped the hard drive when it started getting a bit noisy – not "there are things banging around in the hard drive case" noisy, but "its hum is getting louder". I figured the same thing would work this time, so in my recent upgrade I included a spare hard drive for it. Standard replacement deal – turn the system off, plug the extra hard drive in, toss a SystemRescueCd in the drive, and it refused to detect either hard drive.

Eventually I figured out that my old hard drive was deeply, deeply unhappy. It wouldn't show up in BIOS (and neither would any other drive on that IDE chain) and it wouldn't even initialize – it would just sit there and click. Click. Click. Click. Click-whir. Click. Click. Click. It was spinning up just fine . . . although after enough clicks, it would spin down again. It just wasn't showing up as a hard drive to the computer.

I did a lot of research and tried the standard recovery tricks. Apparently there's a rather infamous hard drive Click of Death, but it's more of a general symptom than a specific cause, and the causes can be anything ranging from "your hard drive is somewhat old" to "your drive head is now bent at a ninety degree angle". So that didn't really help me diagnose it, much less solve it.

The tricks are, to be said, odd, but I tried them anyway. Freezing the drive didn't help – if anything, it made the click noisier. Banging the drive gently didn't help. At this point I had kind of given up, so I tried banging it more emphatically and that didn't help either. That's most of the standard tricks.

So I sat there, with a slowly thawing hard drive sitting on the desk in front of me, and thought.

One of the possible reasons for the Click of Death was that the heads had gotten misaligned, either vertically or horizontally, or in some combination of the two. Another possible reason was that the heads had actually gotten stuck on something. If I could jar the heads loose, or get it started, it might function fine after that. And it had been working just peachy-keen in the computer beforehand – I hadn't even realized it was defective, just old.

So if the heads are just stuck . . . and freezing the drive makes it louder . . . well, brief diversion. If you have a jar that you can't open, there's a trick to getting it open. You run the jar under hot water. The lid expands, and the neck expands, and that also means the gap between the lid and the neck expands. And that makes it easier to open. Now, if I heated up my hard drive, perhaps the same thing would happen. On top of that, the drive had been quite a bit warmer when it was working – it had been encased in that soundproof frame I mentioned before. What if I brought it to near that same temperature before trying?

Obviously I didn't want to melt the drive, or burn it, or get it wet. This is exactly what a double boiler is for, and you can approximate a double-boiler easily using two pots. Thus the picture at the beginning of this entry.

I heated the drive up until it was bordering on "hot to the touch". I figured that was around how hot it was before. I plugged it in, and . . .

. . . well, apparently I've now invented a new way of repairing hard drives. I copied over the most vital stuff, moved it to a different computer quickly (I've never been afraid of a component cooling down before, but I suppose there's a first time to everything) and successfully took a disk image of it. Worked 100% perfectly. I can't find any references to this technique online, so perhaps I really am the first one to try it.

I can't say I recommend this as a standard repair method, and obviously this is no substitute for professional repair services. But if you've tried freezing your hard drive, smacking your hard drive with a hammer, and all the other "normal" tricks . . . maybe it's time to try double-boiling it.

On another subject, I will admit that this has little to do with Mandible Games. I've just been kind of busy lately, in entirely uninteresting ways. First off, Mandible Games almost has a logo – I'm just asking for a few minor changes before I finalize it and put it up. Second, I've been doing a lot of work on the interface to D-Net. I want people to be able to change the game's resolution and aspect ratio, and that takes a lot of effort to make the menus work sanely. Third, I got a new computer and almost lost a lot of data – obviously that's a bit of a slowdown as well.

My todo list, however, is getting shorter and shorter. Right now there's only six items left before I actually release a public demo version. The first version is going to be Windows, since that's what I develop on natively, but D-Net builds perfectly fine on both Linux and OSX – all I need to do is figure out how Linux and OSX packaging and installing works.

The first version also isn't going to include online play or single-player play, just to warn you, but it should give a sense of what the game is like, and if you have some friends who want to blow you up in tanks (and, ideally, some USB game controllers), it'll work just fine for that.

I think that's the current State of Mandible. Double-boiling hard drives and writing uninteresting UI code. Yep. That's about the size of it.

I'm finding it honestly amazing how little good mailing list software information is out there.

I want two mailing lists set up for this site. You can see a "subscribe" box for one over on the left – it's the mailing list that gets notified when I make another devlog post, such as this one. The second is the mailing list on www.mandible-games.com which should get notified when I finally make a public release of D-Net (which I am, note, working on.) The mailing list management software should be smart enough to deal with multiple mailing lists properly, so that the user doesn't have to do the whole verify-that-this-is-actually-your-email dance twice. It should also have an interface that doesn't look like it came out of the 1990s. And, finally – and what's giving me the most trouble lately – it shouldn't get flagged by gmail as spam.

Seriously. About 2/3 of the people who have signed up with gmail accounts haven't verified their addresses. From my testing, the "authorization" mail goes straight into Ye Olde Spam Bucket. Why? I haven't been able to figure that one out, and trust me, I've been trying to. And before you say "screw gmail", I should point out that the gmail readers outnumber all my other readers, put together, by a factor of three. And one of the "others" is my lone Hotmail user who hasn't authorized either. I haven't tested to see if Hotmail tosses it into Ye Olde Spam Bucket also.

If 1/3 of the people who have expressed interest are actually able to receive emails, that is not a good ratio. It is a very, very bad ratio.

I feel like kind of a dick trying to evade gmail's spam filter, but the fact is that I want my emails to actually be received. I mean call me crazy here, but these people have signed up, explicitly, by typing their email into a form on my website – I think they might be interested in getting the newsletter. And yet, they are not.

Options that I've come up with:

•  Try another software package, and see if that one bypasses the gmail spam filtering. I suspect it won't – the exact same message content sent from my personal email account goes right through to the Inbox with no issues.
• Use a paid provider. Problem: which one? There are dozens if not hundreds and I can't find any real information on them.
• Deal with most of my messages vanishing. I don't like this one.
• Figure out some way to bounce messages through the same mail servers that I use for personal mail. Eww.

I don't really like any of these, for various reasons. But I'll have to choose one. Time to start mucking with Option 4.

The advantage to all this work is that I'm getting a really, really good idea of what actually goes into a functional large-scale website – I just feel like I'm neglecting D-Net itself. Back to work though – it's almost finished, I think.

I hope.

So, remember how I indicated it was only a matter of time before I completely broke something?

There's a few people who are signing up to be notified about one thing or another. That's cool, because that's why I put those systems in, and I'm glad people are using them.

It occured to me, perhaps a bit late, that I should check to see how spammy those emails are considered. So I signed myself up on my gmail account and bam, straight into the spam folder.

Looking over the email carefully told me that it had failed gmail's SPF check. That has nothing to do with suntan and everything to do with spam prevention – it's a way for domains to specify where emails from that domain should be sent from. If mail473.gmail.com sends a mail from bob@gmail.com it's probably legit, but if some random IP in Russia sends an email from viagra@gmail.com it's probably not. SPF is a way of listing what servers can send mail from a domain. It's a good idea, and I completely forgot about it.

So, ten minutes of research and fiddling later, and I have a working SPF system set up. I try it again and . . .

. . . right into the spam folder. Fuck.

But at least this time it's listed as having a valid SPF check.

So I improve the email text also, and it still goes into the spam folder. I set it up so the Replyto address is the same as the From address, I set it up so that there's only one domain mentioned anywhere in the email . . .

. . . Oh well. I don't know how to convince gmail that I'm not spamming it. I guess, check your spam folder if you're subscribing to anything.

Edit: I posted this, then checked my Livejournal. It had two "comments" links, and one of them said that this entry had negative one comments. That's fixed now, I think. Bear with me. The launch will be a bit rocky. I swear I tested that before, really I did.