Anson the Gnome

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.

I was kind of amused this morning when I noticed that the new box of coffee we opened shared a name with today's Penny Arcade hero. I convinced one of our artists our art production manager (THE Jon Jones) to whip up something appropriate for this mystical brew that absorbs light. Continue reading "black ensorcellings" »

Yesterday evening I got an email announcing the GameX Industry Summit CFP, but I was kind of surprised by the description: "Our summit is structured in a two-track format, with a 'Right Brain' Creativity Track and a 'Left Brain' Leadership Track." The latter track is clarified to mean that "The Left Brain track will reveal the best practices, business strategies and production methodologies which result in successful, shipped titles. This track can include appearances by studio heads, producers and notable games industry businesspeople."

It makes sense to have a track centered on the creative side of game development, and it makes sense to have a track covering the business side of game development. I can even see some logic in not inviting programmers to a conference like this, the same way that there are sometimes events that are less interested in the business side of making games, events specifically for programmers, and so on.

But I'm a bit hung up on a conference that separates a conference based on lateralization of brain function such that marketing is a left-brained activity. It also seems to convey that, since they are covering the entire brain somewhere in the conference, they are covering the entire development process, and all the different tasks people do in making a game.

Perhaps it's just my left hemisphere insisting that everything adds up correctly, perhaps it's seeing my discipline left out in the cold with the implication that it doesn't even exist... but the good news is that I don't have any reason to put effort into a proposal for the summit, nor do I need to consider attending. :-)

The previous post about UI design vs. code architecture has been heavily edited. I try not to edit posts after they've gone out, but I got a lot of feedback that I was rambling and the subject of the post wasn't at all clear.

Plus nobody commented here, so I didn't feel like I was pulling the rug out from anyone!

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...