Mandible Games

Finally I've got the tank graphics done, or at least mostly done.

There's a lot of challenges and subtleties in these images that might not be obvious. Here's a list of things that you might not have noticed.

• The tank models are divided into tiers. As you go further down, the tanks both become more powerful and gain more vertices.
• The OTEK II has no variations. Most tank types have one variation, which is considered to be in the next tier. CARA II and SEKA I are in the same tier, for example. The highest-end tanks have two variations.
• A tank variation should be noticably different from the original tank, but still related. This is harder than it sounds.
• Tank abilities should be approximately clear from the graphic. Pointier sharper more aerodynamic tanks are faster. Wider bulkier tanks are better armored. Tanks with more pointy bits in the front tend to have better offensive capabilities, and tanks with complex detailed sides are more upgradable. There are other things to distinguish tanks, but most of them don't have to be worried about unless you're piloting it.
• Note that, in this layout, the leftmost tanks are the fastest and the rightmost tanks are the heaviest. In most cases the leftmost tank is also the flimsiest and the rightmost tank is the sturdiest, but there are some exceptions. TUVU is a sturdier tank than MARI, and the GUPE/BORA/HIMO line is backwards. (Yes, the GUPE is both a heavy tank and a fast tank. Relatively speaking, its weapons suck. The HIMO is exactly backwards.)
• I'm working the number 6 into gameplay in a lot of places. Every weapon has six increasing-power versions. There are six rounds between shop phases. I could argue that there are six tank variations in each chunk, but that would be a stretch. Note that there are 7 tank tiers. This is intentional. Still trying to figure out more places to put the number 6. Right now there are 5 damage types, but I want to keep that, so maybe I'll add a "typeless damage" series of weapons.

If there are tanks that you think look too similar, or suggestions, I'd love to hear them. But I'm mostly posting this because I think they look neat.

Also I'm pretty sure that none of them look like penises. It turns out that this is a recurring problem when you're trying to build war vehicles.

User interface design is hard.

Not because it's hard to invent interfaces. Oh no, it's easy to invent interfaces. You can throw the suckers together in minutes once you've gotten a little practice. And not because it's hard to invent usable interfaces. That part is hard, actually, but with a little introspection and a lot of blind testing and a whole hell of a lot of agonizing and rewriting, you can make them work. No, the problem is to invent intuitive interfaces. Because intuitive interfaces are usually far, far more complicated than anyone would expect – since, after all, they're intuitive, and they look so easy.

Right now I'm designing a level editor. It's a 2d editor, used to create curves and paths. It doesn't have very many general classes of "thing" it has to deal with yet. There are paths which have centers. Paths are made up of nodes. Nodes may have curve controls on them. Lines connect the nodes in a loop, either curved or straight depending on the curve controls.

Fundamentally it's quite simple. Here's a screenshot, and I imagine most people feel they could jump right in and start moving points around easily.

Well, you're right. You could. You could grab a point, and drag it, and it would move (and, in fact, the point on the other side of the figure would move too – this particular path is set up with vertical symmetry, which the editor will happily preserve for you. Classy, no?) Note that one point is selected right now – the one that's red, in the upper left – but really that doesn't matter much, you can drag any node around at will, and if there are multiple nodes on top of each other you can just click multiple times until you have the one you want selected. You could also right-click a line to toggle it from "curved" to "straight", and the curve handles will automatically go away. And come back if needed. Pretty neat, huh?

You have no idea how complicated all this stuff is.

Imagine the actual code behind it. The user clicks on a node. The program must select this node. Now the user drags the mouse, and the node moves with the mouse. That's easy.

But what happens if the user clicks on the node again? I've mentioned that you can cycle through nodes by clicking, so we could just have it select the "next" node at that position, whatever that means. Sounds reasonable. Except then the user selects a node, and drags it coincidentally on top of a second node, and changes his mind, and drags it further . . . but whoops, he got the wrong node. The program changed to the next node when he clicked. That wasn't supposed to happen.

Instead, we could make it so the node change happens when the user lets go of the button. Only now we have a different problem – the user selects a node, moves it coincidentally over another node, and lets go . . . and it selects the other node. That's not the right behavior either! We shouldn't change nodes in that case. And, in fact, there's a further problem – if I select a new node that happens to be in a stack of three or four nodes, then let go of the mouse button, it will change to the second node in the stack when I let go of the button.

After some thought, you can come up with the following process to solve these problems:

• The user clicks. If the currently selected item is not underneath the mouse button, it selects whatever is underneath the mouse.
• The user may or may not drag the mouse. If they do, move the currently selected item.
• The user releases the mouse button. If an item was not selected, and the user did not drag the mouse, and there is a second item under the mouse that can be selected, select that one instead.

Note that I still haven't defined "second node" or "next node" or anything like that. Oh, also, there's a bug in that process, which I'm not going to point out. (Find it! It's a challenge!)

But we're not even done. Remember, there's four things in this universe that can be selected – and lines aren't draggable! But you can right-click them to change if they're curved. Or you can right-click nodes to lock their curve controls to "straight", so there are no obvious angles to that node. But curve controls, or the path center itself, can't be right-clicked (even though they can be dragged.) And if the "add node" button at the top is selected, then clicking a curve creates a new node at that position. What happens if you click "add node" and then click a curve control? What if it's a curve control on top of a line? What if you right-click it?

And now I have to go, rip out a hundred lines of code, and rewrite it, because my current approach just doesn't work.

User interface design is hard.