Unformatted text preview:

AnnouncementsProblem: Adding exhaust, shield to spaceshipDecorating the spaceship with shield & exhaustDecorators using object-oriented codeDecorator patternEssence of the Decorator patternImplementation detailsDecorator Pattern: Pros and ConsProblem: Magic system with variable effectsAn approach: Chain of Spell HandlersChain of Spell HandlersChain of Spell HandlersChain of Spell HandlersChain of Spell HandlersChain of Responsibility PatternImplementation detailsChain of Responsibility: Pros and ConsProblem: Representing Game StateApproach: Singleton PatternSingleton ImplementationSingleton AdvantagesHomeworkPotential Exam TopicsPotential Exam QuestionsPotential Exam QuestionsPotential Exam QuestionsPotential Exam QuestionsComputer Science – Game DesignUC Santa CruzAnnouncements•Website–Readings and sample code updated–Last year’s mid-term exam with answer key–Mid-term exam dateComputer Science – Game DesignUC Santa CruzProblem: Adding exhaust, shield to spaceship•Vertically scrolling 2D space shooters have a spaceship that:–Banks left or right, depending on motion–Typically have three animations:•Banking left, straight ahead, banking right•Also want to–Add particle effect for exhaust if the ship is moving up the screen•But turn this off if it’s moving down the screen–Add a shield in front of the ship if the player picks up a shield powerup•Could accomplish all of these visuals using a series of combined animations–Bank left, bank left and shield, bank left and exhaust, bank left and shield and exhaust, etc..–But, leads to combinatoric expansion•Isn’t there a better way? Why, yes!Ikaruga, TreasureComputer Science – Game DesignUC Santa CruzDecorating the spaceship with shield & exhaust•Instead of pre-defining all possible animations…•Draw the shield, exhaust, and spaceship separately–Can think of “decorating” the spaceship with a shield, or an exhaust particle effect, as needed–No longer need large combinations of animationsSome powerup options in GradiusGratuitous picture of a Vic Viper modelComputer Science – Game DesignUC Santa CruzDecorators using object-oriented code•Basic idea is to create a linked list of objects–Each object draws one part of final scene…•E.g., the exhaust, the shield, etc.–… then calls the next object on the list–The final object is the main object being decorated•E.g., the spaceshipspaceshipspaceshipshieldshieldexhaustExhaust, shield, and spaceship are object instancesComputer Science – Game DesignUC Santa CruzDecorator pattern•IComponent interface gives just the decoration Operation()–Can mix in this Interface with a wide range of classes•Component is terminal element (spaceship)•Decorator provides decorating elements (shield, exhaust)–Diamond-headed arrow indicates that Decorator instances have a reference to an instance of IComponent (another Decorator, or a Component)Example of Decorator patternComputer Science – Game DesignUC Santa CruzEssence of the Decorator pattern•The essence of the Decorator pattern–Linked list of object instances, first one calls next one, etc.–Each object adds its particular computation (often, but not exclusively, visual) to the output before passing to next object–It is possible to have multiple chains, each ending at the same terminal (or decorator) object•Can pre-arrange commonly used decorator chainsComputer Science – Game DesignUC Santa CruzImplementation details•Need to know next object in chain–Typically passed into the constructor•Could have a separate method instead (would need to add this to IComponent•May need to know details about terminal object–Need to know position of spaceship to put shield directly in front, and exhaust directly in back–Each object in list can be given reference to terminal object•Use reference to spaceship object to retrieve its current location•May need to remove a decorator–E.g., shields no longer active–Will need to write code that removes a decorator instance, and repairs the links among remaining ones–If the removed decorator is the first in the chain, removal is easyComputer Science – Game DesignUC Santa CruzDecorator Pattern: Pros and Cons•Pro: Favors composition over inheritance–Decorator chains created at runtime, can be dynamically changed–Avoids combinatoric expansion of subclasses•Pro: Avoids feature-rich parent classes –New decorations are “pay as you go”–Avoids need for adding all features into large, customizable parent class•Con: Decorator and component aren’t identical–Requires more complex handling of situations where you really want direct access to terminal component•Con: Many little objects–Can result in designs that have lots of little objects that are very similar–Can be hard to learn and debug, since so many classes affect outputComputer Science – Game DesignUC Santa CruzProblem: Magic system with variable effects•Consider a game that has castles, fighters, wizards, and magic cars–Fighters can be inside castles–Wizards have spells:•Some only affect the castle, weakening its walls (lightening bolt)•Other, more powerful spells, weaken the walls and do damage to the people inside (fireball explosion)•If the people inside the castle are inside a magic car, the car absorbs some, but not all, of the damage•Need some way to have the applied damage vary depending on who is inside what –E.g., damage depends on containmentComputer Science – Game DesignUC Santa CruzAn approach: Chain of Spell Handlers•Create objects that–Represent a cast spell–Represent castles, fighters, cars•Create a chain of object references that represent containment–Castle –references-> Car –references-> Fighter•Pass each spell object along the containment chain–Castle handles spell first, absorbs some damage, reduces power of spell, and passes it along to Car–Car handles spell, reduces power of spell (no damage – it’s magic), and passes along to Fighter–Fighter handles spell last, applying damageComputer Science – Game DesignUC Santa CruzChain of Spell Handlers•Chain of object references looks like Decorator chain–Containment of castle(cars(fighters))•Separate object represents request (spell)fighterfightercarcarcastlefireballpower = 100HP = 500HP = 100HP = 50Fireball spell handed to castle for processing firstComputer Science – Game DesignUC Santa CruzChain of Spell Handlers•Chain of object


View Full Document

UCSC CMPS 20 - Lecture Notes

Documents in this Course
Load more
Download Lecture Notes
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Lecture Notes and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Lecture Notes 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?