Self-Drive Engage

Lately I've been thinking a lot about self-driving cars.

You see, the whole point of a self-driving vehicle is that the occupants of the vehicle are absolved from all the responsibility and all of the joy of operating the motor vehicle.

In such a scenario, which is currently playing out in both California and Nevada, the part that I've been thinking about the most is: Who should be responsible for paying the speeding tickets?

It brings in a number of thorny questions, not the least of which is the difference between driving safely and driving legally.  I hope that we can assume that the car will be authorized to drive safely first, and legally second. (Please let me know in the comments below if this is not the case!!)

It also calls into question the goal of the speeding ticket program in general.  If the goal is to genuinely limit the Kinetic Energy of the vehicle (= mass x sqr(velocity)/2), then lets forget about speeding, and instead record this computed kinetic energy quantity in a continuous manner, along with the GPS co-ordinates, and at the end of the month compare it with the local authority's database of speed kinetic energy limits.

Behavior Modification

In gaming terms, a (speeding) fine is a way of modifying behavior by producing a sharp negative feedback at random intervals.  This is among the most effective ways we know of reducing an undesired player behavior.

Unfortunately this technique simply does not work against computer software.  The only people qualified to change the software are the developers, and it requires active participation on the vehicle owner's part to update the software on a regular basis.

Insurance

I hereby propose an Insurance based licensing scheme for self-drive vehicles.  I propose that in order for a vehicle to (legally) use a self-drive mechanism, the owner of the vehicle must purchase insurance from an organization that is both state licensed, and independently audited.  Eligibility for any given insurance policy will be based on the make and model of the vehicle, plus the software package, version and database of the self-drive mechanism.  At the end of the month, all of the occasions when vehicles with the same policy have exceeded the posted speed kinetic energy limit are summed up, and it's the insurance policy fund which pays out to the state, with no additional per-vehicle owner expenses.

This creates a market for insurance policies.  You can purchase cheaper insurance by buying more conservative software, or pay more in insurance but arrive at your destination sooner with more aggressive software.  As technology and software changes and improves, so too will the market for your self-drive insurance match the current conditions in your state.

And if the price of the insurance is too high for your particular vehicle (e.g. it's too old, or too unsafe, or you're currently out-of-state), you can always opt-out and disable the self-drive feature of your vehicle.

Incentives

This proposal create the right incentives, the software developer must use the best software engineering techniques, the vehicle owner must keep their vehicle updated with the latest software, the insurance socializes the speeding costs amongst all vehicle owners of the same class, and the market ensures an efficient allocation of policies and choice of software programs across all the vehicles in the state's fleet.

The one piece of the puzzle that's missing is the state.  Suppose that a speed kinetic energy limit on a particular stretch of road is changed, but the software developers aren't notified in a timely manner.  In this case, the state itself has been negligent, and it's the state itself which should be fined for putting motorists at risk.  In the same way that the state must adequately signpost the speed limit, so should be it's responsibility to notify the state licensed self-drive software developers.

Speeding?

Of course, I've used speeding as an example of unsafe vehicle behavior, but this regulatory framework extends in a natural way to all vehicle behaviors - stop signs, following distances, red light rules, yielding to buses on residential roads.  Even accident compensation, emission standards, and fuel usage.

The only exceptions I can see are when a vehicle is attempting to drive safely rather than legally.  Without getting all Carl Sagan here, it seems that we could use the black-box data to evaluate all collisions (few) and near-misses (many) to improve the software and improve safety over time.

Failure To Yield

Interestingly, the large majority of vehicle collisions are caused by one simple mechanism, "Failure To Yield".   That's what stop signs and traffic lights and turning circles are all about. A self-drive vehicle, equipped with appropriate sensors, has no reason to stop at stop signs, nor yield at yield signs (if it can negotiate with another self-drive vehicle to yield instead), other than to avoid startling other human drivers.

Reality?

Will it happen?  An insurance based self-drive licensing scheme? I don't know..  If anyone knows of the actual proposed self-drive licensing situation, please post it in the comments below!

The Infinite Blogpost

There's an Indie project floating around at the moment, that's being touted as infinite.

For some reason, it really bugs me when people take a perfectly good word, a word like "infinite", and then apply it incorrectly.

You see, a desktop computer is finite.

Suppose your desktop computer is a Commodore VIC-20, with a whopping 3.5 kilobytes of memory.  Then there are only 256^3,583 different states that your desktop computer can be in.

Sure, that's a lot of states, but it's certainly not infinite. You could, at least in principle, enumerate them all.  And you'd find that there are exactly 256^3,583 of them.  That's the very definition of finite.

Finite software runs on finite computers

Lets take a closer look at those finite states on the VIC-20.  We know that the computer is finite, but maybe there is some magical technique in which we could write a computer program to have an infinite amount of state?

Unfortunately, no, we cannot.  The pigeon hole principle forbids it.

Fast forward to the Modern Era

Oh? Your computer has more memory than a VIC-20? 4 Gigabytes perhaps?

Well that's still just 256^{4,294,967,296} states.  It's still not infinite.

Oh, you have a 3TB hard drive as well?

Okay, so now you have access to an additional 256^{3,298,534,883,328} different states.

That's a lot of storage.  These numbers are large, but they're all still finite.

The problem is that infinity is just so mindbogglingly larger than any number you could possibly store on your hard drive.

You'd need a technology shift to be able to store infinite state.

Bandwidth, over time, is Infinite

So hopefully I've managed to convince you that your computer, and by extension, the software running on it, is finite. Regardless of what that hardware is.

But now consider, the curious case of your internet connection.

If you're like me, you have a bandwidth cap of 4GB per month.  Then it is true, that for any particular month, your bandwidth is finite.

But consider your 4GB bandwidth extending over time.

I can send 8GB in 2 months.  Or 40GB in 10 months. Or 400GB in 100 months.

Here's the curious thing, if we assume that time is infinite (a big assumption, granted), then for any amount of state, we can calculate how many months it would take to send that state on your internet connection by dividing by 256^{4,294,967,296} .


Let me repeat that, given any amount of state, we could send that state in a finite amount of time, over your internet connection.

And that is what is meant by "Bandwidth, over time, is infinite".

Don't Repeat Yourself

When making Indie games, there's a mantra that bears repeating over, again and again:

“Don't Repeat Yourself”

It's actually a corruption of a much deeper truth. If software development excites you, I urge you to read all the gory details about that deeper truth over on wikipedia. (If you want to go read it now, I'll still be here when you get back.)

When making Indie Games, however, “Don't Repeat Yourself” means something different. It's rooted in the notion that (calender) time is the most precious resource. It's the free variable with the highest opportunity cost. The longer amount of time it takes you to do something directly translates into a lesser amount of time you could be working on your next goal.

So what happens if you have to repeat a previous step? Replace an image that's no longer working? Change a sound effect? Rebuild a level? What happens when you have to repeat yourself?

For every repeat, the time you wisely invested into the previous version of that asset is effectively wasted.

You would have been better off using that initial time reading game development blogs. Or meditating. Or playing Dino Switch II.

So what does "Don't Repeat Yourself" really mean? It means that as an Indie, (almost) every piece of content you put time into, needs to ship at some point in the future. It means that each time you touch an asset, you should treat it as the last time you'll touch it before it ships.

Your asset pipeline (as an Indie) needs to go :

Concept -> Placeholder -> Shippable Asset

Cappucino

Contrast that with the apocryphal AAA game producer, “Make three cappucinos... then bring me the best one!”

Of course, what he really means is “Have three baristas separately make three different cappuccinos... then discard the two which aren't as good.”

So here's a Pop-Quiz, are those two discarded cappuccinos wasted?

Some would say “Yes”, referring to the ingredients and skill which went into the preparation of content which will never be consumed.

Others would say “No”, because the producer couldn't know ahead of time which barista would prepare the best coffee. Three times the amount of resources have gone into the production, in exchange for an improvement in quality and a substantially reduced chance (risk) of getting a bad coffee.

Don't Repeat Yourself

As an Indie, where (calendar) time is the most precious resource, “Don't Repeat Yourself” means shipping every piece of content you produce. If you somehow find yourself with 3 cappuccinos, then you're going to be drinking them all!

But does that also mean you need to ship the pieces which didn't work out? Not at all. Because the overarching process goes like this:

• Get placeholder assets for everything into the game

• Without repeating yourself, systematically lift every asset in the game up to shippable quality.
  (Upon completion, your game as a whole ought to be shippable)

• Do a polish pass where you replace only the assets which are (a) quick to improve, (b) have a big impact on quality

• Ship it

And that's indie game development...