User Supported Public Gaming

The midst of an NPR pledge drive seems as fitting a time as any to talk about how the current "microtransaction" wave that is sweeping the U.S. gaming market is both cheezing people off but also paying people off. Gabe & Tycho discuss how currently downloadable content rips people off in their newest old podcast. Specifically they talk about how EA is offering people the ability to re-purchase the same content they just bought, sitting there dormant on their DVD.

It's just another example of how the U.S. market knows that smaller, content-driven transactions are the wave of the future but, no matter what, they can't shake the idea that people need to pay $60 up-front as well. You can't tax people on both sides of the equation - either pay at the counter or pay at the console. Make up your freakin' mind.

GDC Radio (I love them) had an interview with Joshua Hong, founder of the MMO-ish company K2 Network. There Joshua illustrates how the South Korean market distributes the software for free but then charges for accounts, premium features and in-game items. They've been in the black years with this kind of model, not only because the economics works but also because they grow and nurture a user community. Their primary focus is retention, not acquisition. This is an important distinction... the more a user stays, the more the user pays for content, the more the community grows, the more users jump on, etc.

Linden Labs follows the same model, and it works. Users can join for free. A robust society is nurtured, moderated and encouraged. In-game items and real estate costs cash. And so the circle of life goes.

When you're dealing with something massive and subscription-oriented you can't charge an entry cost. Focus on retention and the rest can follow.

ConsultComm 4 Prototype

I just finished working on the first UI prototype for ConsultComm 4. I'm going to try releasing the pre-alphas as a Java WebStart app - available at http://prdownloads.sourceforge.net/consultcomm/ConsultComm.jnlp .

The JTable/JTree mosh-up is courtesy of SwingX. The code has switched from being very state-driven to being more procedurally driven from events generated by embedded components and JavaBeans. Hopefully this procedurally driven approach will mean less bugs, since actions will only take place at one part of the code. An update to one Bean's property will automatically announce itself to all the other Objects that use said Bean, which means you don't have to force each and every component to maintain the Bean's state.

It's hard to explain. But if you look at the code you'll see a ton of event handlers and action listeners, each of which call a single method. Even small changes make ripples across the codebase, so even distant code can hear when a part of the system has been altered.

I'm not making any sense. To any point, even though the demo is fairly simple there was a lot of work that went into it. And hopefully this work will mean accelerated development afterwards.

DeckerEgo's Razor

I changed the title of this blog from "Tales of an Indy Game Developer" to "Tales of an Indie Developer." Right now my game development has stagnated and may go to zero. But I'm still hacking away on a number of open source projects... as well as hacking the various other constructs I have to live with in my day.

One of the things I'm supposed to do in my paid gigs is architect the infrastructure of entire enterprises. If the title sounds nebulous and nonsensical, it is. Basically I try to coordinate data center sprawl or hack away bits when it gets out of hand.

Through my days I've moved progressively from very myopic fields to extremely broad ones. I started out in LISP working on Chez Scheme, moving to C++ & Motorola 68k assembly, moving to 3D rendering pipelines, moving to enterprise applications, moving to Web applications, moving to corporate networking, moving to corporate infrastructure, moving to enterprise Web application development & infrastructure, now moving to enterprise infrastructure. The uncanny thing is that all of these different genres follows the same Tao of Programming, no matter if it's even really programming anymore.

I'm working on ConsultComm 4 now and it's ridiculously slow-going. I have ripped out every bit of old code and have completely redone things (again), this time trying to follow a more... organic... layout. I'm trying to avoid corner cases and develop things as main-stream to Java's intended architecture as possible. This includes more modern event handling (more akin to Servlet chains or AWT events), better thread management and hopefully a better UI with less "surprises" and non-intuitive user interface choices. This has meant a crapton of prototyping, a lot of refactoring and a lot of brute force hacking. But I'm hoping it will be worthwhile in the end; the goal is to make ConsultComm 4 the last major version.

I've also been spending a lot more time in the debugger. The new codebase is loaded with assert statements meant to catch errors as they happen and plan for unexpected consequences. By doing some deep introspection and catching mental assumptions I make while I code things are error'ing out a ton more, but I'm catching more bugs on the front-end. Also I'm able to catch a lot of one-off circumstances and fail over to more appropriate states.

The same thing applies if you're trying to build a nationwide enterprise-ready datacenter tho. Prototype out the wazoo. Go as mainline as possible - don't try to outsmart existing architecture standards. No surprises. Plain for failure and develop for the exceptions. Document your assertions and watch for when they fail. Introspect and watch all the traffic routing back and forth... catch errors before they become problems.

Ultimately both software and enterprise application infrastructure need to pass the same meta-tests in order to become a lasting solution. You should be able to slice away any piece of the structure and have it remain consistent with the layout of the whole. You wouldn't cut a loaf of wheat bread and somehow end up with a single slice of rye in the middle. However, I'd wager if you went into a typical corporate data center and picked out a random server... heck, even an entire rack... you'd likely find out that it is managed or designed differently than the remainder of the servers in the room. Likewise take an object or source file from a typical software application and you'll find code patterns that appear completely different than the rest of the codebase.

All servers should be managed the same. All racks of servers should be organized the same. All types of servers (DBMS, SAN, storage, application server, development servers, load balancers, firewalls) should be updated, backed up and access controlled in the same way. All objects in an application should follow the same pattern. Exceptions should be handled the same way across all methods. Events, error handling and user prompts should all look and feel the exact same. Refactor like mad if you have to... but if you re-design your pattern, you should re-implement your codebase/servers/data center.

The Tao of Programming said it best:

A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity.

A program should follow the `Law of Least Astonishment'. What is this law? It is simply that the program should always respond to the user in the way that astonishes him least.

A program, no matter how complex, should act as a single unit. The program should be directed by the logic within rather than by outward appearances.

If the program fails in these requirements, it will be in a state of disorder and confusion. The only way to correct this is to rewrite the program.