The Kidnap Game

The rules of this game are pretty simple. Player 1 “kidnaps” someone, sets a ransom for them but doesn’t tell Player 2 what the ransom amount is. Player 1 also sets the amount of money that Player 2 has available to pay the ransom, but doesn’t tell Player 2 this either. The object of the game is for Player 2 to free the hostage by paying the minimum amount that he or she can get away with, in as few goes as possible.

In this game, the transaction involves an exchange of money for a hostage. Either the deal goes through, in which case the hostage is freed and Player 2 is worse off, or the deal fails, in which case the hostage remains in captivity but Player 2 still has the same amount of money that he or she started with. There are two reasons why the deal may fail:

Player 2 may try to offer more money than he or she has available
Player 2 may not offer enough money.

We’ll start the design process by considering what resources we are playing with. We have two types of resource: hostages and money.

A hostage resource has the following attributes:

Name
State (free/in captivity)
Ransom

A money resource (strictly speaking, a bank account resource) has the following attributes:

Account name
Balance

How can we represent these electronically? Well, these resources look like a database to me, so we’d better start looking for databases that support transactions, and, somewhat inevitably, we end up at SQL Server. Incidentally, don’t worry too much about using SQL Server if you haven’t had much experience of it; we’ll be hiding most of the SQL behind Microsoft’s ActiveX Data Objects (ADO), and we won’t be doing anything very complicated. This isn’t a database book, after all!

The trouble is that MTS doesn’t show its true colors unless we use a resource manager, and there aren’t too many of them about — unless we want to tie ourselves in to a particular third party database management system (DBMS), such as Oracle. The list of supported resources is growing, but, at the time of writing, the only other alternative is to use Microsoft Message Queue (which we'll look at in the next chapter) or write our own resource manager (which we'll be doing in the one after that).

Also, if you’re just interested in trying this out, you don’t necessarily need to rush out and buy SQL Server. A developer's version comes with Visual Studio, and, if you happen to have NT4 Server Enterprise Edition available, when you install Microsoft Message Queue on Enterprise Edition, you’ll actually get a stripped down copy of SQL Server thrown in for free. The Message Queue system uses this to hold all its static data, and we can borrow a small section of it for ourselves.

In SQL Server, then, we define two databases, called

kidnap1

and kidnap2
. kidnap1
has one table, hostages
and kidnap2
also has one table, accounts
. (I’ve put them in separate databases just to make sure that they are as independent of each other as possible. It doesn’t actually matter from the point of view of the application — I just wanted to make sure that the various data sources were seen to be as distinct from each other as possible.)

The

hostages

table has the following columns:

Key	Name	Datatype	Size	Default
	`name`	`char`	255
	`free`	`bit`	1	0
	`ransom`	`int`	4

and the

accounts

table has the following columns:

Key	Name	Datatype	Size	Default
	`name`	`char`	255
	`balance`	`int`	4

Let’s see how we go about setting all this up.