Talk Funnel

Almost overnight a lot of apps have popped-up for the iPhone and many of them are games. Quite a few of them look like they were developed by hobbyists over a weekend (not that there’s anything wrong with that). But developing a quality, professional game for the iPhone is still a time-consuming and difficult task.

Once you’ve settled on the game concept, you have to create the play logic, then generate the graphic assets and multimedia. And somewhere along the line you actually have to write the code to make it all happen.

To build a serious iPhone game you currently have several choices:

1. Create a custom one-off app in Objective-C (or C++): This gives you the most control but it means your game is pretty much going to stay on the iPhone. No desktop version. No Wii. Just iPhone. That might be fine, but if you’re investing tons of hours in content creation and game design, you may want to think hard about whether it makes business sense to leverage all that work and hit more platforms. Building a custom one-shot app also means that all your development effort is only for that one game. Instead, you may want to…
2. Develop a general-purpose iPhone gaming engine: Where the gaming logic and media content are kept separate and defined in configuration files. This way, you can get two, three, maybe even 100 bangs for your buck. Hopefully, the configuration language is expressive enough so you can build a whole class of apps, not just the same thing over and over. You should be mindful, however, that the iPhone SDK prohibits use of scripting languages, so you can’t embed a Javascript, Lua, or Python interpreter into your code. If you don’t have the know-how or are short on time, you may want to…
3. License a third-party gaming engine: This takes you away from the pleasure of writing raw Objective-C code (I’m not kidding — it actually is a lot of fun) but it also gives you support tools like 3D modelers, asset managers, physics engines, networking, etc. so you can focus on the high-level logic instead of low-level coding. Most also support some sort of scripting, but get around the SDK restriction by compiling it into executable code.

I have worked on several Objective-C-based iPhone apps so far and developed a custom animation engine for a client, so I have squarely followed options #1 and #2. But I also have ideas for quick, fun entertainment/game apps that I’d like to whip out quickly without spending months on building a custom animation engine. I’d rather spend my time on polishing the game logic and generating nice looking multimedia assets instead of working around iPhone Core Animation’s strange quirks (please, don’t get me started).

So I decided to look around and see what’s out there and came up with the following. To be fair, I haven’t had time to dig too deeply into each one, but as a public service I figured I’d share what I’ve found so far. If I’ve missed any other platforms or made any factual errors, please feel free to post a comment and I’ll issue an update.

Here they are (in alphabetic order):

		ShiVa (with the iPhone Authoring Tool) from StoneTrip.
		Torque Game Builder (with the iPhone SDK addition) from GarageGames.
		Unity iPhone.

In terms of features it’s hard to tell them apart from their spec sheets. They all feature 2D or 3D graphics, support a variety of media and content (including shaders, sound, movies, etc), handle physics and collision detection, and playback audio and video. On the iPhone, there’s also support for the accelerometer (for tilt moves). All three engines support server-based multi-user playing which requires licensing their servers (or their hosting services). It’s not clear at this point whether they support WiFi-based Bonjour peer-to-peer networking which the iPhone and Touch both support.

What differentiates the three engines is what other platforms they support and their pricing model, so let’s dig into that.

ShiVa

ShiVa comes in three versions, PLE, Advanced, and Unlimited (here’s the feature comparison table). The development platform runs under Windows (or Parallels on the Mac). The PLE version is free and allows you to create an application, but you can’t publish the output commercially. For publishing you’ll need the Advanced or Unlimited versions. Advanced costs €169 Euros (approximately $235 at today’s exchange rate) whereas Unlimited will set you back €1,499 Euros (approximately $2080).

The main difference between the two seems to be that the Unlimited edition has additional benchmarking and optimization tools and supports team development. There is no extra cost for output to iPhone (and it looks like they intend to support Windows Mobile and Symbian). You can also target your game so it can run in a browser, but it requires the user to download and install a plugin. A standalone desktop app generator lets you target Windows, Mac OS X, and Linux. However, you’ll likely need to repurpose your media to fit the different screen sizes.

As far as console platforms are concerned, not much there yet.

To support multi-player mode, you’ll need to license the Ston3D Server which comes in PLE, INDIE and PRO flavors. PLE is free but is limited to a single application and 6 simultaneous users. Clearly, it’s intended only for development and testing. The INDIE version runs on Windows, Ubuntu, and FreeBSD, but is limited to 64 sessions (game instances) and 4 sessions per server. It runs €359 Euros (approximately $500) and the PRO server without the session limitations runs €599 Euros (approximately $832).

There are also extra server-side features like managed hosting, payments module, and direct messaging to the user (via SMS, MMS, and email).

Torque

GarageGames offers a dizzying array of products and Torque variations, targeted at anything from simple 2D to networked 3D games. The basic 2D package is the Torque Game Builder which runs $100 for Indie apps (those earning less than $250K per year) or $495 for Commercial version. The Pro version also gives you access to the source code for both the engine and the editing tools ($250 for Indie, $1250 for Pro).

If you want 3D support then there’s Torque Game Engine ($150 Indie, $749 Commercial). In both cases, you get a lot of tools that support building levels, media, sprites, etc. and take care of a lot of the low-level grunt work for you.

But that’s not all, Bob. There’s also Torque Engine Advanced ($295 Indie, $1495 Commercial). This gets you all the tools to develop advanced 3D games for consoles and desktops. To deploy your game to a console, you’ll want to look at Torque Wii or Torque 360 (for the XBox 360). License fees for these have to be negotiated.

But it’s the iPhone we care about and to output there, you’ll want Torque for the iPhone. First you’ll need a license to one of the existing ‘builder’ tools (Tool Builder for 2D, or Engine for 3D). for the 2D version, you pay an additional $500 for an Indie license. That lets you publish a single iPhone title. Each additional title you want to publish requires an additional $100 license fee. You also have to show the GarageGames splash screen when the game starts and mention them in the game credits (and app web-site). 3D game support on the iPhone hasn’t been released yet so there’s no price listed.

Want server-based networking? The basic server is open-sourced under GPL. If you want to use it in a commercial app, however, the cost is $295 for Indies and $995 for Commercial apps (consoles are separate). This is for games delivered on Windows, Mac, or Linux. It’s not very clear if networking is supported on the current iPhone version, but I imagine it’ll be there soon.

Unity

Unity supports 2D and 3D content with a visual editor to help you develop and design your game content. The underlying scripting technology is based on C# and Javascript but their iPhone Publishing product spits out an XCode project that they claim ‘just works,’ compiling the scripting code into fast ARM assembler code (and thus avoiding the iPhone SDK’s edict against built-in scripting languages).

Under Unity, the Editor is the main point of creating apps. You visually adjust parameters and get live previews, then create scripts to handle game logic. In iPhone ‘preview’ mode, you adjust settings on your desktop screen inside the visual editor and watch it update live on the target test iPhone. It’s a very cool way to quickly adjust and position your objects and verify that they look right on the iPhone screen.

To develop Unity apps, you need the editing system ($199 for Indie developers earning $100K or less — with free 30-day eval, or $1499 for Pro) which lets you generate output for Mac, Windows, browser plugin, and OS X dashboard widget. To output to the iPhone you can got for the Basic iPhone license for $399 for Indie developers and requires showing the Unity splash screen, or $1499 for the Advanced license. Wii/WiiWare output is separate and carries a hefty license fee ($15K-$30K per title).

The Advanced edition also gets you .NET sockets. This means that you can write your own back-end server and aren’t locked into theirs, but you don’t necessarily get Bonjour/WiFi support. You can also stream assets on-demand (which requires an asset-server client license for $499) but I can’t imagine anyone wanting to stream assets unless the user was on WiFi.

Risks

There are inherent risks with using a third-party middleware. Will the platform continue to be supported? Are they actively fixing bugs? What happens if they go out of business and you want to continue developing your app? If these are concerns, then you may want to consider Torque’s Pro versions since they come with source code.

On a resource-restricted platform like an iPhone there’s also the matter of having a whole extra layer of runtime between your app and the OS. If your app is going to be pretty media-heavy you may want to roll your own and keep tight control over memory use.

Don’t be scared by these caveats. For certain classes of games these engines will amply make up for the risks by letting you concentrate on content instead of engine technology and getting your app out that much sooner. If used properly, they can also act as ‘force multipliers’ if you are an individual developer or a 2-3-person team. With these tools, you can rapidly create cool apps that would otherwise require a small army of coders and designers.

Which one?

Which one you choose will depend primarily on what features you need, so the first thing I suggest is to download and try out each package (here are direct download pages for ShiVa, Torque, and Unity). All three have free or eval versions and offer Indie pricing for small developers. If your app turns into a big hit and brings in enough revenue, it’s easy to justify the cost of the Pro or Advanced licenses.

If you intend to eventually move to the XBox then Torque is the only way to go. If Wii is where you might be heading, then it’s Torque vs. Unity. All three platforms support standalone desktop apps. I’m not sure with the prevalence of Flash in the browser if anyone’s willing to download and install a browser plugin just to run an application, so I’ll call web-based delivery a wash.

If licensing fees are a concern, then you may want to go with ShiVa. If you only need 2D support, then Torque may work for you (although their iPhone per-app licensing fee is a little too strange for my taste). Mac-only developers will want to look at Unity or Torque Engine Advanced . All others require Windows (but may work under Parallels or VMWare).

iPhone-only features

At this point, nobody seems to support peer-to-peer Bonjour-based networking on the iPhone. Quite a lot of games support that feature. Unlike a Nintendo-DS which allows two players to form an ad-hoc network just by sitting near each other, this only works when all the players are on the same WiFi subnet. It works pretty well when players are in the same room or dorm floor and doesn’t require going out to a central server. It’s especially handy in places where data access is metered and hitting a central server through the cell network can get expensive. Hopefully Bonjour support is something that will be supported soon.

All three engines appear to have decent support for the accelerometer but no mention yet of other iPhone-only features like multi-touch, GPS, or camera. One other thing to keep in mind is that all the license terms and prices listed apply to games only. If you want to develop a social networking or business app you may have to negotiate a separate license.

Bottom line

Which one will I use myself? My development environment is currently 100% Mac based and I have a lot of 3D, graphics, and sound production tools there so that will probably influence which way I go. That makes Unity a strong contender for me. However, I’ll defer final judgment until I’ve had a chance to seriously beat up each platform.

Remember that regardless of platform, you’ll need to sign-up separately for Apple’s iPhone development program (a $99 cost for individuals) to get a distribution certificate. You’ll also need to do the actual legwork of submitting the application to the app-store. And once the app is out, there’s the matter of marketing and promoting so your app stands out against all those other ones out there.

Ah yes, marketing. Let’s leave that for a future post…

Update: For those interested in going the open-source route, SIO2 and Oolong Game Engine are two 3D gaming engines for the iPhone/iPod Touch. (Many thanks to Justin Hall for the tip.)

Both look plenty capable for iPhone-only game development (NOTE: there’s no desktop or console output support). Based on a casual first-pass, it looks like SIO2’s tight integration with Blender 3D editor and support for Lua scripting makes it easier for those who want to focus on content-creation instead of low-level coding. Oolong, however, is targeted more at C++/Objective-C coders. According to the Oolong source code site it is the technology underlying Torque Game Builder for iPhone (see above).

The user interface of the iPhone is based on a series of nested UIView objects, arranged in a view-subview/parent-child relationship. When building a complex application with a lot of views, sometimes it’s handy to be able to see exactly what that relationship is.

But if you try to print out the value of a UIView in the debugger (or through an NSLog function) you’ll be sorely disappointed. In this example we have a variable called front that is derived from a UIView. Setting a breakpoint in the XCode debugger, I type in a po (print object) command to show what that variable contains:

(gdb) po _front
<BCCardSideView: 0×106b020>


What you see is that the variable is of type BCCardSideView and its hex address. Not very helpful.

One solution is to take advantage of the Objective-C dynamic runtime and override UIView’s default describe method. This is the method that is called every time you try to display the value of an object. Here we have just such an override that recursively walks the view tree and dumps out the values. The code is contained in a file called UIViewExtras.m. All you have to do to enable it is include the file in your XCode project. There are no explicit methods to call.

Here’s the same output after UIViewExtras.m is included in the project (the indentation is a little messed up because of the column width of this blog. In the debug window, it should look fine):

(gdb) po _front
+ BCCardSideView retain:3 - tag:0 - bgcolor:(r:0 g:0 b:0 a:1.00)
  bounds: x:0 y:0 w:130 h:80 - frame: x:5 y:5 w:130 h:80 - center: x:70, y:45
++ BCCardBackgroundView retain:4 - tag:0 - bgcolor:(r:255 g:255 b:0 a:1.00)
   bounds: x:0 y:0 w:130 h:80 - frame: x:5 y:5 w:130 h:80 - center: x:70, y:45
++ BCCardTextView retain:4 - tag:0 - bgcolor:(r:0 g:255 b:255 a:1.00)
   bounds: x:0 y:0 w:100 h:20 - frame: x:0 y:0 w:100 h:20 - center: x:50, y:10
   text (len:4 - color:r:0 g:255 b:0 a:0.00): ‘name’
++ BCCardTextView retain:4 - tag:0 - bgcolor:(r:255 g:255 b:0 a:0.00)
   bounds: x:0 y:0 w:100 h:20 - frame: x:0 y:20 w:100 h:20 - center: x:50, y:30
   text (len:5 - color:r:0 g:255 b:0 a:0.00): ‘title’
++ BCCardTextView retain:4 - tag:0 - bgcolor:(r:0 g:0 b:255 a:1.00)
   bounds: x:0 y:0 w:100 h:20 - frame: x:0 y:40 w:100 h:20 - center: x:50, y:50
   text (len:5 - color:r:0 g:255 b:0 a:0.00): ‘email’
++ BCCardTextView retain:4 - tag:0 - bgcolor:(r:255 g:0 b:0 a:1.00)
   bounds: x:0 y:0 w:60 h:20 - frame: x:0 y:60 w:60 h:20 - center: x:30, y:70
   text (len:7 - color:r:0 g:255 b:0 a:0.00): ‘phone.1′


For each view object you see:

• The retain count.
• The tag value (if specified).
• The background color value in RGBA. RGB values are scaled up to 0..255 and alpha is shown as a floating point value between 0 and 1.
• View bounds rectangle (x, y, width, height)
• View frame rectangle (x, y, width, height)
• View center (x, y)

If view is a UILabel or UITextField, you also get:

• - Length of text
• - RGB value for text itself (vs. the background)
• - Actual value of the ‘text’ inside the field.

Subviews are indented by multiple “+” (plus) signs. So the top-level has one ‘+’ all its subviews have two ‘+’ signs, *their* subviews will each have three ‘+’ signs etc.

I personally find this handy in debugging views — especially those created dynamically. I hope you do too.

[ Download: UIViewExtras.zip ] (Update: Link updated.)

Time Machine is great, especially if hooked up to a network storage device like Drobo so you can just have it run in the background. In my case the Drobo is connected to a Mac Mini acting as a network file server (yes, I know it’s not officially supported, but it works fine under Leopard).

However, lately the backups have been taking a lot of system and network resources, rendering the machine (in this case my development laptop) practically unusable while they run. But since Time Machine runs in the background, it’s OK to lower the backup daemon’s priority and let it run a little slower.

On Mac OS X Leopard, this is the command that does the trick. From the terminal:

sudo renice +5 -p `ps -axc | grep backupd | awk '{ print \$1 }'`

Here’s what’s going on:

• sudo - This runs the command as the root. You will need to enter the administrator password.
• renice - This is the standard Unix command for changing the priority of a running application.
• +5: Process priorities under BSD Unix-based systems typicall run from -20 to +20, with +20 being lowest (i.e. running slowest) to -20 being maximum (yes, I know it’s unintuitively backward, but there’s an old historical reason for it). What we’re doing is bumping Time Machine daemon’s nice priority up by 5 (or any number you want) to let it run slower.
• -p pid - This is the process id of the process you want to adjust. Since this changes every time Time Machine runs, we have to have a way to find it dynamically at runtime — which is where the rest of the line enclosed in ` back-quotes come in. On most Unix shells, items enclosed in back-quotes get executed and the result returned back to the command line. So we’re going to look up the process ID of the current Time Machine server process and return it here.
• ps -axc - The ps command returns a long list of all running processes on the system. We need to filter out the one we want, which we do by piping the output into a grep filter next…
• grep backupd - We’re taking all the output from the ps command and only keeping those lines that contain the string backupd — which happens to be the name of the Time Machine server. So we end up with a single line of ps output that looks something like this:
  

  19041 ?? 1:07.48 backupd

  But what we need is the process ID to pass back up to the renice command. In this case, it’s the first number on the line. We need a way to extract only that, which is where awk — the amazing text processing Swiss-Army knife — comes in…

• awk “{print \$1 }” - By default, awk splits its input into chunks based on whitespace. We’re simply asking that the first item be returned. Any time you do this, you should apologize to awk for so massively under-utilizing what it can do. It’s like driving your Formula-1 car down to the grocery store to buy milk. In this case all we’re doing is asking it to split up some text and return one item to us, something that awk can do practically in its sleep.

When you run this, the sudo part of the command will ask you for your admin password, then proceed to do its thing. Put it all together and you’ve got yourself a simple way to slow down Time Machine so it’s not such a CPU hog.

If you’re enterprising, you can put the whole thing into a shell function and run it over and over. The following code goes inside your .bash_profile file.


function tmslow {
    echo “Reducing Time Machine priority…”
    sudo renice +5 -p `ps -axc | grep backupd | awk ‘{ print \$1 }’`
}


Start a new terminal session (to make sure the shell function is loaded) then invoke tmslow and enter your admin password. It prints out a little message reminding you what it’s about to do.

Remember, the renice command doesn’t stick, so every time you reboot or a new Time Machine session starts, the process goes back to normal priority. There are ways to automate the priority lowering scheme or even make it permanent, but I don’t recommend doing that. Sometimes, you may want backups to run full-speed. Unix makes it trivial to do what you want by stringing together some built-in commands.

Sorry if the blog’s style keeps switching around. Problem seems to be with the DB and hosting site. It keeps resetting back to the default WordPress style even if I haven’t posted for a while.

Might just have to give up and leave it there. *sigh*

Ad for an institution of higher learning, currently circulating on national news outlet sites.

This message popped into my email inbox today:

A few points worth mentioning:

• The [SPAM] tag was not added to the subject header by any software on my end. As near as I can tell, it was either put there by the spammer’s own email server, or added manually.
• The particular inbox to which the message was addressed is protected by a server-side whitelist service (SpamArrest). For the message to get through, somebody has to go to the trouble of explicitly confirming that they’re really a human and put themselves on the approved list. The sender did this.
• The same message has been sent several times under different email addresses. Every time, I ban the address and a while later it makes its way again with a new sender address (which has to be manually confirmed with SpamArrest, again).
• I feel bad for the ‘real’ Dr. Lulu Gwagwa of South Africa, who appears to be a most accomplished investment banker.

For some reason, the perpetrators of this message are really determined that this message get through and a lack of response (or continuous placement on the ban filter) doesn’t seem to deter them. That they consistently confirm their own address through SpamArrest tells me that they are not exactly high-volume ’shotgun’ spam traffickers. Those people rarely provide a working reply address.

On the other hand, I have to admit that opening with an apology and the fact that they admit they got the email while doing a ‘random transaction’ on the Internet shows refreshing candor.

Sadly, I am forced to ban the sender once again, as much as I appreciate the effort.

A fascinating chart showing the origin of most Spam on the Internet.

Holy crap!

French author Michel Houellebeck gets slammed hard by, of all people, his own Mother (more here).

Wouldn’t it be funny if she ended up with the Prix Goncourt instead of the acolyte of modern nihilistic French literature? The lesson: don’t put thinly veiled insulting caricatures of your Mom in your writings. She probably has more dirt on you than anyone else.

On an unrelated note, I’d like to take this opportunity to wish my mother an early Happy Mother’s Day and tell her what a fantastic, great individual she is…

Jeff Jarvis ponders whether Insurance is impervious to social reinvention. I don’t agree, but I think it’s going to take some pretty big thinking, a major set of cojones, and a fair bit of social engineering.

A few years ago, I spent a fair amount of time working on a desktop healthcare application, with the idea being to let people take care of their own healthcare needs. After a couple of years of research and development, I ended up mothballing the system after realizing that the only way to get something like that to work was not to tackle a small piece of the process (the user’s health records) but the larger, systemic problem of health insurance. Incidentally, it is for this very same reason that I think half-baked efforts like Google Health and Microsoft HealthVault are doomed to irrelevance.

Now, I don’t make any claims to being an expert in insurance or healthcare. But I’ve been cursed with a healthy dose of curiosity and a background in designing and building complex systems, which qualifies me to do a lot of standing on top of hills and looking for patterns. It turned out that most of my two years of work on the software was spent studying the healthcare and insurance industry, instead of coding.

After all that time and effort, I finally came to my senses and realized that tackling the healthcare system was just too daunting a task since it required aligning the interests of ALL parties involved in the chain including insurers, doctors, employers, etc. all the way down to the individual. So I mothballed the project and went off to write fiction and start a family. But the problem has always nagged at me. There’s a little voice in my head that keeps saying: There must be a better way.

My good friend and business partner Mitch Ratcliffe recently went through some experimental surgery (that thankfully seems to have worked). He’s written about it here and his conclusion was that there is a “need for a new economics in medical care.”

I couldn’t agree more. But how do you tackle something as unwieldy as the insurance industry (and its medical offshoot, the healthcare system).

A hint comes from a comment made by Seth Godin in response to Jeff’s post: you have to think big. The only way to do Insurance 2.0 (including healthcare) is to rethink the whole process, free of all the self-interested legacy cruft that has been built into and around the system.

Yes, now is a good time to get those eyes rolling. Contrary to what some might assume, I’m not one of those technology über-alles types. As far as I’m concerned, technology is — as the kids like to say — our bitch. Its purpose is to serve us, not the other way round. Nor do I subscribe to the baby/bathwater theory — that everything is broken and needs to be thrown out.

But please, indulge me for a moment.

The way risk is currently calculated is primarily static and completely opaque to the consumer. Insurance companies hire an army of actuaries who come up with risk tables for a variety of situations and create complex mathematical systems to help mitigate it. These metrics often take into account some key milestone events in a person’s life (i.e. if you get married, move, change jobs, fall ill, etc.) but do not allow for mitigating circumstances (like the death of a parent) nor do they require any sort of active involvement or participation by the consumer.

By and large, you get quoted a rate, you pay your premium without really knowing how or why any of it works. All you know is that if you make a claim, your rates will go up. The insurance company is going to do everything in their power to make it hard for you to pull money out and everything (including hardball legislation) to make it difficult for you to use the benefits. Your interest as a consumer of insurance and that of the insurer are in direct conflict with each other (in computer network parlance, it’s a master-slave relationship.) How your behavior affects others (or theirs yours) doesn’t even enter into it, even though technically you are all in the same risk pool together. It’s as if you live in a silo.

It also makes for a complex, top-down system of rules and risk calculations — most of which are designed to push the risk back down onto the insured and the money up toward the insurer. And the whole edifice comes tumbling down when you get large systemic catastrophes, like floods, wars, or epidemics.

Since we’re complaining about the system, what else is wrong with it? Plenty. The underwriting rules are almost never disclosed completely (not that too many people would care) and any attempts at making a claim is often met with a flurry of complex paperwork designed to slow the process down, to dissuade the (busy) consumer from ever again wanting to make a claim again. As Jeff calls it, it’s a sucker’s bet — in more ways than one.

So what’s the solution? More government regulation? Applying the Web 2.0 salve? Actually… neither.

To get a better picture, we have to engage in my favorite activity of zooming up into birds-eye range and looking at the whole system. The insurance system (if it can be called that) is a series of complex, interlocking, top-down subsystems, with various balkanized pools of information, and players whose interest (and power) is served by keeping a chokehold on that information. By design, it’s complex and anyone who gets too close to it will inevitably get swamped with information overload and quickly back off. Those who don’t (like a certain former First Lady) will likely get singed in the political heat (and maybe start imagining incoming sniper fire
The alternative to a complex centralized system is often a simple, decentralized system that applies rules recursively. Think P2P, fractals, or human cellular biology.

The Web 2.0 version of insurance (again, including healthcare) would have to start with a simple, easy to understand mechanism that anyone can use to assess the risks and the costs. It would have to be dynamic, transparent, and let you know exactly where you stand so you can make informed life decisions. It would have to take into account every other participant in the risk pool and encourage open communication. It should be understandable by anyone, and when applied collectively, provide the best answer to global risk mitigation.

In other words, it will have to be open and transparent. Yes, it sounds impossible, but the alternative is to replace one complex system of knobs and levers with another one. I am convinced that the solution is in simple, recursive, self-organizing systems. I have some ideas as to how this could work, but this is the sort of thing best tackled (and vetted) by a group of interested individuals dedicated to the art of simplification.

There’s another thing to consider: as commenter Uncle Fester says in response to Jeff’s post, there are HUGE regulatory and financial barriers to creating new insurance mechanisms.

First, instead of calling it insurance let’s call it something completely different (Lifecare, for example). This is not just semantic sleight-of-hand. The term ‘insurance’ comes with a lot of baggage which can get one bogged down in regulation and litigation for a lifetime. Second, to make it work so it becomes something that can be trusted (that it’ll be there in times of need) and get large-scale adoption, it’ll have to align the interests of all beneficiaries — in this case, individuals, businesses, government regulators, AND … (wait for it) insurance companies (!!!)

How can this work? Why would any insurance company want to participate in a competitive scheme that threatens their core business?

The problem is that the whole insurance edifice (including healthcare and pension plans) is a Ponzi scheme. As long as there is new, low-risk money coming into the system, the high-risk ones can be covered. The difference, however, is that investors don’t really cash out — they die, or move their business elsewhere, so they have to never be paid off. Most people don’t need healthcare when they’re young and spend most of their lives accident-free. The majority of the time, they automatically pay into the plan. The earlier they die (or get kicked out of the risk pool) without using expensive resources, the better off the scheme will be, having taken all the premiums and paid out relatively little of it.

The way to bootstrap a new Insurance 2.0 is to start by taking the highest risk policies off the hands of current insurers (along with a decent amount of cash for doing them the favor) and bootstrapping a distributed risk management system into place. Who are these high-risk people? For starters: sub-prime mortgages, pretty much any auto driver in Southern California :-), and pension-fund members on the books of large corporations. These are all high-risk, low-reward insurance policies that are liable to cost the insurers billions in years to come.

By taking these groups and putting them into a social/distributed scheme, you get to battle-test the system and make sure all the rules are fairly applied. Sure, there will be initial falterings. But over time, a self-regulating system will develop the right mix of complexity vs. fairness and provide a more balanced mechanism than what we have today.

This is the alignment of interests I earlier referred to: insurance companies (with bad bets on their books), corporations (with increasing healthcare and pension costs), government agencies (who may get saddled with the costs as an insurer of last resort), and the individuals themselves (faced with no coverage) will all be interested in seeing this experiment work.

It will require a large pool of startup capital and easing of regulations, but if it works, it could revolutionize the way liability insurance, healthcare, and pension plans operate.

As Seth Godin says: Think Bigger, Jeff!

But start by thinking small (and recursive).

I write software, stories, and half-truths. This is a place to hold some, all, or none of them.
P.S. If you have a burning need to reach me, you can try raminf on Twitter.