Which programming paradigm resembles or best suits the Game design or game engine programming? by paradigm I mean the Imperative, Object oriented, Functional, etc. I came to know that functional programming is more modular than object oriented and is concurrent. is it??
closed as not constructive by michael.bartnett, ClassicThunder, doppelgreener, ashes999, jco Sep 30 '12 at 14:15
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.
Data oriented design/programming. It means that you consider your data before everything else. This does not exclude OOP where it fits, however this most certainly excludes "all things object oriented". Same goes for functional and just about any other paradigm.
However, there is no need to try and limit yourself to some style of programming or thinking. Try different things. See what works, check if something could work better, work on that. Repeat. The more you learn, the more you develop your coding style. Limiting yourself to some certain "best practices" is worse than shooting yourself in the foot - not only you will miss out on some of the good stuff, you'll also make programming boring to yourself that way.
Nowadays, most games are written in C++, with Java and C being popular alternatives. Two of these are object oriented and the third is not 'functional'.
A lot of casual games are written in AS3 which is also oop.
I am pretty confident that if you base your decision on what most experienced programmers are doing today, using object oriented would come as a first choice.
However, if you are writing a game for learning purposes or simply prefer functional programming than obviously, you can probably make decent use of it.
My answer is based on this wiki article: http://en.wikipedia.org/wiki/Game_programming
This is an open ended question. There is no way to answer it properly as it depends on countless factors. There are exceptions, but if you want a general rule functional programming is not used for game engines. The rest depends on the projects the kind of games, the libraries and SDKs you will primarily use (on consoles, PC, mobile, and other dedicated hardware/systems)... and on the team.
Languages with functional subsets are sometimes used in the video games industry. But the successful projects I am aware of are using these languages mostly for the easy deployment across nodes to provide a distributed service (i.e. leader boards, data and metadata storage, matchmaking and game lobby management).
A game engine is usually built to provide functions which already exist but with an emphasis on performance. The use of mutable variables is key to insuring good performances which a functional language will not deliver.
The way you organize your data will mostly depend on the underlying architecture. But as a rule of thumb most data (positions, physics, models) will be stored in raw arrays of float or doubles in order to allow for fast parallelized operations (OpenGL, OpenCL, vDSP hardware acceleration libraries...).
But how you access to this data is your business. You can use objects, functions where you pass pointers, whatever.
The emerging practice in game engine is the component (or entity) based architecture where game objects are not represented by specialized objects providing functions but with entities which are no more than a key or a collection of components which are designed to interact with each other.
Factors like what is the real aim of your game engine might influence the language and paradigm used. Do you need an engine destined to one platform? Or is your engine a middleware which will abstract access to dozens of underlying OSes and SDKs (OpenGL, OpenAL, DicectX...). In the first case you will probably align your architecture around the existing SDK, in the second case you might want a good object oriented architecture to hide all the different implementations (which might be done using a non object approach).
Back on the functional programming; you might be tempted to use such an approach for a large server based game. But for the vast majority of games the client-side and server-side code are shared to some extent. And the game industry has very few experienced programmers in the field of functional programming which makes it a non obvious choice in this field.
I hope this helps.
Looking over your question I can't help but feel that you're going at it the wrong way around. You're trying to shoe-horn a problem into one of a number of pre-defined solutions, instead of building a solution around the needs of solving the problem.
The truth is that game programming is a multi-paradigm task. You don't need to have to choose one pizza from a (limited) selection beyond which you cannot go; you need to choose your own pizza with your own selection of toppings in the proportions that satisfy your own appetite and tastes the best.