Since a class will always have a super class, this basically says, if I have a super class (which is always) then return myself. This means, if this class is equal to super’s init, then do this and return self. An initializer is just another name for a Class’ init method. So lets take a look at a practical example, an initializer. If GamePlayer doesn’t have that method then it will keep going until it finds that method. So if the method doesn’t exist in GamePlayerHero, the hero object looks to its parent class or super class, GamePlayer. That is what object inheritance in OOP is all about. If it doesn’t exist in self, that object will look to its super for a corresponding method. You are calling the blowHisNose method which should exist in our GamePlayerHero class. Lets say you’re inside GamePlayerHero and you are coding away. This is the reason we subclass objects, in order to use a base functionality for all (all game objects must remain onscreen at all times) but give specific functionality to others (followMainPlayer method). The logic for a friend will not include any methods to follow or attach our hero, whereas enemies will have to have that sort of logic. Clouds may be moved by wind and that is about it! But a GamePlayer, our hero, needs to have a lot more internal logic, his own Artificial Intelligence logic if you will.īy the same token, GamePlayer may include our hero instance but it may also include a friend instance, which may be like his sidekick or something. But some GameObjects will just sit there, like trees and clouds. This makes sense because your GameObjects may be characters that have a personality and animation and perform actions. Which is to say, GameObject is the parent of GameCharacter. GameCharacter is a subclass of GameObject. GameEnemy (Some GameCharacters are bad and some are good).GameCharacter (Distinguish between GameCharacters and GamePowerUps).GameObject (Everything is a GameObject).For example, lets say we create this hierarchy: Self means, that very same class you are currently in. This is where self and super take hold in your brain. You can create a GameObject Class in 1 file set or in different file sets. So let’s look at init methods, designated initializers, self and super. For example, you might want all Powerup class objects to have a setAutoDestroyTime method that gives any object of that class a specific time to live onscreen before it disappears. But you can also subclass GameObject to build functionally similar types of objects like a Powerups subclass or an Enemy subclass. Thus it would be nice to have a method, something like keepObjectInBounds, to make sure you can call it on any or all objects to make sure they are not halfway or all the way offscreen.Īfter you build you base class, GameObject, you will subclass it to build objects. Its not unthinkable to believe that at some point you might inadvertently cause a game object to be pushed off screen. ![]() Its important to create a base class for all objects because, as a simple example, you want to be able to constrain all game objects to your screen. A GameObject is anything used in a game from labels to sprites to power ups. The more you order your objects, the cleaner your code will be as well. Its important to keep your Game Objects ordered as well as your code. Create a GameObject class, a GameCharacter class and then subclass these. ![]() Keep your game classes organized and logically ordered.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |