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.