James Gosling comments:



We'll see what happens, but it seems reasonable to assume the character of major Sun technologies like Java and MySQL will change. How exactly is hard to say, although I suspect in Java's case, Oracle is even less inclined to support standardization and open source than Sun was. MySQL is harder to predict, but some change seems inescapable.

I expect Oracle to exert relatively little influence on MySQL's ongoing development, because several core MySQL developers left Sun prior to the merger and have the community support, skills, and funding to seriously threaten a fork. I also don't expect Oracle to make much money on (new) MySQL support contracts, due to a combination of lack of trust and expertise that has (or will) leave the building. Hopefully PostgreSQL will see an uptick in usage as well.

I've had my vanity domain, idempot.net, for a pretty long time (I know plenty of people who have had vanity domains for longer, but 2002 was about when I realized I needed an email address that lasted longer than any single employer). I don't remember how exactly it started, except with the observation that you could make some puns with '.net' and words like 'omnipotent.' Of course omnipot.net was taken, and I didn't really want impot.net... but I was familiar with another 'potent' - 'idempotent' - from both the pure mathematical meaning, and the C programming idiom.

Since idempotency is a form of uniqueness, it inspired the further pun of notunique@mac.com - the only .Mac user who is notunique. Then Apple started charging for mac.com addresses, and I was unemployed around the time a renewal fee was due, so I gave up on that pun, and started using idempot.net consistently. I liked it better anyway: it is unique, it's punny, and it's geeky.

On the downside, t's hard to pronounce. Not as bad as some, but not as thoroughly in the zeitgeist, either. Personal business cards have helped, but it's still a pain some of the time: if I'm giving my email address over the phone, if I've run out of cards (as happens late in the night at conferences), or if someone simply transcribes it incorrectly.

So now, to fix those problems in the future, I've registered easytopronounce.com. I don't know what, exactly, I'm going to do with the domain, but in the short term it'll just point here.

Happy New Year, everyone. No prognostication from me at present, I'm still figuring out what kinds of things I can talk about since I work for a publicly traded company.

Last night marked the end of Dungeon Runners; it is gone. I haven't been involved in the project, or really the community, since I left NCsoft a year and a half ago, but I am still very sad to see it go. There was something really special there, and there isn't even a hollow shell left to remind us.

Clearly I haven't done a very good job of blogging lately. I'll chalk that up to putting a lot of effort into finding another project to work on.

Today, I started a new job at BioWare, as an Infrastructure Engineer. It's not a glamorous job - I'm working on the tools and systems that keep the more game-specific teams agile - but as I've said a few times, there's a lot to get right when you're making, launching, and operating a successful MMOG.

That's pretty much what I want to do right now, with Dungeon Runners about to close and my last project never seeing the light of day. I'm in this industry to make people happy, and I'm working on MMOGs in particular because they can reach such a broad audience for so long. I've had some trouble actually making that happen, but I think BioWare can do it - that's a horse I want to hitch my wagon to.

For the last year, I've been working on an unannounced strategy MMO based on an IP I can't talk about.

But, that project ended today. Maybe I'll have time to finish more blog posts now ;-)

edited for... clarity.

The data center my web server resides in moved recently; I - and everyone I share my rack with - had to move our equipment some time between the beginning and end of this month. So that happened today, and I'm sorry for the downtime (to anyone that noticed) but it's stuff like this that, honestly, keeps me wanting to run my own server.

I remember once at NCsoft something similar happened; I don't remember (and may not have ever known) the "why" but data centers changed; I just noticed because... wow, all those sysadmins and network admins and other operational staff sure seemed tired and cranky. But as I recall, it didn't actually translate to significant game down time - certainly not the 8 or so hours this site had today (to be clear, everything in the rack was being moved at once - I didn't do such a terrible job that it took me 8 hours to move one 2U system across town).

That's something I should keep in mind, in my opinion. Can the systems I develop be easily migrated if they have to be? Not just for the (generally rare) circumstance of the entire data center moving, or contracts changing, but even the day-to-day of machine failure.

At nearly midnight, having been home for about 15 minutes, I'm certainly not of the right mindset to make a list of proper steps or describe an architecture or any such thing; but I can at least try to remember this feeling later, because I don't really wish it on anyone. :-)

A web developer friend of mine is thinking about conference "back channels." Folks who attended AGDC this year (where the Twitter traffic was heavy and constant, and #agdc09 was everywhere) might want to participate in a brief survey he's conducting on, I guess, making it easier to find and participate in.

It's interesting that I never heard it actually referred to as GDC Austin; the old names, AGC and AGDC, are still fresh in people's minds.

It was announced today that Dungeon Runners won't see 2010. Obviously, this is a project I haven't been involved with for a year... but while I was there, I did everything I could. I crossed a lot of bridges trying to make that game everything it could be; gaps everyone knows about like the one between developers and players, and gaps that are harder to see like the one between live staff and development staff.

I've seen a lot of discussion around the game industry that developers should never talk directly to players; it's probably a good rule of thumb. However, if you want your developers to know exactly what's wrong with the game, so they can fix it, they have to play the game. If you want your players to know that this is happening, they have to see developers in the game. If there's any one thing I think we got right on Dungeon Runners, it was being open and honest with players, and listening to them.

The other divide is interesting; it's broadly true, not just a part of games. Customer support, NOC, server administration... there is often a very large gap between the people who make the product and the people who keep customers happy. Talking with these other teams about what they needed, what problems they were seeing, and what they wanted is actually really important, sort of like having programmers and designers talking to each other. Obvious, but it still seems to get lost in the day-to-day.

But... that's not really enough. Making a fun game isn't enough. What I've come to believe is that to reliably make a successful game, everything has to be in place. You can't make a perfect product, but at every step if you accept "good enough" you are accepting a potential point of failure. Business plan, marketing, game design, user interface, operations, customer service... better is better.

That kind of leads toward the attitude of a control freak; everything is your job, and if someone tells you that some aspect isn't part of your job description, a red flag goes up. On the other hand, it goes the other way too: if anyone is concerned about your contributions to the project, and thinks that you are doing something wrong, you have to listen. They might just be right. If they are right, getting called out by a co-worker is infinitely better than being called out by players or reviewers; the earlier you can correct a mistake - yours or someone else's - the easier it is, and the sooner you can move past it.

I'm grateful to everyone I worked with on Dungeon Runners, because they helped me learn these lessons in a positive light; the layoffs, and now its ungracious end, have emphasized the danger of letting anything slide.

I missed attending PAX this year, because we've been pretty busy at work... perhaps that's a good thing. I've been hemming and hawing about the extent to which I want to participate at the conference in my own backyard, but now... well, a lot of people I missed seeing at PAX will be there. Possibly with the flu.

I will try to see at least a few people coming into town for AGDC, but preferably outside the context of the conference itself :-)

I know I'm not the best at maintaining a constant stream of new content up here, and I know that's important for really making this blog widely read. I try, but I also try to stay focused on interesting technical topics, and that just doesn't permit the kind of post volume required.

On days like this, though, I let out a sigh of relief: if this is the kind of interview I can expect from having a blog everyone knows about, perhaps I don't need that.

Through some roundabout way, I heard about this AI competition today; I can't tell exactly how long the competition has been going on, but according to the mailing list the cash prizes were announced today so that's probably why it showed up on my radar.

The basic gist, if you didn't follow (or have not yet followed) the link, is pretty simple: write an AI that plays Super Mario World-era Mario well, on random levels. Also, the cash prizes are restricted to conference attendees (the IEEE Games Innovation Conference in London, and the IEEE Symposium on Computational Intelligence and Games in Milan). So the contest aspect of it as a whole seems a bit uninteresting to me. Admittedly, it might be a bit more interesting to students who, cash prizes or no, would like to get their name out to the wider world.

On the other hand, it's also a platform for learning AI, regardless of contests or prizes: the game engine, the graphics, and simple examples already done and presented for you to tinker with. Whether your day job is in the game industry or completely outside it, AI is a hard thing to fall into on the job; this seems like a great opportunity to learn and demonstrate proficiency outside concerns of job performance. :-)

EDIT: Sorry, folks, I meant to save this as a draft to finish later and accidentally published it. Please re-read it now if you last saw it ending in an incomplete sentence :-)

Robin D. Laws, pen-and-paper game designer (including the cult classic Feng Shui), explains why his blog is an achingly slow source of of rules support for the games he has designed. While I was working on a live product I occasionally fielded support questions on my blog, but I saw and experienced the issues he talks about far more on the official forums. You don't have to look far in official game forums to find players asking why, even with developers participating, game design questions are answered infrequently and slowly.

Robin has the advantage of being the sole named designer for Feng Shui and HeroQuest, and he still can't answer these questions off the top of his head. When you're instead talking to a community manager, or a random non-designer (such as myself), or even the wrong designer, it gets even slower. On the bright side, when you're talking to a developer or community manager on the forums, or going through other official support channels... answering your questions is part of the job. The community manager might have tools to help track and manage questions to make sure they get answered, people in support definitely do, but for people like me it's a matter of personal discipline, memory, and note-taking to be able to get back to these a week or two (or more) after they're asked with answers.

I've written a bit here before about giving up on traditional relational databases for gathering, storing, and analyzing game metrics data. All three steps have serious scalability issues for the "one big machine" model.

However, SQL is often much more pleasant to write analytical queries in than, say, raw Java (or C++ or Python or...). So progress on a hybrid MapReduce/SQL system based on Hadoop and PostgreSQL is pretty interesting. I haven't had a chance to read too far into the announcements, or research the project itself, but it sure sounds interesting.

Some background before I get on with my point: I read, but only very rarely agree with, Darrin West's blog Online Game Techniques. I think my biggest sticking point was one of his first posts, Replicated Computing (10k Archers) where he argued that synchronized simulation¹ is a terrible idea, and a fool's errand. Since then, there has been more to disagree with, but sometimes I do agree and honestly, I feel bad for not talking about his posts more. I'd comment on his blog, but in the past authenticating sufficiently to be allowed to post comments has been an issue².

Just the same I was pretty interested in his most recent post on Web tech for "game services" because that's been an interest of mine for a while (although in this precise context I've only touched upon the issue briefly). It started as a discussion of whether to be DB-centric or not, and wound up as a discussion of how to use web services as part of the game.

Touching on both subjects a bit, I think the right approach is to treat the database as an analysis-friendly blackbox data store. The game server writes data to the database (from which anything else is welcome to read), and reads it back later, but anything interacting with the game goes through the simulation engine. Some web services, like chat log search or character sheet inspection, would work just fine reading potentially-stale data from the database. Other potential web services, like an auction house or microtransaction system, should go directly to the simulation engines, do their transaction there, and let the engine manage storing the results.

The biggest reason for this is that relational databases don't have a good way of pushing data into the simulation, but they are designed to be excellent for having data pushed into them. This isn't as noticeable with web applications, because HTTP is stateless and so the natural pattern on the web is to gather implicit state from the database in response to a request, then process the request (probably pushing results and state changes back into the database), and to finally return a result. If your game server takes this model - and it's pretty much required for web-based games, so I'm not assuming you don't or can't - then using the database as the communication medium makes perfect sense.

However, as soon as you move away from that polling model, any web services that take that traditional (web) approach will screw the entire system up. The game server isn't notified of the changes; it doesn't poll the database for the changes; the changes are quickly overwritten. The next obvious step is to have the traditional web service take an extra step - notify the simulation engine that something has changed. What changed? Well, either the web service tells the simulation what changed, or the simulator has to figure it out; in the first case, there isn't any reason to complicate your transaction by also telling the database, and in the second case... well, I'll just say that in software development you should never imply a thing when you can state it outright.

In my opinion, then, you are left with two really good options, depending on your game: following the standard web model and relying on the database to be the primary communication and arbitration layer, or taking a simulation-centric model and relying on the database as a backing store only. A backing store that is reasonably amenable to data mining and analysis, yes, but not the arbiter of truth about game state - or even parts of game state.

---

1. Synchronized simulation is an approach to client/server synchronization where you minimize 'event' traffic to clients by sharing initial state, and events thereafter that one side or the other can't predict (mostly player actions - either yours or someone else's), and otherwise don't talk to each other. It is more common in peer-to-peer multi-player games (e.g., older RTS titles), and was also the model used in Dungeon Runners (which, in a previous incarnation, was an RTS). It has its issues, but I think it is a "solved problem" to greater extent than Darrin.

2. Last time I checked, "anonymous" and "name/URL" were not options for establishing your identity for comments; as I recall the options were "Blogspot account" and "OpenID account" - neither of which I have or want to bother creating. I feel bad for not starting discussion here, but then I would want to notify him that I'm talking about him, and the crazy downward spiral continues.