Orbarella (MonoGame) Devlog #7 - New HUD & Multiple Levels

Lots more refactoring work in this devlog. I've separated out a Nightmare System, created a HUD class for the UI, reworked the JSON data so that I could create 3 distinct levels to the game, and finally allowed the player to win the game.

AI Generated Summary: 

Refactoring: A Love-Hate Relationship 

• Mixed feelings towards refactoring, appreciating its ability to clean and maintain code but also finding it challenging when starting with poorly organized code.
• While implementing features for a clock and day-night cycle, the speaker notices their main scene class is becoming unwieldy, prompting thoughts on refactoring.

Identifying Areas for Improvement

• The speaker identifies that the "scene one" class contains excessive nightmare-related code, which leads to the creation of a new class called "nightmare system."
• In the load content section, various text elements (like score and game over text) are scattered throughout the code, leading to concerns about organization.

Conceptualizing a Heads-Up Display

• The speaker considers creating a dedicated heads-up display (HUD) class to manage all text elements like scores and clocks separately from game logic.
• There’s an acknowledgment that this separation will help in managing visual elements independently from logic components in future games.

Balancing Completion with Quality

• As the project nears completion, the speaker feels pressure to finish quickly but recognizes that rushing could lead to unfinished or subpar work.
• Reflecting on past experiences with previous games, there’s an awareness of how hasty decisions can result in incomplete features or messy implementations.

Commitment to Improvement

• Despite wanting to move on quickly, the speaker resolves to invest time into refining their current game through thoughtful refactoring and abstraction of reusable components.

Game Development Reflections and Challenges Refactoring Code in Game Development

• HUD class which initially included elements like the clock and score.
• A new challenge arises with the addition of a **nightmare meter**, revealing flaws in their logic regarding how game states are managed.

Issues with Game Logic

• The current implementation checks if the nightmare meter is full to determine if it's game over, but this approach incorrectly ties graphical representation to game logic.
• The speaker realizes that the nightmare meter should not have knowledge about game outcomes; it needs abstraction into something more generic like a **threat meter**.

Separation of Concerns in Game Design

• Emphasizing separation between rendering and game logic, they note that changing visual aspects shouldn't require rewriting core gameplay mechanics.
• They acknowledge ongoing struggles with organizing code effectively while aiming for better abstraction in future designs.

Future Improvements and Level Design

• The need for a UI system is identified, suggesting components for drawing various meters generically across different games.
• After refactoring, they mention improved clarity in querying systems within their main game's update loop, allowing for normalized values between zero and one.

Building a Level System for a Game Reducing Duplication in Building Definitions

• The speaker discusses the need to eliminate duplication in building definitions, specifically mentioning that houses one, two, and three are currently copied and pasted.
• A proposal is made to create separate files: one for building definitions (house characteristics) and another for level composition (which buildings are included).

Progress on Level Loading System

• The task involves reworking the loading system to accommodate different levels while tracking player progress and scores across them.
• Updates indicate that there is now a single definition per building in the data structure, improving clarity and reducing complexity.

Testing New Levels

• A new folder structure has been created for testing levels; ID0 is used for initial tests without dynamic loading or progression between levels.
• The focus shifts towards compacting data loading processes, making it more readable while passing necessary details to the nightmare system.