Get to know classes

This workbook will help you understand how to use objects and object-oriented programming when building games and interactive art. This is not a required assignment and awards no points. You should still check it out, especially if classes and objects and when to use them mystifies you.

Let's start with the big concept stuff, then we'll get into some practice questions.

Object-Oriented Programming

Until last week, we have been primarily using procedural programming--meaning our code executes line by line. We can use control flow structures, like for loops and if statements to change the order of execution on a relatively small scale. We saw this when we worked with animations in PC06, when we added loops into our generative art. But when we need to change the order of execution on a larger scale, we need to bust out the big guns.

Many students have discovered the limitations of functions and for loops can take us. It's much easier to make similar objects than to write out the script to make similar-behaving animations or interactive components over and over again. Using objects is like using a stamp to repeat similar items, instead of drawing them repeatedly by hand.

Object-oriented programming creates small, standalone pieces of code--like mini scripts-- that can execute tasks and interact with other standalone pieces of code. The clearest example of this is a video game!

In the image above, right to left, we see:

• Mario - who is controlled by a standalone chunk of code that has user interactivity (controller input) and can interact with other features in the game (other characters, pipes, bricks, etc.)
• Goombas (brown mushroom baddies) - who have some programmed behavior and can interact with Mario (they can shrink Mario, kill Mario or be killed by Mario) and other Goombas (change direction)
• Koopa (green shell) - who has some programmed behavior and can interact with Mario, other Koopas and Goombas.

Each of these characters are objects, which are created by classes. The Goomba class would make individual goomba objects, the Koopa class would make individual koopas, and so forth. Each of these objects are individual, but have the same set of traits.

The coolest part of objects is that we can change individual objects, and not affect OTHER objects made from the same class. In other words, Mario can squish a goomba, and other goombas will still putter about, unaffected. 

The features that make goombas look like goombas are controlled by attributes--variables that are stored inside a class and thus contained within objects when they're made.

The features that make goombas behave like goombas are due to methods--functions that are stored inside a class and thus contained within objects when they're made.

We can assign behaviors and features to our objects by creating a sort of blueprint using Classes.

 

Classes

When you're creating your own games or interactive art (like a visualizer or data visualization), you can think of when to sort into objects by thinking about what you want sections of your game to accomplish. Once you know what each type of object will do, you can start to design your classes. When it comes to writing the code in your classes, you can think of classes as little tiny scripts that live inside of a bigger script. 

 

Let's consider the Game structure.

You have Rect objects -- invisible rectangular shapes that interact with your display object (pygame.display) and the user (clickable).

Now let's say you want to make a counter object for your click game. Your counter class would need a method that can detect how many Rect objects there are, and display a number onto your display object.

In order to display numbers, the counter object will also need attributes that describe the text.

Taking the time to think about the tasks you want your object to accomplish will help you write the pseudocode for what the class should contain.

 

In sum: when thinking of how and when to structure your classes for projects, attributes will have to do with appearances -- things like shape, speed, color, size, count. Meanwhile, methods will have to do with behaviors -- things like interactivity, and boundary conditions (do they bounce or disappear or wrap around?).

Let's practice making some classes based on some goals.