I’ve been on a bit of a pork kick, recently, so when I found out about a new butcher that had recently opened up nearby, I knew exactly what I wanted to do. When I ate at Morimoto last year, one of the amazing dishes I ordered was a slow-braised pork belly served with a rice porridge… Marc of No Recipes had recently posted a great video about about black braised belly as well. Obviously, I needed to do something featuring the same, wonderful cut of pig.

The butcher sold me a cut of belly, and since it was so large I decided to prepare it two different ways — since belly is generally cooked slowly, I’d have plenty of time to intersperse the two dishes and their related accompaniments. It would be an all-day project.

Pork belly is a really fatty, flavorful cut — it’s the same place on the pig that bacon comes from, in fact. The difference is that most bacon you find in the stores has been cured and then smoked or seasoned, et cetera. You can find “fresh bacon” in some stores, but even that has still undergone an initial curing process. I decided I would roast half of the meat, and braise the other half. By doing the roasting first, and then chilling it, I could make what is called “pressed pork,” and the chilling time would allow me to braise the other half of the belly and do a lot of the prep work for the other dishes — a cranberry chutney, turnip puree, and a really simple apple salad. You can see the complete set of cooking photos over on Flickr.

After months of speculation and anticipation, Apple unveiled their tablet computer — called the iPad — today. I had been curious about the device primarily from the standpoint of an owner of both an iPhone and a MacBook Pro. What, I wondered, would be the unique appeal of the fabled tablet to people like me?

But after today’s presentation by Steve Jobs, I’m forced to conclude that the iPad really isn’t aimed at me at all. There wasn’t really anything in the its demonstrated range of capabilities that I can’t get from any of my other devices. It seems that Apple is going after the set of people who are iPhone owners but who don’t own a MacBook.

My first impression of the iPad was that it’s just a bigger iPhone, and nothing I saw ever really changed that. That’s not really a negative thing, though: the core apps — Mail, Contacts, Safari — have been rewritten to take advantage of the better screen, beefier hardware, and improved OS features and UI elements. The tablet appears to remain a single-app device — early investigations of the SDK revealed no multitasking support. But the larger screen does allow each individual application to structure itself to support more modeless operations.

I did find the extremely large bezel somewhat off-putting at first, although I realize it’s probably utilitarian: it provides surface area on which you can grip the device. I’d expect you’ll be gripping the edges of an iPad more often than you would an iPhone, due to the increased size. You wouldn’t want your fingers to set off the touch screen in that case. John Gruber, who spent some hands-on time with the device, has the same opinion. Although… it would have been cool to see those “touch-sensitive back casing” rumors (concerning the next-gen iPhone) materialize here in a form that would let the iPad detect how you’re holding it, and react appropriately (shrinking the touch-reactive area, perhaps).

As far as filling needs… eliminating what the MacBook Pro and iPhone provide, the only unique service offered by the iPad is the e-book platform. I’m sure iBooks and all of Apple’s infrastructure for electronic reading will look great, but I’m not sure they’re going to be stealing the Kindle’s thunder — not for me at least (they may have a shot at the people who read newspapers on the Kindle, since the iPad can do better, more dynamic layout). It comes down to the screen: reading on the Kindle’s e-ink screen is a fundamentally different experience than reading off a backlit, glossy LED screen. The Kindle’s screen certainly has shortcomings, but I still prefer it to reading on my MacBook or iPhone. Perhaps if the iPad had been available before I got my Kindle…

The price was also a surprise — cheaper than I thought. I’m wary of the 3G data plans, though. I didn’t catch any mentions of how the iPad’s plan interacts with existing iPhone data plans, and I’m not sure the 3G functionality is worth another $15-$30 on top of what I’m already paying AT&T for their mediocre service.

Still, it’s a solid, good-looking device on the whole. I have absolutely no need for it, but that doesn’t mean I wouldn’t ever buy one. I’ll definitely swing by an Apple store a few weeks after it becomes available to see what it’s like in person.

Oh, but the name is really dumb.

A few days ago, I was asked, “oh, you’re still doing tools programming? They haven’t promoted you yet?” It made me chuckle.

This kind of inquiry is something I am familiar with fielding; even within the industry itself, tools programming is often regarded as less than glamourous. Some — such as the fellow who asked me that question — seem to regard it as a lesser programming discipline. This is unfortunate, because there really isn’t any aspect of game programming that is less important than others, in general. Sure, certain studios may have no need for a server programming team, and some studios may not need much in the way of a tools programming team, either. But when you need one of those teams, you really do need them. The whole development machine has to work together, and if any one cog or widget goes missing, the whole thing breaks down.

But it is true that tools programming is rarely a position of high visibility. As Jeff Ward recently wrote in an excellent post over at the IGDA Toolsmiths SIG:

…in my experience, when you talk to people both inside and outside the industry and say you’re a game programmer, the first thing they’ll ask is “So what did you do on the game?” expecting that you’ll be able to point to something specific. Gameplay programmers can say “I made that system work.” AI programmers can say “I made that person move.” Graphics programmers can say “I made that thing render and look good. Tools programmers can really only point at the team and say “I made that work better.””

But, Ward continues, “that’s the way we like it.” And he’s right. I chuckle when people ask me if I’m “still doing tools,” because if I get my way, I will always be doing tools. Building tools is really all about helping people, and it turns out, I like doing that. I enjoy working with the other developers, trying to figure out why some program isn’t addressing their needs exactly, why some bug is manifesting its nasty little head, or what I can do to further optimize their workflow. I love the sense of satisfaction and accomplishment I get from succeeding at such an attempt.

There are other benefits, too: I get exposed to nearly every other developmental discipline in the studio, which gives me a pretty clear picture of where the project actually stands (and produces a feedback loop allowing me to better customize the tools I build). Additionally, I get to work with a wide range of technology, and have a lot more freedom to explore new ideas and conduct research. In short, I think that being a tools programmer is the best job I could ever land in this industry.

If you’re reading this post, the DNS changes have propagated such that you’re now looking at this blog’s new home. I’ve switched to hosting with WebFaction — not because I had any serious problems with my previous provider, OCS Solutions, but because I hate both Webmin and cPanel. WebFaction uses a home-grown control panel interface that offers an excellent combination of “powerful enough to do what I need” and “simple enough not to tempt me with options I don’t know how to use properly.”

I’d been toying with using Tumblr as a replacement content delivery platform. It was new and sleek, but using it put me very much in the mind of a longer-form version of Twitter. The back-end management provided by the platform was just a bit too simple for my needs. So I’m still with WordPress, albeit on a different machine.

The recent “Rockstar Spouse” incident has, not surprisingly, caused some discussion about the IGDA and their role within the game development industry. Drew Sikora posted via Twitter

“Wake up people. Game devs who blame the IGDA for doing nothing blame themselves for doing nothing. Get it? Now do something.”

which instigated a series of replies, including my own. But since Twitter is a really poor medium for discussion (especially as the number of participants, and thus @replies, grows), Drew elected to expand his argument via a blog post, which he published earlier today.

As it turns out, Drew and I seem to agree on the critical issue, which is that the onus is on the individual developers to take responsibility for the quality of their own work life. Where we differ is our opinion of the IGDA and its role in that process.

The IGDA is not — and never has been — an agent of change within the industry. The organization is about communication: enabling networking between peers, or advocating on the industry’s behalf. But they’re not a regulatory organization: they have no authority to alter how a studio or publisher runs itself. While some would call this a failing of the organization, I feel instead that it is simply their ideal state. In this sense they are impotent, and impotent they should remain. I don’t really feel like the industry has reached a point where it needs a governing body.

That the Rockstar developers are beset with the trials of long, thankless hours is unfortunate, but they allowed themselves to put in that position. It’s naive to think that, as an individual game developer in a studio, you can hunker down and focus on your isolated area of responsibility, letting all the other goings-on in the company pass you by. When you do that, you become complicit in your own misfortunes: you become the faceless cog in the machine. We, all of us, need to take charge and be proactive. When schedules get changed, or features get piled on, when it starts to become apparent that something might be wrong, ask the hard questions. If you don’t think you can ship when the new release date is pinned down, say so, and say why.

Yes, it might be hard. It might be scary. You might feel that speaking up puts your job on the line, and maybe it does. If so, talk to your peers beforehand — a unified front is more effective than a single man or woman. It’s likely to be especially risky in today’s economy, but it is what needs to be done in order for this industry to outgrow these exploitations. You need to convince your bosses, who need to convince their bosses, who need to convince the VPs, who need to convince the publishers, and so on. It’s not the IGDA’s job, it’s yours. If we want to grow up, we can’t expect to run crying home to mother every time a bully says something hurtful about our pocket protectors.

Which brings me back to the original topic, and where Drew and I disagree. He says:

“So unless you’re ready to start from scratch and form your own organization to simply create a more complex problem out there, or you really think we’re all better off acting as individuals (look how that’s turning out) I suggest you get involved with the IGDA by becoming a member. Do it simply to support all the other members actively working and using the monetary resources you provide to continue to improve standards and reach out to more areas of the industry with their advocacy. Or, if you support the idea of the IGDA but feel there are parts of it that need to change, roll up your sleeves and join a SIG or request the formation of your own to address a certain issue.”

Unlike Drew, I do believe that an individual acting alone (or in concert with peers, but not necessarily via a third-party organization) can catalyze change in game development. But I choose not to renew my long-lapsed membership because I do not believe in the IGDA as an aid to that end.

I don’t believe that the SIGs and chapter meetings bring about any more good than the individuals participating in them could do on their own. Having seen no evidence that the IGDA has ever successfully been engaged to mediate a debate, I’ve no faith they could do that effectively, either. Nor do I see anything going on in any given local chapter that couldn’t occur were that chapter their own, independent interest group. Indeed, each chapter is so unique they may as well be. True, we must recognize the IGDA for their work on standards for QoL, crediting, and such… but a standard is only as reliable when it is accepted widely enough — and from what I can tell, much of the IGDA’s standards are accepted by virtue of being common sense.

In the end, I simply see a dearth of evidence sustaining the notion that the IGDA can act as a force-multiplier for the individual actions and opinions of its constituents. That’s not something I want my time, my money or (most importantly) my name associated with.

Before I returned to Pennsylvania for the holidays, I rather quietly made the initial commit to the SlimBuffer Subversion repository.

SlimBuffer is a very straightforward API for creating and manipulating native-memory buffers from managed code. While there exist ways to do this directly — via unsafe blocks (in some languages) or various methods of the System.Marshal class — those methods are usually inelegant, inefficient, or both. SlimBuffer is written in C++/CLI for maximum efficiency and does what it does in a very clean, expressive manner.

If you’ve used SlimDX’s DataStream class, you already have a basic idea of what SlimBuffer’s MemoryBuffer class is like. Indeed, DataStream is the conceptual basis for much of MemoryBuffer, and the problems with DataStream provided the impetus to spin off the SlimBuffer project.

The big difference is that MemoryBuffer is not a subclass of System.IO.Stream. Our original decision to make DataStream a stream was a poor one. It forced certain conventions on us that, as development and usage of our API progressed, became restrictive. For example, the lack of distinct read and write positions causes users to have to remember to “rewind” many streams before handing them back to SlimDX. MemoryBuffer is beholden to no such interface restrictions — save for those of IDisposable, but that’s a given since unmanaged resources are involved.

MemoryBuffer also allows for allocator customization, similar to that offered by the standard C++ containers. As of now, there is a default allocator that uses new and delete, as well as a simple delegating allocator.

SlimDX 2.0 will be replacing DataStream with MemoryBuffer, but the class (and some of the interesting tidbits I have planned for it) can be extremely useful on its own, so we’ve created a dedicated project for it. This way users who aren’t using other aspects of SlimDX can still take advantage of what SlimBuffer provides.

Morimoto, which opened in Philadelphia in 2001, is named after its executive chef Masaharu Morimoto. I had wanted to visit the restaurant for some time. However, as I only return to the east coast once a year, I’d never really had the opportunity.

But this year I was able to secure a reservation for myself, my brother, and six of our good friends. As it turns out, the experience was unforgettable and well worth the wait.

Morimoto’s interior is smoothly modern. Narrow, but deep, the restaurant’s space is flanked by small tables along the walls, while larger booths occupy the middle section, interlocking with each other. The kitchen and bar are in the back of the restaurant, immediately behind one of the few tables the restaurant uses to accommodate big parties like ours. The chest-level interior walls are lit from within by lights that slowly rotate through a spectrum of colors.

It took time to peruse the menu and decide which of the tempting options to choose. I finally settled on the pork belly and the wagyu, with the “rogue beer flight” as my beverage.

Our food arrived staggered; some of us ordered apps or sushi, while others did not. The portions were such that most of us got to at least taste some of everything ordered, and somebody was always on-hand to finish off a dish that somebody didn’t have room for. Highlights included the beautifully-plated lobster ceviche salad, a delicious soba carbonara (soba noodles, bacon and scallops, white truffle oil) and a duck entree called “Duck Duck Duck.”

There were four beers in the sampler, each signature brews unique to the restaurant and ranging from a pilsner to a very dark, chocolatey ale. My favorite was the second-to-darkest — it was either the soba or hazelnut ale.

The pork belly was braised for ten hours and served on a bed of white rice porridge. The meat was extremely tender, and sauced with something that gave it a slightly sweet edge. It played well against the sharper, almost acidic tang of the porridge.

My entree was an eight-ounce cut of wagyu; extensively marbled beef, perfectly cooked. It was served with three accompaniments: a spicy ponzu sauce, a kind of Japanese barbecue sauce, and some wonderfully coarse crystals of Japanese sea salt. There was a side of pan-fried potatoes and a small salad, to help counteract the extreme richness of the beef. This steak was richer and more tender than anything I’ve ever had before. There was a texture to it, which I suppose comes from the fat content and provenance of the meat, that was quite unique.

Downsides? Well, it was crowded and as a result, a touch loud. There were at least two areas I saw available for more private dining experiences, however. I’ll try and get seated there when I go back — and I will absolutely go back: this was one of the best dining experiences of my life.

The SlimDX sample situation is currently pretty disorganized: some of our samples are checked in to the Subversion repository, but others are just referenced from issues in our issue tracker. Not all the samples use our internal sample framework, either, and the framework itself has a few issues. But as SlimDX becomes more and more stable, and begins to really approach complete parity with the native APIs, we have an opportunity to revisit problems like this one and clean things up.

In the future, our intention is to create a firm split between official and community samples. Only the former will be checked into source control. The community samples will be hosted on our website somewhere, and when warranted we will fold appropriate community samples into the official distribution, after appropriate modification. One of the things we want to ensure is that the official samples have a uniform style (to make them easy to follow and compare) and that they meet certain quality criteria.

The other thing we’re going to do is refactor the sample framework itself. The current framework feels like a “mini-XNA,” which has caused some users to adopt it as a more generalized “game” framework, which is problematic for us. We do not want to be in the business of writing — more importantly, of maintaining — anything resembling an engine. There are other projects out there that fit that bill; SlimDX is a lightweight wrapper, and we want to preserve its minimalist ideals even across aspects of the project that are not the core library itself.

The sample framework should be about making it easy for us to build samples. The native SDK uses a pretty robust sample framework, and we’ve seen that hamper it as an educational tool. When the sample is trying to demonstrate some concept or technique, it should demonstrate that in the language of the API itself. API calls should be used as often as is reasonable in order to demonstrate ‘the simplest thing that could work,’ which is usually what a user is looking at the sample code for.

Basically, we want a relative lack of abstraction. Users are just going to peel away the abstraction layers anyway, so we’d just be creating more work for them.

It’s still going to be a framework, though! We’re still going to wrap the creation of the primary window and the ‘game loop,’ and we’ll provide extensibility points allowing a sample to customize the main phases of application execution: pre-initialization configuration, initialization and resource load, logic update, render update, and shutdown/cleanup. Simplifying such boilerplate code, code that is not directly related to the primary tasks one would use SlimDX for, is perfectly acceptable.

Similarly, we’ll probably wrap mesh loading (especially since there is no built-in method for creating ID3DX10Mesh objects from a file, and we’d like to use the same source assets when possible for homogeneity) and similar ancillary operations.

UI is another interesting issue. The native sample framework supports a simple collection of UI controls for tweaking parameters for a sample. I’d rather not implement (and thus maintain) a similar system in SlimDX, but the alternative of using Windows Forms controls means that tweaking won’t be available in samples running in fullscreen mode, which is a deal-breaker. So we’ll support a small set of basic controls useful for tweaking parameter values in the new framework as well.

These framework changes probably won’t make it into the next release (if indeed the next release is this month, as we suspect), but you should see them in the release immediately following that at the latest… as well as some other interesting changes. And of course, you can always live on the bleeding edge and work from the head of our repository.

And now a word from the marketing department…

In other SlimDX news, Arcen Games, LLC recently released AI War: Fleet Command. I’ve posted about this on Twitter already, and SlimDX lead Promit Roy has beaten me to the punch on a blog post, but I’ll repeat it here for the benefit of other readers: AI War is the first game available for purchase that was built using SlimDX! This is very cool. Developer Chris Park has written about his experience evaluating rendering solutions for C# projects, explaining how he ultimately chose SlimDX… head over and give his blog a read, and when you’re done, be sure to check out the game itself!

Hobbyist developers don’t make MMOs.

Which isn’t to say they don’t try, or don’t think they are. But more often than not, they are simply misappropriating the terminology because they think it sounds cool, because it will attract more attention to their project. This is often true, although the attention they end up cultivating is typically the negative kind.

Here’s the thing: that first “M” in the acronym “MMO” stands for “massively.” That means the expected player base of the game is large. Not fifty players. Not a hundred players. Multiple hundreds of players is a bit closer to the mark, and ideally you’d want a number somewhere in the four-digit range. Building a game with the capability to support peak concurrency volumes like that involves two things that differentiate such games from others. First, it requires the technical acumen to build a network infrastructure — which consists of both software and hardware — that can scale appropriately. Second, it requires actual people to actually connect and play the game.

The complexity curve to achieve the first point, the technical scalability, isn’t linear. MMOs are involved… there are client programs, server programs (often multiple types… login and authentication, backups, core gameplay, tournaments and player-versus-player arenas, economics, web portals), physical machines that run those servers, and IT and security glue linking everything together and guarding against thirteen-year-olds with too much time on their hands.

It is extremely unlikely that any given hobby developer will have had the requisite experience with the problem domain to build all that out correctly — not the first time, at least. Because of that, their game will evolve in painful, halting stutter-steps. The first hurdle might be around the hundred-player mark. Perhaps it will be because the server is persisting character data too frequently, causing the database save to bottleneck and become unstable. Perhaps it will be because the core networking layer is using a naive mechanism for handling clients, and starts to thrash trying to service all the pending and active connections. It could be for any number of reasons, but something will break. It will need to be fixed, and then eventually something else will break, and so on and so forth. With time, dedication, and a healthy measure of elbow grease, one can end up with an MMO this way. It’s been done before, although it’s uncommon. Of course, this is assuming the players stick around through all the trials.

Which brings us to the real meat of the issue: the players. Getting players is tough for hobby and indie games, because they are competing for eyeballs that are far more likely to go to big commercial titles with huge publisher-backed budgets and similarly turgid marketing campaigns. Player base retention is tricky as well — typically this isn’t given as much thought, since the important thing for financial success is to dazzle a player enough to cause the cash to fly swiftly from the wallet, after which they are not given much thought. This doesn’t work in the long-term, of course, and it certainly doesn’t work in the MMO space, which is currently dominated by the monthly-fee culture. You’ve got to really keep players engaged to keep them coming back, especially if they are paying for the privledge and especially if your game is undergoing those inevitable growing pains discussed above.

The grim truth of the matter is that most hobby games will never achieve nearly enough players to actually scale and stress the system enough to be considered an MMO on the basis of that first, critical, “M.”

But then again, does it matter? There are generally two kinds of person who want to make an MMO as a hobby project: the guy with a lot of ambition and not a lot of grounding in reality who really does want to make the next World of Warcraft where you can participate in a massive online world in which you can do anything, even marry The Hulk, and the guy who really just wants to make a cute little persistant world of his own imagining that he can log in to and fool around in with his buddies. There is no hope for the former — and regardless, if they manage to get anything off the ground, it will end up being the latter kind of game anyway. The latter’s goals, though, are actually quite achievable — yes, they are misusing terminology by calling their projects MMOs, and they should be gently corrected. But there is no reason to jump down their throats, telling them how impossible their projects are and how they will never, ever have any success.

So the next time you see some poor newbie on your favorite game development forums or IRC chat asking for help on something related to an “MMO,” try to get a bead on just what it is exactly that is being built before flying off the handle. Jumping to conclusions, bashing them, failing to provide any kind of assistance, correction, or guidance — that’s just a disservice to entire hobbyist game development ecosystem.

Earlier, in “COM and SlimDX, Part 1,” I discussed an early design decision that was made in SlimDX that prevented us from supporting the idiomatic C# pattern for disposal of unmanaged resources. In closing, I mentioned that our new solution, while a huge leap forward, still had some problems.

Today we’ll discuss them.

SlimDX supports the ability to share — in a sense — the native objects of other APIs using System.IntPtr, an opaque managed representation of a pointer or handle. All SlimDX COM objects expose their native pointer as an IntPtr. They can also be constructed from IntPtrs.

With the old SlimDX design, we only ran into two serious issues with this process. The first was that since IntPtrs are entirely opaque, we’d more-or-less trust the user to construct the correct type and pass the correct pointer. Sure, we performed a QueryInterface(), but that may not have been the best idea in retrospect — there are known scenarios (for example, see here and here) where DirectX objects don’t behave the way you might expect a COM interface to behave — and so our code might have occasionally failed in situations it should not have.

The second issue was that we used these IntPtr constructors internally, occasionally in scenarios where it was impractical to know the proper type to construct. Remember the GetDevice example from last time? In Direct3D10, there’s a similar method for resource views (GetResource()) that is used to get a pointer to the resource that the view object is looking at. The method is a member of the ID3D10View base class, so naturally we placed it in the analagous SlimDX.Direct3D10.ResourceView class. The implementation would have looked something like:

Resource^ ResourceView::GetResource()
{
  ID3D10Resource* resource = 0;
  NativeComInterface->GetResource( &resource );
  return gcnew Resource( IntPtr( resource ) ); 
}

The problem with this approach is that it logically “slices” the object. This is similar to slicing in, say, C++ except that the underlying object is not physical destroyed, only the way you can interact with that object reference. In other words, even if the ID3D10Resource* returned from the native call pointed to a derived ID3D10Texture2D, it would be an error to downcast the managed Resource reference to a managed Texture2D reference, because we statically constructed a Resource, not a Texture2D.

A solution to this is a factory-type construction process — fortunately for us, most of the types involved here had base class methods that would indicate the actual runtime type of the object somehow — even though that would mean we’d have to push most implementation of the method lower in the class hierarchy. That was the solution we were considering, until the object table was brought up, which neatly solved the whole issue for us.

Almost.

You see, there’s one final caveat. The reason the object table eliminates the need for a factory is that it stores the native pointer as the key, and the actual runtime managed instance as the value. Thus, the aforementioned code snippet becomes a table lookup instead of a gcnew statement. The problem rears its ugly little head when you consider the possibility that the table lookup can fail to find the key. At first that might seem impossible (and thus not worth handling) because the view can’t be created with a resource, and given the existence of the object table, the only way the resource can cease to exist before the view is if the programmer intentionally disposed of it. This would be a programmer error, which is generally something we do not concern ourselves with handling gracefully (that is, we’d throw an exception indicating the programmer is a dim bulb, rather than try to bravely soldier on).

Unfortunately, since SlimDX can exchange native resources with other APIs via IntPtr, it’s possible to get into this sticky situation rather easily — simply construct a new ResourceView using an exposed IntPtr. SlimDX will correctly handle the ResourceView, incrementing the native reference count and placing an entry in the object table. But SlimDX won’t know about the original resource, so if you call GetResource() on the view, SlimDX will not find the Resource’s key in the table. What will happen, in that case, is that SlimDX will treat the object as a new one, increment the native reference count, and add an object table entry. This is unfortunate because the user now has to Dispose() of that resource, even though they didn’t explictly allocate it with new.

We’re currently considering this a pathological use case, and aren’t addressing the issue. Users doing that kind of advanced interop with SlimDX will simply need to be aware of the problem and the non-standard call to Dispose() they’ll need to make. I do believe it is a fixable issue, but the fix isn’t in the March release since it will not adversely affect the majority of our user base — you’ll have to wait for June, if we’re even able to remedy it all. In the interim, however, it’s important to be aware of the dangers that lurk in the shady corners of the API.