November 2013


The proof copy of The Conlanger’s Lexipedia arrived last week, and I’ve been proofing and revising.  Then my wife started reading, which is adding time to the process, but it’s valuable.  She worked as a Spanish editor, so sometimes her instincts are wrong (e.g. on capitalization of titles); however, she pointed out a couple places where I demonstrated a somewhat deficient mastery of the alphabet.

The Lexipedia nestled in a pile of its sources. My floor looked like this most of the last year

The Lexipedia nestled in a pile of its sources. My floor looked like this most of the last year

(Huh.  My camera is not only poor at capturing indoor scenes, it lives in the past.)

This weekend I hope to get the final PDF files together, so hopefully the sales page will be up in about a week.  Behind schedule, but as alert reader John Cowan helpfully pointed out, not by nine years, like Johnson’s Dictionary.

So Li’l Guardian Pyro is up for a Saxxy award. I just watched all of the nominees, and it’s the best. But some others are very good, IMHO:

  • Chinatown Getaway is set in Koth King and feels just like a Hong Kong action film.  Makes me wish TF2 included parkour and expanded melee.
  • Frozen in Love is very clever.  Someone turned their lack of animating skills into a plus.  Plus why can’t we have female models already?  There’s already an insane amount of pictorial variation in the game.
  • A Fragile Dream is affecting.  Post-Apocalyptia is a little bit easy for generating pathos, but this is well done and very well animated.

Hat tip to my friend Samwise for pointing this out:

This is pretty much the best Source Filmmaker short I’ve seen yet. A little bit of cute overload at times, but it’s lively, clever, and totally captures the spirit of TF2.

A lot of TF2 shorts are good, but marred by wooden animation. This stuff is professional-level, and goes beyond merely re-using Valve’s art assets– the little pyro/spy/medic have all been specially rigged and animated. As I’m doing this stuff for my game, I’m aware of how much work it is.

And technical prowess isn’t enough; you also have to have characters and a story. The interaction between the characters is really well done here– lots of little details like the wordless frustration of the Pyro when he wants to be in two places at once, or the fact that when the Guardian Pyro is put back at the end, the other Guardian pyro is animated and looks at him. Really amazing work.

So, where’s the book? I ordered the proof copy today. As soon as it comes, I’ll do some intensive editing and correcting, and then GET IT OUT THE DOOR.

Each step seems to be taking just a little longer than I expect. But the end is near. Tell all your loved ones to buy you a copy!

I finished Arkham Origins last night… well, it was verging on early morning.

This is how I inspire Gotham

This is how I inspire Gotham

Overall impression: AO is like someone was told to closely study and imitate the greatest game of all time, Arkham City, and they did. It’s very much like AC, it nails the art style, it even extends it in some ways, it’s fun being Batman again… but it has little flavor of its own.

I have a bunch of complaints, which I’ll present in handy bullet point form.

  • The voice actor for Joker tries to match Mark Hamill without really getting there.  This is not what you should do with an iconic performance– you should find your own way instead.  He even sings a song over the credits… not well.  It doesn’t help that the writing never hits the heights of AC either: Joker is not very funny.
  • There are some very annoying boss fights– particularly Deathstroke and Bane.  I guess I dislike the mode of “ordinary damage does no good; you must only use these particular maneuvers”.  At least there’s no annoying cooldown.
  • Man, I hated one puzzle where you have to use the glue gun very quickly.  If you aim and fire, you just do not have enough time.  Finally I realized– this game was optimized for consoles, it doesn’t require aiming– use the 5-5 quick combo.  And that worked.
  • Mad Hatter returns… he gave an annoying fight in AC, and here he has his own dream sequence, which highlights one of the persistent problems of AO: it’s linear to the point of bugginess.   E.g., there’s a place where you have to run to a wall, in a spot you can’t stay on long because it’s periodically electrified, and use your explosive gel.  Except 3/4 of the time, you hit the gel key and he gels the floor.  Finding the sweet spot where the Batdoofus will actually gel the wall is frustrating and makes you wonder if they actually had QA.
  • They also return, ill-advisedly, to the 2.5-d sequences of Arkham Asylum, and there’s points where the controls go wonky and the game takes your attempt to jump a gap as a command to plummet to your death.   General rule of thumb, designers: don’t kill me for a mistake which the character would never make.  Rocksteady realized this, turning accidental leaps into graceful recoveries with the batclaw.
  • Similarly, there are a lot of places where your abilities should work, but don’t– e.g. walls that you can’t grapple up.  I know Batman’s abilities make level design hard, but it can be done– see AC.
  • I realized only very late that you only get the Sonic Batarang for a very specific challenge– complete a predator scene without being seen. And I’d already gone through most of them.  There is, by the way, often no feedback on whether you’ve been seen, so you can’t replay the encounter if you finished it and got spotted invisibly.
  • The plot is a bit meh.  AC’s plot doesn’t stand up to rigorous analysis, but at least it had panache.  I never quite understood the Joker-Bane relationship, and they never explained where Black Mask was.  (The game implies he’s dead, but we see him in AC.)
  • The overall setup promises an intimate glimpse at eight villains, but few of them have as much character as AC’s Penguin, Poison Ivy, Mr. Freeze, and Two-Face.  They’re almost all just dudes who show up for a boss fight and have no agenda of their own.
  • I dunno, whaling on cops is just a smidge disturbing.  Batman is supposed to be noir, and while noir may feature corrupt cops and an edgy hero/cop relationship, they’re usually not fair game for beating up.
  • No Catwoman.  (Though there’s a cute reference in the GCPD.)  It’s a pity, because AC really benefitted from having an additional playable character, and such a fun one.

Hard to get used to, but defensible: combat is much harder than AC.  The biggest change is subtle: the mooks hit you a tad earlier, which is just enough to screw up my AC-honed skillz.  If you wait till the “gonna attack” symbol is big, it’s too late.  You have to hit faster, or evade.

In the same category, it’s weird that there are some places that are too tall to grapple up to.  It makes sense that the line isn’t infinite, but it’s an unexpected change from AC.

Some good stuff:

  • After a punishing fight with Bane, he turns into a Titan.  I was expecting an even more grueling fight… but it turns out to be a predator encounter.  Awesome: the last boss fight requires stealth rather than power or gadgetry.  The single best design decision of the game.
  • Oracle does return.  The whole Gordon arc is pretty good.  He’s maybe maybe too stubborn, but after all it’s just one long night in Gotham, he’s not going to change quickly.
  • Similarly, we see more of Alfred.  Though the dude is right: even Batman has to eat.  If Batman has time to respond to random crimes in progress, he has time to grab a turkey leg and a beer.
  • If you let him, Anarky will jaw at you forever.  Although I can’t approve of the terrorism thing, he actually makes some good points about Batman’s weird insistence on going it alone, and his complicity in keeping a corrupt system pretty much the same.
  • The shock gloves feel slightly cheesy, but hey, they’re fun.  As the combat is harder, it’s great to have something to equalize it.
  • The crime scene re-enactments are one of WB Montreal’s few extensions to the Rocksteady basics.  It’s a nice mechanic and I’d like to have seen more of it.
  • The Quincy Sharp appearance at the end is cute.

That’s enough for now.  I’m not sure if I’ll do all the Riddler challenges this time, but the extra challenge maps do beckon, and there are a few loose ends to tie up in Gotham…

I keep plodding along at my (unnamed) Unity project, and it’s starting to kind of look like a game.  Here’s what it looks like right now:

shut up

Are you hungry? I hope not, because I haven’t modeled any food

There’s a few new things here, like the fire in the fireplace and the water in the pool, but mostly it’s modeling, modeling, modeling.  When I was using Hammer I could use Half-Life 2 assets, but here I have to do everything myself: the house, the furniture, the girls.  There’s even a little knife and spoon on the table.  All of these are modeled and animated in Blender, then textured.  (Yes, the furniture gets animated: doors, chests, and wardrobes open and close.)

I’ve learned some tricks to speed up the building and texturing– e.g., I built a single plank of that barrel, textured that, then replicated it to form the cylindrical shape.

Here’s what the whole house looks like so far.  Compare to this picture.  The only major furniture that’s missing is some shelving; I actually won’t model everything in the linked picture because it would get too full to move around in.  (Video game rooms are abnormally large and empty.)  However, there will be a lot more set dressing (pictures, candles, chamberpots, etc.).

talk

I should probably add a roof

I started to build walls and such in Unity, but the texturing got too complicated, and anyway there are too many fiddly details (like those closets).  So this is all models.  It’s easier to mock up buildings in Hammer… on the other hand, things like doors are far easier in Unity, since they can be duplicated at will.

More excitingly, there’s a dialog system now, and I have a story!

My main notion is to concentrate on depth rather than breadth.  The anti-model here are games like Far Cry 2, or Remember Me— gorgeous environments where the only things you can interact with are ammo and health packs.  Skyrim comes closer to the ideal, as you can pick up and drop objects, as well as use the forges and cooking pots.

For the dialog, I want to get past the thing where you have three dialog options, normally corresponding to aggressive, nice, or neutral, and half the time your choice doesn’t even matter.  Besides, if there’s just three choices, you can always just pick one and reload if it worked out badly.

In this game, you’ll take one of a dozen or so approaches– e.g. anger, naivete, flirting, curiosity, intimidation, probing.  The clever bit is that the more powerful approaches can only be used once per game.  So you can intimidate, or seduce, or kill, one NPC.  Hopefully this will make you think about which character to do what with.

Plus, there are actually three possible stories, and the same characters are involved in all three.  Ideally details of the story will randomly change between playthroughs, so a) you can play more than once, and b) there is no one right path through the game.  (So, think Skyrim meets The Stanley Parable.)

Will this work, or be fun?  I don’t know yet!  At this point there’s just a lot of modeling and dialog writing to do.  I was mostly trying to see how far I could get with Blender/Unity and wasn’t worrying about whether it would turn out to be a game or not.  So I’m happy to at least have a plan for the game.

I’m also really tempted to record the dialog in Verdurian (with on-screen translation), which is either an awesome or a terrible idea or maybe both.

An alert reader asked what, as a software developer, I thought devs should learn from the healthcare.gov fiasco.  It’s a good question!  I don’t know what systems are involved and of course have no insider information, but I think some general lessons are obvious anyway.

1. Program defensively. According to early reporting, the front end and back end were developed by different firms which barely talked to each other.  This is a recipe for a clusterfuck, but it could have been mitigated by error handling.

The thing is, programmers are optimists.  We think things should work, and our natural level of testing is “I ran it one time and it worked.”  Adding error checking uglifies the code, and makes it several times more complicated.  (And the error checks themselves have to be tested!)

But it’s all the more necessary in a complex situation where you’re relying on far-flung components.  You must assume they will fail, and take reasonable steps to recover.

An example: I managed– with difficulty– to create an account on healthcare.gov in early October.  And for three weeks I was unable to log in.  Either nothing would happen, or I’d get a 404 page.  The front end just didn’t know what to do if the back end refused a login.

Oops, I’m anthropomorphizing again, as devs do.  More accurately: some idiot dev wrote the login code, which presumably involved  some back end code, and assumed it would work.  He failed to provide a useful error message when it didn’t.

Now, it’s a tricky problem to even know what to do in case something fails!  The user doesn’t care about your internal error.  Still, there are things to do:

  • Tell the user in general terms that something went wrong– even if it’s as simple as “The system is too busy right now”.  Be accurate: if the problem is that an external call timed out, don’t say that the login failed.
  • Tell them what to do: nothing?  try again?  call someone?
  • If you’re relying on an external call, can you retry it in another thread, and provide feedback to the user that you’re retrying it?
  • Consider providing that internal error number, so it can be given to customer service and ultimately to the developers.  Devs hate to hear “It doesn’t work”, because there’s nothing they can do with that.  But it’s their own fault if they didn’t provide an error message that pinpoints exactly what is failing.
  • In a high-volume system like healthcare.gov, there will be too many errors to look at individually.  So they should be logged, so general patterns emerge.
  • Modern databases have safeguards against bad data, but it usually takes extra work on someone’s part to set them up.  E.g. a failed transaction may have to be rolled back, or tools need to be provided to find bad data.

2. Stress-test.  Programmers hate these too, partly because we assume that once the code is written we’re done, and partly because they’re just a huge hassle to set up.  Plus they generate gnarly errors that are hard to reproduce and thus hard to fix.

But pretty obviously healthcare.gov wasn’t ready for large-scale usage on October 1… which means that the devs didn’t plan for that usage.

3. Provide tools to fix errors.  I called a human being later on– apparently human beings are cheap, I didn’t even have to wait long.  I explained the problem, and the rep (a very nice woman) said that they were using the same tools as the public– the same tools that weren’t working– so she couldn’t fix the problem.  D’oh.

Frederick Brooks, 38 years ago in The Mythical Man-Month, answered the common question of why huge enterprise systems take so long and so many people to write when a couple of hackers in a garage can whip up something in a week.  Partly it’s scale– the garage project is much smaller.  But there are two factors that each add (at least) a tripling of complexity:

  • Generalizing, testing, and documenting– what turns a program that runs more or less reliably for the hackers who made it into a product that millions of people can use.
  • A system composed of multiple parts requires a huge effort to coordinate and error-check the interactions.

Part of that additional work is to make tools to facilitate smooth operation and fix errors.  It’s pretty sad if healthcare.gov really has no way of fixing all the database cruft that’s been generated by a month of failed operations.  There need to be tools apart from the main program to go in and clean things up.

(I was actually able to log in today!  Amazing!  So they are fixing things, albeit agonizingly slowly.  We’ll see if I can actually do anything once logged in…)

3. I hope this next lesson isn’t needed, but reports that huge teams are being shipped in from Google worry me: Adding people to a late project makes it later. This is Brooks again.  Managers are always tempted to add in the Mongolian hordes to finish a system that’s late and breaking.  It’s almost always a disaster.

The problem is that the hordes need time to understand what they’re looking at, and that steals time from the only prople who presently understand it well enough to fix it.  With a complex system, it would be generous to assume that an outsider can come up to speed within a month, and in that time they’ll be pestering people with stupid questions and generally wasting the devs’ time.

As a qualifier, I’ve participated in successful rescue operations, on a much smaller scale.  Sometimes you do need an outside set of eyes.  On the other hand, those rescues involved finding that the existing code base, or part of it, was an unrecoverable disaster and rewriting it.  And that takes time, not something that the media or a congressional committee is going to understand.