Unit 4: Programming - Subjective Questions

A scripting language is a programming language used to define and control the behavior of objects and systems within a game.

In 3D game development, scripts are commonly used to:

• Control player movement and input.
• Implement enemy artificial intelligence.
• Detect collisions and trigger gameplay events.
• Manage animations, audio, cameras, and visual effects.
• Update scores, health, inventory, and user interfaces.
• Define rules for levels, missions, and game progression.

In Unity, C# is the primary scripting language. A script usually inherits from MonoBehaviour and is attached to a GameObject as a component. The game engine invokes lifecycle methods such as Start, Update, and OnCollisionEnter at appropriate times.

Thus, scripting connects game assets and engine features to create interactive gameplay.

A scripting language suitable for game development should provide the following characteristics:

• Ease of use: Developers should be able to write and modify gameplay logic quickly.
• Engine integration: It should provide access to objects, physics, animation, audio, input, and rendering systems.
• Object-oriented support: Classes, inheritance, interfaces, and encapsulation help organize complex game logic.
• Event handling: The language should support callbacks and events for collisions, user input, and gameplay notifications.
• Rapid iteration: Scripts should be easy to edit and test without rebuilding the entire game engine.
• Debugging support: Breakpoints, logs, stack traces, and runtime inspection are essential.
• Performance: Frequently executed scripts must run efficiently, especially inside frame-update methods.
• Reusability: Developers should be able to create reusable components and systems.

C# in Unity satisfies these requirements through strong typing, object-oriented programming, garbage collection, delegates, events, and extensive engine APIs.

Unity invokes lifecycle methods at different stages of a component's execution:

• Awake: Called when the script instance is loaded. It is commonly used to initialize internal references and singleton instances.
• Start: Called before the first frame update, provided the component is enabled. It is useful when initialization depends on other objects completing Awake.
• Update: Called once per rendered frame. It is suitable for input handling, timers, and general gameplay logic.
• FixedUpdate: Called at a fixed time interval. Physics operations, such as applying forces to a Rigidbody, should normally be performed here.
• LateUpdate: Called after all Update methods for the frame. It is often used for follow cameras and logic that must occur after object movement.

Using the correct lifecycle method improves consistency. For example, reading input in Update and applying physics in FixedUpdate prevents frame-rate-dependent physics behavior.

Game architecture patterns are reusable structural solutions to common software design problems found in game systems. They describe how classes, objects, and modules should communicate and divide responsibilities.

They are important because they provide:

• Separation of concerns: Input, movement, audio, user interface, and game rules can be handled by separate systems.
• Reduced coupling: Components depend less on specific implementations.
• Reusability: A well-designed system can be reused across scenes or projects.
• Maintainability: Changes can be made without rewriting unrelated systems.
• Scalability: New features can be introduced as the game becomes larger.
• Testability: Individual systems can be tested independently.
• Team collaboration: Clear responsibilities allow multiple developers to work safely on different modules.

Patterns such as State, Singleton, and Observer solve different architectural problems. However, they should be applied only when needed because excessive use can add unnecessary complexity.

The three patterns solve different types of architectural problems:

Key distinctions:

• The State pattern organizes behavior that varies over time.
• The Singleton pattern controls object creation and global access.
• The Observer pattern provides one-to-many event communication.

They can also be combined. For example, a state may publish an event through the Observer pattern, while a singleton audio manager listens to the event and plays the appropriate sound.

The State pattern is a behavioral design pattern that allows an object to change its behavior when its internal state changes. Instead of placing all behavior in one large conditional statement, each state is represented by a separate class or object.

Its main components are:

• Context: The object whose behavior changes. For example, the player controller.
• State interface or base class: Declares common operations such as Enter, UpdateState, and Exit.
• Concrete states: Implement behavior for specific conditions, such as IdleState, RunState, JumpState, and AttackState.
• Transitions: Rules that determine when the context changes from one state to another.

For example, the player begins in IdleState. Movement input changes the state to RunState, while pressing the jump button changes it to JumpState. Each state handles only the logic relevant to that behavior.

This approach improves organization and makes new states easier to add.

A State-pattern-based enemy AI can be implemented with an EnemyState interface and separate concrete state classes.

Common state operations:

• Enter: Performs initialization when entering a state.
• Execute: Runs the state's behavior during an update.
• Exit: Performs cleanup before leaving the state.

Concrete states:

• Patrol state: Moves between waypoints. It changes to chase when the player enters the detection range.
• Chase state: Moves toward the player. It changes to attack when the player enters attack range or returns to patrol when the player escapes.
• Attack state: Performs an attack according to range and cooldown conditions. It returns to chase if the player moves away.
• Dead state: Stops movement, disables combat logic, plays a death animation, and prevents further transitions.

The enemy acts as the context and stores the current state. A ChangeState method calls the old state's Exit, assigns the new state, and calls its Enter method.

This design keeps AI behaviors independent, readable, and extensible.

A state transition changes the active behavior of an object from one state to another. Transitions are triggered by conditions such as input, timers, distance checks, health values, or animation completion.

The standard state operations are:

• Enter: Called once when a state becomes active. It can reset timers, start animations, configure movement speed, or subscribe to events.
• Execute: Called repeatedly while the state remains active. It processes behavior and checks transition conditions.
• Exit: Called once before leaving the state. It can stop animations, clear temporary data, or unsubscribe from events.

A safe transition generally follows this order:

1. Call Exit on the current state.
2. Assign the new state.
3. Call Enter on the new state.

Separating these operations prevents repeated initialization and ensures that resources and event subscriptions are cleaned up correctly.

A large if or switch statement keeps the behavior of all states inside one class, whereas the State pattern places each state's behavior in a separate class or object.

Conditional approach:

• Simple for a small number of states.
• Requires fewer classes.
• Becomes difficult to read as states and transitions increase.
• Often creates one large controller with many responsibilities.
• Changes to one state can accidentally affect another state.

State pattern:

• Encapsulates each state's behavior.
• Makes states easier to test and modify independently.
• Supports adding new states with fewer changes to existing code.
• Reduces deeply nested conditionals.
• Introduces additional classes and architectural complexity.

For a simple object with two states, a conditional may be sufficient. For a player or enemy with many behaviors and transitions, the State pattern is generally more maintainable and scalable.

The Singleton pattern ensures that a class has only one active instance and provides a globally accessible point through which that instance can be obtained.

A singleton game manager commonly performs tasks such as:

• Controlling the overall game state.
• Starting, pausing, restarting, or ending the game.
• Managing score and progression.
• Coordinating level loading.
• Storing session-level information.

In Unity, the manager usually exposes a static Instance property. During Awake, it checks whether another instance already exists. If a duplicate is found, the duplicate is destroyed. If the manager must survive scene changes, DontDestroyOnLoad may be applied.

Although this provides convenient access, the manager should not contain every game system. Giving it too many responsibilities creates a tightly coupled and difficult-to-maintain architecture.

A persistent Unity Singleton can be implemented using a static instance reference and lifecycle checks.

Typical implementation process:

1. Declare a static Instance property.
2. In Awake, check whether Instance is empty.
3. If it is empty, assign the current component to Instance.
4. If another instance already exists, destroy the duplicate GameObject.
5. Call DontDestroyOnLoad when the object must remain active across scene changes.

Important safety concerns:

• The instance should be assigned in Awake so other components can access it during Start.
• Duplicate objects may appear when a new scene contains another copy of the manager.
• The singleton should define how its static reference is cleared when it is destroyed.
• Script execution order should not be assumed without explicit control.
• The singleton should not perform expensive object searches whenever Instance is accessed.
• Persistent managers must remove references to destroyed scene objects.

A safe implementation provides predictable initialization while preventing multiple active manager instances.

Advantages of Singleton:

• Ensures that only one instance of a manager exists.
• Provides convenient access from different game systems.
• Works well for truly unique services such as save management or audio configuration.
• Can preserve important systems across scene changes.
• Reduces the need to pass the same reference through many objects.

Disadvantages of Singleton:

• Creates global state that may be modified from anywhere.
• Hides dependencies because classes access the instance directly.
• Increases coupling between gameplay systems and the singleton.
• Makes isolated unit testing more difficult.
• Can create initialization-order problems.
• Often grows into a large class with too many responsibilities.
• Persistent instances may retain invalid references after scene changes.

Therefore, the pattern should be limited to services that are genuinely unique. Dependency injection, serialized references, events, or Scriptable Objects may be better when explicit dependencies and testability are important.

The Observer pattern is a behavioral design pattern in which one object notifies multiple dependent objects when an event or state change occurs.

Its main participants are:

• Subject or publisher: Maintains an event or a collection of observers and sends notifications.
• Observer or subscriber: Registers interest in the notification and defines a response.
• Notification: Carries information about the event, such as score gained, health changed, or an enemy defeated.

For example, when an enemy dies, it can publish an EnemyDefeated event. The score system may increase the score, the achievement system may update progress, and the audio system may play a sound. The enemy does not need direct references to all these systems.

The pattern reduces direct dependencies and supports one-to-many communication. Subscribers must unsubscribe when disabled or destroyed to prevent invalid callbacks and memory-related problems.

The player health component acts as the publisher, and the health-bar user interface acts as an observer.

A suitable process is:

1. The health component stores the current and maximum health values.
2. It exposes a health-changed event.
3. Whenever damage or healing modifies health, the component invokes the event and passes the updated values.
4. The health-bar component subscribes when it becomes active.
5. When notified, the health bar calculates the displayed proportion using:

6. The health bar unsubscribes when it is disabled or destroyed.

This is better than making the UI check the player's health every frame. The UI updates only when the value changes, and the health component does not need to know how the information is displayed. Other observers, such as sound, animation, and game-over systems, may subscribe to the same event.

Polling means repeatedly checking whether a value or condition has changed. Event-driven communication means notifying interested systems only when a change occurs.

Polling characteristics:

• Often runs in Update or another repeated loop.
• Can be simple for a small number of checks.
• May waste processing time when values rarely change.
• Requires the polling object to know where the data is stored.

Observer characteristics:

• Subscribers react only when an event is published.
• Reduces unnecessary per-frame checks.
• Allows multiple systems to react independently.
• Reduces direct references between the publisher and subscribers.
• Requires careful subscription and unsubscription management.

For example, a user interface could poll the score every frame, but an observer-based interface updates only when a ScoreChanged event occurs. Polling may still be suitable for continuous conditions, such as checking movement input, while events are better for discrete changes.

Common Observer-pattern problems include:

• Missing unsubscription: A destroyed or inactive subscriber may continue to receive callbacks. Subscribers should unsubscribe in an appropriate method such as OnDisable or OnDestroy.
• Duplicate subscription: Registering the same callback multiple times can cause repeated responses. Subscription logic should be paired carefully with unsubscription logic.
• Unclear execution order: Multiple observers may run in an unexpected order. Systems should not rely on listener order unless it is explicitly controlled.
• Hidden program flow: Events can make it difficult to determine what caused an action. Clear event names and logging help debugging.
• Event chains: One event may trigger another event repeatedly, creating loops or complex side effects.
• Memory retention: Long-lived publishers can keep references to short-lived subscribers.
• Modification during notification: Adding or removing observers while iterating through them may cause errors.

These issues can be reduced through disciplined lifecycle management, immutable event data, clear ownership, defensive invocation, and debugging tools.

A Scriptable Object is a Unity data container that can be saved as an asset in the project. It derives from ScriptableObject and does not need to be attached to a GameObject.

A MonoBehaviour, by contrast, is a component attached to a GameObject in a scene or prefab.

Major differences:

• A Scriptable Object normally stores shared or configurable data as a project asset.
• A MonoBehaviour represents scene-based behavior and can use callbacks such as Start and Update.
• Scriptable Objects do not have transforms and cannot be attached as components.
• Multiple GameObjects can reference the same Scriptable Object asset.
• Scriptable Objects help separate configuration data from runtime behavior.
• MonoBehaviour instances are commonly created with GameObjects, while Scriptable Object assets are created through the Unity editor or runtime creation methods.

Typical Scriptable Object uses include weapon statistics, enemy definitions, item data, dialogue, level settings, and event channels.

Data-driven design separates configurable game data from the code that uses it. Scriptable Objects support this by storing data in reusable Unity assets that designers can edit through the Inspector.

For a weapon system, a WeaponData Scriptable Object may contain:

• Weapon name and description.
• Damage value.
• Attack speed or cooldown.
• Range and ammunition capacity.
• Projectile prefab.
• Audio clips and visual effects.
• Icon and animation references.

A generic weapon component receives a reference to WeaponData and performs attacks according to those values. To create a new weapon, a designer creates another asset and changes its configuration without writing another weapon class.

Benefits include:

• Reduced duplication of data.
• Faster balancing and iteration.
• Reuse across prefabs and scenes.
• Clear separation of data and behavior.
• Easier collaboration between programmers and designers.

Runtime values such as current ammunition should usually be stored separately if modifying the shared asset would affect every object using it.

The three approaches serve different purposes:

Scriptable Objects are useful when many objects need to reference the same editable data. Plain C# classes are suitable for engine-independent logic and are usually easier to unit test. MonoBehaviour components are required when behavior depends on Unity callbacks, transforms, coroutines, or scene objects.

A well-designed game may use all three: a Scriptable Object stores weapon configuration, a plain C# class calculates damage, and a MonoBehaviour handles input, animation, and projectile spawning.

A Scriptable Object event channel is an asset that represents a gameplay event. Publishers raise the event through the asset, while listeners reference the same asset and register callbacks.

For example, a PlayerDiedEvent asset may be referenced by:

• The player health component, which raises the event.
• The game-over interface, which displays a menu.
• The audio system, which changes the music.
• The save system, which records the result.

Advantages:

• Publishers and listeners do not require direct references to one another.
• Connections can be configured through the Inspector.
• The same event channel can be reused across scenes and prefabs.
• Event relationships become more designer-friendly.
• The approach reduces dependence on global singleton managers.

Precautions:

• Listeners must register and unregister correctly.
• Runtime listener collections should not accidentally persist stale references.
• Asset events should be named and organized clearly.
• Designers must avoid assigning the wrong event-channel asset.
• Event channels should not become an uncontrolled replacement for all direct communication.