Saturday, May 15, 2010

3D Challenge

We are holding a 3D modelling challenge with the help of society and several notable others for aspiring and experienced game artists. You can read every thing about it over here.

Let all the artists know about this event.

Friday, May 07, 2010

To OOP or not to OOP !!

Object Oriented Programming has been the buzz word for quite a long time in computer programming. The concept has even leaked to higher level issues such as OO Design and OO Analysis.

Just like any other buzz word in the world of information technology, Object Oriented programming has received much more attention than what it deserves.

But what does it really do? We all know that eventually all code written in a programming language needs to be translated into machine code and once in machine code, it is all the same, no matter writing your code in VB or python, it will end up in a unified language of instructions which the target machine knows well.

Object Oriented Design/Programming, is a way of adding a few conceptual layers between the problem domain in our real world and the instructions which need to be run by the target machine, a way of making a smooth transition between the layers of abstraction, a way to help our mind understand the problem and find a proper solution for it. After all, Object Oriented Programming is something to help us human beings overcome our limitations and be able to make better computer programs. Some argue that Object Oriented Programming brings with it new functionality which was not possible to have before such as Inheritance and Polymorphism, however, simple C structs and function pointers are all that you need in a structure programming language such as C to simulate inheritance and polymorphism.

All of these added values toward writing easier code for the programmers come with costs, sometimes huge costs. In other words intellectual manageability which is probably the most important aspect of Object Oriented Design comes with major costs, the most significant side effect is always performance.

Real-time simulation software have usually performance high on their priority list and so Object Oriented Design in such programs, such as games, needs some second thoughts. Such applications usually see their world as groups of data rather than groups of objects which contain data and behavior, unlike the way we see our world.

An example for the above is the way the main loop for a physics simulation engine works, all it cares about is a few data related to the physical properties and for it, other properties of an object such as its visual properties, sound and game related meta data is of no use.

In these cases, when a part of an application needs to work on specific data, in order to best utilize the system cache and increase the performance, it would be best to provide the relevant data to the sub-system rather than pushing in a whole object containing lots of data, just because handling the code in an object oriented manner is easier for us programmers. Multi-Processing can be managed easier once related data is batched together.

Enter Data Oriented Design. A rather harder way to look at the problem domain and to model which is by far easier and more efficient to process by the machine.

A very good article regarding Data Oriented Design can be found here:
Data-Oriented Design (Or Why You Might Be Shooting Yourself in The Foot With OOP)

And another very inspiring article is from Sony Research:
Pitfalls of Object Oriented Programming

Also a very nice presentation by Mike Acton:
Three Big lies: Typical design failures in game programming