|
Pages: 1 [2]
|
 |
|
Author
|
Topic: SENSO - A fighting game (Read 4379 times)
|
|
|
RTyp06
*Smell* controller
 Offline
Posts: 491
|
Object-oriented programming (OOP) is a programming paradigm that uses "objects" – data structures consisting of data fields and methods together with their interactions – to design applications and computer programs. Programming techniques may include features such as data abstraction, encapsulation, modularity, polymorphism, and inheritance. Many modern programming languages now support OOP.
That's straight from Wikipedia. Perhaps i'm not understanding your objection but onpon said:
Your GM days might have taught you that "objects" refers to special game classes, but the term is actually much more loose. In this usage of "object", I am referring to any set of immutable data, i.e. an integer, string, or class instance.
Object doesn't refer to a special "game class" and an object, as I understand it, is not refferring to any particular variable which is what he seems to be saying an object is. An object is a collection or set of data manipulated by a single object name and that contains it's own coding instructions to manipulate the data held within the object. Game Maker, which I've been toying around with for several years now, is a scripting language based around object oriented programming (OOP). Objects in GM act much like objects in any modern programming language. GM is just less flexible and all objects in GM have alot of overhead because they are universal. So if I need, say, a simple object to draw a head's up display on the screen, there are alot of unnessicary variables not being used such as image_angle, image_speed or hspeed etc..
|
|
|
|
« Last Edit: September 08, 2010, 07:59:32 pm by RTyp06 »
|
Logged
|
|
|
|
onpon4
Enlightened
Offline
Gender: 
Posts: 709
Sharing is good.
|
Object doesn't refer to a special "game class" and an object, as I understand it, is not refferring to any particular variable which is what he seems to be saying an object is.
Actually, you're off about what I said. I was saying that "object" refers to ANY class, not just classes which GM calls "objects". In fact, I was a bit too specific previously, because I stated that I was referring to only immutable data types, when in reality mutable data is still an instance of a class.
For example, in Python, there is the int class (for integers), the float class (for floating-point decimals), the str class, the list class, the dict class, and so on. All of these are in fact objects.
When I was talking about "returning objects", I was specifically referring to the canned collision detection functions, i.e. collision_point(), collision_circle(), and collision_rectangle(). The word I should have used is instance, because these functions return either 0 (if there is no collision) or the first instance ID, which is actually not an object, but an instance of (I believe) GM's float data type.
What I was saying is that because these functions only return the first instance ID, and not a list or array of all instance ID's which pass the collision test, collision detection is MUCH more difficult. I encountered serious issues with half-solid platforms in Bowser Engine which could have been easily solved if I were able to act on ALL collisions, rather than just the first one the game detected. Of course, this problem could have been averted by using a custom script instead of the canned function, but the problem is, Game Maker's ONLY advantage is that it's supposed to do these things for you.
Game Maker, which I've been toying around with for several years now, is a scripting language based around object oriented programming (OOP). Objects in GM act much like objects in any modern programming language. GM is just less flexible and all objects in GM have alot of overhead because they are universal. So if I need, say, a simple object to draw a head's up display on the screen, there are alot of unnessicary variables not being used such as image_angle, image_speed or hspeed etc..
Actually, GM isn't a scripting language or even a language at all; it's a special program designed to help you create games. GML (the Game Maker Language) is a scripting language. Python is also commonly used as a scripting language; in fact, I learned of Python when I saw users suggesting using Python as GM's scripting language instead of GML.
"Objects" in GM don't really serve the same function as classes in a programming language. In GM, all objects inherit a base class which is designed to be the framework of any game object you might create. In addition to the many built-in variables you mention, this base class also does a lot of work for you that you don't even notice, such as being managed in the background (created, drawn/redrawn, collision detection) without you having to lift a finger, and having an established loop structure and a set of "events" for you to use. Therefore, objects in GM are made to serve a much more specific purpose than classes in, say, C++ or Python.
|
|
|
|
|
Logged
|
|
|
|
RTyp06
*Smell* controller
Offline
Posts: 491
|
When I was talking about "returning objects", I was specifically referring to the canned collision detection functions, i.e. collision_point(), collision_circle(), and collision_rectangle(). The word I should have used is instance, because these functions return either 0 (if there is no collision) or the first instance ID, which is actually not an object, but an instance of (I believe) GM's float data type.
Except collision_point(), collision_circle(), and collision_rectangle() are not objects or instances of objects. Those are called functions or procedures. You provide the arguments and they return a value after the arguments you provide have been run through an algorithm. They are designed so that you can simplify repetitive tasks in your code and don't have to recode the same algorithm time and time again. In GM you create your own functions with scripts. You pass arguments into the script and the script call returns a value. You are correct that those functions return the id of an object if that's what you mean. 0 for false, the returned id equals true.
objects are just a collection of data or variables that relate to itself and are accessed through the object name..
object_tree
object_tree.species
object_tree.color
object_tree.age
object_tree.height
So surely you can understand my confusion of your use of the word object previously.
|
|
|
|
« Last Edit: September 08, 2010, 10:45:28 pm by RTyp06 »
|
Logged
|
|
|
|
|
|
|
|
onpon4
Enlightened
Offline
Gender:
Posts: 709
Sharing is good.
|
Yes I got that part but look what you are saying. For example, in Python, there is the int class (for integers), the float class (for floating-point decimals), the str class, the list class, the dict class, and so on. All of these are in fact objects. integer, float and str are classes assigend to variables. They indicate the value that those individual variables will hold. I've never heard them called objects before... Call me crazy I guess. I don't know what they are teaching you over at Python school. 
So, you can't assign an instance of your game's Player object to a variable? Strange... I remember doing that all the time when I used GM.
On a more on-topic note: Has anyone tried Senso, perhaps with a friend? I haven't seen any feedback yet.
|
|
|
|
« Last Edit: September 08, 2010, 11:14:48 pm by onpon4 »
|
Logged
|
|
|
|
|
|
onpon4
Enlightened
Offline
Gender:
Posts: 709
Sharing is good.
|
Of course you can. The variable will hold the id number of the object. That doesn't mean the variable itself is an object or instance of an object.
Have you ever used a language other than GM? Other languages don't store a number "id" referencing an instance. The variables point to the instance itself. Let me demonstrate with Python. Take a look at this script:
class foo(object):
pass
x = foo()
print('Variable: {0}'.format(x))
print('ID: {0}'.format(id(x)))
If we run this little script, we get this output:
Variable: <__main__.foo object at 0x02A0ABB0>
ID: 44084144
Whoa! That doesn't look like a number at all, does it?
But it gets even better: see, I can actually manipulate exactly what converting it to a string does! By adding the __str__ method to the class foo, as seen here:
class foo(object):
def __str__(self):
return 'Class foo(d!): ID - {0}'.format(id(self))
x = foo()
print('Variable: {0}'.format(x))
print('ID: {0}'.format(id(x)))
We get a different output:
Variable: Class foo(d!): ID - 44084432
ID: 44084432
This is because, in Python, what gets stored in a variable when you create an instance isn't a number, but a reference to the instance itself. In Python, what happens when you convert an instance into the str class is determined by the special __str__ method. On the other hand, if the variables only stored numbers (integers), printing the variable would always result in printing the "id" of the instance.
Game Maker works a little differently. It actually stores the "id" of the instance. Not having seen the source code, I can only guess, but it looks like if a variable is a "real" (float) value, and is followed by a dot, GM assumes it must be a reference to an instance and searches for that instance.
Look, I was just trying to tip you that your use of the word might be confusing to others. That's all.
Being inaccurate causes MUCH more confusion than being accurate.
|
|
|
|
« Last Edit: September 10, 2010, 12:23:37 pm by onpon4 »
|
Logged
|
|
|
|
ziper1221
*Many bubbles*
Offline
Posts: 124
|
"real language" sounds a little harsh.
|
|
|
|
|
Logged
|
|
|
|
|
|
Novus
Enlightened
Offline
Gender:
Posts: 1938
Fot or not?
|
Good grief. I should have looked at this thread earlier. To make this discussion a bit saner:
- An object is an instance of a class (assuming you're not programming in Self or some other language that lacks the concept of class). In this case, there is no such thing as an "instance of an object" (although Microsoft has apparently got their own terminology confused in their NullReferenceException message).
- In some programming languages, primitive values (e.g. integers) are not objects (e.g. C++ and Java), in some they are objects (e.g. Python).
- In some programming languages, an object variable can contain the object itself rather than a reference or pointer (e.g. C++), in some languages only references or pointers are available (e.g. Java).
All of the above are "real languages" in the sense that there are lots of people who use them commercially and academically. Never assume all programming languages work like your own favourite.
|
|
|
|
|
Logged
|
|
|
|
onpon4
Enlightened
Offline
Gender:
Posts: 709
Sharing is good.
|
"real language" sounds a little harsh.
Indeed. Onpon4, by all means continue debating programming languages, but tone it down a bit. Your last message contains a lot of attitude that can be left behind. Lets keep it friendly in here, eh?
I'm sorry, you're right. I've tried to tone it down a bit. For the record, my point does not still stand.
- An object is an instance of a class (assuming you're not programming in Self or some other language that lacks the concept of class). In this case, there is no such thing as an "instance of an object" (although Microsoft has apparently got their own terminology confused in their NullReferenceException message).
Really? I've never heard that. In GM, objects are classes (the term "class" doesn't even show up anywhere in GM). In fact, newbies to GM are often scolded on the forums that an object is not an instance, and to stop referring to instances as objects.
|
|
|
|
« Last Edit: September 11, 2010, 12:29:18 am by onpon4 »
|
Logged
|
|
|
|
|
|
RTyp06
*Smell* controller
Offline
Posts: 491
|
Thanks Novus. It's nice when a knowledgable programmer shows us the error of our ways. My background comes from object oriented programming, Visual C++ which uses pointers to access an object's memory location and Visual Basic which uses "object variables" for the same purpose. Esentially I thought onpon was discussing the equivalent of object variables here.
Symantics aside, if you open up the hood and look at the nuts and bolts of what's going on behind the scenes of any language that has an object class, I'm willing to bet you'll see a similar scheme taking place. All object's are a collection of data that resides at a predefined memory location. Then you access that data through a pointer, variable or other sort of "handle".
GM wasn't confusing for me at all. With GM an object is like any other resource such as a sound or a sprite. When you create an object in GM you are esentially building a resource which acts as a template. When you want to use an object in the game you do so by creating an instance of the object which will then behave according to the programming of the template. This is why they make a distinction between an object and instance of an object.
|
|
|
|
|
Logged
|
|
|
|
|
Pages: 1 [2]
|
|
|
|
|
