Lab: game design patterns

Scenarios: game design patterns

1. 1.

   A player picks up a coin. The score UI, the sound system, and the achievement system all need to react. You don't want the player object to know about any of them directly. Best approach?
   Have the player directly call score.add(), sound.play(), and achievements.check()Emit a coin_collected event; let each system subscribe to it independentlyUse a global variable the player sets to TrueCheck for coin pickups in every system's update loop
2. 2.

   You have Player, Enemy, and NPC entities that all need health, but only Player needs input handling and only Enemy needs AI. Using inheritance, GameObject → LivingThing → Player quickly becomes tangled. Better approach?
   Make a deeper inheritance hierarchy with more intermediate classesUse multiple inheritance for all shared traitsCompose entities from components: attach HealthComponent, InputComponent, AIComponent as neededDuplicate the health code in each entity class
3. 3.

   Spatial hashing is worth implementing for any game that has collision detection, regardless of entity count.
   TrueFalse
4. 4.

   In a spatial hash, you set the cell size much smaller than your largest entity. What problem does this cause?
   Entities span multiple cells and must be checked in each, increasing query costThe grid becomes too coarse and misses nearby entitiesEntities can no longer moveThe game loop runs out of memory immediately
5. 5.

   Your game's UI needs to update every time the player's HP changes. HP changes happen in the physics update, in the damage system, and via power-ups. Which pattern fits best?
   Component architecture — give the UI its own HP componentObserver — fire an hp_changed event; the UI subscribesSpatial hashing — track HP changes by grid positionPoll the player's HP in the UI's draw method every frame