How to make a game without OOP? [closed]

Question

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?

Answer 1

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:

http://prog21.dadgum.com/23.html

This article specifically addresses your "shell hits a tank" question:

http://prog21.dadgum.com/189.html

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

Answer 2

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];
}

Answer 3

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.

Answer 4

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.