/rss/rearch_dev/ Insomniac Research and Developement Sun, 14 Mar 2010 20:37:47 +0000 en-us http://www.insomniacgames.com/research_dev/articles/2010/1520939 http://www.insomniacgames.com/research_dev/articles/2010/1520939 Wed, 03 Mar 2010 08:00:00 +0000 Here’s an introduction to a method for synchronizing AI in multiplayer games. It addresses an implementation that uses the Sync Host system that was described in the previous presentation as well as outlining the methods it uses to synchronize the many different aspects of AI. You’ll find details on the rationale behind why systems are synchronized in the way that they are, as well as the problems and solutions programmers have to keep in mind when using this method of synchronization   http://www.insomniacgames.com/research_dev/articles/2010/1520338 http://www.insomniacgames.com/research_dev/articles/2010/1520338 Thu, 25 Feb 2010 08:00:00 +0000 Online functionality has become a fundamental component of our games. This is an introduction to Sync Host, a system developed to address some of the tougher issues we’ve encountered when implementing network synchronization.   http://www.insomniacgames.com/research_dev/articles/2010/1513818 http://www.insomniacgames.com/research_dev/articles/2010/1513818 Wed, 06 Jan 2010 05:00:00 +0000 An algorithm has been developed to asynchronously load, unload, play and relocate sound files without the use of locks. The algorithm allows the programmer to arbitrarily assign different logical subsections of the underlying system to different threads, all while remaining completely lock-free.   An example implementation has been developed that asynchronously loads and unloads sound files in one thread while playing and relocating the same sound files in another thread. All of this happens in a single shared memory heap, all without locking. A complete working version of this system will be described, highlighting the simple yet elegant design principles. http://www.insomniacgames.com/research_dev/articles/2010/1513819 http://www.insomniacgames.com/research_dev/articles/2010/1513819 Wed, 06 Jan 2010 05:00:00 +0000 Here's an internal presentation I gave just about a year ago on using wavelets for image compression. A nice and gentle introduction to a subject that's really pretty simple that is often buried under so many details that people don't know how to approach learning it. http://www.insomniacgames.com/research_dev/articles/2009/1500796 http://www.insomniacgames.com/research_dev/articles/2009/1500796 Fri, 23 Oct 2009 04:00:00 +0000 A basic introduction to the concept of a colorspace for artists, programmers, and anyone who's just curious about the meaning of terms like "sRGB, "gamma," and "color profile." Talks about where colorspaces come from, what they look like, and why you might need to think about them. http://www.insomniacgames.com/research_dev/articles/2009/1500757 http://www.insomniacgames.com/research_dev/articles/2009/1500757 Mon, 21 Sep 2009 04:00:00 +0000 The Dynamic Component System is now firmly established in our gameplay architecture. We’ve realized substantial benefits in workflow and performance from implementing gameplay as Dynamic Components. In this presentation, I provide a brief introduction to a few gameplay systems of Dynamic Components. http://www.insomniacgames.com/research_dev/articles/2009/1500943 http://www.insomniacgames.com/research_dev/articles/2009/1500943 Sat, 15 Aug 2009 04:00:00 +0000 This presentation was an introduction to solving concurrency problems. In particular it was about breaking down previously held beliefs and approaches that in fact make multi-threading and multi-core problem solving seem much more difficult than it actually is. The key is understanding that concurrency is not a code problem, it's a data problem. It always comes back down to the data. I used a doubly-linked list as a reference point in this presentation in order to demonstrate that the "classic" data structures are actually "sequential" data structures and that by looking at concurrency problems from a data design point of view you'll find that those data structures in general, and doubly-linked lists in particular are *not* concurrent data structures. Certainly you can make them work, as many people have, but you're forcing an inherently sequential data design into a concurrent system and you're going to be paying a price in terms of both added complexity and performance loss. These slides are hopefully readable on their own. So enjoy! And remember we're always happy to get feedback. http://www.insomniacgames.com/research_dev/articles/2009/1500942 http://www.insomniacgames.com/research_dev/articles/2009/1500942 Fri, 14 Aug 2009 04:00:00 +0000 Here's a GDC presentation outlining our SPU job-manager and some tried-and-tested SPU debugging practices - it touches on details such as job-layout, the job-building process and some of the debugging assistance it provides - it concludes by walking through two debugging case-studies from Resistance 2. http://www.insomniacgames.com/research_dev/articles/2009/1500769 http://www.insomniacgames.com/research_dev/articles/2009/1500769 Fri, 10 Apr 2009 04:00:00 +0000 Fundamentally, the system simulates waves propagating across a planar surface. Each component wave is a sinusoid, and a detailed height field is generated by summing many such waves. The Fast Fourier Transform (FFT) provides an efficient way to perform the accumulation of the waves. For general background in this technique, see the classic paper by Tessendorf. The paper describes the method used for creating ocean water in the film ‘Titanic’, where the offline generation of images provides the luxury of using very large arrays in the FFT calculations – 2048 × 2048 grid points, with a grid resolution of 3cm. In real-time applications though, it quickly becomes apparent that the size of FFT array must be severely restricted. Consider also the need to render views in which details smaller than 3cm are visible. Our solution is to combine detail at many different scales. We employ only 32 × 32 FFTs, but many such height fields are summed from long wavelengths down to short wavelengths as required by each particular viewpoint. This is not unlike rendering fractal terrain, the major difference being that in the case of water the detail added at each level of detail (LOD) must be animated in a particular way.   We decided early on to devote much of the development budget to the modelling of interactive waves – waves emitted by local disturbances such as the impact of a projectile or a character wading through the water. The result is that while we feel the system is still lacking in certain features, we believe it demonstrates a technological first in games: interactive waves with the property of dispersion (a physically-based dependency between wavelength and wave velocity).   Full details: water.pdf Source code (via Nocturnal Initiative): Nocturnal_igR2O_1.0.zip http://www.insomniacgames.com/research_dev/articles/2009/1500846 http://www.insomniacgames.com/research_dev/articles/2009/1500846 Fri, 10 Apr 2009 04:00:00 +0000 This year I spoke at GTC about how a physics solver works. My intention was to provide a simple run-through of rigid bodies, constraints, and how they are used to pre-condition a solution. The presentation is meant to be comprehensive for everyone, so regardless of math background the information should be relatively easy to grasp. My hope is that this presentation will demystify how core solvers work. As a supplement to the presentation, I’ve provided source code for a simple 3D constraint solver which you can find on our nocturnal site. I encourage you to download the source code and experiment with it. I’d also like to point out that the solver does not have to be used for physics, as illustrated in my presentation.   Source code (via Noctural Initiative): Nocturnal_SolverExample_1.0.zip Presentation: Physics_GTC_2009.pdf   http://www.insomniacgames.com/research_dev/articles/2009/1500921 http://www.insomniacgames.com/research_dev/articles/2009/1500921 Fri, 10 Apr 2009 04:00:00 +0000 This presentation, given as part of the Insomniac tutorial at GDC 2009, describes some of the systems and conventions used to support gameplay code on the SPUs. http://www.insomniacgames.com/research_dev/articles/2009/1500923 http://www.insomniacgames.com/research_dev/articles/2009/1500923 Fri, 10 Apr 2009 04:00:00 +0000 Resistance 2 had a big dynamic lighting overhaul from previous Insomniac titles. Here Mark Lee describes the new lighting and shadowing schemes used and touches on some of the implementation gotchas. http://www.insomniacgames.com/research_dev/articles/2009/1500924 http://www.insomniacgames.com/research_dev/articles/2009/1500924 Fri, 10 Apr 2009 04:00:00 +0000 This year I had the opportunity to be part of Insomniac’s all day tutorial for GDC. I gave a presentation on Insomniac’s proprietary physics system, describing the evolution of its pipeline from inception to current day. In this presentation I explain the importance of optimizing a system for the SPU via shaders (isolated code fragments) and library shaders, as well as explaining the importance of good data design for optimal concurrency.   http://www.insomniacgames.com/research_dev/articles/2008/1500931 http://www.insomniacgames.com/research_dev/articles/2008/1500931 Wed, 19 Nov 2008 05:00:00 +0000 Continuing our For Everyone series. Chester Hsieh (Associate Engine Programmer) had a go at describing how normal and cube maps work to the general studio population. This presentation is for the curious that might want to know a bit more about the math and logic behind these very common texture maps. http://www.insomniacgames.com/research_dev/articles/2008/1500933 http://www.insomniacgames.com/research_dev/articles/2008/1500933 Wed, 19 Nov 2008 05:00:00 +0000 Heather Barclay (Multiplayer Lead Programmer) gave an introduction to the programming team on our approach to synchronizing the network data for Resistance 2 Co-op mode. For those of you playing the game now, you know how crazy these games can get, and yet everything stays pretty smooth (for the most part). Enjoy! http://www.insomniacgames.com/research_dev/articles/2008/1500934 http://www.insomniacgames.com/research_dev/articles/2008/1500934 Wed, 19 Nov 2008 05:00:00 +0000 In February, we gave a presentation to the Sony first-party studios on how we progressed during the development of Ratchet and Clank Future: Tools of Technology. The purpose of these presentations is to share with other developers and to give hints to the things that improved our development process. And not just our engine or tools technology, but anything that we think might be helpful. I've culled out a few slides due to NDA, as well as a couple that might have caused forum meltdowns. But otherwise, this should hopefully provide a good inside look into some of our processeses as well as the tech changes we made during RCF. http://www.insomniacgames.com/research_dev/articles/2008/1500926 http://www.insomniacgames.com/research_dev/articles/2008/1500926 Wed, 02 Jul 2008 04:00:00 +0000 Driven by hardware design and media requirements, sound file formats are constantly changing. For example, on the PS3 we encode and decode an AD-PCM format for the majority of our sound sources during playback. On computers and portable music devices, most of you will listen to perceptually-coded, lossy, variable bit-rate MP3s. Those who still have CD players will listen to CDDA-encoded, signed 16-bit PCM sampled at 44.1 kHz. And sound designers will work mainly with chunked file formats like WAV and AIFF that give them flexibility in storage, playback and interoperability.   In this talk, David will demystify all the jargon. You won't walk away an audiophile, but you'll definitely understand the difference between a VAG, CD-based PCM and an MP3.   Who should check this out? Anyone with an interest in learning more about sound file formats.   http://www.insomniacgames.com/research_dev/articles/2008/1500927 http://www.insomniacgames.com/research_dev/articles/2008/1500927 Wed, 02 Jul 2008 04:00:00 +0000 A year ago, we talked about a Gameplay Architecture for Performance, and since then, we’ve been hard at work putting our ideas into practice. The Dynamic Component System is our way of expressing gameplay in bite-size chunks that can be added to and removed from the game as needed. Dynamic components represent aspects of a game object or system’s behavior. They are allocated and deallocated on-demand from efficient memory pools, they’re hierarchical, and client code can query for an object’s component of a given type or a component that implements a given interface. Because of the way components are pooled, it is straightforward to run updates for a given component type in parallel with other component types, and on a different processor such as an SPU. http://www.insomniacgames.com/research_dev/articles/2008/1500929 http://www.insomniacgames.com/research_dev/articles/2008/1500929 Wed, 02 Jul 2008 04:00:00 +0000 What does a next-gen engine look like? Well, for one thing, it needs to take advantage of the multi-CPU architectures. Scalable systems don't just happen, they're designed that way. I was lucky enough to give a presentation at Sony Devcon 2008 about how the Cell (and multi-core architectures generally) need to influence the design of gameplay systems. Designing your gameplay to work with deferred systems is an important step to scaling your performance with future platforms. I hope that this illustrates some of the planning that should go into place to eliminate "gotchas" when writing your next-gen gameplay code. http://www.insomniacgames.com/research_dev/articles/2008/1500841 http://www.insomniacgames.com/research_dev/articles/2008/1500841 Sat, 26 Apr 2008 04:00:00 +0000 Usually in presentations, what we (or anyone else really) usually give to the audience are answers (hopefully!) to some interesting problem. Especially when it comes to optimization techniques. It seemed to me there was a big gap there - certainly a lot of people can simply use the answers to make their code/game/application faster, but how do they get better at solving these problems themselves? Usually the answer is simply, "with experience."   But maybe there's more we can do. In this talk, I wanted to focus on the PROCESS that I (personally) went through to optimize a particular function. Including all the little mis-steps and shortcuts I took along the way. The hope was that people would find that the process itself isn't something magical and it's something that can be learnt.   Although there are some people *cough*John Edwards*cough* that might tell you make sure you get another opinion on your optimization advice. ;)