Mandible Games

I am, of course, a perfect programmer. You can tell because I never make mistakes. Since I'm obviously perfect, this release is clearly not a bugfix for an incredibly stupid and important mistake, but rather I have decided that implementing one or two very minor features clearly justifies a new release, for excellent reasons that nobody else could hope to comprehend.

Therefore, this release includes a few things:

• A little codebase cleanup
• The EMP weapon's glory device resistance has been increased significantly, and I've added a visual effect to show it
• Small UI improvements, including a note to emphasize the glory device resistance a little further and some improvements to gamepad setup
• I've heard that some people might have found that the game just didn't run. Obviously this is impossible since I never make mistakes but, you know, if you did have an issue running the game . . . you, uh, might want to download this version.

Time for another release!

Version 0.1.4.0 is now here, with two new exciting features.

First: Linux support! I've done my best at getting a functional Linux package together, and I think I have one. This ought to plug straight into a vanilla Ubuntu installation. If you want to install it on any other distribution . . . well, hopefully you can figure it out. Is there a better way to package it? Maybe. If so, please let me know, since I'm really kind of in the dark here. You will need some kind of 3d acceleration support, just to warn you – software rendering is, shall we say, slow.

Second: Editor support! I've included the level editor I use for all the levels and much of the 3d geometry. It's undocumented and largely unsupported, and there are many issues with it (such as the lack of copy/paste) but it does work, and it is usable. If you want to make your own levels, or edit the existing levels, now you can. I'm certain there are ways you can make invalid levels that will cause the game to crash, but I'm OK with that because invalid levels should really be spitting out useful error messages instead of just crashing.

As for the game itself, it's mostly only been changed with a few small bugfixes and usability fixes. Finally, though, I'm moving onto actually improving the game itself, so with luck it'll get more exciting soon.

As a side note, I'd love to make an OSX version. However, I don't have a Mac. If anyone has an ancient OSX-capable Mac system that they'd be willing to donate or loan, I promise I'll get an OSX build working just as soon as I have a platform I can run it on :)

Download the Windows version and the Linux version, and if you're getting the Linux version, please tell me if it works!

New version of D-Net.

I have to say, first off, that this is going to be one of the least interesting releases ever. There's basically nothing changed that you'll notice. What there is, though, is quite important.

First off, I rewrote the build system entirely, in scons instead of make. This is entirely meaningless to the end-user, but it means that modifying the build system in the future will be much easier. This is a good thing. It makes Zorba less stressed.

Second, I added a small intro screen explaining what exactly you can expect from the game. If you're reading this, you probably already know what to expect, but the average dude coming in off the metaphorical street probably won't. So while that's not exciting either, it's important.

Third – and most importantly – I finally have a good crash reporting system. If the game crashes, it will beg permission to report the crash dump to my servers, and if given permission, give me information on what went wrong. I actually have no idea if it's been crashing for people – with luck it hasnt been – but the reason I don't know is because, fundamentally, nobody ever reports crashes, they just roll their eyes, say "oh, indie developers" and delete the game.

Which is not ideal from my point of view.

There's a lot of subtlety in a crash reporting system. For example, I've got mine rigged up so I can return messages, based on the game version, before the potentially large crash dump is sent. So if I start getting flooded with crashes that I've fixed, I can tell people to go download the new improved version, please, and stop bothering me with things I already know. (Perhaps not in those words.) Not only that but I can also return messages after the crash dump is sent, so I can analyze it server-side and return things like "your graphics card sucks" or "your RAM is bad". And it transmits the data in a compressed form to save on bandwidth, and it records as much information as I can without violating the privacy of my users.

Oh, yeah, that too. I don't violate user privacy. I don't send a single byte before the user has said "yes, I am fine with sending my debug log to Mandible." I've carefully checked the debug file to make sure I don't include anything that's identifiable (and removed a few debug printouts that went a bit too far, in fact) – the worst I can do is tell you what kind of graphics hardware you have, and what kind of joysticks you have plugged in. Which is obviously kind of important for debugging. I do not feel bad for including this.

Any kind of reporting of this type, of course, has to be agonizing careful about privacy issues. And, inevitably, someone is going to get annoyed at what I'm doing.

At least this way, I can tell them to just click "no".

Quickly on the heels of that alpha test is 0.1.0 official release. Grab it (nowhere, sorry, removed!).

What's different? Not a lot. There's an installer, and that's it. I haven't gotten any bug reports, so I'm calling this a release.

But there's a new site feature – I've added a site forum for discussions. Take a look, start a thread, talk about D-Net. It's still under very heavy construction, so beware that the layout and look might change drastically as you browse. But it's officially open. As always, I'd love to hear any commentary you have about D-Net or the site, and if you can't find an appropriate thread to post it in, head for the forum.

This is probably not the most exciting post you've ever read, but there'll be more coming. Not to worry.

This has taken far longer than I hoped.

I've told you about the interface issues. Those were problematical. Once I finally figured out how gamepads should work, I had to figure out how keyboards should work, and that was another issue. Pretty much every interface element has had to be redesigned at least twice as I gradually understood what I needed better.

This behemoth is finally in a good state to be released.

Download Devastation Net, version 0.1.0 Release Candidate 2

(Note: download removed since it was technically not complying with some licenses.)

Now, just to warn you: this is not a final release. It's not even an alpha release. It's an alpha release candidate, and you'll notice it's Release Candidate 2. There's no installer either – you'll have to just decompress it to a directory yourself. (Installer is one of the next steps.)

I'm releasing this, probably a day or two at most before the actual alpha release, only to people who read this dev journal. I'm hoping people will download it and give it a try. If it crashes – and it's entirely possible it will – I'm hoping to fix problems before the official alpha release.

But this is, of sorts, a release. It's playable. There's AI you can play against, and there's enough support for multiplayer on a single computer (which, incidentally, I highly recommend.) The AI is terrible, and I know it's terrible, but it should at least give a sense for the game. Some of the interface is unfinished, still, but it's generally good enough to figure out what you should be doing.

Let me know in comments, or in emails, if it works or not (and, for that matter, how well it works.) Your feedback is very appreciated on this one.

As for why this has taken a while:

My unofficial goal is to post here weekly, at least. But, as always, problems crop up and things get delayed, and unexpected opportunities arise. In this case, the unexpected opportunity was this thing:

That's a small part of the Babbage Difference Engine. You might think it looks pretty cool, but you'd actually be wrong – it's far cooler than that. I had the opportunity to watch a good deal of the setup and tuning process, as well as stay out of the way of the people working on it, and honestly even staying out of their way was quite an honor. If you're in the Bay Area, I recommend coming and taking a look at it once it's officially open – although needless to say, the exhibit launch is likely to be packed beyond all comprehension.

Hopefully the delay is understandable.

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.

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.

Emergent behavior is a curious, curious thing. Take a bunch of very simple processes of some kind – birds, ants, or humans, for example. Put them in a situation with some basic rules. Then watch in amazement as more complex behaviors evolve out of those. Traffic jams are a good example. The basic rules of the road are pretty simple. "Go where you want to go, stay in the right lines, and don't run into anyone." Nowhere in there does it say "come to a grinding halt every day at 4pm going southbound" – it turns out traffic jams just happen when you have the rest of the rules in place. Traffic jams emerge from the basic rules. Emergent behavior.

Well, D-Net turns out to have some of that. There are new forces and new gameplay techniques evolving out of the basic rules I set down. And some of them are pretty irritating.

One of the basic D-Net Rules is that weapons get more and more powerful, exponentially so, the more you play. And tanks also get exponentially more powerful, but in "stairstep" patterns. What this means is that at some points you're blasting away at your enemies and it takes ten or fifteen seconds to kill them, even at full power, and later on you can annihilate them in about three seconds.

What hadn't occured to me is how this affects weapons that depend on range. See, if it takes fifteen seconds to kill someone, and you're using a long-range weapon, you'll get a third of the way there and they'll be in your face tearing you to pieces. Whereas if it takes three seconds to kill someone, you'll be able to just incinerate them before they can even get out of the way, let alone advance to a range more favorable to them.

Which means that certain weapons have advantages at different times in the tank cycle. That's cool. It means that if you pick up an autocannon early, then shift to a laser later, you'll do better than someone who's just relying on one weapon or another. Which is extremely, extremely neat, and suddenly a lot of the difficulty I've been having in balancing weapons makes sense. (Including why lasers are now too weak, when they used to be just right.)

But it's an absolute bitch to balance.

One thing I'm really hating about D-Net is the emergent behavior.

I'm trying to come up with a few more Exotic weapons for D-Net. After some terrible ideas I came up with the concept of having half a dozen little drones following the player around, shooting at enemy tanks with rifles. It's a cool idea. I'm not yet sure how it will work, but I do like the idea.

The problem is that I already have a weapon class called "drones". They were originally called "rockets", but they also did exotic damage and rockets sound explosive. Now I needed a new exotic weapon name. Argh.

I eventually settled on Automaton. That sounds neat. I can live with Automaton. I'm certain I'm going to regret this decision eventually when I want to call something else "automaton", but hey! At least I have a name.

Now I'm trying to figure out what to do with Beam. I've got two weapons called Conversion Beam, one being a satellite weapon and one being a normal energy weapon. I guess I could rename the satellite version "Conversion Satellite", but it's part of a larger group which is all satellites, and there's no way I'm renaming them all "Satellite". On top of that, one of those subcategories – the Mines From Space – isn't consistent either – every other weapon type is "Variant Type", like "Heavy Railgun" or "Eliminator Drone", and mines are sometimes swapped.

So I either need to come up with a new term for "awesome-sounding laser weapon", or I need to come up with a new term for "lasers fired from space", and in any case I need to come up with three more terms for awesome mines from space. To say nothing of another half-dozen exotic and trap weapons I need to come up with, and another three or four special-purpose kinetic, energy, and explosive weapons.

I dunno, maybe Automatons should be trap weapons. I am considering having them hang around the area, even though there isn't much of a surprise component in them.

Argh.