Ask me anything
Recent Responses
-
-
Yes. As personal computing moves onto the web and the web moves onto the television, the browser becomes a convenient place to play the games that have traditionally been played on a console. Many of the high-performance techniques used on consoles have not been available in the browser, but that's changing rapidly. Upcoming versions of Flash and Silverlight will enable support for hardware accelerated 3D graphics, and rather sophisticated games techniques are already available in the browser through the Unity plugin. There are still substantial performance limitations, since for security reasons, each environment abstracts-away the platform from the perspective of the game developer. So I think game consoles will continue to have a substantial "fidelity" edge for the foreseeable future, and certain genres benefit greatly from that fidelity. But the explosion of mobile and social gaming have demonstrated that using cutting-edge technology isn't the *only* way to make a great game. I expect over time, console manufacturers will need to find new ways to differentiate their products with features not available to a browser. Wii, Kinect, and Move (from each of the major players) are good examples, but they won't be enough. It won't be long before we can use kinesthetic and AR techniques in a browser.
Thanks for your question! -
We used different techniques to handle update order dependencies, depending on the specific case. One technique that we used commonly was to break updates into different stages of the game update loop. So for example, any updates that happened in the 'PreUpdate' stage are guaranteed to be finished by the time the 'PostUpdate' stage begins. Each component type can specify during which stages it wants to update on the PPU, and during which stages it wants to update asynchronously on an SPU.
-
Hi Mr. Hodara. Thank you for your question. The 'chain' is basically a bridge between the traditional Game Object model and the component-based model. A Game Object or other system has a chain member, which is the head of a list of component handles that conceptually "belong" to that Game Object or system. The chain acts like a linked list, but uses indices into an array of ChainLinks instead of pointers. That way, the DCS owns all of the data related to the system. Ideally, the chain is not used often, but rather operations are performed on all instances of a component type as a batch. (That's much better for performance.) But there are rare cases where you want to iterate over the components that belong to a particular host. For example, when a Game Object is destroyed, you want to free all of the components that belonged to it. Another example in our case was HealthModifiers: when a Game Object takes damage, the Health system wants to give each of the GO's HealthModifiers a chance to modify the damage. (HealthModifier is a base class of other component types.) Hope that helps! Thanks again, Terrance.
-
No. If there were, they would have had more time to develop interstellar travel than we have (since our solar system is relatively young). Since we as a society are relatively close to having that capability (perhaps a few hundred years), there would have been many other races of intelligent life that would have had plenty of time to develop interstellar travel. And with a head start of thousands of years, they would have populated the galaxy. So there's no intelligent life on other planets because they would have made it to Earth many times over by now. [This is an argument that Larry Niven presented to me on May 26, 2010 at the launch event for The Unincorporated War.]
-
Ah, good question. In my presentation "A Dynamic Component Architecture for High Performance Gameplay" (http://www.InsomniacGames.com/research_dev/articles/2010/1530793) I say that all operations (except searches) have small constant-time cost, which is correct. But I also said that a component handle contains the component's Roster index, which is incorrect. Rather, a component handle contains the component's Pool index. Since components are never copied by the system, their pool index never changes. The base Component class contains its Roster index. Constant time allocation is simple because we can just grab the next free component from the Roster (if any). Constant time deallocation is achieved by taking the component's Roster index, manipulating the Roster as illustrated in the presentation, and storing the new Roster index back into the component. It's not quite as cache friendly as I represented since we have to access the component data in addition to the Roster. But it is still constant-time.
Thank you for bringing the error to my attention. I will fix it in the presentation.
Just checking if anyone's paying attention. 8-) -
Thank you, groby, for your excellent question!
Many of us intuitively felt that sharing some of our answers to common game development problems would be a good thing™ for everyone involved. The vision and credit for actually doing it goes to Mike Acton (Engine Director) and Geoff Evans (Tools Programmer), and to Ted Price (CEO) for giving it the green light. Mike takes it a step further, and says, “My personal view is that it’s a moral imperative. I got here because I learned from others. I must pay that back or I’ve essentially stolen from the community. i.e. Standing on the shoulders of giants. And that extends to all of us.”
We’re sharing what we consider to be good answers to questions that just about every developer has to address. By doing so, we hope to allow studios to focus more on what sets their games apart from others, and less on the basic building blocks necessary to create a modern game. We hope this will result in studios making better games in less time, and thereby benefit the industry as a whole. If it helps the development community make better games even in a small way, that can only be good for us – better games means more people buying more games. It’s that simple.
If you'd like to see our presentations or check out our source code, please visit these links:
http://www.insomniacgames.com/research_dev
http://nocturnal.insomniacgames.com -
There isn't any music I can't stand. There's a lot of music I don't like, and a lot that I do. These days, I'm listening to HIM, Opeth, and Katatonia. I also like Yanni, Live, Tears for Fears, Queensryche, and Epica. Random, huh? I prefer to call it, "Diverse."
-
Terrance Cohen’s Bio
Los Angeles, CA
I'm the Lead Systems Engineer at Insomniac Games. I've worked on titles including Bioshock, Resistance, Medal of Honor, SWAT, Tribes, and Ratchet & Clank. I specialize in balancing game architecture for convenience and performance.
