Insomniac Games Shares Technology

One very nice habit of Western game companies is that many of them share their technical knowledge with competitors. Insomniac Games is a very good third party console game developer that has concentrated mostly on the PlayStation platform. Their recent games include the shooter "Resistance Fall of Man" and the action platform Rachet and Clank series.

At this year's GDC they announced the "Nocturnal" initiative. It's not a whole game engine, but rather a collection of useful utilities. Things like logging code, C++ object serialization, and a cross-platform performance monitor. Some of the utilities are Playstation 3 specific, but most are applicable to any modern game platform.

Much of this code would be right at home in a "Game Gems" book, but it's even better to have it freely available, on the web, with a BSD-style license. Good for you Insomniac!

Insomniac also publishes technical papers in a GDC-presentation-like format on their Game R & D Page.

Why do so many game companies share information like this? I think it's for a number of mutually supportive reasons:
  1. It's a form of advertising, to show off how smart and competent the developers are. This is helpful in attracting job applicants and impressing publishers and game reviewers.
  2. It educates all game developers, some of whom will eventually end up working for the original developer.
  3. It encourages other developers to share their technology, which benefits the original game developers.
  4. It reduces the value of middleware, driving down the cost of middleware.
Game developers can give away source code because, unlike other kinds of software, the major intellectual property in the game is in the copyrighted and trademarked art assets, (the data) rather than in the code. Yet, at the same time, game quality is directly tied to the performance of the code. This creates a unique economy in which it is profitable for game developers to exchange performance tips with their competitors.

And it's a lot of fun for armchair developers like me. Now if only we can get Naughty Dog to open-source their GOOL and GOAL Lisp-based game engines. :-)

Comments

Post a Comment

Popular posts from this blog

GLES Quake - a port of Quake to the Android platform

I've just published the source code to a port of Quake to the Android platform . This is something I did a while ago as a internal test application. It's not very useful as a game, because there hasn't been any attempt to optimize the controls for the mobile phone. It's also awkward to install because the end user has to supply the Quake data files on their own. Still, I thought people might enjoy seeing a full-sized example of how to write a native code video game for the Android platform. So there it is, in all its retro glory. (Porting Quake II or Quake III is left as an exercise for the reader. :-) What's different about this particular port of Quake? Converted the original application into a DLL Android applications are written in Java, but they are allowed to call native languge DLLs, and the native language DLLs are allowed to call a limited selection of OS APIs, which include OpenGL ES and Linux File I/O. I was able to make the game work by using Java for: T
Read more

A Taipei-Torrent postmortem: Writing a BitTorrent client in Go

This is a BitTorrent client. There are many like it, but this one is mine. -- the BitTorrent Implementer's Creed For fun I've started writing a command-line BitTorrent client in Google's go programming language. The program, Taipei-Torrent , is about 70% done. It can successfully download a torrent, but there are still lots of edge cases to implement. Go routines and channels are a good base for writing multithreaded network code. My design uses goroutines as follows: a single main goroutine contains most of the BitTorrent client logic. each BitTorrent peer is serviced by two goroutines: one to read data from the peer, the other to write data to the peer. a goroutine is used to communicate with the tracker some "time.Tick" goroutines are used to wake the main goroutine up periodically to perform housekeeping duties. All the complicated data structures are owned by the main goroutine. The other goroutines just perform potentially blocking network I/O using channel
Read more

A Multi-threaded Go Raytracer

Image
Above is the output of the raytracer. Below is a diagnostic mode showing which goroutines raytraced which section of the screen. Each goroutine has its own color to outline the pixels it traces: I wrote a simple multi-threaded ray tracer in Google's new "go" language. It's an adaptation of Flying Frog Consultancy's Raytracer . It runs single-threaded about 1/2 the speed of a comparable C++ version. I guess the C++ version benefits from a more optimizing compiler and the ability to inline small functions. Compared to ordinary C/C++, the Go version was easier to multithread. On my dual-core Macbook Pro I get an 1.80x speedup when running with GOMAXPROCS > 1: $ GOMAXPROCS=1 time ./gotrace 1.52 real 1.50 user 0.01 sys $ GOMAXPROCS=2 time ./gotrace 0.82 real 1.50 user 0.01 sys $ GOMAXPROCS=3 time ./gotrace 0 .81 real 1.50 user 0.01 sys On an eight-core, 16 Hyperthread HP Z600 running Ubuntu 9
Read more