Proceural Programming vs. Object Oriented Programming

[User137]

Unit types are like this:
1. Land unit capable of atacking other land units
2. Land unit capable of atacking air units
3. Air unit capable of atacking other air units
4. Air unit capable of atacking land units
5. Air units capable of atacking submersible units
6. Naval units capable of atacking other naval units
7. Naval units capable of atacking submersible units
8. Submersible units capable of atacking other submersible units
9. Submersible units capable of atacking naval units
10. Submersible units capable of atacking land units.

Your code also need to make sure that these units can move properly (prevent ilegal moves)
1. Land units can move only on land
2. Naval units can move only on water
3. Submersible units can only move in deep water when submerged
4. Air units can move anywhere

I do not see how this couldn't be done in non-OOP way very easily. Anything that programmer tries to justify by objects, the non-OOP programmer can explain with pointers. Your list of 1-10 is irrelevant, your unit can simply have like:

unit: array of TUnit; // TUnit record containing all different kinds of units, and target indexes

Movement can simply be a comparison between unit type variable and land grid at its location.

I mean, the example above is hardly enough to light up a "war" between the approaches, as it is too simplistic

[SilverWarior]

Maybe I haven't chosen the best example.
Currently I'm workning on a code for a strategy game I might develop sometime. In my game units will be made from various parts (drivetrain, chasis, weapons, shields, utilities, etc.). I'm using OOP approach becouse it alows me to change some units parts just by changing pointers to point to apropriate clases wich represent various parts. Also this way I gat the ability to have some custom methods wuch are being used by this methods (different way of calculating defense for various unit types - some have uniform shield others have directional shields).

[LP]

I do not see how this couldn't be done in non-OOP way very easily. Anything that programmer tries to justify by objects, the non-OOP programmer can explain with pointers.

Indeed, you can transform one approach into another and vice-versa. In fact, when program is compiled, both procedural and OOP are converted into primitive instructions: CPU itself knows nothing about objects and/or records. So this is not very relevant here.

The argument is about qualitative attributes between different approaches when used in typical applications.

Actually, an interesting topic is that in both Delphi and FreePascal you can use units as if they were objects: they have public (interface) section, private (implementation) section, constructor (initialization) and destructor (finalization). This makes the language somewhat unique, since the entire project is divided into object/namespace hybrids (units) that may have other objects inside.

[Jimmy Valavanis]

I wrote some prototyping code to solve the above problem, it's the text attachment. I didn't use OOP

[User137]

Hmm, that looks way more complicated than i had in mind. Also pay attention to memory usage! Do you have 2 billion different terrain types, or could you decide texture by just that terrain type instead of separate variable? Is the collision list required?

  terraintile_t = record
    texture: integer;
    terraintype: integer; // 0(unpassable), 1(land), 2(water), 3(sub) - Also could be set as a compination of FLG_xxx flags with 0 as unpassable for easier checking using bitwise or
    blocklist: unit_p;    // colision list linked with unit_t.nextsamatile
  end;

I would plan something like this:

const
  MAX_UNIT_TYPES = 10;
  MaxLandW = 256;
  MaxLandH = 256;

type
  TUnitType = (utLand, utAir, utNaval, utSub);
  
  TUnitInfo = record
    ut: TUnitType;
    attLand, attAir, attNaval, attSub: boolean;
    maxHP, movespeed, acceleration: single;
  end;
  PUnitInfo = ^TUnitInfo;

  TUnit = record
    info: PUnitInfo;
    position, movement: TVector2f;
    HP, rotation: single;
    target: integer; // Target index from unit-array
  end;

var
  land: array[0..MaxLandW-1, 0..MaxLandH-1] of byte;
  unitTypes: array[0..MAX_UNIT_TYPES-1] of TUnitInfo;
  unit: array of TUnit;
  uCount: integer;
...

Then just initialize by filling details to unitTypes for 10 ship types. Give pointer to needed unitType when adding a new unit. And i'm missing guns and stuff for now...

[Ñuño Martínez]

Come guys, why you need to be that strict? As I see it, there's no sacred war here, the proposal is to learn from different aproachs on the same problem. Any of us can come with a brilliant solution to it, don't you think? Let's work on enlightment instead of senseless fight between us.

Actually I'm not so strict. I often mix procedural and object oriented in my programs (I call it "structured using objects"). But there are a lot of people "out there" that use the computer as if it were a religion. Specially if they're C++, C# or Java programmers.

Actually, an interesting topic is that in both Delphi and FreePascal you can use units as if they were objects: they have public (interface) section, private (implementation) section, constructor (initialization) and destructor (finalization). This makes the language somewhat unique, since the entire project is divided into object/namespace hybrids (units) that may have other objects inside.

Good point. I've planned some projects that way. And it works.

Oberon goes away within the same concept. In Oberon there's no a "main" unit. All "units" are actually "programs" or better "objects" with public and private "sections" that may or may not depend to each other. When you executes an Oberon program you actually "loads" an object "instance" and calls a method. Much like Small-Talk but different.

[Colin]

OOP in most cases is going to produce slower code, so its a weigh-in between speed of development vs performance of the finished application.....the fact that Mr. Valavanis can code without an influence of an OOP approach is commendable, and in-fact it is an advantage over others, I would personally hire such a programmer.

[Ingemar]

So why don't we alow him first to prove himself solving a real problem in practise and only then judge him.
I will present problem below (the problem can be easily solved using OOP aproach) and I hope Jimmy would be so kind to take some of his time to show us how he would solve it. Maybe we will even learn something from him. Isn't that the purpose of our comunity - to learn.
Now Jimmy if for some rason you don't want to publicly participate in this I still hope that you take some time and send me solution for the problem below using your approach. I would realy like to see how it can be done in procedural way becouse I cant imagine how myself. Maybe I will learn something.

The problem is as folows:
Lets say you are creating a strategy game. In this game there are several different unit types. Your goal is to write a code wich will define these unit types as specified below.
For the sake of simplicity lets say that the gameworld is respresented with two dimensional array (tiles). These are defined like so:
0 for unpasable terrain
1 for land terrain
2 water terrain
3 for deep water terrain

Unit types are like this:
1. Land unit capable of atacking other land units
2. Land unit capable of atacking air units
3. Air unit capable of atacking other air units
4. Air unit capable of atacking land units
5. Air units capable of atacking submersible units
6. Naval units capable of atacking other naval units
7. Naval units capable of atacking submersible units
8. Submersible units capable of atacking other submersible units
9. Submersible units capable of atacking naval units
10. Submersible units capable of atacking land units.

Your code also need to make sure that these units can move properly (prevent ilegal moves)
1. Land units can move only on land
2. Naval units can move only on water
3. Submersible units can only move in deep water when submerged
4. Air units can move anywhere

Naturally each units have his health so this should also be covered in your code.

If you wish I will show you all how I would solve this problem myself using OOP aproach. I could also try to explain the benefits of using OOP in this case.

I think this is a wonderful idea!

Actually, I recently proposed a slighly similar student project, although geared towards comparing languages. Same idea, stop bickering and get down to the facts, write some solid code for each case and compare, as objectively as possible (pun not intended). But your description goes a good step closer, by specifying pretty well what it should be, I like that. Maybe we should make a common base of graphics and sounds? And map? Same size, same data.

The big question is whether this is the right problem, but maybe it is. A few rules are missing though: Can there only be one unit in each space? Do you attack by moving into an occupied space? Are there hit points, strengths? What odds should there be? Winning conditions? Game menus, save files (should be mandatory or forbidden, no optionals)?

Of course, one of the biggest arguments in favor of procedural programming is performance, and we will get no difference for this case. We would need a problem with high complexity and large data sets for that.

I am tempted to write one or even two approaches to the problem. I think you need several. There is more than procedural-vs-OOP, there are several approaches in each, and it is perfectly possibly to write lousy code for both cases.

One more thing: The evaluation should preferably be positive and open-minded. That isn't very easy to do. It is so easy to flame the way that isn't "my own", but I think it is better to speak about advantages than pinning down what we think is bad. Objective, and absolutely avoid getting personal. But the way you state your intentions, I think you are on the right track already.

So what do you say, is the "tile-based naval game" idea the right one to try? I'm in if you want, just let's get a bit more exact on the rules so we write the same game.

[SilverWarior]

When I presented the problem I had no intention for making whole game. My intetntion was to present an opurtunity for Jimmy to show how he would solve this problem using his approach. This would then alow us to have some constuctive debate on comparison between OOP oriented programing and Procedural oriented programing.

[Ingemar]

When I presented the problem I had no intention for making whole game. My intetntion was to present an opurtunity for Jimmy to show how he would solve this problem using his approach. This would then alow us to have some constuctive debate on comparison between OOP oriented programing and Procedural oriented programing.

But I think it can be made, written, working, in reasonable time if the problem is well-defined and with precise limits. I can write that in, well, say two days. Maybe one if I can focus well and the specifications are strict and complete (and limited enough).

The question is, of course, if such a short project would produce anything meaningful.