Add additional functionality to an instance of a class?

[randy0428]

I’m not so sure I understand the usefulness of making classes (pseudo-classes).

I’ve created a class called Shape (based on the video www.youtube.com/watch?v=KDXUE1enqXE). It takes 5 arguments: x, y, xSpeed, ySpeed and shapeMode (which is used to make the shape either “fill” or “line”). I didn’t include width and height because I extended this class with 2 sub-classes, Rectangle and Circle. Circles don’t have width and height. This class (Shape) has NO update or draw functions.

The two sub-classes are very similar to each other and have 2 arguments and update and draw functions. Rectangle has width and height and Circle has radius and numSegments (the number of segments for drawing the circle). They work fine. If I create an instance with an xSpeed and/or a ySpeed they do as you’d expect: they appear on the screen and move as specified by the speeds.

With these classes, I can make instances of them but I’m not sure how to actually use them. For example, if I make two instances and I want one of them to stay in the game (like a ball), how do I add the functionality of bouncing off the edges/”walls”? And if I want the other to go off screen when it gets to an edge/”wall” and be destroyed (like a bullet), how do I add that functionality?

I guess the question boils down to “How do you give a specific instance of a class additional functionality that other members of the class don’t have?” Is this possible as in the bounce off walls vs go off screen example I mentioned above?

[St. Cosmo]

While I am not an OOP wizard, usually two instances of the same class should implement the same behavior and only differ in their variables, like for example position, color. Like there are red cars and blue cars, but they are all part of the "car" class. In a strict OOP pattern, you would then define further child classes, like a "BouncyBall" and a "StaticBall".

However, you do not HAVE to do this since Lua is not an object oriented language.
Since both the class itself as well as their instances are simple tables, there is nothing that is stopping you from adding functions or variables to either of them at any time you want.
For example, you could create a new separate table

Code: Select all

BouncyBehavior= {
    restitution = 0.9,
   otherValue = true
}

function BouncyBehavior:bounce()
    //do whatever here
end

Then you can simply Add the contents of this table to either the class (if you want this behavior available to all instances) or to a specific instance only.

Its as simple as

Code: Select all

function AddBehavior(target, source)
        for k, v in pairs(source) do
                target[k] = v
        end
end

This is called "composition" as opposed to "inheritance".

[randy0428]

Thanks for your reply St. Cosmo. I’m inclined to follow the advice you give in the first paragraph, rather than try to do as you suggest in the rest of your reply, which seems unnecessarily complicated. I’ve actually been thinking about 2 options related to your first paragraph. One option is to create a bouncy (called bounded, since the object is contained within the bounds of the screen) and a “go off screen” (called unbounded, since it can go outside the bounds of the screen) child class for both the Rectangle and Circle classes.

The other option is to skip the Rectangle and Circle classes and just make 4 separate children classes of the Shape class: BoundedRectangle(), UnboundedRectangle(), BoundedCircle(), UnboundedCircle(). I guess I really need to look at what will be necessary in the game to see if I will need to create enough such rectangles and circles to justify making classes rather than simply creating instances of rectangles and circles as necessary without classes.

Thanks again.

[St. Cosmo]

Whatever works for you, I just want to give you one last thought, that is that many people (who are far more knowledgeable than me) consider object oriented programming to be largely unsuited for gamedev.

At the beginning it all sounds like it makes sense, you need a basic "Entity", then maybe as children a "GameObject" and a "Prop", then for the GameObject maybe "Moving" or "Static", then "Shooting", "Bouncing" etc., but sooner or later you might find that your "projectile" class moves like a character but has no health and inherits from some other object that has this property you need but not some other.

What I am trying to say that gameobjects tend to need certain behaviors (Moving, Shooting, Bouncing) that cannot be aligned in a logical hierarchical inheritance tree, which is where either an ECS pattern or class composition come into play, just as keywords for a google research if you are interested.

[randy0428]

Thanks again, St. Cosmo.
I've made a few games and I didn't use OOP for them. I've been experimenting with the OOP and I can see why someone would think it's not that well suited to gamedev. That may be especially true for the type of games I'm making. I teach English in Brazil and I make games to keep my classes interesting. There's not a lot of repetition of items (like firing streams of bullets) that are well handled by OOP. It's been interesting to experiment with it, but I'll probably not use OOP much in the future.