Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 25

Thread: Proceural Programming vs. Object Oriented Programming

  1. #11
    Quote Originally Posted by SilverWarior View Post
    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:
    Code:
    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

  2. #12
    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).

  3. #13
    Quote Originally Posted by User137 View Post
    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.

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

  5. #15
    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?
    Code:
      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:
    Code:
    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...
    Last edited by User137; 30-03-2012 at 10:53 AM.

  6. #16
    Quote Originally Posted by pitfiend View Post
    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.

    Quote Originally Posted by Lifepower View Post
    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.
    No signature provided yet.

  7. #17
    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.
    Last edited by Colin; 30-03-2012 at 11:01 AM.
    Download the Ziron Assembler
    Get free hosting for Ziron related fan-sites and Ziron projects, contact me in private message.

  8. #18
    Quote Originally Posted by SilverWarior View Post
    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.

  9. #19
    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.

  10. #20
    Quote Originally Posted by SilverWarior View Post
    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.

Page 2 of 3 FirstFirst 123 LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •