# How to make a game without OOP? [closed]

I am currenty studying game development and practicing making games.

I use a lot of OOP in my games. For example, each missile that is shot is an instance of a Missile object, and added to a list of Missile objects. Each tank in the game is a Tank object. Etc.

The entire design of the program is based on this. For instance, having a list of Missile objects allows me every frame to move the missiles, draw them, etc. And having an instance of a Tank object for every tank allows me to check for each tank if it collides with something, etc.

It's hard for me to imagine how a game (which is more complex than Pac-Man) could be programmed in a non-OO language. (With no disrespect to non-OO programmers of course). Not only in terms of how long it will take, but mostly in terms of how a game could be designed this way.

I can't imagine designing a game without using object oriented programming, because my entire understanding of how to design a game-program is based on OOP.

I would like ask: Today, are there any games that aren't programmed using OOP, in a similiar fashion to what I described above? Are there any 'professionl' games that don't use OOP as a major factor in the development process?

If so, could you give me an idea of how, for example, collision detection between a tank and N number of missiles could be implemented, without OOP?

## closed as too broad by Josh♦Feb 7 '14 at 16:23

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

• Is this a philosophical question? Even if you don't call your tanks "objects", you're probably going to want "entities", "actors", "agents", "structs" or just some other name for the same idea, which is a collection of attributes and behaviours that make up a rotating cuboid thing with a turret that can shoot things, called a tank. Programming languages will have different ways of formalising this same idea, but in the end, it's going to be a tank. – Anko Feb 7 '14 at 14:09
• Many games use a Component-based system as this answer describes: gamedev.stackexchange.com/a/31491/9366 – John McDonald Feb 7 '14 at 16:08
• This is both exceedingly broad (which you could possibly fix by narrowing the scope) and not really specific to game development (since building software without OO techniques is not something a game developer would give you a better answer than any other software developer would), which makes it off topic here, I'm afraid. – Josh Feb 7 '14 at 16:26
• It may be suitable for StackOverflow, or you can check out the help center to find a selection of sites that are game-development specific (like GDNet) that would permit this sort of broad, discussion-oriented topic. Good luck! – Josh Feb 7 '14 at 16:26

I can't imagine designing a game without using object oriented programming, because my entire understanding of how to design a game-program is based on OOP.

Then it will probably be good for you to try writing some programs in non-OO style. Even if you discover that this is not pragmatic for you, you'll probably learn a lot along the way that will help you in the future.

OO style is pretty well-suited for games because games are almost always about manipulation of stateful objects. A laser beam hits the robot and the state of the robot changes while its identity remains the same.

However it is possible to program games in a functional style. In a functional style, state doesn't change per se. Objects are immutable. Rather than changing objects, you ask the question how would the universe be different if I changed this? and then produce an entire new universe that has the changed property. Of course, you can re-use a lot of the previously existing universe because it is immutable.

In functional programming every function must compute its return value solely from the information passed in; there's no reading from "global state".

If you do this, the fundamental problem you will have to get through your head is that every update is non-destructive. When the laser hits the robot you don't change the robot's state. Ultimately you compute an entirely new universe identical to the old universe except that the robot has a different state; if you need that old universe, it's still there, unchanged.

This series of blog articles has more thoughts on writing games in a functional style:

In fact, just read the whole blog. There's good stuff there and the articles are short.

Any object-oriented program can be refactored to a procedural program by replacing all classes with structures and converting all member-functions into stand-alone function which take the object which would be this as an argument.

So

 missile.setVelocity(100);


becomes

 setMissileVelocity(missile, 100);


or when that function is trivial, you just do

 missile.velocity = 100;


The main difference between object-oriented programming and procedural programming is how you treat your data. In OOP, data is smart. It manages and manipulates itself. But in procedural programming, data is dumb. It doesn't do anything on its own and needs to be manipulated from the outside.

When you even consider structures too object-oriented, you can replace one array of structures with multiple arrays, one for everything which would be a variable of a missile. So

struct Missile {
int x;
int y;
int velocity;
}

Missile missiles[256];


becomes

int missileX[256];
int missileY[256];
int missileVelocities[256];


In this design, a function which does an operation involving multiple attributes on the same missile would now take an array index instead of a reference to a structure. Its implementation would look like this:

function updateMissilePosition(int index) {
missileX[index] += missileVelocity[index];
}

• But missile is an instance of an object. In non-OOP, there are no instances, am I correct? If so, how could you do setMissileVelocity(missile,100)? – user3150201 Feb 7 '14 at 9:16
• @user3150201 You aren't entirely correct. Most non-OOP languages (and I would argue just about any which is suitable for serious game development) supports structures. A structure is kind of like a class, just that it contains nothing except public variables. So it would allow you to create a type Missile, which is a structure with several fields, like x, y, angle and velocity. – Philipp Feb 7 '14 at 9:25
• @user3150201 Updated answer with a section about how to do it without structures. – Philipp Feb 7 '14 at 9:48
• Nice answer Philipp, although, I don't understand why would one doesn't want to program Object-Oriented. It's really hard to read non-OOP languages, and can be fustrating. The code can become a mess in no time. – Zhafur Feb 7 '14 at 10:14
• @Zhafur You are aware that your statement is a massive flamebait, are you? – Philipp Feb 7 '14 at 10:17

I do it as follows:

• All OOP classes/methods have access to this. In order to utilise this in a non-OO approach, simply pass in whichever instance (see next point) this should be, as the first parameter.
• Now, as for instances, you can pass structs into your functions as this, but I find the best way to achieve good cache performance for objects which are prolific, such as entities or particles, is to simply pass a single index into several arrays of primitives or small structs. So this index is used for each individual data member of the original class. So for instance if you had

...

class Entity //let's say you had 100 instances of this
{
int a;
char b;
function foo()
{
.../*can access 'this' herein*/
}
}


You would replace that with

int a[100];
char b[100];
function foo(int index);


So that you are now passing an index into the function to get what would usually be this.

Bear in mind that you may wish to use either arrays of primitives as above, or arrays of structs, depending on how best to interleave your data for good cache locality (locality of reference). Of course, decent cache performance relies on a lot more than this -- particularly, what language / platform you are writing your code on -- but even in VM-based, dynamically-allocated languages like Java, large linear arrays of primitives tend to display better performance characteristics than object instances. The main reason for this is that objects are accessed by reference and this means you are jumping all over memory to access data -- inefficient compared to accessing primitives contiguously from a large array.

For more information on building entities etc. as array of structs or primitives, see Mick West's Evolve your Hierarchy.

In addition to the existing answers you may want to know how to do polymorphism in a procedural language.

There are two approaches:

Storing the type

In this case the struct has a field for the type identifier, probably an enum, that's checked using a switch statement when type specific action needs to be done.

The other way is:

Storing function pointers

You didn't mentioned which programming language you have experience in, but in various languages they are also called callbacks, delegates, events or high order functions or simply function objects.

In this case you won't store a type, but store a pointer/reference to a function that does the particular action. When type specific action needs to be done, you simply call this function. This one looks much like the ordinary virtual methods.

By allowing setting each function independently you get the strategy pattern free.

Regarding your last paragraph with the collision detection. I think you probably have multiple kinds of tanks and you have multiple kinds of missiles, and each combination can potentially have a different outcome when they collide. If this is what you look for, you have a problem that's not yet solved by even OOP languages: multiple dispatch and multi-methods that can have multiple this parameters of different types. For this problem there again two alternatives:

• Nested switches for each combination of tank and missile.
• Two dimensional dispatch arrays, which contain pointers to functions for each combination of tank and missile.