A Client/Server Tools Architecture


I mentioned Insomniac’s client/server tools architecture during my GDC talk earlier this year, and this topic has generated considerable interest. This article gives a very high level overview of the system as it is currently implemented.

All interactive productivity tools developed over the last two years at Insomniac Games have been built on this architecture. The basic idea is that the edited document is not kept in the memory space of the editor application itself, but rather each individual modification is transmitted to a server application, running on the same machine as the editor. The server maintains the authoritative document. Any number of documents may be open at any time. Any number of editors may communicate with the same local server application. The server provides various document related services.
Read more →

A student had been sitting motionless behind his computer for hours, frowning darkly. He was trying to write a beautiful solution to a difficult problem but could not find the right approach. Fu-Tzu hit him on the back of his head and shouted, “Type something!” The student started writing an ugly solution. After he had finished, he suddenly understood the beautiful solution.
Marijn Haverbeke Eloquent Javascript

Assertions in Game Development, Part 2

In Part 1, I discussed the so-called “skippable” assertion, which is ever popular in game development. This form of the assert macro may detect a precondition failure, display a message, execute a fix-up or bail out, and allow the program to continue to run “with its fingers crossed”. In game development, this is essential, because it allows the content team, who rely on the unfinished game executable to continue working. The drawback is that skippable assertions present their error messages to everyone and anyone, resulting in a very poor signal-to-noise ratio, and therefore end up getting ignored.

I also discussed “tagged” assertions, which attempt to remedy this aimless spamming of error messages by tagging each assert macro with a likely recipient. But this ends up sending too many messages to the author of the libraries. The assert system need to identify the target programmer more accurately.

And that is what we’ll be doing next.

Read more →

Assertions in Game Development, Part 1

Assertions in game development pose a particular problem that is unique to our industry. In other software development industries, software is generally developed and thoroughly tested, before it is delivered to the users. But in game development we offer half finished, barely tested versions of our work to our users. No, not to the consumer (hopefully), but to the artists and designers on our team. The content team. They are users, too. In order to put awesome content into the game, they need to be able to run it every day, stable or not, so they can see their work in its proper context.

Read more →

Featured Posts

Back from GDC 2012

GDC12 Flash Forward

Back from GDC 2012. This was my first public speaking experience. Nervous as hell but everything went great. The best part: when people asked questions during the Q&A, and afterwards, it became clear to me that they had actually understood what I said. And that is awesome! Will definitely do it again.

Read more →