Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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??

share|improve this question

closed as not constructive by michael.bartnett, ClassicThunder, doppelgreener, ashes999, jcora 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.

oop and functional are not mutually exclusive. You can use oop to model data and how it is manipulated and still use functional to perform the manipulations. – zehelvion Sep 30 '12 at 9:54
oh and I am pretty sure Object oriented is a type of, or an extension of Imperative programming. Also I don't think it is a "one ring to rule them all" situation, each strategy has benefits and it would be hard/impossible to give an answer that completely satisfies the question. They are both tools that can accomplish various tasks. Related question:… – zehelvion Sep 30 '12 at 10:02
By looking at votes (or lack of), not only I am confused by the topic. I'd say: focus on the effect, and achieve it the easiest way possible, or use such practices that you find best in your experience. – Markus von Broady Sep 30 '12 at 11:47
There is no best paradigm. Do whatever suits you. (What happens to suit quite a lot of people is OOP.) – doppelgreener Sep 30 '12 at 11:50
up vote 1 down vote accepted

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.

share|improve this answer

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:

share|improve this answer
A programming paradigm isn't limited to a certain language. – jcora Sep 30 '12 at 14:15
Yeah, true, still I would think certain languages lend themselves well to certain paradigms. Right? – zehelvion Sep 30 '12 at 14:17
True, but "paradigm" is a very broad term. – jcora Sep 30 '12 at 14:18

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.

share|improve this answer

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.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.