You used the required software (e.g., Godot, HTML/CSS/PHP) and created a working project that can be used by the target user. 

You tested the project to ensure it functions correctly and doesn't crash on standard use.

Your project uses the standard elements expected for that medium (e.g., a game has a main menu).

TWO or more implications should be explained in the context of the game's design, code, and user experience. These points explain the non-technical factors students must consider and document in their project.

• Functionality: You must explain why robust collision detection is essential to prevent the player character from falling through the floor or getting stuck, which would otherwise ruin the game's stability.

• Usability: You must state why the game needs intuitive controls (e.g., WASD for movement) and a clear, simple on-screen UI (health bar, score display) so the player can learn the game quickly.

• Accessibility: You must mention why features like high contrast UI text are necessary for players with visual impairments, or why you need to include subtitles for important dialogue or sound cues (as an alternative to audio).

• Aesthetics: You must explain why maintaining a consistent art style (e.g., pixel art) across all sprites and backgrounds is vital for maintaining the game's theme, and why the music must match the intended mood of the level.

• Intellectual Property (IP): You must explain why any non-original assets (e.g., free background music, sound packs) must be honoured and credited according to their specific license (e.g., CC0 or Attribution), even in a student project. 

• Social: You must briefly discuss one message your game might convey (e.g., promoting teamwork or critical thinking if it's a puzzle game) or why player data (if scoring/logins are implemented) must be stored responsibly.

You must show evidence of actively debugging the game, finding a specific issue during testing, and applying a technical fix (e.g., changing a GDScript function or adding a control structure) to resolve the problem. (This is the exit ticket/ePortfolio daily lesson posts)

For example (partial evidence):

• Initial Test Finding: During playtesting with classmates, the game kept randomly freezing when the player interacted with the enemy object.

• Debug/Improvement: The code was reviewed, and I discovered the enemy's collision script was running every frame (_process) instead of only when needed (_physics_process), causing a resource conflict. I changed the function call in the enemy GDScript from _process() to _physics_process().

• Merit Met: This shows I used information from testing (the freeze) to improve the quality (stability) of the outcome using a technical fix informed by engine conventions.

You must consciously use recognised game development best practices (like modularity or centralising resources) to make the code or design better than the initial version.

For example (partial evidence):

• Initial Test Finding: I initially wrote the code to manage the player's score and health directly inside the main Player script, which made it confusing when trying to update the UI score.

• Debug/Improvement: I refactored the score and health into a separate Autoload (Singleton) script called GlobalStats. I then updated the Player and UI scripts to reference the centralised GlobalStats variable.

• Merit Met: This shows I applied relevant conventions (modularity/singletons) to improve the quality of the outcome by making the code structure clearer and easier to manage for future updates.

You must show how one of the implications you identified (e.g., Usability or Accessibility) was actively addressed in the final product.

For example (partial evidence):

• Initial Implication Finding: I noted in my planning that Usability requires the player to clearly understand their status. My first version only showed health as a number, which was slow to read.

• Debug/Improvement: I added a visual health bar UI element that changes colour from green to red as the health decreases. I then wrote GDScript to link the Player health variable to this bar's visual percentage.

• Merit Met: This demonstrates I addressed a relevant implication (Usability) using a visual solution, resulting in a direct improvement in the quality of the player's experience.

You must document not just fixing bugs (Merit), but making intentional, cyclic improvements to the design, code structure, or user experience (UX) across multiple stages (design, development, and testing).

For example (partial evidence):

• Process: I started with a single, complex MenuScene containing all UI elements (start, options, credits). During initial user testing (Stage 1), players found the layout confusing.

• Refinement: I iteratively restructured the menu into three separate, linked scenes (e.g., StartScene , OptionsScene , CreditsScene ) and used a ChangeScene function to manage the flow. This required refactoring the navigation GDScript but made the user experience significantly cleaner.

• Excellence Met: This demonstrates iterative improvement throughout the design process (refactoring complex structure into simple, modular parts) to produce a high-quality UX outcome.

You must show evidence that you planned and used advanced, efficient methods (like those listed in the advanced techniques) to save time, reduce code redundancy, and ensure professional quality. 

For example (partial evidence):

• Process: When creating the first two enemy types, I wrote two completely separate GDScript  files, duplicating the movement, damage, and death logic.

• Refinement: I created a generic "BaseEnemy" Scene Template and an accompanying BaseEnemy.gd script containing all common logic (damage calculation, physics calls). The specific enemy types (e.g., Slime, Bat) then Inherited from this base script.

• Excellence Met: This shows I used an efficient tool and technique (inheritance/scene templating) to reduce code redundancy and create a highly modular, professional structure.