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;
}
}