I like OOP!

Always had issues with OOP because I thought it might be inefficient compared to to a procedural language (more complicated for the compiler) and I had used procedural languages for so long that it felt awkward to change.

When you think about it OOP really suits game programming - especially inheritance. At least for the average game I think - players, aliens and the like inheriting common attributes and extending others. Really like the way objects of a particular class are dealt with as a unit.

But does it work for all games? Chess for instance? I don't think it does. Maybe I'm still thinking in procedural terms, but I think procedural programming suits this type of game - rather than a shoot 'em up for instance.

Yes.
Sure it does, particularly the AI.
Anyway, the point of using an object oriented approach doesn't really hit you until you have to go back and support a program you haven't even thought about for 2 years. At that point in time, you will thank whatever god you subscribe to, that you used an OO design.

FlameDuck pretty much said what I was going to, only shorter.

I like oop... And oop likes me.... Like it through and through.

bless you all...

and may the force be with you...
always...

--Mike

I still don't get it. I know I'm not the brightest star in the sky so no need to aim and shoot.

I have problems understanding the whole extend a type thing. Also, function pointers( Err! Don't get it ). Byte Ptr's? ect..

I can work with types in a simplistic way but when I try to get clever with them my code becomes horribly complex. Don't know what I'm doin of.

Why extend a type?
How do you do - TType.something.something()? (Don't get the somethings.)

WTF is polymorphism, Abstract Types?

Why do people use This.self()? Why self? How come? How do you use it?

If I had a type with a Create() function and I extended the type, could the extended Type use the Create() Function?

Function Overloading? WTF is that?

I'm sure I've seen people use methods when an object isn't even created. How can this happen? Or did I read the code wrong?

Why can't I enjoy OOP like everybody else does?

Why does everybody use ListAddLast List(somthing) instead of adding it to the begining of the list?


The force is definately not with me on this one.

Amen Amon... I stand with the Amonster on this one... I can see some benefits of oop but maybe its just lazy plug and play programming? I admit a thourough lack of knowledge of this topic which is why I can pundit so well!

:)

This was made by John J:

www.alsbonsai.com/john/BlitzMax_OOP_Tutorial.pdf (125kb)

It helped me get my head around OOP

hahahahaa... ahhhh, refreshing to see such honesty...

take a look at this guys, it's a primer of sorts... and although it's aimed at the java coder, it covers the basic concepts in plain language english... an easy and short read that should get you up to speed...

look here--> http://www.toodarkpark.org/computers/objc/oop.html

good luck

--Mike

Usually because you've got two types which contain chunks of similar code. In a GUI for example, all your gadgets will have methods like position, hide, show, parent, etc so you may as well write that code once and have it apply to all your types. Then when you decide you want to change it, you only have to change it once instead of twenty times.


Normally, you don't. I guess the middle something could be a function or method which returns a type instance. So it might be First=TType.GetFirst() which returns the first one. Then you want to hide it so you say First.Hide() But you could do it all in one and just say TType.GetFirst().Hide() if that's all you need to do with that type instance.


Polymorphism is having a single function which can work on multiple different types. So in my example above, with the GUI and the hide method, you only have that one method, but it can be used on any type of gadget. You don't need to know which gadget type it is, and neither does your code.


Self refers to a type instance. When you call a method, that method is attached to a type instance, right? Sometimes you'll need to know which type instance it is and do something with it. That's what self is for.


Blitz can't do it so I wouldn't worry. But essentially it's having two ( or more ) functions with the same name but different parameters. So you might have two function called add. One takes two floats and one takes two ints. The compiler checks to see if you've passed ints. If you have, it uses the function which adds two ints. If you've provided two floats, it calls that instead. Blitz doesn't do it because Blitz has a lot of implicit type casting and it could get quite confusing where you wouldn't know which function might get called. It works well if the language is more strict about typing though.


Not methods, no. You can call type functions without creating a type instance, but a method MUST operate on a type instance.


Because it hasn't clicked yet. How can I best put this? Not sure if you're old enough, but let's try this..

Do you remember when Vic Reeves and Bob Mortimer were doing "Big Night Out" on Channel Four? Remember how everyone would rave about it? Then you watched an episode and thought it was complete bloody drivel? Then you watched a few more episodes, and it still seemed like drivel until one day it just clicked and you saw why everyone thought it was brilliant? It's a bit like that. It will just click eventually if you're patient. If you're not, it won't and you can continue coding procedural code instead. Mike ( Red ) probably won't forgive you, but most people won't care if you prefer procedural coding. OOP is only really to make your life easier. If you don't want to make your life easier or you just can get it to make your life easier, forget it.

[quoteWhy does everybody use ListAddLast List(somthing) instead of adding it to the begining of the list?[/quote]
No special reason, I don't think. Personally I just usually like them in the order I create them. Sometimes I count on it, but usually it wouldn't matter.

Nice. :)

I'm going to test a few things out now and may be back for more questions. Thanks Dude. :)

Just some thoughts on the following :



I didn't know that was polymorphism but have tried to use this method in my coding. What happened was I created a TCreate() function, in my type, to create a set of tiles. I extended the type and tried to use it to create a set of collision tiles but it didn't work. What I think I did wrong was not programming the TCreate function a certain way which would allow it to be used in an extended type.

I guess my questions are; are there limited instances where you could use polymorhism? Or could a complex TCreate() function be used across multiple types( depending on how it was coded)?

[edit] I'd like to see a code example of this.

Wow!
I didn't know any humans were capable of such big tutorials.
Great work, John. It looks very informative.



When I started with B3d, I would always use the Last type as the special one, even though everyone else uses First.
I guess I just found it easier to write Last than it is to write First.
Never really got over that habit...
(Doesn't matter, though)

Personally.... I think the problem most people have with OO is they get too caught up in the metaphor. Object.

Really you aren't talking about Objects in an object sense. It helps to think about it that way, but it isn't always going to happen that way. And it isn't always right to break everything down into many objects.

It is conceptual, and isn't always going to be real world objects.

the metaphor works great, until it doesn't. And most people that have trouble with OO get hung up where it doesn't work so great.

Lets take a simple example. An FPS.

One might be inclined to have a Character class that in composed of all kinds of sub classes like Eyes for seeing and Ears for sound. Then you extend that composite to both the player and the AI. However, in reality, this isn't going to be the best way to go about it, as the Eye is going to have Camera info for the player that the AI won't use, and other parts just for the AI that the player won't use.

What you'll likely end up with in reality is a Character class for all the aspects that will be shared, such as mobility and weapon choices and other things, then have a Camera class for all game cameras such as a 3rd person view, a cutscene or even the characters first person eyes.

You see, the metaphor breaks. the Player doesn't have a Camera. There is no rational Has-A relationship. However, functionally, in the game world, the player DOES have a Camera, because thats how the game works.

The whole point of OO is to allow for reuseable code. That Camera Class isn't going to do anything but camera related things. And so, if it is well written, you'll be able to port it as is into your next game.

but, unlike a procedural function. The camera class will be able to do things you couldn't do with a procedural system, and it will be faster. Example. Lets say you want a secondary 3D map view, or turrets, Or TV screens that have a view of another room. Since, in a well designed Camera class you will be able to grab essentially a screen capture view of what the camera sees, you'll be able to use it to create that view.

At least, if you designed it to do so, you could.

this is the power of OOP, reuseable code, easy to edit code, and since everything is designed seperate from eachother, if it can be understood by another class, it can be used by that class.

Camera becomes like a graphic, and could be queried for a screen capture like chunk of data just like it were a graphic. The fact that it grabs new data each time it is asked for a picture, should be irrelivent to the other classes. In fact... the Camera class has to ask the Player or TVSet class WHERE it is located to generate it's view. The camera just takes it's location and it's viewing angle, and any other properties it might have and pulls that from the 3D world...


This is just a simplistic example.

DampeS8N

Great, it is the best thread about OOP I have ever read.
It is what I tried to explain in an other forum some time ago
In my opinion OOP is a great step forward also for game programming provide you dont' abuse of it.
Up to a certain extent procedural programming is much more intuitive.
You define a class "Animal" which contains the sub classes "Dog" "Cat" ...
You see, how simple it is !!
The point is the very seldom you have to do with "concrete" classes
I made the example of some "high reputed" full OOP game engines
Actually they are a mess for the end users,in my opinion with no evident advantage vs a semi-OOP and common sense designed engines

Yeah.. OO design is just a way to isolate sections of code by what they do, and enable'n them to be able to plug into other bits of code without having to change things in the first set. If you know what you are doing, it make life a lot easier.

but in reality, you can code in an OO manor with procedural code. You can isolate functions so they will return values anything can use and such, it is just that OOP allows you to create instances of, to extend my other comment, Cameras, so you can look at the output of one camera, printed on a screen in the engine, with another camera which is an extension of the big Camera class. Where in procedural code, you would hold all the data in variables and use ifs and end up with a very complex piece of code, the ScreenCamera just extends the Camera with new values.

People tend to think of Objects in the Animals, Dog, Cat sense... when in reality, you rarely have objects that are that clear.

Some people like cheese and some people dont.
Some people like cats others like dogs.
It's the same with OOP, some like it others dont. But does it really matter ?
Well no not really, if you write your game/app in a procedural method with sensible coding style and plenty of relevant comments,variable and function names to cover any future updating or you do it in an OOP style with the same sensible information on your classes etc. Then the only thing that really matters is if your program works and does what it's meant to do. The end user doesn't give a rats rear end how you coded it, they just want it to do what it's meant to do as well ;)

Joncom2000 has it right. Although... There are reasons to use OO for some things, and reasons to use Procedural code in other situations. There are even good reasons to mix the 2. But it all comes down to wether the thing works or not.

However, sometimes that isn't the only concern. For example, when the code is going to be changed regularly by a lot of people. Then it is only sensible to use OO, since it can be edited by object and added to with an ease that Procedural code just can't offer.

On the other hand, there are reasons to not use OO, such as when you are not dealing with complex and large amount of object, but rather big streams of number crunching. Such as an application to search through a giant relational database for something. Or an application that runs a detailed find search on a hard drive, stores a relational database of what it finds tagged with useful information that can either be edited in bulk or piece by piece. From an OO stand point this might be 10 object... each of which are thousands of lines long... which makes it pointless and in fact noticably slower to code in OOP.

Joncom is missing a few essential aspects of application development in a modern, fragmenting, destructured world... and especially in the world of computers...

back in the dark ages, things were a lot simpler... you had DOS, you have BASIC, PASCAL, C... and most applications back then were the size of what would be considered, by today's standards, as demos... the elements of those apps were also a lot simpler to implement, and usual ran on a single hardware platform, on top of a single, less complicated OS...

in today's world, application elements assume a new complexity... if only by the very nature of the environment that they exist in...

these elements must consider a broader range of functionality in order to exist as part of an application...

whereas a game element in the past could easily be represented by a few pixels on the screen, or a simple lone variable in memory... and, in most cases, were controlled by a single io device... todays game elements must be able to be presented in a range of formats, and they may be controlled, not only by a multitude of io devices, but increasingly more by ai logic and physics logic...

plus, they are usually part of another similar assembly of elements, each one of, which in turn could've been coded by a team member a thousand miles away...

such apparent complexities would grind procedural coding practices and environments to a halt under what would undoubtedly be an overwhelming burden... not only on the implementation side, but on the logistical front as well...

code segregation, reuse, and interoperability is what todays programming environment is about... OOP is the only sound approach which gives even the single 'bedroom coder' a chance to make any substantial modern application a reality...

those who don't see this will, like the dinosaurs before them, become extinct in the computing world...

--Mike

Perhaps, someone will find this useful: Applied Object-Based Programming with Blitz3D

Some people like cheese and some people dont.

Very popular argument but I dont't agree with it.
Programming is science , it is not art
Ok there are ,of course , some borderline situations but you can not reduce programming to a matter of taste.
Also I dont agree that result is , at the end of the day, the only important issue.
You can code any kind of applications ,even the most sophisticated using the if..else statement only
It would be hard however to claim that other features are of no use just because your client can not see the difference
Once again DampeS8N hit the target , in my opinion.
For some application OOP is a must
Software re_usability and team programming are typical examples
But for some other apllications definitly not

I think it's art, that's why solutions differ. Sure some may be right or wrong. But even the right ones ahve different ways.

> those who don't see this will, like the dinosaurs before them, become extinct in the computing world...

You liked that Cobol dinosaur from Dilbert too eh?

For me, I use OOP in every case possible (in other words, whenever the programming language supports it). Maybe it's just me, but so far I have not come across anything that OOP does not make easier to program, simpler to manage, and more stable (bug-free).

To me, the term "object-oriented programming" can mean many things. For example, you can use OOP techniques (which used to be called "modular programming") in any language, whether it supports "OOP features" or not. To me, OOP is simply a method of splitting up your code into managable and logical chunks, each individually doing a specific task.

In a way, Functions and Types are OOP features. Classes and Methods simply provide a much more conveniet way to do the same thing. Things like polymorphism and inheritance are also possible without a language that features them, although that would require many complex and error-prone Select..Case structures.

In my opinion, the only true non-OOP language is a language with no Functions, no For loops, no While loops, etc. (aka spaghetti code).

By your logic, even spaghetti code can be OO cause you can always use

label A
if exit = 1
goto label B
endif
goto label A
label B

Which is a while loop... while exit != 1.

This is, after all, how loops began, and how everything evolved into more advanced features.

Modular programming did evolve into OO, but OO is a sort of.... standard.... that allows for ease of us, just like loops make goto loops easier.

OO classes inherintly have functions that procedural functions don't automaticly have, therefore, each procedural function would have to have redundant OO spoofing code to impliment the more advanced features of a class.

Redundancy of this calibur would lead to serious code bloat... and you can't really easily make a whole function to handle the redundancy... and if you did, well, you just created your own OO engine.

C'mon dude, that's a load of nonsense. How was writing for DOS machines, with all the different sound and GFX boards they might or might not have, *easier* without the unified driver architecture that we enjoy today? Doom was mostly C with a smidgen of asm and I don't see many indies writing more ambitious code than that... the idea that you absolutely *need* OOP at this level has no basis in fact whatsoever.

"Oh calamity! How am I ever going to write my Puzzloop clone without OOP?! Won't somebody think of the child entities?! Etc"

If it works, it's right. And if OOP makes it easier for more people to tap out their dream projects then great. But that's a long way from being necessary.

OOP isn't necessary, it is the next evolution. Apes didn't all die out when Humanity evolved, they continued to evolve into more fit forms in themselves. And OO will eventually evolve into something even more advanced and easy.

This, in turn, doesn't mean that OO isn't a better method, or that it isn't more powerful. It is both in most situations, and only is some instances, particularly ones where you are dealing with legacy systems like relational databases with massive amounts of data to be processed procedurally, or converted into objects, is it not better.

It doesn't make it wrong to use procedural.

There is no reason not to use a slide rule, and in some cases it is faster than a calculator in the right hands. But calculators are better, and more powerful.

As long as you get the right answer in the time required, no one will care how you got it. But eventually the slide rule won't be able to do what is required, at least in the right amount of time. Eventually you'll need to calculate pi to 1000 places, which can only be done with a more powerful system.

Eventually you will need to make a game like Oblivion, which is simply impossible to make without OO.

heh, I started with line numbers and gotos and rarely even used gosub (primative procedures). Then in assembly you just use to use labels and jumps and returns (and tried not to overflow the stack), no "passing variables". When procedures came along they were a lot easier. Types in C were a bonus too. Then when OOP came along, it just makes things a whole lot easier (imho). It didn't used to be that fast in C++ for DOS but speed is good now and nicely structured code that can be expanded easily, reused, shown to others who'll understand it etc. is the reason I use it now. Sure, small app, don't bother if you don't want (I still would), but it's SO needed for bigger apps. Programming an entire game (well 3 + 3 demos) in BlitzPlus without OOP was frankly HORRIBLE and a real pain in the arse. That's why I moved to BlitzMax - that and the fancy 3D card effects.

weellllll.... maybe just a little nonsense... but definitely not a whole lot of nonsense... look through that DOOM code and try to follow it... even the id guys went over to c++ eventually... they know a good thing when they see it...

yeah... but they didn't go to the moon neither... nor did they develop cars and buses and planes or hot video games... ya know why... cause they coded their aps in procedural coding languages...

ever hear of the dodo bird... they did go extinct... ask me why... :)

bottom line... and i think someone said it above... if it woiks for you, then use it... i aint makin' no extra cash from the Interplanetary OOP Society, so don't mistake me for one of their OO Evangels, out to convert the world... hey, i used to be one of those 'apes' doing everything with gotos and gosubs and blind functions too...

but i evolved...

:)

--Mike

This is simply not true
OOP doesnt make anything possible that was impossible without OOP
And remember Blitz3d is NOT oop. Could Oblvion be written in that?

hey... with the proper motivation, i'm sure you could even make a horse deal cards...

... so nuthin is impossible, per say... but that's not really the point though, is it.

--Mike

Ohhhh snappy ;)

I dont think that in a one person project a game similar to Oblivion would be any harder to program with OOP or without.

Its not my fault that you cannot non OOP program properly (HAHAHAHA) :)

Gosub 100*case+8000

again... possible, but it would take one heck of a dealer...

do ya really think that something on that scale is written by one person?

do ya think the codebase is maintained by a single person?

what's gonna happen when Oblivion II:The Prequel is rolled out... do ya think it would be better to rewrite ther whole thing fromt he ground up... or cut and paste the code into new functions for the new version?

and, do ya think all this is likely to be done by one person...

have you ever worked in a big software house at all... what about a small software house... or a software division of a big company?

--Mike

Honestly Red, To me the main problrem is the media (music, graphics etc)

I dont see any problem in writting anything in any language. (Although a non irritive solution to the tower of hanoi problem in forth, might be a bit.. no sorry I was wrong, even that could be done :)

Ok a bit too far but you know what im trying to say

Anyway the problem is the use of the term "Impossible", I would be willing to accept "More Difficult", but not impossible

And were did this idea that you cannot reuse procedures but you can reuse objects come from

now you're begining sounding like an evolved thinker :) (sorry, please don't hit me )

... and you are 200% correct.

it's not impossible... it's just a whole lot more work intensive.

why do you think that Blitz has evolved... VB, C, Pascal, etc, etc have evolved to OO versions of their originals... the advantages are obvious and evident...

Blitz3D is a dinosaur... it was great in its day, but it's day has passed.... it'll soon be surpassed by BlitzMax3D...

the decision to go this route wasn't, i'm sure, a capricious whim on Mark's part...

--Mike

Im not saying OOP isnt better, Im just annoyed at people that think it makes the programing of some types of program possible as apposed to easyer.
This generaly only happens when that persons first exposture to programming is oop, and they cannot visualize how to do it without, and I feel we should all oppose this opinion, not claiming that the other forms are better, just pointing out that they just ment you had to do things differently, but could do them

(And to have evolved doesnt mean to have become better par say, look at the sloth for example)

And While I agree that the on the Main oop is good, its rise seems to have become linked to a huge amount of "layers of abstraction"

i agree... i feel that i'm a better coder for having learned procedural methods, then learning OO methodologies...

i think that people should learn c before learning c++... BASIC before learning Visual BASIC... but all that is changing as more and more new coders come into the fold... very few procedural languages will be available for em to cut their teeth on in the near future...

--Mike

We should all learn Logo first ;)

The Object metaphor is so deeply ingrained in how Oblivion functions, that coding a system like it without OO classes would be comperable to calculating pi to 1000 places with a slide rule.

Impossible.

True, some being with a truely incredible brain and who lived for 1000 years could do it... but none exists.

Sure, a team of people useing procedural coding scheme COULD make oblivion. However, it would become more and more difficult as aspects of the code become more and more dependant on eachother, this would require more and more time to add each new function, and the data (which is held in an object based database) would take up a great deal more space in tables and records and would require more ram to surf. Which is fine, because the engine would likely have taken 10 years to code.... course, they wouldn't have had the budget to pay their team for that long... So the project never would have been started.

Guess what that is the same as?

Being Impossible.

Your wrong DampeS8N. And thats it.

I agree that it wouldn't be impossible... But I think that in the case of oblivion... the code would be FAR more bloated with procedural code than with object oriented code. Nor do I think it would take more than 50% longer to complete (using a guesstimate).

That said. Why on earth would you WANT to do it procedurally???

The code would probable be smaller with procedural programming. But heh yes, what would be the point

What I meant was this: No matter what language you use, you can always use good programming techniques (modular programming) to some extent.

I like OOP languages because OOP standardizes good programming techniques and makes them much easier to use, allowing you to get better results easier and faster than "procedural" languages.

"Oblivion" could have been made in a procedural language, but it may have taken many many times as long. Saying you can't make a game like Oblivion with a procedural language is like saying you can't dig a well with a teaspoon; of course it's possible, but it is rediculously impracticle.

I am 100% right. It isn't the size of the code that would make it take longer, it is the complexity and planning. The fact that for each new function you would require a deeper and deeper understanding of the whole project that it would slow it down to a crazy slow pace.

In addition, the way they save the game data is in an Object Database, or system of them. You can load the ENTIRE game world in about 2 min in the editor. Why? Because the game world is made out of about 1000 prefabricated pieces, so each 'level' is a list of these and their rotations, these objects include everything from leveled monster spawns to lights to wall sections. This is how it can calculate what things in the distance will look like on the overworld. Because the entire 16 square mile map can be loaded into memory with ease.

This also contains all the dialog and NPC placement and creation. Each of these 1000+ items is completely editable in their own rights. Such as the power or cost of a sword, or even creating whole new NPCs and weapons.

Without an inheritence system, you would have to code those relationships differently, which would likely mean extra variables (in the code, as the class takes up more memory in reality) and huge case statements... which would slow everything down some.

I'm not saying it can't be done, rather, that it wouldn't ever be done. That no group of coders would attempt to make something like Oblivion with OO because it would only be wasteful and take extra time. In which case, the people that are giving the team a few mil to sit down and make the game, wouldn't give a team of programmers who suggested they make this game with procedural code, knowing it will take more time and be much harder to maintain.

In this sense, it would be impossible for it to happen.

And all you have to do to prove me wrong is show just one instance of a AAA game with a 20+ man code team who DOESN'T code with OO for their next gen games.

Just 1.
Who isn't also making a really bad title that looks cheap and is obviously NOT AAA. I only add that because there are surely some over paid people out there making really terrible games, there were in the last gen, with all the copy cat vietnam games or better, those games that people made where you run off to fight a low poly osama.

Lets go with anything that has currently been released for the Xbox 360. Just find me one not coded with OO.

It seems my point was completely missed, I wasnt arguing for or against OOP. My point was everyone has there own view and niether is right or wrong in all cases.

If you are coding an exact clone of Asteroids, what makes it better OOP or Proc coding ???
Well it would still play the same no matter which method was used to code it.

But you're missing one significant factor. Size is a significant part of complexity. Small programs can be mathematicaly proven to be bug free. Larger programs can't. Why? Because as the size of a project increases linearly, the number of possible states, increases exponentially.

Well you're half right. While there may not be anyone who is right in all cases, there are certainly people who are wrong.

Flame... what does that have to do with Oblivion being possible or impossible to be made useing procedural tecniques. This was exactly my point, by the way. Where OO allows a team to work on each part separately, the complexity of working on them when they may or may not collide, or having the increase in complexity that is large numbers of long case statements, means that making it work will take much longer. Exponentially longer, as the code base gets bigger and needs to work in conjunction with other parts. It would take a lot more detailed planning to ensure you don't have any conflicts. And these increases in development time would have killed the project, even if it were a 50% increase in development time. Oblivion had been in the works since BEFORE they launched Morrowind. They begun work on it sometime in 01 or 02, and lets assume they only spent half of that time working on the engine, which is rediculous, a 50% increase is a year, a whole year. At the smallest. And if my suspicions are true, it would have taken much longer than that, and I happen to know they worked on the code for the game up until it's release, which makes at least a 2 year increase with only a 50% increase in development time for procedural coding. I happen to think it would be more than a 50% increase in time, as it would grow exponentually as the size of the project increases. So it could have easily doubled the development time.

Yeah, with unlimited resources, and no goal to make any money, the game could have cost twice as much to make and been possible to make.

But that sure does ignore a lot of what determins if a game gets made or not.

If the Oblivion guys wrote down a 50% increase into their game proposal, it is likely that it would have been revised and therefore had less content, or scrapped. Either way, what Oblivion is now wouldn't have been made.

OO tecniques make programing easyer.
Fair enough, thats it easyer. Not smaller code, or quicker code, or better code, just easyer.

If you think you can only program things that are easy. Then yes most thing couldnt be programed by you in a non oop way because it would be too hard

Whatya on about, G?

Personally, I *usually* understand OOP, but I read code like a book, I can normally tell when i'm near what i'm looking for, with OOP I find the code becomes harder to wade through.

It wouldn't matter at ALL when you create that clone of asteroids. It would make a WORLD of difference when you decide to make sequels. It's the derivitives after the fact that would benefit the most from the codebase of Asteroids being done in OOP. Entire sections of the code could be copied wholesale into the new project(s) without change and without worry that they will conflict with new code.

THAT is the power of OOP.

I agree that the nature of oop means that it is more transportable, but the same transportability can be done with procedures if you plan it so.
If you use a good nameing convention you could still use a lot of the code from your original asteroids.
But probably you wouldnt have done if the language didnt force you to.
With oop, you are forced to, so in that sense oop is better. But the original asteroids (assuming no mid progaming concept change), would be quiker to do not in oop.
Also, surly this reuseability is part of the reason so many games look the same. And I for one am not a fan of sequals, except when the sequal is fundermantaly better that the original.

(Just to make clear I think that oop is a better way to program, but mostly that it because it forces a nameing/structure convention apon all its users)

no... no, you're missing the point here... code reusability and content are two entirely different matters...

and the asteroids game wouldn't take longer... mainly because by the time you decide to write it, you'll have all the game infrastructure (classes and methods) already written... and your base classes defined, so that an asteroid class can inherit from a gameobject class and all the behavior are already there...

you wrote em out a few months ago...

that's the whole thing about code resuse...

--Mike

Not only that, but it makes it alot easier to use a better structure convention, and features like polymorphism helps keep complex object relationships more tidy.

@John Agree totaly

@Red, the same could be said if you had kept a good procedure libary, (Just the chances of that are smaller)

... and even if you did, ya can't inherit properties and methods from a procedure lib, from which to extend your base classes... now can ya...


--Mike

Didnt claim it would be easy, just pointing out that a good procedural programmer still makes them reusable. Just that with procedural programing its self imposed, but with oop its inherent

no... that's not it... you're missing the whole point...

there is no way you could make abstract classes and then build upon them in a procedural language... well, no practical way that is... and there is no true inheritance in Blitz3D... no methods... none of that good stuff...

we're not just talking about reusing the same ole functions you wrote last month, over and over again... we're talking about using the logic that the functions implement to extend the object that these functions (methods) belong to, in order to derive new types of objects... a gameobject class-->a vehicle class-->a tank class or a stretchedLimo class... and so on...

can't do dat in with procedural languages... and Blitz doesn't even let you nest a TYPE within a TYPE...

ya see what i'm trying to get across... it's not just code reuse in the sense of reusing the same ole code... it's code resuse in the sense of reusing proven logic to build upon...



--Mike

No you are missing my point. All that stuff you could do in procedural programming, it would just be spread out rather than in one place. When you wanted to add more functionality, you would do it across all the "Object data" (I dont think I can explain it without useing oop termanology, how stupid is that), rather than over a single object.

OOP, just makes a standard and simple way to do it. But it could still be done proceduraly.

Say you wanted to extend Tcar to TSportscar you would just extend it as normal, then create the new fields you wanted etc. Or you simply (for example), add an array the size of the number of cars you want, and bitflag issportscar.

What you have to remember is that OOP didnt just appear, it developed out of what procedural programers were already doing. It standadised it and made it in essence compulsory, but it didnt introduce anything that good procedural programers couldnt already do.

I for one wouldnt go back to non oop, but if I had to I could. And it takes very little effort to make Procedual logic as reuseable as oop.

ok... show me... show me just one thing...

show me an abstract class in any procedural language you choose... and a sub class of it that i can use to create an object...


wrongo... again...

ever here of Smalltalk... predates a lot of your procedural languages by a ways...



--Mike

I am saying you dont need a "class" at all

edit (afer your edit)
Fair enough, though I would have used simula I as the exapmle

how can you create an object without one?
how can you create an object that inherits from a predecedant object type without em?
how can you link methods (functions0 to each individual object?


show me... i'm open to other ideas...

show me just one short simple example...

--Mike

AHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH

You are saying I need oop because it has Objects, I am saying you dont need objects. How can I show you how to make what it doenst have, even when I am saying it doent need it

Show me A specific piece of code that uses OOP, and I will rewrite it so it doesnt

no... just show me a simple anything that i can make an entity from, and then call a function from that entity that will work on that entity only...

then allow me to make a super version of that entity... one that has all the functionality of it, plus the super new functionality...

--Mike

You are asking me to use a non oop language to show you how to do an oop concept. I am saying you dont need the oop concept.

Im not saying it cannot be done in oop, you are the one saying it cannot be done in non oop.

Provide a real exapmle, that you feel cannot be done in non oop.

Show me where the "lock thread" Button is and I'll show you.

well, you're the one who said it could be done in any language... oop or procedural... and i quote...



besides, this is not an oop concept... it's a general concept... code reuse... and, more improtantly, logic reuse... i didn't say anything about methods or anything objective... do it any way you want...

now go ahead, show me :)

--Mike

I think... that while he knows the concepts of OOP, Red... It's not FULLY clicked with him yet. Once it does he'll have that little lightbulb over his head.

yeah... he sounds like he pretty much knows it...
i'm just messing with him a lil...

if he'd look at Frank's tuts, he'd have some idea to come up with a hack of sorts in Blitz3d :)

--Mike

That would be making a form of oop, whereas im talking about not using oop at all

Type AType
	Field One:Int
	Field Two:Int
End Type

Function SumAType:Int (This:AType)
	Return (This.One+ This.Two)
End Function


Global MyAType:AType	= New AType
MyAType.One=1
MyAType.Two=2
Print SumAType(MyAType)

'Lets "ReUse that code

Type BType
		Field OneTwo:AType
		Field Three:Int
End Type

Function SumbType:Int (This:BType)
	Return (SumAType( This.OneTwo)+This.Three)
End Function

Global MyBType:BType = New BType
MyBType.OneTwo.One =3
MyBType.OneTwo.Two=4
MyBType.Three =5

Print SumbType(MyBType)

then show me what you're talkin' 'bout... that lil bit of crap you just entered don't show nuthin but that you need objects...

--Mike

Uhoh, that old guy with the triple full stop key has escaped from the old folks again. Somebody call happy hour and save us from the ramblings!

I dont need to show you, you have already cutit out once and reposted it, but as im nice

ahhhh, you just can't do it in Blitz... can you...

don't gimme no excuses... boiiii :)

--Mike

Was a good thread here once. Good to see you again Red =]

good to see you too Toby...

yup... it was a real good thread... lots of useful exchange of info, and of opinion...

i missed you too, back there when the thread was going along well...

i see you chose to wait it out, not contributing anything positive... 'till it deteriorated into mumbo jumbo... so you could feel right at home, and make your usual contribution... in your own, unique, and typically Toby way...

guess i'll see ya again at the tail end of the next thread that deteriorates into a waste of time...

--Mike

Now I know why everyone thought I was Red when I first joined the forum a year+ back.... >.>

Ah, here we go! :

You were being a smartass? =]

no... he was just smart...

it took you long enough to come up with that smartass response... you tryin to make people think you are Toby...

--Mike

Some people need to sleep, smarty.

sounds like a personal problem to me...

:)

--Mike