Anyhow.  At a similar time to when I started using vim, I started experimenting with using git, rather than subversion, for source control.  This wasn’t for any special reason, just that I’d been learning a little git (since it’s very popular amongst vim users), and wanted to make a lightweight repository for tracking changes to my Vim preferences.  And then for fun, I imported the MMORPG Tycoon 2 history into git

For me, the best feature of git, compared against subversion, is the ease with which it handles branching and merging, which were always at least mildly painful under subversion.  With git, though, it’s so easy to maintain separate streams of development that suddenly, I’m finding that I can work on several features at once, each separately from each other.  The screenshot above shows a graphical view of the current MMORPG Tycoon 2 codebase.  Right now, I have four different feature branches running, some for core features (“context” is for figuring out how to handle the context actions which I’ve previously shown in a “context matrix”), and some experimental (“duothreadman”, which is doing comparitive performance testing by maintaining two separate pools of threads, so that a glut of low-priority tasks can’t clog up the task queue).  If a feature branch works out well, I can merge it back into the master branch.  If not, I can just delete it and it doesn’t clutter up my repository any more.

Under git, it takes a fraction of a second to create a new feature branch, or to switch from one to another.  These operations would have taken several minutes each under subversion, and been major undertakings which had to be carefully considered and executed.  But they’re trivial now;  not even worth spending time thinking about.  Just make the branch, and delete it later if it turns out to have been a bad idea.

This sort of flexibility means that when I’m feeling blocked on one task, I can easily set it aside and work on a different task, without having to struggle to keep the two sets of changes distinct from each other.  And that’s tremendously freeing.

To begin with, I should again mention that I’ve been in the commercial video game industry (with one recent six month break) continuously for the last fourteen years;  that’s more or less since the first accelerated 3D cards hit the market.  My comments in this post (and indeed, all the rest of this site) reflect only my own opinions, and not those of any of the fine people who have employed me or with whom I have worked in this time.

I should also mention, just as full disclosure, that there was a point where I might have gone to work on L.A. Noire during the latter half of its seven year development timeline, and that I now know and work with people who did work on various parts of this game.  I’m not going to go into any of those details, but I thought I should put it out there just as fair warning, so that people can take the following comments with any grains of salt they feel are deserved.

Full discussion is below the fold.

At its core, L.A. Noire is what I call a “kitchen sink” project;  a project which is defined by a bulleted list of unrelated features.  ”Kitchen sink” projects are typically started by a designer (or set of designers) brainstorming all the features they can think of, writing them down, and then telling workers to go and implement them all, without ever considering how those features fit together into a coherent game.

These sorts of projects usually can never be completed, because they were never considered as a game in the first place, only as a list of bullet points which each on its own would be “cool”, and so therefore must be even more “cool” when taken in aggregate.  As a result, development gets stuck in a loop of “the game isn’t fun yet”, “well, maybe if we add Fun Feature <X>, that’ll make it fun”, “no, it still isn’t fun yet.”   As a result, they usually either get cancelled for simply taking too long to complete as feature after feature is added to the list, or else they get dramatically cut down into a more manageable feature set, in order to cut the losses and just release anything.  L.A. Noire (apparently) did neither of these.

So yes, to me it’s surprising that L.A. Noire took seven years to make;  it surprises me that it could be completed at all, much less that it would be completed in just seven years.  Most development studios could not ship this game in any amount of time.  And there’s some amazing stuff in it.  But to be honest, the game is a mess.  An eclectic jumble of the awesome and the awkward and the beautiful and the buggy.  It is not at all (in my mind) a candidate for “game of the year,” but it absolutely is a signpost which, from now on, every other video game will have to measure itself against.

So.  From my vantage point up here, high atop the majestic VectorStorm tower, this is my rundown of what’s notable in L.A. Noire:

Facial motion capture

Yes, this is by a substantial margin the best facial motion capture we’ve yet seen, and it’s the main reason why people are talking about L.A. Noire.  The facial acting is definitely on the north face of the “uncanny valley”, occasionally even climbing fully into the “this looks just like television” category, which is pretty much unheard-of in realtime video games, and is a major achievement.

It’s just a pity how little attention was spent on hats, given how much time those near-photographic-quality-heads spend next to single-color hats which are made from 200 triangles and don’t properly fit.

The facial motion capture, more than anything else, is why L.A. Noire is Babylon 5.

Back in 1994, Babylon 5 was the first thing out there making substantial use of computer generated special effects instead of traditional physical models, and it looked stunning at the time.  But Babylon 5 inspired people to realise the possibilities in those effects, and everyone built on those first steps so quickly that it’s difficult to take the special effects from Babylon 5 seriously any more;  they just look so primitive by modern standards.

Similarly, L.A. Noire is the first to do high quality facial motion capture, and it’s completely revolutionising what everyone else thinks is possible in the medium.  And as a result, there’s going to be a lot of innovation in a very short period of time, and L.A. Noire is almost certainly going to look quite staggeringly dated in just a few years.

So play it now, while it’s fresh.  Because this technology isn’t going to be notable two years from now, and in fact will probably look quite dated. (caveat:  unless the mainstream video game industry crashes before then).

Plot

The game has a plot targeted exclusively at grown-ups, which is extraordinarily rare for video games.  It does stray into the gratuitous several times, but the writing is substantially better than the norm for video games.  I’m really not going to say any more on this, because anything else I said would put me in serious spoiler territory.  Let me just say that for me, this is the real thing that makes L.A. Noire notable and worth playing, far more than anything else I pick out in this discussion.

And I really wish that development studios would be inspired by this crafted, intelligent plot and mimic this, instead of fixating on the facial motion capture.  But I’ve been in the industry for long enough to know which of these two features gets publishers and marketing departments excited.

Out-Phoenix Wrighting Phoenix Wright

The detective work in L.A. Noire is heavily inspired by Capcom’s GBA/DS game series, Phoenix Wright.  In structure, it’s nearly identical.  But L.A. Noire improves on Phoenix Wright in one major way:  In Phoenix Wright, every story was strictly linear;  you were stuck in every conversation until you found every contradiction in what you were being told.  If you couldn’t figure out a contradiction to press a witness about, then you couldn’t leave that conversation, and would eventually lose the game if just guessed at random.

In L.A. Noire, the stories branch (to a certain extent).  The actions you take change what happens next, and even if you don’t realise that a particular piece of evidence contradicts what someone has told you, you can simply continue on with the conversation, and still reach the end of the case, often still with a correct outcome due to receiving the same (or similar) evidence in some other manner from some other character.

Both games are based around simple prepositional logic;  ”I know A, he says B, so therefore he is lying, and I can show him A as proof that he’s lying”.  This works great when there are simple cases and simple lies.  In practice, though, this stops working as cleanly once cases become more complicated.  Often you end up with several different pieces of evidence which could each equally apply as “proof of lying” for a particular statement (say, I have evidence A1, A2, and A3, each of which contradicts statement B), but the game only recognises one of them (say, it only recognises A2 as the contradiction, and penalises you if you try to present A1 or A3).

In the case of Phoenix Wright, this is almost a game-breaking problem in some of the more complicated cases;  you’re left to try to apply every piece of evidence to every possibly-incorrect statement until you find the combination that the game will accept.  L.A. Noire’s approach of only letting you try only one thing and then moving on makes this far less frustrating.

Although it’s still frustrating.  You’re still punished for not magically knowing which of the relevant pieces of evidence the game was thinking of.  But at least you’re only punished once, instead of forever.

Needless to say, there’s still a lot of room for someone to further improve on this game mechanic, in future games.  But this is a big step forward.

A game that isn’t about shooting, except when it is

At the moment, in the same way that pretentious know-it-alls will claim that there are only three plots for stories, I’m claiming that there are currently only three genres for mainstream video games.  These three genres are:  Killing, Racing, and Sports.  Virtually every mainstream game that’s made these days fits into one (and only one) of these three genres.   (Note:  casual and mobile games include a lot more genres;  it’s only the mainstream boxed product that has atrophied to this state, thus far)

So it’s always refreshing to have a game which is about something else, something we haven’t seen a dozen times already this month.  The problem is that… well… L.A. Noire doesn’t really know what it’s about.  Progression in the game is tied to its investigation and interrogation modes, and those are quite novel, as I said above.  But on the other hand, the game is continually putting the player into cover-based shooter sequences.  Which isn’t necessarily a bad thing, I suppose.

The problem is that L.A. Noire’s gunplay just doesn’t feel right.  There are several reasons for this:

1. Awkward controls.  (R1 either runs or shoots, depending upon whether you’re holding L1 before you pull R1.  And depending upon whether you’re in a game mode which allows you to shoot.  Which, incidentally, the game won’t tell you until after you’ve actually tried to shoot.)
2. Awkward camera.  (L1 auto-targets, except when it doesn’t work.  Manual targeting has too much momentum to allow precision aiming.)
3. Awkward cover. (The mechanism for moving from one piece of cover to another isn’t intuitive or consistent.)
4. Bad pathing + AI.  (Not much else to say about this one)
5. Awkward conclusion.  (After defeating enemies, we’re left looking at the player from an awkward angle, doing nothing, for the duration of a slow fade out, as though we had completed the level in an unexpected, non-optimal way.  We then are shown an unsatisfying cinematic closing out the gunplay sequence, usually of the player watching bodies being loaded into a vehicle and being taken away)

I would be jumping up and down with glee about all of these things if the game was doing them intentionally as part of taking a “this is not supposed to be a game about shooting” stance.  In the mid 1980s, Chris Crawford wrote a masterful cold war game, Balance of Power.  In that game, if the player brought tensions up to the point where World War 3 was declared, the game displayed a simple text screen which read: “You have ignited a nuclear war. And no, there is no animated display of a mushroom cloud with parts of bodies flying through the air. We do not reward failure.” Game over.  How great would it be for a game to intentionally make its gunplay unsatisfying, because at the end of the day, it was trying to get the player to approach the conflict differently, and didn’t want to be a game about shooting?

But sadly, I really don’t believe that these things are there intentionally, consciously designed to prevent the player from feeling like he has received a reward.  They just feel like the game is unpolished.  These are all the usual places where games are difficult to polish;  it seems much much more plausible to me that this is just one of the game’s rough sides.

Especially since they immediately undercut any possible “shooting a criminal is sometimes necessary, but doesn’t deserve a celebration” moral of the story by keeping score and displaying how many times you’ve done it.  (And I haven’t checked this, but I’d be mightily surprised if there wasn’t an achievement/trophy for fighting through all of them)

A free-roam mode that isn’t.

In most games with an open world, the “free-roam” mode serves as the central hub for all gameplay.  You go to and from it, between the various other game modes, and there are plenty of things to do within the “free-roam” mode as well.  In any game with this sort of massive free-roam world, most of the development time goes into building this large and open world.  There is a lot of tech that goes into supporting this, and a lot of art (and often tech as well) that goes into populating it.  So normally, development teams want to get the most bang for their development buck as possible.

But in L.A. Noire, you can completely skip the free-roam mode;  at all times, you have the ability to quick-travel to the next game segment that you’re supposed to take part in.  That, combined with the lack of things to really do in the free-roam mode (apart from enjoy the recreation of historic Los Angeles), makes this mode feel kind of pointless, like it’s just a time-sink.  Which is a shame, because it’s very clear that a huge amount of work went into crafting this depiction of historic Los Angeles.

Now, there are a few things you can do in free-roam mode;  you can find hidden cars, you can find notable landmarks, and you can respond to a limited number of police alerts (see “A game that isn’t about shooting”, above), but that’s about it.  The hidden cars are even helpfully marked on your map before you find them, so you can quick-travel to their locations instantly.  Neither finding the hidden cars nor discovering the landmarks nor completing the police alerts are relevant to the game;  they are simply bafmodads for completionists to collect.

I find myself wondering:  How much faster could this game have been finished, if the development team had focused on just making the parts of the game which are actually required for the game, and not on everything else in the periphery?

Global illumination

I’m not even sure why I’m mentioning this.  But apparently L.A. Noire is one of the first games out using a global illumination model.  To my eyes, the lighting looks terrible, unless you squint or you’re television is really blurry or covered in vaseline or something, in which case it probably looks pretty awesome.

I think it’s just a problem of resolution;  it looks like they’re doing a weird dithering filter to try to hide how blocky it is.  Maybe this will really be ready for prime time on the next generation of consoles.  Or maybe it’s just me slowly morphing into a visual effect programmer and going all graphic snobbish.

Community Features

I’m not a huge fan of inserting social media features into games.  The whole “tweet this?” or “post this to facebook?” thing that’s showing up everywhere is a pretty transparent advertising ploy that just feels a bit gauche to me.  (On the other hand, it apparently works, so by even mentioning it I’m probably just marking myself out as an old man shouting at kids to stay off his lawn).

But I love this one thing that they’ve done in L.A. Noire, where you earn points which you can use to “ask the community”.  If you’re having trouble deciding how to best reply to a statement from a witness, you can spend a point to ask the community what to do, and you’re told the percentages of how many people chose each of your options.  Additionally, you’re told that of those who had asked the community, how many chose the correct option after seeing those percentages.  I really love this, and wonder how it could be incorporated  into other, deeper game situations.  There’s a big possibility here for building a sense of community in a concrete game-relevant way, far more meaningful than simply getting people to advertise you to their friends list.

In a way, it’s similar to the bloodstains from Demon’s Souls, but more reliable (and with a built-in estimate of its own reliability, too!)   To my mind, this “ask the community” button is the single most intriguing piece of game design in L.A. Noire.

Black & white mode

I’ve mentioned before that I once worked on a 3D game using a Looney Tunes license, where I argued vociferously against including any real-time lighting, in order to emulate the flat look of the original cartoons.  I still believe that that was clearly and obviously the right look for the game, even though we could easily have lit the characters in real time if we had wanted to.  Similarly, L.A. Noire should have been presented in black and white, even though they had the ability to present it in color.  Black and white is clearly and obviously the right choice for this game, for exactly the same reason that Bugs Bunny should not be drawn with CGI-style lighting.

Now, L.A. Noire does provide an option to play it with black and white graphics (and it does a fantastic job of balancing contrast to keep everything visible), but sadly, the game is not truly playable in that mode, since often you’re called upon to make fine distinctions which rely upon color.  This is particularly the case during trailing and chase sections of the game.  So you are forced to return to the options screen and to turn color back on, every time you reach one of these sections.

I would suggest that the game should have played entirely in black and white, but with a small amount of a pale color (perhaps in a flower or a carried bag), wherever necessary to act as visual cues during these sections where you need to be able to pick an individual out of a crowd, similar to how Spielburg used that technique for the same purpose in Schindler’s List.

And while I’m on the topic of “my opinion is objectively right and everyone else is stupid and wrongheaded”, Red Dead Redemption ought to have ended five minutes and one mission earlier than it did.

Yeah, I said it.

It’s something that I’ve always wanted to do, and have been thinking about more and more since leaving Krome.  As somebody who’s been a gameplay programmer for more than twelve years, I think I’ve accumulated some insights over that time, which might be of use to other game makers out there.  So far, when I’ve posted things like this, they have been in the form of essays posted to this blog, but they’ve always felt really dry to me.  A podcast might work better, but in this field many concepts need to be accompanied by animated visual aids.  So a vodcast might work, perhaps.  I don’t think that my internet connection is up to attempting a live ustream show (although if it was, that would probably be the ideal forum, so the thing could be a little more interactive).

If I do this, it wouldn’t be a “how to create a game” tutorial; instead, it would be targeted at people who can already make games (or are learning via some other avenue), and would be about the more nuanced craft involved, regardless of what platform, language, or toolkit you’re working in.  It would cover the principles of camera behaviour (in 2D and 3D), the design of control schemes, user interface issues, general fit and finish, and so forth.  And of course, it’d be available for free to anyone who was interested, whatever form it eventually took.

What do you guys reckon?  Is this something you think people would be interested to see?

In MT2, “status effects” are implemented as little blobs of code that can be attached to individual characters.  They get run periodically, and can affect just about anything on a character.

For example, right now I’m using them to implement Damage over Time (“DoT”) and Heal over Time (“HoT”) effects.  In the future, I’m planning to use them for movement speed adjusters (for roots/stuns, mounts, travel powers, etc.)  Eventually, you’ll be able to set whether or not they should be allowed to “stack” (although that’s not yet been implemented).

By adding the concept of status effects on characters, I’ve managed to drastically simplify the combat ability code;  there are now only two types of combat abilities (down from four);  there are “instant” abilities, which do their thing immediately when you click on the button, and there are “toggle” abilities, which do their thing periodically for as long as they’re left turned on, and can have yet more effects when they’re turned off again.

Now, there are plenty of combat abilities which don’t fit into this model.  Games like WoW have “channelled” ability types, which are a “toggle” ability with a maximum duration (and a requirement that you not move while using the ability).  Champions Online has a “charged” ability type, which is an “instant” ability that triggers when you release the button, instead of when you press it, and the length of time you spend pressing the button before releasing it determines the strength and cost of the ability.  But I think that for now, just “instant” and “toggle” will do me;  those capture the most important ability types, especially now that I’ve got support for DoT and HoT abilities using “instant”.

I’ve got a couple of housekeeping engine things that I need to get done eventually.  Folks who’ve looked at the VectorStorm library code will likely have noticed that I have a “vsLinkedList” class, which is similar to std::list.  I also now have a “vsArray” class, which is similar to std::vector.  I also have a “vsLinkedListStore”, which will only hold pointers, and automatically deallocates all of the items inside of it, when they’re removed from the list (or the list is destroyed).  I need to implement a “vsArrayStore”, which will do the same thing;  store pointers to its contents in an array, but delete those contents if they’re removed from the array.  I have a  hacked-together implementation of this layered around a vsArray, but it’s not done properly;  there are just too many ways to leak memory if you’re not being careful.  So I need to make a proper “vsArrayStore”.  Will do that tomorrow.  After that, I need to really buckle down and start writing the AI to create combat strategies.

Side-topic:  Toward the end of last week, a few friends and I (finally!) finished Halo: Reach.  It took us three play sessions, probably about 6-7 hours in total.  I keep being surprised at the number of distinct game styles and modes in the Halo campaigns.  Vehicles and situations which appear only once in the game (often for very short periods of time), and then are gone again.  And yet they have their own tutorial sequences to teach you to use them.  I haven’t really decided whether this is a case of expertly using a gameplay element for only precisely as long as it feels “fresh”, or whether it’s just unfocused kitchen-sink game design.  I have trouble believing that there’d be that garden variety “kitchen-sink” design going on in Halo, though, just based on how much groundbreaking, still-never-been-matched design work has been done in the series (I’ll write about this someday, I promise), but sometimes I wonder..

I’ll also confess that for me, the Halo: Reach storyline remained as impenetrable as ever.  It wasn’t until the final moments before the end credits that I even realised that we were in a prequel.  I don’t know;  for a game series as cinematic as Halo, I think I’d appreciate it if its storyline was a little more coherent.  On the other hand, difficult-to-decipher plots have been a staple of Halo since it was Marathon, so it’s obviously been working for them.

As I mentioned in an earlier post, I think that for me, Reach worked because it was something to do with friends.  This puts playing it in the same category with going to a movie or out to a pub.  Or, for that matter, playing Mario Party.  They can all be great fun in a group of friends, but not (for me) on their own.  Certainly Halo ODST (which I had a short stab at solo, earlier today) isn’t feeling fun to me by myself.  By comparison, I can have a lot of fun playing Team Fortress 2 without bringing friends into it.

What do you guys reckon?  Does the Halo campaign work as a solo game, for you?

Maxis

My first job in the games industry was at Maxis, in the financially-gloomy days shortly before it was purchased by EA.  I was working in QA there, about two meters from (and with clear line-of-sight to) Wil Wright’s glass-fronted office.  In those days I mostly remember him sitting in his office, by himself, looking sad.  I felt bad for him.  I never went to introduce myself.  I was, after all, only a temp in QA.  To this day, I regret not having talked to him.

Wil Wright had a reputation for starting every company meeting with a shaggy dog story, which he would invent on the spot.  I was told that sometimes these would reach a fantastic conclusion, and sometimes they would just eventually stop.  I only had occasion to hear him do this once, on board a ship he had chartered for the meeting where he was telling us about the possibility of the EA buyout.  I don’t remember how his shaggy dog story ended.  I wish I did.

In any case, I well remember thinking, as I was walking to my car at the end of my second day of QA work at Maxis, “I can see myself eventually getting really tired of this job”.  And at the end of my third day of work, “I’m really tired of this job.”  But I stuck with it for six months, met some really neat people, made (what seemed to me at the time) an awful lot of money, and received the best advice that anyone has ever given me:  to work abroad while I was young, if I had the chance.

During my time at Maxis, I was credited on “Streets of SimCity”, and also tested SimMars (never released?), SimSafari, and the infamous SimCity 3000 prototype which was the star player at the center of Maxis’s financial woes.

Trivia:  In “Streets of SimCity”, on the date of our first release candidate build, I found a bug where if you created a new player and named him “*”, it would delete all of your existing saved games.  I was a hero, that day.

At Maxis they had a network server which contained installers for every game they’d ever built, whether actually published or merely prototypes, and everyone was encouraged to install and play these games during lunch breaks or after work.  Amongst the fantastic games (I loved Marble Drop), there were a few particularly notable ones.  One, “Fractured”, was a turn-based strategy game played on a procedurally shattered stained glass window.  It seemed to be a fully functional prototype, complete with network play and AI.  And it was fantastic, but sadly (to my knowledge) has never seen the light of day outside of Maxis.  Another, “SimDollhouse” was the game which eventually, post-EA was to be resurrected and become The Sims.  When I saw it, it was basically Little Computer People, where you could build the house that a family lived in.  One of my co-workers told me that it had been there on the server for more than six years;  that it was just another failed prototype.

Eventually, my chance came to work overseas.  A development studio called Beam Software, or else called Melbourne House (which name they used seemed to depend upon the day of the week) wanted me to come out and write the software 3D renderer for an oddly named racing game they were writing, DethKarz.  However, due to the complexities of working out visas, by the time I got there DethKarz was already complete, and I was instead put onto a little shooter project called “BioTech” or “BioTek” (also, seeming to depend upon the day of the week).

Infogrames Melbourne House

After a few months on “BioTek”, it became clear that Melbourne House was in financial difficulties, and the whole company was likely to shut down.  However, at the last moment we were purchased by Infogrames, just one of a whole slew of development houses they were purchasing at the time.  Infogrames cancelled “BioTek” very quickly, but took a lot of time to decide what we should actually be making instead.  So during the down-time before work started up as Infogrames Melbourne House, I invented a scheme for doing real-time cel shading, and made a few demos of it.  On the basis of that cel shading technology, Infogrames Melbourne House was given the opportunity to make Looney Tunes: Space Race (video) for the Dreamcast.  It’s notable that this was the second released game to use cel shading (reaching store shelves just a few months behind Jet Set Radio).  So on the one hand, I’m disappointed that we weren’t first.  But on the other hand, maybe that means I’m not entirely to blame for the glut of cel shading effects that were to follow for the next several years.  I also wrote the game’s animation system, wrote all of the character behaviours, as well as the weapon effects.

Together with the animators, I strongly argued for the “no directional lights” artistic policy which resulted in the characters being flat-shaded, making them look so much like the hand-drawn characters that Warner Brothers’ games division decided they weren’t qualified to approve the characters.  To get our character models approved, we had to go through Warner Brothers’ cartoon and movie licensing groups instead.  This led to some fun exchanges, such as when the cartoon licensing group objected that in our game it was possible for Bugs Bunny to lose a race, and that ever losing at anything would be completely out of character for him, so could we fix that please.

While the game is now showing its age, and in hindsight there are some very obvious rough spots (that HUD;  what were we thinking??), I’m immensely proud of what we managed to accomplish under the constraints.

After the game was shipped, I was (probably quite rightly) taken to task for having “hijacked” the project;  having steered its design quite strongly, even though I was only a junior programmer.  There was no raise for me that year.

Trivia:  Space Race was the first game to use Melbourne House’s new “Vertigo 2″ game engine.  In fact, for the first half of development we used Sega’s game engine (which was supplied with the Dreamcast development kits), and only transitioned over to Vertigo 2 halfway through development.  Switching between game engines in the middle of development is a highly unusual and often dangerous thing to do, but it was totally worthwhile in this case;  our engine was both higher-performance and more flexible than the Sega-provided one.

Trivia2:  Space Race was also one of the first video games to make extensive use of inverse kinematics, which allowed me to freely move the characters around on their vehicles, while still keeping the characters’ hands and feet on the controls.  It even allowed me to give Marvin the Martian’s flying saucer real moving control levers, without requiring us to make special “steering” animations for him.  Each character in Space Race had six sets of inverse kinematic information, and interpolated between them based upon what they were currently doing (some were relative to their vehicle for when driving normally, some were relative to their head for when carrying a gag, etc).  More than anything else, it was the combination of inverse kinematics, advanced animation layering, and physics-driven animation bending that gave the characters such a fluid, expressive appearance.

Trivia3:  We had a secret “instant martian” character built and working for the game, but couldn’t actually include it in the final build because it hadn’t been sent to Warner Brothers for approval in time.  A fez and vest were eventually added to this character (for reasons that were never clear to me), and it was included in the later PS2 port (which I wasn’t involved with).

Trivia4:  Players often wonder about the odd frequency of “falling object” weapon pickups in this game.  Toward the end of development, we realised that I just wasn’t going to be able to finish many of the planned weapon pickup concepts in time, and so several types of weapon were replaced by yet more variants of the “falling anvil” gag, which only required a new model and no new code and so were much faster for us to create.

Trivia5:  The introductory real-time cutscene (video) we shipped on the Dreamcast discs was actually the wrong version of the cutscene;  it was about two weeks old, and my code managing that sequence was just silently coping with the errors in the data as best it could.  This single incident convinced me that “fails early and loudly and with as much detail as possible at even the slightest provocation” is a far superior approach than “robust and reliable, won’t crash no matter what,” and has guided my system design philosophy ever since.  With that said, the difference was subtle enough that I don’t think I’d ever have noticed this mistake if one of the animators hadn’t pointed it out to me years later.

Trivia6:  During development, I had a one week vacation in which I was supposed to be relaxing.  But in fact, I spent most of that vacation writing what I called the “Bugs Bunny Ear Physics Simulator” on my laptop; an attempt to figure out the maths involved in making nice and responsive ear behaviour for Bugs Bunny, when he’s sitting on an object that could rapidly accelerate and decelerate.  Variants of this code were eventually also used for Elmer’s scarf, Sylvester’s tail, Yosemite Sam’s moustache, and possibly a few other things that I’ve forgotten about.  But Bugs’ ears were definitely the most difficult to get right.

Trivia7:  During development, we inadvertently destroyed three Dreamcast development kits, due to a known (but never addressed) electrical issue with their video cables.  Two of those destroyed kits were entirely  my fault.  Sorry, guys!

After Looney Tunes, we started work on a Men-In-Black-licensed game, “Alien Escape“, which was originally supposed to just be set in the same world as the Men-In-Black movies, but eventually became tied in with the Men In Black 2 film, with the same protagonists and some of the same villains.  Which was tricky, because we had virtually no information about the film during development;  only a few photos and character names, and virtually no storyline information.  In this game, I was responsible for coding the visible player behaviour, and for scripting all of the boss encounters.  I remember feeling at the time that I wasn’t getting enough design direction, and that I had to design the specifics of each boss encounter by myself, and I really wasn’t very happy with the designs I eventually settled on.

This was the first and only “death march” project I’ve ever been a part of, with mandatory 12-hour days and 6-7 day weeks for the last several months of the project (as I remember it — actual facts may differ).  At the end of the project, those of us who were still with the company were given black “I survived” mugs.

Trivia:  I took one of the final release candidate builds home to show to some gamer friends of mine.  None of them could survive the initial alien encounter and escape the very first room of the game.  The game was brutally difficult; a side-effect of having had virtually no gameplay tuning based on anyone but our elite QA department.

Trivia2:  Most of the game flow was to block the player into a small area of the game, fight some respawning bad guys until they stopped respawning, then unblock the player so he could progress, and then block him into the next section with more respawning bad guys, and then repeat until the player reached the end of the level.  The mechanic we used to block the player was a magic blue ribbon with scrolling text on it, which was intended to look like a sort of futuristic police tape.  From this point on, anything in any game which inexplicably blocks the player’s progress until the player defeats enough monsters is referred to as “mib tape”.

Atari Melbourne House

At about this point, Infogrames acquired the rights to the name Atari, and switched their name, and so we became known as Atari Melbourne House.  During this time, I worked on the 2004 PS2 game Transformers (video), where I was responsible for robot-mode and glide-mode player control, the camera behaviour, and I designed and implemented the final boss fight against Unicron (video).  Apologies to everyone for that final boss fight;  it was entirely designed and implemented in the last six weeks before shipping, and without much time available from the artists to create extra art assets or animations for it;  I’m sure there must have been something better I could have done within the limitations I had, but I still don’t know what it would have been.  (Thuyen came up with an awesome design for this final level;  I wish I’d have been allowed to use it.)

The most notable thing about Transformers is the visuals that we were able to achieve, thanks to our evolving graphics engine, Vertigo 2.  The visuals it was putting out were favourably compared against even the modern XBox games such as Halo, which were coming out at the time.  I can’t praise our engine team strongly enough;  they pulled out some fantastic tech to support this game.

Trivia:  I believe that Unicron is the largest boss in any video game ever made.  He’s a little over 13 kilometers in diameter (In this level, Cybertron is a complete sphere, about 25 kilometers in diameter).  This whole sequence would have been completely impossible without the amazing efforts of the engine team and our lead graphics coder, Simon.  I’m in awe of you guys.  But with that said, Unicron isn’t the large boss that people remember from the game.  People quite rightly remember the Tidal Wave boss fight, which was so epically implemented by Keir.  Hats off to you, too, Keir!

Trivia2:  When gliding in most levels, the camera never banks to match the player’s banking, the way it does in most flying games.  This is because our graphics tech for drawing trees was so highly optimised that it didn’t support drawing distant trees in any orientation other than perfectly vertical on the screen.  This was a source of considerable disappointment to me.  (Thankfully, there were no trees on Cybertron, so I could bank the camera there).

Trivia3:  In the Unicron boss fight, the player is moving so fast that the player’s flight model needed to be updated 200 times per frame, just to keep from exploding due to the magnitude of the forces involved.  Luckily, there wasn’t much game logic going on in that level, so the PS2 had plenty of CPU time available for updating the flight model so many times each frame.

Trivia4:  Transformers used a technique we called “betwixt”, to make everything appear to be rendering at 60fps, while the game was only actually drawing 30 times per second.  In effect, we were taking advantage of the common interlaced television signals of the day; televisions would first update half their scanlines, and then 16 milliseconds later, they’d update the other half of the screen’s scanlines.  So when we drew, we’d draw half the scanlines as “16 milliseconds ago”, and the other half as “now”, and the television itself would automatically handle displaying those graphics at the right times.  Sadly, now that everything has gone to progressive scan (that is, all screen scanlines get updated every frame), this sort of trick won’t work for modern games.

Trivia5:  Transformers was our first game to include anamorphic widescreen support.  It contained widescreen support because I had just purchased an extremely expensive widescreen television, and came in on the weekend to add support for it.

Trivia6:  The related Penny-Arcade strip.

After Transformers, we started work on a sequel, imaginatively entitled “Transformers 2″.  However, it wasn’t many months before we were informed that Atari had sold the game rights to someone else for a surprisingly large amount of money, and then shortly afterward we learned that Michael Bay was making a related film (which explained why the someone else had been willing to pay so much for the game rights).  So with Transformers 2 gone, we were eventually given a game to do:  ”The Big One”.  Not much to say about that one, except that we spent an awful lot of time and effort on it, developing lots of complicated technology and lengthy and intricate storylines, but never quite finding the game amidst all the technology.  This game was eventually cancelled.

We were then tapped to make PS2 and PSP ports of Eden Games’ Test Drive Unlimited.  Now, Melbourne House had long been known as a studio which made well-regarded racing games.  I had never worked on one of them (and so I haven’t mentioned them in this post), but that’s just because I’m not really a racing game player, so always ended up working on the character-based games instead.  But in this case, it was the only thing going on.  The big fancy new features in “Test Drive Unlimited” on the XBox 360 were (a) open-world racing, instead of having pre-defined circuits, and (b) freeform networking where you would dynamically be paired up with other nearby players as you drove around.  ”A” has now become a fairly standard feature in racing games.  ”B” is still unique.  When we started on this project, since I wasn’t really interested in racing game mechanics, I pushed for us to keep the networking features of the 360 build, and I (together with Ross) ended up being the networking team for the game, with me focusing on servers and generic networking, and Ross focusing on the myriad PSP issues (including supporting ad-hoc server-less networking).

Trivia:  The PS2 and PSP Test Drive Unlimited servers are still running, with a daily maximum of about 80 simultaneous users.  Technically, I’m probably not supposed to know this.  But they  never removed my admin access to the servers when Atari took over responsibility for running them.

Trivia2:  Our servers logged a lot of interesting data.  The most fascinating data concerned the frequency with which people chose different starting cars.  In the UI, players were presented with five possible cars to rent.  Their cursor started on the leftmost car, and they could scroll to the right to select any of the other cars.  In practice, twice as many people chose the first car as chose the car to its right.  And twice as many people chose that second car as chose the third car.  And so on, through the whole list.  The further away the car was from the initially highlighted option, the less frequently people would choose it.  Conjecture:  This is why World of Warcraft, when asking you to pick a class, starts without any class selected, and without putting them in a list that you have to increment through.

Near the end of Test Drive Unlimited, we learned that Atari was in some financial trouble (sensing the pattern, here?), and wanted to either sell off our development studio, or else close us down.  As it happens, we were rescued by long-time Aussie developer

Krome Studios

At one of our first visits with Krome Studios’ CEO, he asked if any of us had interest in working with this new console that was coming out, the Wii (or the “Revolution”, as we knew it then).  We’d all already heard that it wasn’t a stunningly powerful machine, but it had this fancy accelerometer-based input device.  I was the only one to put up my hand;  most of the other tech-folks were more interested in the XBox 360 and PS3.  As I’ve mentioned before, we had some really smart tech people who really wanted to get a chance to flex their muscles with a little more processing power.  And as a result, I was the one who was tapped to port “Star Wars:  The Force Unleashed” from the PS2 to the Wii, and I was the first to get to try my hand at writing gesture recognition for swinging a lightsaber.

After a week arranging an initial port of the first level (very similar to the shipped version of the “TIE Fighter Construction Yard” level in the game), I was shipped off to San Francisco to meet up with our CEO and to pitch to LucasArts to let us do a Wii port of the game, in addition to the PS2 and PSP versions that Krome was already making.  Now, the Wii was still generally unknown at this time, outside of the gaming industry.  What’s more, Nintendo’s Wii development kit does not look like retail hardware;  it’s a big black box with all sorts of exposed electronics, and a cheap-looking sticker labelled “Property of Nintendo”.  So imagine if you will, what it would be like to take this ominous black box into the USA past the TSA and through international customs.  The process wasn’t as bad as I had feared, luckily.  I made it through customs without too much trouble (I was lucky enough to get a customs inspector who was a gamer, and so was fascinated to see a real development kit), and I spent the night refining the game port at the hotel, coding on a laptop and with the Wii development kit hooked up to the hotel room’s television.  And with the sound turned down low-low, so the neighbours wouldn’t hear me reflecting laser blasts.

Walking through LucasArts’ buildings at the Presidio in San Francisco was scary.  Imposing.  The design of the buildings’ interiors had clearly been inspired by Star Destroyers;  they have the same sense of immense scale, although nicer carpeting.  And there are beautiful (and huge) concept art paintings mounted all along the walls.  But the most frightening moment came at the end of our pitch, when LucasArts’ very imposing director of development looked past my CEO and straight into my eyes, to ask if I personally was certain that we could complete the game within the time limit.  I said that I was certain, yes.  And I went to the bathroom, later.

I was made Lead Programmer for the Wii version of Force Unleashed (I think I was credited as “Lead Programmer (Melbourne)”), and that was my first time leading a whole development project.  It was at this time that I learned that when you’re a lead programmer overseeing a group of six or more other programmers, that you don’t actually have time to write any code yourself;  all your time is spent managing the other programmers.  As a result of being unable to find time to code at work, I started this blog and started writing the VectorStorm engine, just to keep my programming skills up in my spare time.

Trivia:  Despite being the lead programmer on the game, I’ve never actually played all the way through the Wii version of Force Unleashed.  I’ve properly played the first several levels, and the last several levels, but there’s a big chunk in the middle that I’ve never played through normally, watching the cutscenes and actually progressing without using debugging aids.  I’ll play it someday.  Just.. I’m not ready, yet.  It’s too soon.

Trivia2:  We pitched to Nintendo about making a “lightsaber” handgrip to clip around the Wii Remote.  We even prototyped one ourselves.  Nintendo wasn’t interested;  they were highly concerned about the recent reports of people causing TV damage by losing a grip on the Wii Remote, and didn’t want to even consider putting the Wii Remote inside another potentially failure-prone device for a game which involved swinging.  In the end, it didn’t really matter;  a third-party released a lightsaber grip, instead.  And I believe that I saw an official one from Nintendo in the shops last week, for Force Unleashed 2.  Regardless, the ones in the shop are heavy and imbalanced, and actually make it much more difficult to swing the Wii Remote accurately, due to the illuminated blade.  Our prototype (which was only a grip) was much nicer to use, in my opinion.

Trivia3:  The Wii version’s lightsaber attacks actually do about three times as much damage as in the PS2 version, to compensate for the extra effort required to swing your arm.  (I got yelled at for making this change without involving the design department;  only having checked it with QA and Production.  I was used to working on projects with minimal designer support, and on Force Unleashed we had designers who wanted to stay intimately involved in these sorts of decisions.  I absolutely deserved to be yelled at over this one.  As it turned out, though, the designers did like the change as well, and it stayed in.  And I learned a valuable lesson about including designers in discussions about design.)

Trivia4:  The title animation that displays in the Wii channels screen when you insert the Force Unleashed disc was designed and put together by me, as a placeholder very early on in development, to demonstrate to LucasArts the sorts of possibilities that were available in that space.  I never intended for it to be the real one that went out with the final retail discs, but nobody ever seemed interested in replacing it.  I think I made some of our sound people cry, when I told them that I needed the first dozen notes of the Imperial March compressed down to fit into an 8kb mono sound file for this purpose.  Sacrilege.

Trivia5:  My favourite thing in this game is the 3D lightsaber cursor that we use instead of the usual 2D cursors used by most Wii titles.

Trivia6:  I can’t tell you how soul-crushing it is to have Zero Punctuation cover your game.

Trivia7:  During this time I also wrote the initial implementation of camera behaviour for the racing sequences in Viva Pinata: Party Animals.  My initial implementation was substantially modified and improved upon by others later on in that project, but I still was listed in the credits.  Thanks, guys!  :)

Trivia8:  Force Unleashed contained the worst single bug I’ve ever had to track down.  It was a crash which would only occur if you played through the whole game up to a particular cutscene in the Nar Shaddaa level on a retail kit, playing from a real game disc, all in a single sitting, only in German.  It took about eight hours of intense scouring to find the uninitialised memory bug which caused that crash.

Trivia9:  We prepared an altered version of the Wii Remote Safety Guidelines screens that are displayed at the start of every Wii game which uses motion controls.  You know the ones;  the ones which show the silhouette of a guy knocking over vases and hurting his friends with his wild, uncontrolled flailing, with explanatory text advising you not to do that.  Our modification was to exchange the generic guy’s silhouette with that of Darth Vader, with a red lightsaber extending from his Wii remote.  I sent these altered images to Nintendo to get their approval, even though I was pretty certain that (since they were legal screens) they wouldn’t let us doctor them in any way.  Usually when we asked Nintendo questions about this sort of thing, we would hear answers back within about eight hours or so.  In this case, we didn’t get a reply for nearly two weeks.  The reply eventually came from the head of Nintendo’s approvals team;  apparently our question had been escalated up through every layer of management, with each person saying “I don’t think we can let them do this, but I don’t want to reject this”, and forwarding it up to their boss.  In the end, they wouldn’t let us use it.  But everyone liked the idea.  Oh well.

Shortly after Force Unleashed (and my lengthy vacation after that), I was brought over onto a new Transformers game, this one to coincide with the second Michael Bay Transformers movie:  Revenge of the Fallen.  Or Return of the Fallen.  I can never remember that subtitle.  Anyhow, we were doing the Wii and PS2 versions of the game, and I was initially set to be Lead Programmer on that, but after some disagreements regarding scheduling and project scope, I stepped down from that position and took care of the game’s UI, instead.  I also designed and implemented (and created about twenty levels for) the lockpicking minigame.  And they even gave me a design credit for that!  :)

Trivia:  This Transformers game is probably the only Transformers game ever made where there is no “transform” button.  You don’t want to know about the fights and bitter feelings within the team caused by this intentional omission.  (correction: As Liam has pointed out, two secondary game modes did have a “transform” button.  Only the primary game mode was missing it.)

Trivia2:  The original plan was to provide a whole set of lockpicking minigame levels as a special “extra” game mode.  But in the end, the time it would have taken to build a GUI for selecting levels and comparing high scores was just too much for an already tightly-scheduled game.

Trivia3:  If work had rejected my design for the lockpicking minigame, I was fully prepared to ask for permission to turn it into a “Game in a Week” to be released for free on this site.  Happily, though (or sadly, depending upon your point of view), they seemed to like the game.  :)

Trivia4:  Originally, each of the lockpicking minigame levels had a level name and a caption.  Usually these were puns which only made sense to me, or in-jokes or literary references which also only made sense to me.  And in the end, the names and captions were removed because they made the minigames feel too “gamey”.  But all of my original levels are still in the game.  For those who  have played the game (anyone?), notable named levels include the one shaped like a sailboat under a starry sky (title:  ”And a star to steer her by”, caption: “Straight on ’till morning”), and the one composed entirely of north-south strips of floor tiles (title:  ”Vertical slice”, caption: “It’s like a cake!”).  If you squint a bit, one of the level layouts looks a very little bit like a Decepticon logo.  That one was originally titled “Programmer Art”.  Later levels (created after the “no text” policy) were mostly created by our designers, and were more abstract, more intricate, more tricky, had more possible solutions, and were never given names.

After Transformers, I took an extended vacation.  I put in for a full year off work, but ended up buying a car and returning after only (only!) four months off.  That’s four months with pay, mind you.  Did I mention that I had accrued an awful lot of annual and long-service leave during my career, and that I never used it?  In retrospect, I really should have used a lot more of it before the company shut down.  But back to the story.  When I returned from my lengthy time off, I was brought onto a game which kind of floundered for a while, before being pulled off to work with the engine team for a while, and then being pulled off of that to work on another non-game project for a few months.  And that brings us up to this last weekend, when we learned that Krome was in financial trouble.  This third time, there was nobody standing in the wings ready to swoop in, buy the development team, and let us continue on as before.  This time, we actually shut down.

I’ve said before and I’ll say again that I bear no ill-will to my employers.  It was my honour to work with such fantastic, talented people for well over twelve years, and I would happily work for or with any of them again.  It’s tragic that the last vestige of Melbourne House has now vanished;  it was a bit of living video gaming history, a development house that had been around continuously since the days when games were distributed on audio tapes, with many staff members who had been there continuously, making games, for as long as twenty years.

But it’s over now, and the people who were part of Melbourne House are scattering.  To other companies, to other industries, to other places.

And I suppose that it’s also time for me to stop dwelling on what has been, and is no more.   Time instead for me to look forward and begin asking myself:  “What awesome things might I be a part of, next?”

Postscript

On the topic of “Kill Doctor Lucky,” as pictured on my mug.  Kill Doctor Lucky is a traditional board game made by James Ernest’s Cheapass Games.  The idea behind Cheapass Games was that much of the cost associated with traditional games is in the cost of generic components.  For example, every board game you’ve ever bought has come with its own dice, even though you probably already own dozens of your own dice.  Cheapass Games made games and would send them to you in little paper envelopes (or later, very thin cardboard boxes), only including the rules and any custom cards required.  Dice, pencils, pads of paper, tokens, and any other required bits, they’d just expect you to already own and re-use (or they would sell to you separately, if you preferred).  Cheapass Games usually sold their games for about $4-$8, depending upon their complexity and production costs.  Or if you were like me, you just pre-paid with a subscription;  you’d say “Here, have $60, and just send me everything new you make, and deduct it from that credit as you go.”  They’d release one or two new games every month.  I’d basically ignore their web site, and just magically receive a new game every once in a while, like unexpected little gifts.  Many years back, when Mr. Ernest stopped designing games for Cheapass Games, he shut down the subscription service, and refunded any balance that people still had remaining in their account.

I keep wondering whether that sort of system would work for computer games.  Prepay a certain amount, and automatically receive copies of all the new games, with money being pulled out of that account to pay for them as they’re released.  I imagine that you’d need to have games coming out at least once per month in order for it to work.  But it’s an interesting thought.

Anyhow, I still have my subscription refund check for $26.65 sitting on my shelf, Mr. Ernest.  It’s been there since 2006.  And no, I’m not cashing that sucker;  someday you’ll start Cheapass Games back up again, and I’ll be there, waiting.  Oh yes, I’ll be waiting.  :)

Fundamentally, that sort of cheap knock-off is no different than modern “piracy”.  The pirate looks at a desired, expensive good, and then recreates it cheaper, and sell their copy to consumers at a lower price than the original manufacturer can manage.  The only difference we’ve got over the older “Hey Mac, wanna buy a watch?” approach is that it’s possible for software folks to cheaply make an exact duplicate of an existing product, rather than having to manufacture our own version of a physical object using the original as a guide.

But it’s not always going to be like that.

With 3D printing and other fabrication processes becoming commoditised, it’s only a matter of time before the common Joe on the street will be able to manufacture items to the same standards as big companies.  Imagine a combination 3D scanner and 3D printer — it’s not a far-fetched idea;  we already have primitive versions of both types of device.  Give us twenty years, and they’ll both have gotten much more sophisticated, and could well have been merged into a single object.  Let’s call this object a “duplicator”, and assume that most families will have one about the size of a toaster.  Need an extra copy of the house key to give to a visiting family member?  Drop yours into the duplicator, and it’ll make another key for you.   Run out of paper towels?  Easy to make more, from the single spare you keep around for exactly that situation.

Of course, most businesses would be using these devices to avoid needing to keep huge warehouses full of goods.  All they need is one copy of anything they want to be able to sell, and a duplicator large enough to hold it.  It’s like on-demand book printing, but for sofas and refrigerators.  Restaurants would only need one chef;  each night he’d prepare one instance of each dish on the menu, and everyone who ordered that meal that night would get a duplicate.

Thought experiment time.  What do you suppose will happen to the fabulously prestigious company ChairCorp when random Joe on the street can furnish his apartment by borrowing one of his friend’s ChairCorp chairs and duplicating it?  ChairCorp’s chief source of wealth, their real product is their intangible chair designs, and the intangible workmanship they put into their chairs.  But their income comes from selling physical chairs, and suddenly those physical chairs have become extremely cheap.  How can they continue to pay their designers?

I imagine that the first thing they’ll do is to try to lobby for regulation of these duplicators.  That they should be able to put some sort of “watermark” into their chairs which duplicators will be required to recognise, and then refuse to perform the copy.  Of course, every time they release a new chair design, there will be people who make a small profit in removing that watermark, so people can purchase the latest exciting new ChairCorp chair, remove the watermark, and then duplicate it as often as they like.  And there’ll be a vocal group of protesters complaining that they really ought to be allowed to legally duplicate these expensive chairs for backup purposes, in case the original is scratched or broken or something.

It’ll probably take a few years, but ChairCorp will eventually realise that they’re losing this battle, and so they’ll move to the next tactic;  legal wrangling.  Here, they’ll ship each of their chairs with a legal agreement which requires the purchaser to agree that they will not attempt to remove the anti-duplicating watermark.  Now when someone removes the watermark, they’re violating a contract, whereas previously they were merely defacing an object that they owned, and it’s much easier to prosecute someone for violating a contract than for defacing their own posessions.

Now, some will argue that this kind of ship-wrap arrangement isn’t a valid contract, but that won’t be ChairCorp’s biggest problem.  The problem is that even though they now have a more concrete reason to start legal proceedings against the duplicators, it won’t be easy at all for ChairCorp to figure out precisely who altered their chairs to allow them to be duplicated without sending out enforcers to examine all their customers’ chairs, looking for unauthorised duplicates.  And maybe they’ll do that for their big corporate customers who each bought thousands of chairs, but it’s just not worth the investment of money to investigate all their civilian customers who only bought one or two chairs, each.  Maybe they’ll make a few token investigations of somebody’s grandparents, just to make an example of them.. but they’ll soon give up on this as being bad publicity.

Eventually, ChairCorp will realise that they’re fighting a losing battle;  they simply can’t stop people from duplicating the chairs.  So given that people are going to be successful in duplicating the chairs, how can they stop the duplicated chairs from being used, so people will still need to buy original chairs?  Well, one thought is that they might attach their chairs to whatever ubiquitous wireless network is around at the time, and “phone home” to find out whether they’re a legitimate chair, or a duplicated chair.  If they determine that they’re duplicated, or if they’re unable to reach the ChairCorp Activation Server (say, because they’ve been installed inside a Faraday cage, or are just in a spot with poor reception, or perhaps ChairCorp has decided to stop supporting that model of chair), then they’ll fall apart when sat upon.  Of course, those who want to make duplicate chairs will now just remove that “phone home” feature, in addition to the anti-duplication watermark and continue as normal.  And the legitimate customers will complain about how their chairs fall apart every time they suffer a network dropout.

Where does it go from there?  I don’t know.  I don’t know how ChairCorp continues to make a profit when their value to the world is in their ideas, but they sell a physical, easily-duplicated object.  Maybe they don’t;  maybe they go out of business, and nobody can design chairs for a living ever again.  Or maybe they figure out some way to make it work;  some sort of “design licensing scheme” that doesn’t rely on people purchasing original chairs to generate income.

Make no mistake;  there are interesting times ahead.  What we’re going through right now with computer software is going to go very, very big, and almost certainly within our lifetimes.