OOP... If You Don't Wanna Hear It From Me...

... what about a totally unsolicited testimonial from an experienced developer who just happened to post on a topic which was an ongoing discussion here a few minutes ago...

http://www.blitzbasic.com/Community/posts.php?topic=56217

... and supported by the opinions of two other well known developers here.

i can be censored... but the truth can't...
you can shut me up...

but the great truth that is OOP shall not be censored...

and in my absence, it will still find a way :)


--Mike

I saw this, what really got my attention was why someone like Halo took so long to pick up and try Bmax.

ps.. tell him

GL_DEPTH_BUFFER_BIT+GL_COLOR_BUFFER_BIT

should be

GL_DEPTH_BUFFER_BIT|GL_COLOR_BUFFER_BIT

And for those who have not used BMAX.... You get direct access to everything.. no more limits!! ITS @#!*ING SUPERB - just think C++ made BASIC

That's just the same in the end, and some people prefer to use + as it better denotes the fact that you're "adding" two "properties". And no it generaly doesn't even have any overhead (who would care anyway) as compilers are rarely dumb anough to actually perform operations at runtime when all the operands are constant.

As for how it took so long to Halo to discover methods, that's indeed a mystery.

Huh, so the previous thread disappeared ? Well, to be honest, I DO like OOP programming, and I use it from time to time. But I also like procedural programming.

Even if OOP offers you much more flexibility, it's also a question of personal taste. For some projects a simple and procedural approach can be fine, too.

Max has a lot of potential, but it takes some time to get used to it, and the crappy docs don't help. :-(

Not always. But in most instances it can be used, especially with the 'max constants, which tend to be just a single bit turned on (i.e. 1,2,4,8,16, etc, not a combination like 15).

I know addition is not the same as binary or "in the genal case". But with bit flags, it is. Unless you're working on some exotic computer that doesn't use 2's complement. That is, a computer on which BlitzMax doesn't work anyway...

And as hinted by the "_BIT" suffix, the constants in question were bit flags.

Well, to be completly precise, the bit flags HAVE to be exclusive or else you'll indeed go into big troubles if you just add them rather than ORing them :) (they don't necessarily have to be have just one bit set, 15 is fine if you don't add it to an overlapping bit pattern).
And it's true they're not always exclusive (but here they are), meaning taking the habit to use the bitwise or is certainly a good idea to avoid being bitten one day. Yeah, true, so I guess "should be" was actually adequate here in the sens it would be better (when I read it as "it must be for it to work").

Jeez, I'm on a nitpick roll these days, I really need to get some holidays :/
I could slap myself. You know you're really bored when your own posts make you yawn.

I am not even a coder and have known for years that oop is really important/practical , so why are people so against it.

Nothing like having a default class that you can just add to or modify slightly.

working on unreal mods for so many years made me appraciate that having are re useable default class for a weapon was invaluable.

I *am* a developer :-) and know OOP rocks for resuseability and maintenance. It used to suck for speed (a bit) but not any more.

I always OR as well, just in case.

I'm amazed Halo has only just discovered OOP actually.
Good on him.

Hmmm.... What is the difference in speed C++ vs Bmax ??

About 80%. As in BlitzMAX generally runs at 80% of the speed of a similar C++ program. At least it used to, it could've changed in the mean time.

what tests have been done to confirm this? Loops; writing data to RAM, VRAM or Disk; general logic etc.?

hmm, one thing about C++, different compilers get different results. In torque with OPCODE collisions Jeremy got a 50% performance boost using the VC++ 7.1 optimized compiler over the VC6 one.

Good to see someone as skilled (and picky -- but don't tell him I said that!) as Halo picking up that stuff.

Lots of different tests. Jim Brown wrote some Sieve of Eratosthenes code in different basic languages and I wrote the C++ reference (that is using no optimizations, just a straight port that does the same ammount of work) code. There's a thread about it somewhere complete with links to sourcecode.

Also a series of tests involving various Krushkal and Dijkstra implementations, and large scale (4GB) duplicate integer finder algorithm, showed the same consistent 80% performance.

The tests I did was compiled with the same compiler (the MinGW version of GCC) that powers BlitzMAX for most consistently useful and comparable data.

OK great. Wonder if BMax is faster on anything else, or slower on other stuff for that matter?

I doubt it'll ever be faster, and that's hardly the point, unless you want to write for embedded (read: underpowered) devices. The question is, is it fast enough for what you want to do. 99% of time the answer is going to be yes.

The slight proformance drop you may get from using something like Blitzmax over C++ is more than made up for from the easy of use that max offers, and C++ code is only fast if it's well written and optimized either by the coder and/or the compiler. I am pretty sure I can code some c++ that runs slower than blitz doing the samething :)

If effective programming was about speed we'd be using assembler. The time to make, and ease of code reading, production (to a reliable state) and update are uber important. And Object thats safe within itself and cant be misused by accident is a wonder. Too bad BMax classes have no privates.

hee hee
[link removed by moderator]

I didn't see anyone "against" OOP in that last thread, just people against the implication that they are backwater yahoos for not adopting OOP when their projects are sufficiently straightforward that it would yield no significant benefit. Of course it will be worthwhile for Halo to pick up OOP given the type of work he involves himself in.

Oh yeah, that was my response too. I was gonna post it, but then I got distracted by a shiny object or pretty girl or something.

Once, I was showing an interactive art piece and a computer science student just about @#!* a brick when I said I do procedural programming. The piece was cool and all, but all of like fifty lines of code (admittedly, this was 50 lines in Blitz, so doing it in C using DirectX would be more like 5000.) I just smiled and shrugged at his disbelief, but I was thinking, "Huh? Why the hell would I want to OO-ify a program that's 50 lines of code?" Nowadays it's just assumed that anything interesting has to be done using OOP.

---

This reminds me of something kinda off-topic. Somehow my programs are always way shorter than people expect. Apparently I tend to use like a quarter of the code other people need to achieve the same end result. I wonder why that is?

I don't see a significant difference between the OOP of BlitzMax and the OOP of properly written Blitz3D code:

x#=Entity.x
x#=EntityX(entity)

It's more just the fact that you have objects with properties.

The fact that I am going to be controlling it with Lua scripts means that whatever cool conventions BMax has, I will be doing without them in the end.

Now if only it could compile a dll, that would really be something.

B3D don't got Methods, though, so... er hang on, isn't this where we came in?!



Wheeeee!

That's because the Blitz3D entity system is an object oriented design. The main difference is that in BlitzMAX you have direct access to the objects structure, and can extend it at will, and that you can let the compiler do work for you, that could otherwise mean rather intricate If//EndIf or Select/Case structures. These can now be simplified by extending a base or super Class/Type to do what you want, meaning you only have to change the code in one place (the class itself), rather than in two (the class itself, and the complex select statement).

For instance imagine you where making a FPS game and had 7 different types of enemy. In Blitz3D you would have to go:

Select myEnemy\Type
  case "Soldier"
    do soldier stuff
  case "Marine"
    do Marine stuff
  case "Sentry"
    do Sentry stuff
  case "Tank"
    do Tank stuff
  case "Helicopter"
    do Helicopter stuff
  case "Jet Fighter"
    do Jet Fighter stuff
  case "APC"
    do APC stuff
  case "Stealth Bomber"
    do Stealth Bomber stuff
End Select

and each time you wanted to add a new type, you would have to remember to add to this statement. In an OO language you can simply go.

myEnemy.doStuff()

And the compiler will figure out which "doStuff" method it has to invoke for you.

Yeah, but you often have to update classes in a specific order, so you will just end up doing this:

if myEnemy.class=marine myEnemy.dostuff()

if myEnemy.class=troll myEnemy.dostuff()

if myEnemy.class=fish myEnemy.dostuff()

Let's say that does happen that often, that would still doesn't mean methods are not usefull. And I mean "real" methods, not functions attempting to trasvestite into methods like you'd do in Blitz3D.

You just not always do all your "stuff" in a sequencial manner, nor need and should know each and every possible class in every part of your code. With OO you can by example have a function like that

Function doStuff(e:TEnnemy)
    Print ("Going to do something...")
    e.doStuff()
    Print ("...Done something")
End Function

You won't care if 'e' is is atroll, a marine or whatever. That makes a whole lot of a difference compared to having to write a big select with hard coded type identifiers.

No you wouldn't. You would keep them in an ordered/sorted datastructure, that ensured that things where done in whatever order you needed.

it's a lot more than that Josh... i see where you are coming from, but you are just slightly missing the main point here... as are a few of the people responding to what you are saying are equally missing the point...

this is not so much the syntax, or the differences in organization... OO coding goes far beyond that...

OO represents a paradigm shift in the way you think about coding your projects...

this is the key to the whole thing... most of us are adept enough coders to pickup on the syntax and doctrines regarding the mechanics of coding in an OOP environment... but a lot of us miss the more subtle, but equally as profound aspect of thinking OO...


ok, what i mean is this... look at the example you discussed above... you talk about a myEnemy class, as if it were something that you would just pop into your program without any aforethought... exactly in the same manner that a Blitz3D procedural coder might do... even if he/she was using an OO type hack of Blitz3D... or, for that matter, any procedural BASIC language...

and this is where the problem lies...

in an OOP environment, as i see it, the above examples and points shows that you are not thinking OO here... you are merely using OOP facilities in a half a$$ed, hybrid fashion, to come up with something that is a lil better than procedural methods, but still a lot less than it could be...

any remote thought about a myEnemy class should've started a long time ago... while you were in the process of coding, or developing your gameEngine class... a base class that every game should spring from... after all, every game should be it's own engine, ideally based on a generic set of members, methods, etc that enforce a universal set of doctrines, so that you can use it as a jumpoff point for every game you write in the future...

in turn... myEnemy should be a descendant of gameObject, which itself, should be a member of your gameEngine class...

and, like Koriolis said above, then you could derive specific behaviors at this point, for specific types of enemies... trolls, marines, whatever... all inheriting the behaviors and properties of their descendants...

just like real objects in the real world... virtual object in the OO world have ancestors... and inherit qualities, even instincts one might say :)


am i getting my point across here in a way that can be seen... what i'm trying to say is that you've gotta start to think OO if you wanna code OOP... you've gotta abandon those imgrained ideas of functions and subroutines and procedures...

... you've got to adapt a new mindset, not just a new tool set.



--Mike

... you've got to adapt some proper punctuation.

... you see what i mean, a perfect example of a mind trapped in traditional morays and thought patterns... eyes wide shut to anything but what it has been indoctrinated into believing is, and what should be, the status quo...

OOP will be difficult for this mind to adapt to...

thank you octo for providing a perfect example of linear thinking... and in turn, helping further clarify the point i was trying to illustrate above...

... if you don't mind though, i'd prefer to return to the topic at hand now, surely a much more interesting discourse than one about my grammatically challenged (as you see it) typing.

--Mike

Thank you for providing a perfect example of assumptive reasoning: this mind is quite familiar with object oriented design, thank you very much.

Care to make any more wild accusations about me, or are you going to stick with wildly accusing everyone of missing the point of OO?

Proper spelling and grammar seem to be important to you, why not punctuation? I find it just as annoying reading something with ellipsis strewn about haphazardly as I do reading 1337 sp34k.

it was neither wild... nor was it an accusation... nor was it about you per say...
it was merely a logical observation of what was stated in your post, and it was aimed at the sort of thinking i described, and not specifically at you...

now, please allow this thread to return to the topic at hand, for those interested in the exchange of viewpoints and information on said topic...

pm or email me or if you have anything further to advise me of on the topic of grammar and punctuation... or, if you are annoyed so much, find another topic to browse, or merely skip past my posts...

--Mike

I said that I didn't like your punctuation and you "logically observed" that I wouldn't have a good grasp on OOP?

pm me... or email me... please don't mess up this thread with your off topic likes and dislikes, and your misunderstanding of what i said...

--Mike

Ah, now I get it! OOP is about freedom from restrictive punctuation rules. FREEEEEEDOM!

LOL... well... uuhhh, yeah :)

that lil aside wasn't directed at anyone in particular... it was directed at the sort of thinking that grips so tightly on established and in a lot of cases arbitrary dogma...

procdedural coding is one of those dogmas... it's served us well for quite a long time... and that is whay there is so much resistance to even considering another way...

... just like the rules of punctuation and grammar.

--Mike

About the c++ vs bmax performance thing: Is writing to a bank or pixmap in bmax equally fast as writing to some bit o' mem in c++ ?

I experiment with image/texture-generating now and then, tho iirc things like blurs etc. are quite slow compared to blurring in Photoshop, to name something. Now I dunno if I'm really the most l33t-coder on that, but I figure that reading out bank-values, doing a little math and putting the new values back is very low-level code anyway. Not much you can ruin in there, speed-wise..

What is the advantage of making every class a subclass of a baseclass, except for the purpose of making your code more complicated?

I've messed with the Unreal package format quite a bit, and found all the superclass stuff to be pretty wasteful. It seems like a good tool for the Frank Taylor-type programmer who never wants to make a final decision.

I suppose I could start with one EngineNode class. What fields would I give it? Probably none. Okay, not I make every class a derivitive of the node class. I suppose I could make a list of EngineNodes. Okay, so now I have a list of every entity in the engine. Big deal.

hahahaha... whoa halo, give Frank a lil break... huh :)

i understand what you are saying... but can i just ask how you feel that this complicates your code...

if anything it would simplify it...

take that lil example i proposed... once gameEngine class is written (to include the member gameObject), and the functionality that takes care of all gameObject instances is written... you are now free to concentrate on the actual objects themselves...

their relationship to the gameEngine has already been taken care of, and since it's all encapsulated in the gameEngine class, you need not even take it into consideration any more... just define your objects now... the engine you've just written will take care of em and make sure that they are well behaved gameEngine members...

the same thing applies to all base objects and their derived classes... everything inherits the functionality of it's descendant... once that code is done, you can forget it... and build more complex and individual objects ontop of the functionality of the immediate predecessor...

like i said... wouldn't this make things much simpler in the long run...

--Mike

Sounds like a lot of BS to me.

Let's say I have a base class, in this case "tEngineNode". If your player class then has a "target" value of another entity, you can supply it with any kind of type, since they are all derivitives of the tEngineNode. However, when I try this, I am unable to recover the "speed" value.

Type tEngineNode
EndType

Type tPlayer Extends tEngineNode
	Field target:tenginenode
EndType

Type tVehicle Extends tEngineNode
	Field speed#=100
	Field target:tenginenode
EndType

player:tplayer=New tplayer
vehicle:tvehicle=New tvehicle

player.target=vehicle
Notify player.target.speed ' crash here

My own OOP system uses banks. Since I am just using integer handles, I can pass them around any way I like. A parameter can reference any class of object, not just a certain declared type. And you can call ObjectClass() on any object to find out what class it is.

you're missing a preliminary member of tEngine... the generic member for all game objects should exist in tEngine...

and it's functionality should be generic, almost virtual, so it can be overridden by all subsquent derived classes... it only handles the functioanlity necessary for the engine to instanciate, draw (if necessary), and update this member... and any other basic stuff...

speed would be part of a base vehicle class, which would in turn be derived from tEngine:gameObject...

--Mike

blah blah blah blah blah

Show me.

Are you saying tEngineNode should contain all the properties I might need for any entity? Way to go, I just created one generic class so my texture objects can have a "health" field. Oh, the wonders of OOP.

Type tEngineNode
Field target:tenginenode
Field speed#=100
EndType

Type tPlayer Extends tEngineNode
EndType

Type tVehicle Extends tEngineNode	
EndType

player:tplayer=New tplayer
vehicle:tvehicle=New tvehicle

player.target=vehicle
Notify player.target.speed

hahahahahahaaaa...

you're rushing things... you're coding before thinking it out Josh...

what's the purpose of tEngine... forget vehicles and players... just the basic purpose of tEngine...

of course not... stop being obtuse...

in my vision of the universe, tEngine just needs to know about the environment it will be running in, how to cleanly instantiate itself and exit, and how to manage whatever members it contains so that they will be represented (this does not mean seen) while the game is running, as they are designed to be...

after you get that fleshed out... thenyou can think about what your generic gameObjects need to do to be good members to tEngine... one of the first things that comes to mind is that all game objects will need to be updated on each cycle of the main loop... therefore, i would have a member function that iterates through all gameObjects and calls their update function (or signals an event, or something. are events part of the BNax repertoire?)

no code... just a virtual member function (does BMAX have virtual functions) that is left to be overridden by derived classes...

once you get the basics outta the way, then you can start worrying about vehicles, enemies, etc... it is then that you would code (override) their update methods... to do whatever you need it to do...


maybe i'm not explaining it clearly enough... lemme see if my trial BMax is still working...

in the meantime, take a look at the structure of the irrlicht eng... or do you have a copy of laMothe's OpenGL Game Programming handy...

look at the structure of the OGRE renderer...

--Mike

This is a very important point. So I guess, yeah, I'm taking advantage of OOP every time I use Blitz. Whatever. That there is why I love using Blitz; it has all this useful stuff in place which I don't really have to give a crap about.

"What is the advantage of making every class... your code more complicated? "

Generally speaking I like C++ , however I tend to agree with this.
Any abuse of oop concepts make your code more complicated
Take for example the famous "Ogre"
A part , may be, for some particular applications only a snob programmer can, imho, like it
Actually it is a mess
An other example ,Direct x and opengl
Although Direct x won the API war , most of the amateur graphic programmers prefer opengl ,its architecture being much easier

@ jH...
although the Blitz entity system can be thought of as being object oriented... it is incapable of providing you with anything more than the basic hierarchical functionality that is already designed into it...

i think that to call this by itself OOP is stretching the term just short of its limits...

i would better look at it as being a hierarchical relationship structure that you can plug things into... but the structure is fixed... non polymorphic... and nom modifiable...

@ Alberto...
OOP is only as complicated as you the developer, and MS Visual series of compilers wanna make it...

the clean simplicity of OOP is apparent when you find yourself only coding what you need at the moment... and then weeks later when that rush of genius as eluded you, being able to leverage what you've already done by instantiating or building upon existing class functionality with only needing to acknowledge the interfaces...

nothing can be less complicated, and more natural than that :)

--Mike

Yeah halo, target is of type tEngine node and you're
giving it the value of tVehicle, which has more fields.

I haven't been coding in a while, but I think you should be declaring abstract fields in tEngineNode(?)

The main reason I don't like Blitz's type system is it makes interaction between types a pain in the ass. If you have a switch with a target value, and you want it to open a door, turn on a light, or activate something else, you can to go through some very messy code.

However...

If you have a couple of standard interactions like "activate" or "update", you can include the methods in the EngineNode class, and elaborate on them in the subclass:

Type tEngineNode
Field target:tenginenode
	Method Activate()
	EndMethod
EndType

Type tPlayer Extends tEngineNode
EndType

Type tVehicle Extends tEngineNode	
	Field speed#
	Method Activate()
		Notify 1
	EndMethod
EndType

player:tplayer=New tplayer
vehicle:tvehicle=New tvehicle
player.target=vehicle

player.target.activate()

Still, the inablity to retrieve "player.target.speed" is something that really scares me, because it won't come up until my code is well established. I don't want to have to make a base class with a lot of extra parameters.

For example, if one player shoots another player, I need to retrieve a bunch of info on health, score, client info, etc. Now all my textures will have to have a bunch of bull@#!* attached to their base class. Either that, or I have to set up a queryvalue() function with a lot of constants, in which case I have to wonder why the hell I am bothering with types at all.

again Josh... tVehicle should not extend tEngine at this point... or actually at any point... it's too early to even think of tVehicle...

you need to establish the ground rules and doctrines for a generic gameObject first, before you start adding onbjects... then you'll be ready to create a vehicle class from that...


tEngine just has to take care of itself, handle generic app functions such as input and output for example, and anything else you want, depending on how complicated you want the engine to be...

--Mike

Whatever.

This is why messaging is convenient. You send a message to the object, if the message is relevant it does what it's told, otherwise it does nothing.

Another thing you could do is have a hash table for each tEngineNode and store the data in it (somewhat like a symbol table, maybe..). So then you just do node.properties.GetEntry( "speed" ). However, I prefer messaging.

hey... this is just my take on it... i'm sure a lot of other views on the subject will be forthcoming...

... at least i hope so, i have a few questions i'd like to hear discussed as well.

--Mike

How are those questions supposed to be discussed when you haven't asked them?

Noel, you might as well just use a bank if you are going to have to query a bunch of values with constants.

This is a bit better. The tEngineNode class has to reference the subclass in order to access its parameters:

Type tEngineNode
Field target:tEngineNode
Field vehicle:tVehicle
Field player:tPlayer
EndType

Type tPlayer Extends tEngineNode
	Method New()
		player=Self
	EndMethod
EndType

Type tVehicle Extends tEngineNode
	Field speed#=100
	Method New()
		vehicle=Self
	EndMethod
EndType

player:tplayer=New tplayer
vehicle:tvehicle=New tvehicle
player.target=vehicle
Notify player.target.vehicle.speed

in due time... if the opportunity presents itself...

no sense rushing things... give a few more coders a chance to comment and input on the current discussion...

--Mike

This makes it a bit better, adding a "class" field to the tEngineNode class, so you can tell what kind of object it is:

Const CLASS_PLAYER=1
Const CLASS_VEHICLE=2

Type tEngineNode
Field target:tEngineNode
Field vehicle:tVehicle
Field player:tPlayer
Field class
EndType

Type tPlayer Extends tEngineNode
	Method New()
		player=Self
		class=CLASS_PLAYER
	EndMethod
EndType

Type tVehicle Extends tEngineNode
	Field speed#=100
	Method New()
		vehicle=Self
		class=CLASS_VEHICLE
	EndMethod
EndType

player:tplayer=New tplayer
vehicle:tvehicle=New tvehicle
player.target=vehicle

If player.target.class=CLASS_VEHICLE
	Notify player.target.vehicle.speed
EndIf

Overall, I get the feeling this will make my code less manageable. There's a reason C/C++ programmers take ten times as long to get anything done.

That's actually a pretty good idea. Have a buffer that, if CLASS is the same then use FIELD_SPEED (which would be the offset into the type's memory buffer) to get the speed.

I'll have to use that idea.

Ha, that's the whole basis of most of my programming.

From my class declaration file:

Const CLASS_BRUSH=1
Const BRUSH_BUFFERSIZE=140
Const BRUSH_PROPERTIES=116
Const BRUSH_FACELIST=16
Const BRUSH_CORNERLIST=20
Const BRUSH_EDGELIST=24
Const BRUSH_COLOR=28
Const BRUSH_CENTERX=32
Const BRUSH_CENTERY=36
Const BRUSH_CENTERZ=40
Const BRUSH_MINX=44
Const BRUSH_MINY=48
Const BRUSH_MINZ=52
Const BRUSH_MAXX=56
Const BRUSH_MAXY=60
Const BRUSH_MAXZ=64
Const BRUSH_POLYCOUNT=68
Const BRUSH_VERTEXCOUNT=72
Const BRUSH_HIDDEN=120
Const BRUSH_EXTENTSCHANGED=124
Const BRUSH_RENDERCOLOR=128
Const BRUSH_LIGHTMODE=132
Const BRUSH_FLIPPED=136

Now a brush command:

Function CreateBrush()
brush=CreateBank(BRUSH_BUFFERSIZE)
PokeInt brush,0,CLASS_BRUSH
PokeInt brush,4,0
If Not BRUSHBUFFER BRUSHBUFFER=CreateBank()
AppendInt BRUSHBUFFER,brush
PokeInt brush,BRUSH_FACELIST,CreateBank()
PokeInt brush,BRUSH_CORNERLIST,CreateBank()
PokeInt brush,BRUSH_EDGELIST,CreateBank()
PokeInt brush,BRUSH_PROPERTIES,0
PokeInt brush,BRUSH_EXTENTSCHANGED,True
Return brush
End Function

To go through brushes:

Function CountBrushes()
If BRUSHBUFFER Return BankSize(BRUSHBUFFER)/4
End Function

Function Brush(n)
Return PeekInt(BRUSHBUFFER,(n-1)*4)
End Function

So some program code looks like this:

brush=CreateBrush()

For n=1 to CountBrushes()
	Brush(n)
Next

yes... that's a lot better... but still i might do it something like this...

forget these...
Const CLASS_PLAYER=1
Const CLASS_VEHICLE=2

Type tEngineNode
Field target:tGameObject
Field Player (there will always be one of these so)

(methods to instantiate and update tGameObject objects)
EndType

Type tGameObject
(fields to id it and to maybe to provide linkage)
(methods to instantiate it)
(methods to update, display, etc generic stuff)
EndType



Type tVehicle Extends tGameObject
	Field speed#=100
	Method New()
		vehicle=Self
		class=CLASS_VEHICLE
	EndMethod
                (methods to drive, whatever) 
                (inherited methods to display, update, etc from game object)
EndType

leave the following stuff out... its not really object oriented type logic design, in my opinion, as you are looking at the object from the outside in... the whole point of OOP would be to have each object 'take care of itself automatically...

player.target=vehicle
Notify player.target.vehicle.speed


this is ok...
vehicle:tvehicle=New tvehicle

but this...

player.target=vehicle
Notify player.target.vehicle.speed

should be handled automatically by the vehicle object if a player mounts it...

as should this...

If player.target.class=CLASS_VEHICLE
Notify player.target.vehicle.speed
EndIf


all this should be methods of tVehicle... encapsulated and automatically invoked or invoked when queried...

*** added***

the player doesn't actually mount a vehicle anyways, now that i stop to think it out... the player is an abstract entity in the game, represented by a gameObject.Actor which he/she uses to move about the game, or if the tPlayer.ControlObject==NULL, then the tPlayers default move methods are invoked...

the gameObject.Actor mounts the vehicle where the vehicle now becomes the player.controlObject...

... or something like that :)

anyways... all the functionality of these things should be encapsulated, and private if possible.

(sorry about not actually writing the code out, i'm not that BMax lierate yet... and i know nothing about banks, but i'm sure its functionality could be included inside the member methods for each derived class)

(also... this is a simple implementation... i would porbably use some sort of cyclical linked list to manage the game objects)

--Mike

Noel... no messaging or events in BMax?

--Mike

In relation to?

raising an event, or sending a message to one, all of a type, or all objects entirely... like windows does to each of its windows to tell em its time to repaint an invalidated region...

--Mike

Doable but inconvenient.

I prefer to avoid messaging when it's possible. As for events, well, events suck. Bring on callbacks and specialized control implementations.

Type tEngineNode
EndType

Type tPlayer Extends tEngineNode
	Field target:tEnginenode
EndType

Type tVehicle Extends tEngineNode
	Field speed#=100
	Field target:tenginenode
EndType

player:tplayer=New tplayer
vehicle:tvehicle=New tvehicle

player.target = vehicle

Notify tVehicle(player.target).speed

No crash.

Unless the target happens to not be a vehicle. Didn't think that one through, eh?

I did, but then you need a debugger. I didn't say that it was safe practise.

[edit]
But as you wish

If tVehicle(player.target) Then
  Notify tVehicle(player.target).speed
EndIf

No need for those ugly CONST's for defining the class.

Btw. Noel,I didn't read your post in the other forum.

LOL :) vehicle crash :)

i'm trying to tell him (josh)... he's still thinking 'BlitzBASIC' with this type of design... he's gotta start thinking 'Objects'...

he's gotta design the object from the objects perspective outward... then this wouldn't, couldn't happen...

a properly OO designed gameObject wouldn't be coded to allow the player to 'target' it unless it was a valid target...

--Mike

Enough talk, show us some code, submarine boy.

hahahahaha... :) sub boy :)

i'm in the middle of work now... i'm trying to get this sub thing off the ground in 3DRAD... quaternions kickin' me around a bit...

but this is interesting... lemme see if i got a demo version of BMax around that hasn't expired yet...

--Mike

One thing that OOP may be useful for is cleaning up all resources used in a level (textures,sounds)
You could have a base 'level' class that contains classes for textures,sounds,level data,enemies,flags,

Procedurally the code would be a lot messier.

Don't get me started on static vs dynamic typing. :)

Halo - you know you can put your CONSTs inside the type itself don't you?

I'm getting to be less of a fan of "OOP" as I use it more. I think I see why C/C++ programmers never get anything done.

Well, they're really good at endlessly noodling around with data structures. That's something.

Presumably, you're not creating or extending large projects. For simple projects, OOP may be elegant, but is often a waste of source code: explaining your problem space conceptually to the compiler takes extra work.

In larger projects, this extra work is an investment in your project's succintness - its readability, maintainablility, and avoidance of code duplication.

Wikipedia puts it best:



So, yes, there can be a lot of noodling with data structures. In a proper software development cycle, this would occur solely in the Architecture and Design phases, and proper noodling will save many a headache down the road at code Construction. It's important to do enough noodling to prevent future headaches (and rewritten code) but pointless to do more. Knowing how much noodling to do can be tricky. I prefer mine al dente.

(..) is to minimize dependencies among modules (..)

I minimize it to strictly-zero, more zero than zero. I tend to slap myself if there's even 1 dependency anywhere..

You presume too much.

In that case, I charge that, you sir, are blaming your tools before you know how to use them. ;)

My code was a lot simpler when I used banks to create my structures. This already getting out of hand.

Sometimes you get advice that you know in the end will make your code more complex, but you try it anyways, because you think there might be some as-of-yet unknown benefit. Beware those moments. Don't be like Frankie.

Type tMediaCategory Extends tEngineNode
	Global list:TList = New TList
	Field name$
	Field path$
	Field MediaFiles:tlist=New tlist
	Method New()
		list.addlast(Self)
	EndMethod

EndType

Const MEDIATYPE_TEXTURE=1
Const MEDIATYPE_MODEL=2
Const MEDIATYPE_SOUND=3

Type tMediaFile Extends tEngineNode
	Field mediacategory:tmediacategory
	Field filename$
	Field name$
	Field extension$
	Field packfilename$
	Field mediatype
	Field texture:ttexture
EndType

Function FindMediaFile:ttexture(categoryname$,name$,createnew=True)
	mediacategory:tmediacategory=FindMediaCategory(categoryname$,createnew)
	If Not mediacategory Return
	For mediafile:tmediafile=EachIn mediacategory.mediafiles
		If mediafile.name=name Return mediafile.texture
	Next
EndFunction

Function CreateTextureMediaFile:tmediafile(mediacategory:tmediacategory,name$,file$)
	texture:ttexture=New ttexture
	texture.name=name
	texture.filename=file
	texture.mediacategory=mediacategory
	mediacategory.mediafiles.addlast(texture)
EndFunction

Function FindMediaCategory:tmediacategory(name$,createnew=True)
	name=Lower(name)
	For mediacategory:tmediacategory=EachIn tmediacategory.list
		If mediacategory.name=name Return mediacategory
	Next
	If createnew
		mediacategory=New tmediacategory
		mediacategory.name=name
		Return mediacategory
	EndIf
EndFunction

Function LoadTextureDirectory(path$)
	dir=ReadDir(path)
	If Not dir Return
	Repeat
		file$=NextFile(dir)
		Select FileType(path+file)
			Case 0 Exit
			Case 1
				ext$=FileExtension(file)
				Select ext
					Case "bmp","jpg","pcx","png","dds","vtf","tga","jpeg"
						If mediacategory:tmediacategory=Null
							mediacategory=FindMediaCategory(filedir(path$,0))
						EndIf
						name$=filename(file,0)
						CreateTextureMediaFile(mediacategory,name$,file$)
						texturesloaded=texturesloaded+1
				EndSelect
			Case 2
				If file<>"." And file<>".."
					LoadTextureDirectory(path+file+"/")
				EndIf
		EndSelect
	Forever
	CloseDir dir
	Return True
EndFunction

Before my code would have been this:
For n=1 to CountTextures()

Now it is this:
For texture:ttexture=EachIn texture.list

The big problem I see is type fields not being able to reference each other properly, i.e. a field point to a model or a brush, but it can't do both.

1) In B+ I'd use banks again yea (I also put everything in banks, data, gadgets, variables etc.), but in BMax I'm kinda brainwashed towards types :P (it's mainly the . seperator and the precence of methods)

2) You can use banks in types, so go ahead with banks!

3) Use arrays if you don't like lists

4) I never extend stuff, I connect flat types to eachother, kinda like you connect icons/'machines' in a modular synth.

5) Make tea!

I sure didn't bother to read the entire thread... I will just share my experience in a similar vein...

I was programming in primarily quickbasic4.5 (that's the compiled one) for dos and then something really new and interesting came out for windows around 1991 or so. So I bought this nifty Visual Basic. Now I'd been programming in basic, C, ASM, pascal... And I wasn't too shabby. But that was all linear code. And this whole event-driven code thing in vb just threw me for a loop. "WTF" came out of my mouth more often than I care to think about. I just couldn't get my head around that whole idea. So I put VB1.0 down and didn't pick it up again until VB3.0 came out. And I was running into the same wall repeatedly.

"Why the hell do I need this event driven crap?" I didn't see it as being useful at all. Then one day. A little light went off over my head and I "got it". I understood what the he11 the entire event-driven architecture was all about and how to implement it in writing my own programs.

The same thing applies to OOP. When I first looked at C++ vs C code. I didn't understand what the he11 was going on. Why on earth did I need to do THAT when I could just do THIS? "THIS" was much simpler to understand and did the same thing. It might have even done it a tad bit faster.

Then. I got it. It took a while but I saw the light. OOP just suddenly made sense.

Those people that don't think OOP is worthy of using... Don't yet "get it". Once they do, they'll realize that it's easier, makes things easier to read, and wonder how they could ever live without it.

I now await the programmer that knows everything to jump all over me and try to lay the smack down on how I *dont* "get it" and try to educate me on how wrong I am. But I'll just quietly sit back and smile... Knowing that I saw the light and he/she is still looking for the switch on the wall to gain their own illumination.

Lemme guess, you saw the light because your apps became too big and you wished for some datahiding and automated object-eventhandling/updating, after reinventing wheels for years? :P

quietly sitting back and smiling. :)

Took me some while too before I discovered the OO idea ..

verrrrrry well put octo, Kanati...

he's a bright young coder... he will see the light soon...



--Mike

Unfortunately, being told that you just "don't get it" and that you have to "stop thinking X and start thinking Y" isn't a very effective way to learn.

If I knew BlitzMax I'd be suggesting alternate solutions to halo and explaining why they'd be advantageous down the road when things get complicated - like FlameDuck and Koriolis did above with virtual methods. However, I recall from my limited experience with the demo that it's missing a couple of C++ language features, so I'm loathe to suggest things that simply might not work.



Do you mean that you want the field to be able to point to either? You can absolutely do that! That's called polymorphism and is generally accomplished with inheritance in OOP. If both the classes are derived from the same class, you declare the field to be a pointer to the base class. Then, you call (virtual) methods on the object and it does brush-things if the object is a brush or model-things if the object is a model.

If "brush" and "model" are someone else's classes - and not derived from each other or do not support the virtual methods you want - you'll likely want to create your own wrapper classes (I forget the correct Design Pattern name, sorry) to control them.

If you want any of that explained further, ask.

For the sake of example, here's a scene graph.

Strict

Import Cower.Math3D

Private
Global __iscenegraph_instance:ISceneGraph
Public

Type ISceneGraph
    Field DeltaTime# ' <- Public
    Field _root:INode
    
    Method New( )
        Assert __iscenegraph_instance=Null,"ISceneGraph already created"
        __iscenegraph_instance = Self
        _root = New INode
    End Method
    
    Method Update( )
        _root.Update( DeltaTime )
    End Method
    
    Method Draw( )
        _root.Draw( )
    End Method
    
    Function Singleton:ISceneGraph( )
        If __iscenegraph_instance = Null Then New ISceneGraph
        Return __iscenegraph_instance
    End Function
End Type

Type INode
    Field _parent:INode
    Field _children:TList = New TList
    Field _link:TLink = Null
    Field _draw%=1
    Field _transform:Matrix = New Matrix
    Field _x!,_y!,_z!,_sx!,_sy!,_sz!
    
    Method New( )
        SetParent( Null )
    End Method
    
    Method Update( delta# )
        For Local i:INode = EachIn _children
            i.Update( delta )
        Next
    End Method
    
    Method Draw( )
        For Local i:INode = EachIn _children
            i.Draw( )
        Next
    End Method
    
    Method BeginDraw( )
        glPushMatrix( )
        glMultMatrixd( _transform.GetPtr( ) )
    End Method
    
    Method EndDraw( )
        glPopMatrix( )
    End Method
    
    Method SetParent( node:INode )
        If node = Self Then Return
        _parent = node
        If _link Then _link.Remove
        If Not _parent Then _parent = ISceneGraph.Singleton( )._root
        If _parent Then _link = _parent._children.AddLast( Self )
    End Method
    
    Method InsertAbove( node:INode )
        If Not node Then Return
        node.SetParent( _parent )
        SetParent( node )
    End Method
    
    Method InsertBelow( node:INode )
        If node Then node.SetParent( Self )
    End Method
    
    Method Scale( x!, y!, z! )
        _transform.Scale( x, y, z )
        _sx=x _sy=y _sz=z
    End Method
    
    Method Offset( x!, y!, z! )
        _transform.Translate( x, y, z )
        _x = x _y = y _z = z
    End Method
    
    Method Rotation( pitch!, yaw!, roll! )
        _transform = Matrix.FromEuler( pitch, yaw, roll )
        Scale( _x, _y, _z )
        Offset( _x, _y, _z )
    End Method
    
    Method Quaternion( q:Quaternion )
        _transform = q.ToMatrix( )
        Scale( _x, _y, _z )
        Offset( _x, _y, _z )
    End Method
End Type

Type ITformNode Extends INode
    Method Draw( )
        BeginDraw( )
        Super.Draw( )
        EndDraw( )
    End Method
End Type

Type IMeshNode Extends INode
    Field _mesh:IMesh
    
    Method Draw( )
        If _draw = 0 Then Return
        BeginDraw( )
        If _mesh Then _mesh.Draw( )
        Super.Draw( )
        EndDraw( )
    End Method
End Type

Well ,the discussion is getting too advanced for me.

I would only suggest to examine the architecture of two well known OOP oriented game engines :
Truevision3d and Irrlicht
The former makes a proper use ( I mean a "limited" use ) of OOP, the latter abuse of it.
The difference are evident
Everybody can grasp ,at a first glance, a truevision code and its advantages over a a procedural program
A irrilicht code means nothing to everybody except to seasoned Irrlichr programmers

well... being a bit receptive to the ideas that you are being presenting with, and the reasoning behind them, or at the very least, taking an open minded approach... just might help the learner actually learn a few things...

now whether or not he wants to use what he would have learned, is his decision...

i think that a lot more than just "you just don't get it" has been given to him... more than necessary for someone on his level needs...


--Mike

> he's a bright young coder... he will see the light soon...

Well, I can't see the light. But I can see the full stops.

that's what you get for subsisting on a diet of cheeze wiz... maybe you should look with better eyes...

--Mike

I just had strawberries and a banana and even I see them.

My experience has been that C/C++ code tends to be...not very modular. You can't change one thing without destroying a million little links to other things. Thus, it takes 6 months to add a feature, if it doesn't require a rewrite of the whole engine.

I remember when I was drinking with this C/C++ programmer guy who was asking me about the 3D World Studio source. I told him it was written in BlitzPlus, and he laughed and asked why I did it that way. I told him that it was the simplest way to get results the fastest, so I could spend my time coding instead of fighting the language. This guy did some network coding or something, and would never be able to write something like 3D World Studio in a million years...but he felt superior because he coded "properly". Is that someone you really care about impressing? No one else will even care.

I think programming is a lot like law, in the sense that the professionals seek to make it as complicated as possible, in order to ensure their own usefulness. I say make everything as simple as possible, so that you can spend your effort on really mind-boggling principles, instead of screwing around with silly conventions. The smaller the source code, the better.

The basic vs c/c++ discussion will always be, no matter what. Usually lead by c/c++ ppl protecting their job, and basic ppl protecting their basic. :)

There're a lot of ppl who say that inheriting too much leads to messy code. I never inherit. I treat my code as icons/components in a modular system with wires (think synthesizers). The stuff I connect to eachother is flat, no inherited stuff.

Exactly how did you write B+ code? Could be the same way I did.. (see the B+ tutorial-section, 'own gadgets')
Having all the gadgets, images and variables stored as ints in banks and use global functions as 'methods' for those variables. Perfect datahiding, and nearly like classes.

You use constants for the peek/poke adresses? Or do you remember all the stuff? Or do you make quick tables as reference (like I did in the tuts)?

The way I write my flat objects in Bmax is exactly like those components in a modular synth. The object has inputs and outpus and wiretypes. As long as all the ins/outs/wiretypes don't change, you can simply replace any object without a milllion others not working anymore.

c'mon halo... that's not right... if anything, c++ is the very epitome of modular...

you must've been stung by visual c++ and the way it's wizards tend to distribute your code all over the place... don't confuse visual c++ with c++... first learn c++ and then use the VC++ wizards...

write c++ code in the MS compiler as if you were creating a new win32 console app first, and get used to it... then take advantage of the wizards...

or better yet, lets forget c++ entirely for the moment...

you mentioned Frank Taylor a ways back up there, and how his methods resulted in a lot of time wasted... or something along those lines...

well, lets go back to Blitz3D briefly (sorry i have no working BMAx available at the moment), and look at OOP in Blitz3D for a second... see if i can prove a point about modularity and coding at the point of the action, in an attempt to get you to see the light of OOP :)


what if you could provide a Blitz3D developer with a game engine where all he/she had to do to get a game started was to write two lines of code...

myGame.tGame=createGame("Invaders")
run(myGame)

that's it... nothing else, and you've got a whole game (it doesn't do much right now, but we'll deal with that shortly)... using an OOP based game engine written in Blitz3D...

this is something like what you are doing with your game engine... right... except you have real OOP in BMAx to code with...

what if i could show you a simplified OOP game engine in the next 15 minutes (i really don't have time for this, but i feel the gods want me to spread the bible according to OOP to all the non believers... so i must do it)

--Mike

Why do you care if others like/use OOP, or not, Red. I don't.

Also worthy to remember: there're 2 OO-schools afaik. The school from c++ where beginners start learning how to work exactly according to the book and take the info for granted, and the school of autodidacts who went through all the code-phases themself and prolly use OO a different way. I had this discussion some while ago with a fellow TBL'ian (demoscene-coder), who did asm, pascal, c++. He more or less learnt c++ from the moment he started working at a company. He also thought that for example things like 'inheritence' is way overrated, he sees classes more like a way to group things together and as a proper way for datahiding. And really, he's a *brilliant* coder on all aspects. I had the very same discussion with yet another coder, who also states that alot of typical c++ coders are basically trained monkeys who repeat what their teachers once said. :P (he's also a coder with a huge rep) From him I copied the modular-synth idea.. sofar it works. :D

Go to GameDev.net, you'll find out just how true that is.

@ big10...

actually, i don't... but the gods do... and they tasked me to spread the word... so, as to not anger the gods (and because josh did ask a few posts above), i take time to do this...

@ noel...
true... but there are just as many, if not more that don't... so your point is what...

@ CS...
good examples of a sampling of OO coders and what they think... personally, i think that all programmers should learn procedural coding before jumping into OO coding... c before c++... but that's just my take on it...


ok, so where's halo.. lets get this OO game engine started, so he can see how modular it is... and hopefully, how it will make life easier... maybe not in the beginning, but definitely as things progress and his engine, and any games written with it grow (and maybe i'll get a complimentary license for his new game engine, eeehhh :) )

--Mike

My point as well, as I said in some other topic: OO is the upgrade for procedural, and the need for OO comes automagically when you grow out of the procedural world. So, in a way no-one needs to teach stuff here, it'll come. :P

Yes Halo: @ you too ! Just remember this topic when it happens and send us a chocolat bar. :P

" OO is the upgrade for procedural, and the need for OO comes automagically ..."

Do you mean thst OO has been developed for large projects ?
I mean , the larger the project the better it is ?

I'm just asking, I am an hobbyest programmer

However , as far as I know OO has been mainly developed to produce re-usable pieces of software as well as for software upgrading and distribution( you send a module only)

This is for example an advantage of direct x over opengl

A key topic in the industry but not so important for an indie game programmer .

Even though I would like to have a Blitz SDK, same as DarkBasic did, I found Halo's remarks defintly consistent

If you exagerate in using classes and sub classes , linked togher your program become a mess very soon

The larger the project, the more happier you'll be with OO.

Reusable pieces o' code are going to be useful when you do large projects.

If your program becomes a mess, it was designed poorly, got not much to do with classes by themself.

Tho, admittedly, I only talk from an app-pov, I never do games. But I figure that in any case: in the end it's all numbers we're dealing with, just the representation is different. :P

i agree whole heartedly here... if your code is a mess using OOP, then it never would never even have stood half a chance using procedural methods...

think about it for a second Alberto... say you are creating a tank game in B3D, no OOP hacks or anything... most people would open a graphics screen, place a camera and a skybox... load up a terain mesh, create a tank, and procede to flesh out the logic to make it all work... most will give up before the game is done, frustrated by a seemingly overwhelming amount of logic that they've gotta implement...

a few will see it all the way through, and get it done... but waht about maintainence, bug fixes, small changes, the next game...

now, if they applied OO coding practices... not only would they have been able to start off with their last game engine class and their last game object member of that class, and build upon that... taking each step at a time...

gameobject (already done and validated) derives vehicle... vehicle derives tank... if you don't already have a vehicle class, concentrate on making one... once that's done, a new sheet of paper, and tank extends vehicle...

what could be simple... what could be more easy to code and debug... you only have to go as far back as the last object you are designing... all the stuff prior to that is test bug free and working (or it should be :) )

even if it's not entirely free of bugs, as long as you don't destroy the interfaces, you can clean up newly discovered bugs in ancestor classes (admittedly, they may be harder to locate), and the fixes will trickle down to all descendants...

this is the way to code... in the beginning it's gonna seem like a lot of work because you are establishing your groundwork... your base classes, and their functionality... but very soon it will start to become easier and easier...

enough preaching for one post :)

--Mike

I think the way I code is already very OOP. I have many classes made with banks, and some of them have identical properties:

Const CLASS_CAMERA=1
Const CAMERA_POSITIONX=4
Const CAMERA_POSITIONY=8
Const CAMERA_POSITIONZ=12

Const CLASS_PLAYER=2
Const PLAYER_POSITIONX=4
Const PLAYER_POSITIONY=8
Const PLAYER_POSITIONZ=12

Then I can call a "MoveObject" command that works on both camera and player classes. That was basically just a case of inheritance.

However, I think formal derivative types are a waste of time. I also think integer bank handles are a lot nicer to pass around than special type variables that only work in Blitz.

"Special type variables that only work in Blitz" are essentially "C++ objects." C++ can do the same things as Blitz with them, and then some.



That's an example of polymorphism, not inheritance. Inheritance would also tell the compiler automatically which classes can legally have MoveObject() called on them and provide a way to override aspects of how MoveObject() works directly in your subclass definition (which is greatly helpful for encapsulation.)

They will always be a waste of time for you until you face a project complicated enough for them to help you. ASM can already do everything, so every programming tool is useless until you find its purpose.

P.S. The way you code can be called object-based - which is exactly what I call the way I code in Blitz3D. The term "OOP" tends to be reserved for programming which uses the builtin inheritance and polymorphism features of a programming language.

P.P.S.


I disagree. The less time you spend, the better.

In my experience it's not worth compacting code to save space - code volume costs you nothing in compile time and a small amount in Construction, but readability can save you rediculous amounts of time in Maintenance. If you write comments, you understand what I'm getting at here. As projects become more complicated, the amount of overhead required to be able to make changes in a particular section of code becomes phenomenal. Well-planned organization and explanation save time - we're talking orders of magnitude.

The more succinct the source code, the better: small and simple.

It's really all about saving time (and optionally headaches.) If you don't have a problem with either, you don't need OOP.

Alberto: Yes. Large projects are when good organization becomes critical for coding efficiency, therefore they will get the most benefit from any tools that aid them in that respect.

However, once someone learns an effective organizational technique, they may tend to use it in smaller projects where it isn't terribly useful. Perhaps they envision the project growing at a later date. Perhaps they're keeping their habits in practice. Perhaps they like standing on a soapbox.

It's analogous to keeping a small collection of music CDs in alphabetical order - you'll end up spending more time keeping them sorted than you'll save finding the correct ones.



This is probably only a second-order benefit: keeping the code encapsulated means that most changes will be localized to one module. If you sent a "patch file" with only the changes to several files it would probably be of a comparable size.

No it was developed for two different reasons. One reason for a language (SmallTalk) to be OO was because the developers at Xerox PARC needed a nice conceptual model for another one of their innovations, the GUI. As it happens a GUI is very easy to visualize, use and implement, when using an object oriented design.

Another reason was that researcher needed a language (SIMULA) that would help them model physics simulations, and like the Xerox PARC guys, they found the object oriented approach very suitable for simulations of that type.

No. It's a matter of complexity. Ofcourse, size is one aspect of complexity (as a project grows, the software has more possible states, and thus a higher degree of complexity) but its not always the key aspect. Now the best way we know ATM to reduce complexity, is by abstraction, and the best forms of abstraction come in advanced languages (using a 4th generation, over a 3rd [and certainly 1st] generation language for instance) and by using an object oriented approach to problem solving.

Which is probably why veteran developers encourage almost religious use of low coupling, high coherency and other design patterns.

hey... in the long run... whatever you are most comfortable with is the way you should go...

language wise as well as concept wise...

while i like OO, it is where my comfort zone lies... that's all... it's not a holy grail, nor one of the 10 commandments, or anything like that...

now the OOP gods will surely punish me for saying this... but my first born is already as old as some of you, so, i don't have to worry about that :)

good luck with your coding...

--Mike

well... we've seen a lot of varying views on this... now, would anyone be interested in putting all this OO nonesense to the test...

would anyone be interested in working up a simple, but fully capable (for big projects) OOP Game Engine in Blitz3D real quick...

the goal will be to whip it up in about 2 days, and make it so that any sort of 3D game could be made with it...

no inheritance or strict polymorphismn in order to keep it simple and not make it more work than what it's worth... just a generic core game engine that could easily be extended to include all sorts of 'classes'... but mainly will afford the developer some of the key benefits to using the OO paradigm... a lil code reuse, and better organization tied with the ability to code and concentrate on your app right where the action is gonna happen...

anyone interested in following this, or even throwing bricks at it (i need the negatives just to make sure it is a valid concept)?

if so, i'll start a new thread, and start the whole concept to code thing...

hey... it should be fun... for everyone... devote or detractee :)

--Mike

Red, how can I put this lightly?

You don't have any idea what you're talking about. :)

Without requirements (or even a general idea of what kind of game you're making) you can't decide what classes you'll need. Simply put, you can't orient "nothing" or "everything" into objects. You need a problem. OOP isn't magic, it's just a way to organize things. What are you trying to organize?

Blitz3D is already a game engine capable of making any sort of 3D game.

Add some requirements and your challenge makes sense. For example: a multiplayer FPS with enemies, vehicles, and multiple levels.

If you're going to advocate OOP, please spend some time learning it instead of repeating marketing hype.

P.S. If you want to see the source for my work-in-progress Blitz3D object-based 2d-with-quads platformer I can look for somewhere to host it. You'll never get proper "OOP" in Blitz3D. BlitzMax is capable of it, Blitz3D is not.

P.P.S.

In the long run, the best tool for the job is the one you should use. Good luck building a skyscraper without a crane.


FlameDuck: Good point and thanks for the history lesson. I stand corrected: complexity, not size. :)

hahahahahahahahaaaa... hahahahahaaaaaa...

aaaaaaaaahahahahahahahaaaa!!!!

i'm so grateful to you for putting it so lightly octo... how else can i thank you, but by showing you how much you don't know what you're talking about... but, i did ask for all input, from all sides of the fence... so i'm gonna take all that you had to say as constructive criticism... ( even though it is so full of it to be laffable)

challenge accepted... every statement you made in the last post i will make you eat :P

actually, this is gonna be mainly for those interested, and those not interested, but with an open mind on the topic...

new thread begins now CORE B3D OO ENGINE...


--Mike

[strike]Violence[/strike] laughter is the last refuge of the incompetent?

that laughter you're hearing is the gods laughing at your humilation... hey, look up and see why :P

the core of game engine is done... in about 2 hours...

heee hawwww!!!!

LOL ;)

--Mike

Mine's bigger.