Why Oprah is Awesome

An item about Oprah, sent to me by the effervescent Jeff Shaughnessy:

On one of the Secret shows, Oprah gave an example of the scientific power
of the concept. She said that once, while she was hosting an episode about a man
who could blow really big soap bubbles, she was thinking to herself, "Gee, that
looks fun. I would like to blow some bubbles." When she returned to her office
after the show, there, on her desk, was a silver Tiffany bubble blower. "So I
call my assistant," Oprah told the audience. "I say, 'Did you just run out and
get me some bubbles? 'Cause I got bubbles by my desk.' And she says, 'No, the
bubbles were always there. I bought you bubbles for your birthday and you didn't
notice them until today'."

There are many lessons that might be drawn from this anecdote. One is that
if you give Oprah a thoughtful gift, she may not bother to notice it or thank
you for it. This is not the lesson Oprah took away from her story. Because the
way she sees it, her assistant hadn't really given her the gift at all. She gave
it to herself. Using the power of The Secret, she said, "I had called in some
bubbles."

Weirdness in Banking and How it Affects Games

I've been trying to figure out how a game can work in real-world banking structures without making it so convoluted that it becomes boring or too difficult, while still providing real-world banking semantics that might result in some fun game scenarios. I've had a few problems doing this, many related to this being the first time through some system structures. The biggest conceptual hurdle is how the M0 and M1+ money supplies turn to total bullshit in a fictional world based on the future. The best way to explain what I mean by this is by walking through, in my own (possible inaccurate) words, how I understand the evolution of banking systems.

In the beginning, people would barter for goods, with exchange rates being determined in real-time. For example:

Shepherd: I want a shovel.
Blacksmith: I want a wool coat.
Shepherd: Let's trade then.
Blacksmith: Sounds good.

Naturally, this is an incredible pain in the ass once you try to scale up, which becomes essentially a requirement once you get to things like tenement law, which is the basis for all modern taxation. It basically means the king owns everything and you have to pay him a certain amount in labor or goods to use the land you live on. (Believe it or not, this is still the basis for modern taxation, the only difference is that you no longer have the option of paying the "king" in labor or livestock.) For example:

King: Give me half of all your stuff.
Peasant: All I have is this cow. Should I cut it in half?
King: No thanks, I'll just rape your eldest daughter.
Peasant: Fair enough.

Fortunately for commerce, everyone started falling in love with shiny metals like silver and gold, which led to its use as an intermediary product that you could carry around (and tax) more easily:

Shepherd: I want a shovel.
Blacksmith: I don't particularly want a wool coat right now.
Shepherd: How about a quarter ounce of gold?
Blacksmith: Cool! I mean, come on, who doesn't love gold?

Gold and silver became such commonplace exchange items that the government would mint standard amounts to make it easier to count out value without having to continuously weigh everything. This naturally led to people shaving gold off of the coins, which was a problem because the money was only worth the materials it consisted of. In that sense it wasn't a real currency at all, rather it was simply a convenient form of barter. This is also known as commodity currency.

As people got richer, they found that bigger and cooler things came up that they wanted to buy. Unfortunately, carrying around a big heavy sack of gold just made it easier to steal and harder to use, especially with lower value precious metals like silver. (Ever try to run with 60 pounds of sterling silver? Didn't think so.) Try buying a mansion with silver:

Rich Guy: I'd like to buy that mansion.
Salesman: Sure. That will be 500 pounds of silver.
Rich Guy: Sure. Does that include a horse-drawn cart or do I supply my own?

This is where the first banks come in. People could store their valuables in a vault and be certain of their safety (at the very least, they could be more certain of their safety than they would be if they kept the loot in their house). With the banks holding your gold, you could start exchanging the promissory notes much more conveniently:

Rich Guy: I'd like to buy that mansion.
Salesman: Sure. That will be 500 pounds of silver.
Rich Guy: Sure. It's in this bank. Here's a note. Trust me, they are totally good for it.

You would then be responsible for going to the bank at your leisure and retrieving the gold. That was often a phenomenal pain in the ass for people, and that's how the dollar bill was born. In this form, the paper bills represented a fixed amount of some tradeable good, or specie, held on your behalf at a reserve bank of some sort. This type of bill is known as representative currency.

Eventually governments usually get tired of trying to collect taxes from a bunch of different banks with different bills and different security, so they set laws that force people to use a single type of currency from a specific reserve bank, generally affiliated with the government in one capacity or another. This system exists today, and that's the reason we have dollar bills.

Up until now this kind of makes sense, but here's where it gets weird.

As governments gain power they gain the ability to enforce commerce laws in their nations. They can also depend on the fact that, under normal circumstances, people just simply don't walk up to a national reserve bank with all of their bills and say, "I'd like my gold, please". As the nation grows in power, the money gains an inherent value in that it is the required means of commerce within the land controlled by a government. As this occurs, the government divests itself of the gold investment it has made because it no longer needs to maintain a certain reserve. At this point the currency becomes fiat currency, and it is backed by the general confidence in the nation that issues it. For example, the United States has been liquidating their gold reserves since the Nixon presidency. (I think it was in the 70s, anyhow.)

So now we have a situation where a bank stores dollar bills for you. The paper money is now the valued commodity. Vaults are now filled with as much paper money as the bank feels the need to meet the withdrawal needs of its creditors. The size of the economy drives the amount of value associated with the paper money and governments can control inflation (in part) by printing money or destroying it. The paper itself, outside of the context of being required for commerce, has as much value as a store coupon.

Notice how I suggested the government only controls part of the inflation. The rest comes from the M1+ money supply. (This is where it gets really weird.)

If you add up all of the printed money a government produces, that's what's known as the M0 money supply. The M0 supply also includes electronic money supplies associated with the appropriate reserve bank that backs the currency in question, so it's not necessarily all paper, but it's all under specific control. M0 is the only quantity that the government directly controls. The M1, M2, and M3 money supplies (these are called various things by various financial institutions, but for the purpose of this post let's call it M1+; for more info, check out the money supply article on Wikipedia) are actually produced by the banks.

That's right, the bank prints money. Here's how.

Let's say you give a bank $100 in cash for a deposit, and I come in right after you and borrow $50. As far as you are concerned, you still have $100, but you don't really need it right now. As for me, I think I have $50. So, adding up our total assets between the two of us, we now have $150. The bank has effectively printed $50. That's M1 money. Higher levels refer to term deposits and other less fluid investment capital.

M1 money in particular is the same as real money, especially in the digital age, because we do so many transactions completely electronically. I have no idea how much real money my bank has, I just use my debit and credit cards. If I restricted my dealings to the same institution (for example, if I only shopped at Walmart, and they used the same bank I do) there's no real reason for any actual M0 money to be used at all. In effect, I have as much as my bank tells me I have, and there's not a damn bit of good the government can do about it.

So what prevents the bank from just running up accounts to a virtually infinite amount? Two things. First, I can always go to a local teller and ask to withdraw cash. Banks can't print cash so they have to keep a certain supply on hand. Second, if I transfer money between banks and there's not a specific trust relationship between them, I would have to use the reserve bank to get funds across, and the reserve bank account is an M0 supply.

Based on electronic availability of funds, less and less cash is in use all the time. So, what happens if cash simply stopped being used for most trades? The bank would not feel any need to keep any kind of real "reserve", and an infinite amount of money could be produced. Interest free loans could be provided and 100% weekly interest rates could be offered on savings accounts because there's no need to back the account with anything concrete.

And here's the climax. Mapping this onto a futuristic game becomes difficult because no logical futuristic game would support cash, and without enforcing some kind of banking regulator (which would defeat some of the realism) there's little to no physical asset to associate with the money. If I have no capacity or reason to ask my bank to convert my cheque into a concrete asset representing the appropriate currency, there's no need to manage money, and the economy collapses.

Maybe the possibility of massive inflation becomes a key part of the game. Maybe most banks would be forced to have an asset account with a core regulator or reserve bank, and that would become the M0 asset. Maybe a physical "cash" asset is still needed. Or, maybe all three are true.

More on this as I continue. There's definite possibilities for something new here.

Reality in EVE Online: A Rebuttal

I've been thinking about the EVE Online scenarios in a previous post and how a game can be written that offers a similar freedom and fun but with more realism and less of a hardcore gamer element. As I was thinking about this, a lot of "flaws" started to show up in the two scenarios that could be solved by applying more in-game automation and less of a "wild wild west" approach.



For example, take the Ubiqua Seraph assassination. Although many of that corporation's members likely resigned outright in its aftermath, EVE Online supposedly attracted numerous new players because of the "raw realism" of the events that transpired. But how realistic is it that a group of people could infiltrate a relatively small number of high level positions and then essentially liquidate the entire company? This is hardly real-world, and the flaws are largely to do with in-game corporation management.



Look also at the Nightfreeze scam. This is reminiscent of the Bernie Madoff scandal in recent American news. Essentially, a person claims to invest a large amount of money for a group of people but just shuffles it around and takes a big cut for himself, leaving all of the investors with little to no resources remaining.



It has been said that the EVE Online manifestation was realistic, but is that totally true? Not really. For one thing, once the scam was revealed, Bernie Madoff didn't get to keep his money. In the EVE scam Nightfreeze immediately quit the game after handing $300 million to some new player, but that would never happen. If Bernie Madoff killed himself that might be equivalent to "quitting the game" but if he walked up to a McDonald's employee and handed him a cheque for billions it's not likely that the American government would have allowed him to keep it.



So, is it possible to have a more realistic in-game situation that allows full player freedom without being so arbitrarily non-interventionist?

Signs You Need A Hobby, Part 26: Data Access Stimulates You

Here's a manifesto about Microsoft's Entity Framework. I need you to understand something about the tone of this message: there's actually enough people who feel passionately about data access to write a manifesto about Microsoft's Entity Framework, and I frankly find that shocking. You know what? If you care about this so much, go look at a mountain, have sexual intercourse, do some old-school breakdancing, do some tequila shots. Seriously, time to prioritize.

I gotta pick this blog post apart. I realize that, in doing so, I am lowering myself to that level, but if it's any colsolation it's already 3:00 in the afternoon so I'm probably already drunk while I write this.

Let's start with a few choice quotes:

The signatories of this letter are unanimous in expressing concern for the
welfare of software projects undertaken in the Microsoft customer community that
will make use of the forthcoming ADO .NET Entity Framework.

And here's another:

We remain willing to collaborate with Microsoft and the ADO .NET Entity
Framework team to forge a positive action plan to help the Microsoft customer
community achieve success with entity architecture applications.

Now if the first quote was written like this:

The signatories of this treaty are unanimous in expressing concern for the
welfare of Palestinians living in the West Bank community that
will need to make use of the forthcoming UN emergency aid package.

And the second like this:

We remain willing to collaborate with the UN Security Council and the Israeli government and millitary to forge a positive action plan to help the Palestinian Authority achieve success with its efforts to support innocent civilians.

I could understand the need for enthusiasm. But let me reiterate: THIS IS A FUCKING DATA ACCESS LAYER. I don't normally like to swear, particularly in all caps, but seriously.

There's also a ton of technical statements that are basically phrased like "most people think you can access data in more than one way, but we members of the Entity Zealot community believe there can be only one, and only morons don't recognize that ours is the one true path." For example:

The Entity Framework encourages the Anemic Domain Model anti-pattern by
discouraging the inclusion of business logic in the entity classes.

I'm sorry, "Anemic Domain Model"? Ever heard of messaging oriented applications? Also, how do you propose taking your non-anemic domain model and spreading it over a WSDL boundary? Is there no value in a data-only approach? Normally one might suggest that the article in question merely suggests one possible way of doing things; however, by referring to "data-only objects" as the "Anemic Domain Model anti-pattern", I think it's basically saying only fuck-ups use it.

I'll restrict myself to two more rebuttals, even though I could really get stoopid and just comment on every sentence in this document.

Here's something on lazy loading:

Lazy loading is an essential capability of a data access framework for
entity-based applications. Without lazy loading, an entity-based application’s
codebase will need to include unnecessary prescriptive data loading procedures
for every possible business scenario in which the business entities will be
used.

I'd probably add the following sentence to this quote: "Of course, you will have to augment the built-in lazy loading capabilities of most ORMs with a large amount of optimization hints and restrictions on use to avoid making 47 round-trips to the database every time you ask for a simple set of information, but hey, that's definitely easier than writing a SQL statement. I mean, 'Select Name from People', what the hell does that mean?"

Last one: Here's something on the value of "persistence ignorance":

A team’s ability to do evolutionary design and incremental delivery is
damaged by the Entity Framework’s inattention to fundamental software design
principles like Separation of Concerns.

I always enjoy it when a person writes "Separation of Concerns" but they really mean "Separation of Concerns exactly as I would implement it". Has it occurred to no one that lazy loading, by hiding the fact that property accesses may or may not return to a database depending on current cache state, forces a business application to be heavily dependent on side effects or non-functional behaviors that are generally difficult to understand fully enough to predict with any certainty the final behavior of the system? Isn't it of benefit to be explicit when you say, "Now I'd like you to go to a database, which is historically the bottleneck in an enterprise application, and perform your multi-millisecond activity?"

This is exactly why I stopped working on my custom LINQ provider stuff. I've come to realize that the data access question is simply a problem we've already solved a thousand times, and each solution has its own advantages and disadvantages; the intelligentsia is better served by focusing on technology choices that actually have a direct impact to clients.

One last dig: whether you like it or not, if you are a big ORM advocate you should probably just go back to .NET 1.1 and stick with typed datasets. I've heard all the arguments about what makes ORMs great, and I could argue that typed datasets do each of those features better. (FYI: I HATE typed datasets.)

Two Articles about EVE Online

Here's two reasons why EVE Online is one of two MMOs that are truly multiplayer experiences that I have seen (the other, by the way, is Planetside):

Nightfreeze's Great Scam

The Assassination of Ubiqua Seraph

This is exactly the kind of deep player griefing that makes an MMO good. Yes, it kinda sucks that you can get stabbed in the back like that, but the only thing that would be worse is if there were an admin who logged in and undid it.

I played both of these games for a fair bit. I quit Planetside years ago because it is a very player skill intensive game and I simply couldn't put in the hours needed to be as skilled as my adversaries. That's not really a negative reflection on the game itself (other than the fact that there's no such thing as a casual Planetside player).

I quite EVE a few months ago for a few reasons. First, the game doesn't offer sufficient ways to automate mundane tasks. For example, I can't ship goods from point A to point B without doing it myself, and that shit gets B-O-O-O-O-R-I-N-G. And mining - don't get me started. It's basically "click every 30 seconds", if you call that a game. This could be mitigated in a few ways that I've thought of.

Second, there should be more elegant user interfaces for setting up financial or trading automation. The contract system doesn't allow you to automate things like private insurance or banking. I'm not suggesting the game should prevent you from putting up a fake bank or force all players who create a bank to follow certain financial rules. I'm suggesting that you should have some automation capability if you want to set up a bank (real or fake) so depositors could use a nice UI to create accounts with you. Escrow management in the game as it is today is time intensive and inelegant.

Third, the game has a few unrealistic constraints that simply serve to increase effort (I suppose, to increase scarcity). For example, there's no global stock market and no way to see stock prices in other regions. That's an unnecessary restriction that prevents some of the deeper economic richness that the environment should have. Another is the restriction on copying blueprints. That's just silly - you should be able to buy a blueprint from anywhere and immediately copy it to anyone. You could eliminate both of these restrictions, foster a good automated trade network, and the one-hour-a-day players could focus on trading while the 1337 kids could focus on being pirates and stealing automated or player-controlled convoys. Players shipping cheap bulk goods might let them go with limited protection while players shipping expensive items would personally guard them.

Copy from Byte Array To Structure

I've seen a few bad (or at least suboptimal) implementations of this out there, so I thought I'd throw my own implementation into the mix.

There are three reasons why I have some issues with many other implementations I've been seeing:

1. The implementation uses managed pointers to access the byte array as though they are unmanaged pointers. Unfortunately, this doesn't really work.
2. The implementation locks the managed pointer on the byte array, which affects garbage collection and can seriously affect throughput. Locking should be avoided for copying small structs around.
3. The implementation copies the data properly into an unmanaged pointer first, but it uses a heap allocation method to get the memory, which for small structures is somewhat suboptimal - stack memory is probably better for this sort of thing.

The following code snippet avoids all three of the issues above. The only problem is there is an extra memory copy which could only be avoided with managed C++ and its managed pointer construct (I may post that another time). Enjoy.

public sealed abstract class BinaryStreamSupport
{
private BinaryStreamSupport() { }
public static T ReadStruct(Stream s)
{
int size;
byte[] data;

size = Marshal.SizeOf(typeof(T));
data = new byte[size];
s.Read(data, 0, size);
return _ReadStruct(data, 0, size);
}

public static T ReadStruct(byte[] data, int start)
{
return _ReadStruct(data, start, Marshal.SizeOf(typeof(T)));
}

private static T _ReadStruct(byte[] data, int start, int size)
{
T returnValue;
unsafe
{
byte* stackDataPtr = stackalloc byte[size];
IntPtr stackData = new IntPtr(stackDataPtr);
Marshal.Copy(data, start, stackData, size);
returnValue = (T)Marshal.PtrToStructure(stackData, typeof(T));
}

return returnValue;
}
}

XAML Syntax Discovery

I know I've been promising to finish some LINQ provider stuff, but I have ADD...

If you're like me, you have had a bit of trouble debugging data binding in XAML. Typical syntax looks like this:

<TextBlock Text="{Binding ElementName=mySourceElement,Path=Text}">

... which, to me, looks like some kind of crazy nutjob specialized syntax specific to binding that has no real (Intelli)sense. For example, where can you use "{Binding...}"? What classes can you use this with?

Turns out I should read a syntax guide. The code block above is essentially equivalent to:

<TextBlock>
<TextBlock.Text>
<Binding Path="Text" ElementName="mySourceElement">
</TextBlock.Text>
</TextBlock>

I didn't understand that the above syntax was a fairly simple, standardized shortcut because I have never (until just now) seen an example of data binding that used the long form. Perhaps I should have done more to try to understand the underlying syntax of XAML, but this sample really opened my eyes and helped me diagnose problems. In particular, by avoiding the braces shortcut in the top syntax, you get much more effective Intellisense which has helped me a lot with my WPF data binding.

I could have known this had I done more boring reading. The full details are available in the MSDN library page called XAML Syntax Terminology. In particular, the Markup Extensions section explains why some classes, such as StaticResource and Binding, can use this syntax. For more information on how markup extensions work, check out Markup Extensions and XAML on MSDN.