Anson the Gnome

Late last year I was talking about helping the rest of the BioWare team be more productive, and I feel like I took great strides in that direction. Although I wasn't hired to work on the build system, I was tasked with making some minor improvements here and there, and I quickly realized it needed someone's full attention. By the time I left, I was able to expand the single build machine managed in spare time to a multi-platform build farm managed by a team, which is the right way to approach builds for a project of that scope.

I accomplished what I wanted - I expect to leave a lasting positive impact on the productivity of the team - and I got to work at BioWare while doing it. They're a great group of studios, and it seems like they have had a big effect on what it means (and what it's like) to work at EA. However, I came to realize that core game development was what I really wanted to be doing, and another studio was the perfect storm for me: KingsIsle Entertainment is small, but they've got a successful live game.

I like small, because it means I have more of an impact and risks are lower. However, after my time at 2K Games on a small team making a game no one will ever see, having a live game (or, admittedly, the kind of studio support that The Old Republic has) is also important to me. If it's an already successful live game? Well, that means I'm less likely to be writing this post again in a year, and I'm ready to settle down now. I started at KingsIsle yesterday, and as I get back into game dev I'll try to have more juicy posts up here. :-)

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.

I'm primarily a server programmer, but I still end up doing UI work every once in a while, and that's been true for the majority of the last three weeks. Not being an experienced old hand at UI design, I find myself falling back on first principles and decade-old books. I'm mostly happy with the results, but the code that results in implementing the interface... well, it's not the kind of code that I like to write.

One of the basic principles of interface design¹ is coherence:

Internal consistency means that the program's behaviors make "sense" with respect to other parts of the program.... One should strive towards the principle of "least surprise".

If one part of your interface shows that your sword gives you a skill bonus, everything that displays information on skills should incorporate that bonus.

Put another way, each individual part of the user interface that displays information will grow to depend on both the information it ostensibly displays, plus what every other part of the interface ever displays. Very little code is left loosely coupled to the interface: data hiding obstructs coherence, singletons and global variables spring up, even the code that takes actions based on user input gets more context-sensitive (making it hard to avoid keeping that code loosely coupled and non-repetitive), and so on.

Is this bad? Nah, not really. It's just one of the many pressures that (in the short term) pushes against loose coupling, DRY code, and good code architecture. A good UI is an important aspect of good software, including games. But sometimes... sometimes, the things I do to the code in the name of users just seems awful. :-)

EDIT: Edited for clarity based on early feedback.

---

1. Per A Summary of User Interface Design Principles. See? All my references are a decade old...

Scott already has the best picture of the vulture stalking us. We've seen him outside the office a couple of times, but this time it seemed like he really wanted us to know he was there.