//This creates the object
LET badGuy = new BadGuy
badGuy.name = "Darktanyon"
badGuy.hp = 5
badGuy.str = 3
badGuy.def = 6
badGuy.weapon = "Whip of Misfortune"
//Now that the bad guy is all set lets add him to an array
APPENDARRAY badGuyArray, badGuy
//Set up bad guy object
LET BadGuy = 5
LET BadGuyName = 1
LET BadGuyHp = 2
LET BadGuyStr = 3
LET BadGuyDef = 4
LET BadGuyWeapon = 5
LET badGuy$ = CreateObject$(BadGuy)
LET badGuy$ = SetObject$(badGuy$,BadGuyName,"Dartanyon")
LET badGuy$ = SetObjectNum$(badGuy$,BadGuyHp,5)
LET badGuy$ = SetObjectNum$(badGuy$,BadGuyStr,2)
LET badGuy$ = SetObjectNum$(badGuy$,BadGuyDef,6)
LET badGuy$ = SetObject$(badGuy$,BadGuyWeapon,"Whip of Misfortune")
PRINT GetObject$(badGuy$,BadGuyName)
PRINT GetObject$(badGuy$,BadGuyHp)
PRINT GetObject$(badGuy$,BadGuyStr)
PRINT GetObject$(badGuy$,BadGuyDef)
PRINT GetObject$(badGuy$,BadGuyWeapon)
LET returnString$ = ""
FOR i = 1 to object-1
LET returnString$ = returnString$ + ";"
NEXT
RETURN returnString$
LET val = COUNTFIELDS(object$, ";")//number of fields separated by ";"
IF objectVar > 1 THEN
FOR x = 1 to objectVar-1
LET var2$ = var2$ + NTHFIELD$(object$, ";", x) + ";"//gets each field of var$ and adds it to end of var2$ and then adds separator
NEXT
END IF
IF objectVar+1 < val THEN
FOR x = objectVar+1 to val
LET var3$ = var3$ + ";" + NTHFIELD$(object$, ";", x)
NEXT
END IF
LET object$ = var2$ + setVar$ + var3$//put it back together again
LET var2$ = ""//set variables back to nothing so they are fresh for your next change
LET var3$ = ""
RETURN object$
return NTHFIELD$(object$, ";", objectVar)
LET val = COUNTFIELDS(object$, ";")//number of fields separated by ";"
IF objectVar > 1 THEN
FOR x = 1 to objectVar-1
LET var2$ = var2$ + NTHFIELD$(object$, ";", x) + ";"//gets each field of var$ and adds it to end of var2$ and then adds separator
NEXT
END IF
IF objectVar+1 < val THEN
FOR x = objectVar+1 to val
LET var3$ = var3$ + ";" + NTHFIELD$(object$, ";", x)
NEXT
END IF
LET object$ = var2$ + str$(setVar)+ var3$//put it back together again
LET var2$ = ""//set variables back to nothing so they are fresh for your next change
LET var3$ = ""
RETURN object$
return val(NTHFIELD$(object$, ";", objectVar))
Yes, yes, getting all technical.
I use the word object because it is easier to understand than struct for someone who has never programmed in anything but simple game makers.
I'm fairly sure it won't matter. This artificial object test I made is incredibly similar to Classes which in turn is also similar to Structs. They are all close so I doubt it matters.
The goal is to make game making easier to understand and use. One reason sprites are called sprites. When in OpenGl they use textures. Unless a custom sprite class is made.
Bah, doesn't matter. Call it what you wish. It's functionality resembles both.
Classes can hold variables. Variables can be accessed, set, and read. Classes can be stored in arrays.
These artificial objects can do the same. They resemble classes even if they don't fully duplicate functionality.
They also resemble structs.
But the word object is easier to understand than struct to a beginner. For example, a weapon object. Holds the name, damage, cost, ect. Makes more sense to an untrained mind than a weapon struct. Chances are when they move to a more advanced language they'll just use classes as objects instead of structs.
i dont see how thats easier than just putting all the enemy stats in one string array like this:
LET badguy$(1)="dartanyon,5,2,6,whip of misfortune"
then when needed, all the stats are loaded into arrays.
In a non-C related programming language where other terms aren't known, the name object makes complete sense.
An object has attributes, certain definable characteristics.
This is what my code accomplishes.
For example there's a cube in front of you. Lets say it's the color red, is 5 inches in length, and is 1 pound.
In Sc that cube would be an object with those attributes defined.
From an inexperienced user's viewpoint this name makes perfect sense.
I'm sure you guys are correct in your terminology.
In a non-C related programming language where other terms aren't known, the name object makes complete sense.Reread?
An object has attributes, certain definable characteristics.
Reread?I have read it, its still wrong.
Gan - I hadn't, but I have now. Very cool stuff. I love how they described Bohr's use of neutrinos as a "hack."The method thing is a bit iffy too. But my problem is not with syntax, its with semantics, plus thats not what this thread is about. Also I was wise (not really) and more-so cynical (not too mention opinionated!) at least a year or two before my year long exodus, so your argument and humorous 4chan culture reference is invalid. (http://www.thebuzzmedia.com/wp-content/uploads/2008/05/my-hair-is-a-bird-argument-invalid.jpg)
Also, x, SC calls its functions "methods," which they are technically not because they do not belong to classes.
An object, such as a weapon, a dragon or a castle, is a thing with characteristics, such as size, shape, colour etc. Therefore, I doubt there'll be any confusion in referring to the collective group of variables which represent an object's characteristics as an "object".
I can only speak for myself, Gnome and Eq, but none of us were very surprised to learn that our simplistic card based development systems used dumbed down commands and features from the high level languages they were built in, whilst retaining the names they were based on.
I've never met a kid with a cork-pop riffle who couldn't understand why people referred to it as a gun, when clearly it was a toy. In the same way, this list of variables represents an object.
is a castle not a structure as much as its an object? Wouldn't it make sense to name this using the correct programming paradigm?Clearly to you it would, as you think it would be sensible if the term was correct with other languages, but I think it would be more sensible if the term was immediately understandable, and I think object is considerably more obvious than struct.
Please read my posts before you criticize me for a moot point. :PI don't mean to criticize you, and I did read your posts.
Clearly to you it would, as you think it would be sensible if the term was correct with other languages, but I think it would be more sensible if the term was immediately understandable, and I think object is considerably more obvious than struct.
Nobody's wrong here, there's just a disagreement on what's sensible.
I don't mean to criticize you, and I did read your posts.
x, it is you that doesn't understand! ;D I'm talking about real objects, not the programming sense of the word. I'm talking the chair your sitting on, the glass of milk you're sipping, and the clock that's just made me aware of how late I am! Fare thee well!
I think I understand what the argument is. Silverwind is programming the chair by saying their is a chair there and it has these features. x is arguing that the chair is an object with these chair features like all other chairs in the chair object.
I think I understand what the argument is. Silverwind is programming the chair by saying their is a chair there and it has these features. x is arguing that the chair is an object with these chair features like all other chairs in the chair object.
THE ARGUMENT: Chairs are things with chair-like properties that are shared by all other chairs within a chair, recursing to infinity.
8)
I agree, no-one is wrong, we're just arguing semantics I guess.
I know that! I'm just saying that seems silly too me since these things are also structures are they not? So we may as well use the correct programming term! Although the term object does make a little more sense to be fair, I just can't stand incorrect terminology, which is a fairly odd character flaw I must admit. And good day too you sir, sleep well and try not too lucid dream, I hear its very tiring ;)
I would like to point out that in C++ both structs and classes are exactly the same. class is just a C++ struct in which the default access to it's variables is private instead of public, like a struct.
Class is just formally used for objects that'll take into consideration encapsulation, polymorphism, abstraction, and hierarchy.
and although the C++ struct can hold functions, in good programming practice it doesn't. That is left to objects, because of practice, and the added functionally of the copy-constructor, printing constructor, and all the rest.
thanks ;) grave digging is my specialty
You assumed that an object is a data type that holds both data and functions. Thats a common incorrect assumption. The definition of an object is something that is capable of data hiding, polymorphism and inheritance. Thats the important difference between a struct and a class.
Otherwise whats the point of C++? Since C has structs...
Edit: Nice grave digging.
thanks ;) grave digging is my specialty
a C++ struct is way different than a C struct. It has added functionalities.
You just compared a C struct to a C++ class.
I was comparing C++ struct to a C++ class
Well thats an annoying and pointless comparison. Lets compare a sea with an ocean while we're at it, thats just as frustratingly niggly and irrelevant.
If you look at the ASM generated, a struct and a class in C++ is the same thing from a machines point of view.
The comparison was meant to show that structures, and objects are so closely related. That determining a difference is impossible. The only way to distinguish is the declaration, and usage. not very 'niggly' now is it. 8)
P.S. aren't sea and ocean the same thing? Except that most (comparably) smaller bodies of water are seas.
oh I see we're on the same side ;D