Inspiration

What it does

How we built it

Challenges we ran into

Accomplishments that we're proud of

What we learned

What's next for NEO NUGGET TREASURE

Development Journal: Improving Kahliq's RPG Loot System What Inspired Me The original RPG loot system sparked my interest because it mimicked a classic gaming scenario: defeating a boss, earning gold, and sharing rewards with a party. However, its flaw—leaving leftover gold in the chest—resonated with a common frustration in tabletop and video games. In many RPGs, players expect every single coin to be distributed fairly, even if it means some characters receive a minimal extra share. This inspired me to redesign the system to prioritize total loot distribution while maintaining clarity and fairness. I also drew motivation from game design principles that emphasize transparency (e.g., showing exact splits) and player trust. What I Learned Integer Division vs. Real-World Fairness The original code used // (integer division) and % (modulo) correctly to calculate base shares and remainders. But I learned that in collaborative games, fairness isn’t just mathematical—it’s perceptual. Leaving remainder gold unassigned feels unfair, even if logically “even.” Distributing the remainder to the first few players (instead of discarding it) creates a more satisfying experience. The Power of math.ceil and math.sqrt Calculating the “Power Bonus” using math.sqrt() taught me how mathematical functions can add depth to game mechanics. For example: math.sqrt(100) gives 10, but math.ceil(math.sqrt(101)) rounds up to 11, ensuring bonuses scale meaningfully even for small gold increments. User Experience (UX) in Terminal Outputs I realized that raw data (e.g., “leftover_gold = 1”) isn’t engaging for players. Using emojis, section headers, and step-by-step breakdowns makes the system feel like a polished game feature—not just code. Loop-Based Distribution Logic Building the player-by-player breakdown with a for loop taught me how to handle dynamic distributions programmatically. For example, checking if i < remainder to award extra coins simplified what could have been messy conditional statements. How I Built the Project Step 1: Diagnose the Original Problem I started by analyzing the original code: Gold generation (random.randint(100, 500)) was perfect. Power bonus calculation was correct but lacked flair. Distribution failed because it reported leftover gold as “remaining in the chest,” violating RPG norms. My goal: Distribute 100% of the loot. Step 2: Design the Distribution Algorithm I drafted a plan: Calculate base_gold = total_gold // party_size. Calculate remainder = total_gold % party_size. Distribute the remainder: Give 1 extra coin to the first remainder players. For example, with 155 gold and 3 players: Base = 51, Remainder = 2 Player 1: 52, Player 2: 52, Player 3: 51 Step 3: Enhance Output Clarity I structured the output into logical sections: Loot Summary (gold dropped + power bonus). Distribution Overview (base share, remainder explanation). Player Breakdown (loop to show individual rewards). To make it immersive, I added emojis (🎯, 💪, ⚠️) and separators (=== ... ===). Step 4: Code Implementation

Key code snippets:

party_size = 3
base_gold = gold_dropped // party_size
remainder = gold_dropped % party_size

Distribute remainder

for i in range(party_size):
actual_gold = base_gold + (1 if i < remainder else 0)
print(f" Player {i+1}: {actual_gold} coins")
Copy Code This loop dynamically assigns extra coins to the first remainder players. Step 5: Testing Edge Cases I tested scenarios to ensure robustness: Perfect splits (e.g., 348 gold → 3 players × 116). Remainders of 1, 2 (e.g., 155 gold → 2 extra; 157 gold → 1 extra). Minimum/Maximum gold (100 and 500) to validate power bonuses. Challenges I Faced

1. Balancing “Fairness” and Simplicity Initially, I considered distributing remainder coins randomly among players for “strategic depth.” However, players might perceive this as unfair. The solution—giving extras to the first remainder players—prioritizes deterministic fairness while keeping the logic simple.
2. Avoiding Floating-Point Errors When calculating math.sqrt(gold_dropped), I worried about decimal results (e.g., sqrt(10) ≈ 3.162). Using math.ceil() solved this, but I had to confirm it worked for edge cases like perfect squares (e.g., sqrt(100) → 10.0 → ceil(10.0) = 10).
3. Making Output Engaging Without Overcomplicating Adding emojis and verbose explanations risked cluttering the terminal. I iterated by: Using section headers to group information. Adding a detailed breakdown only when necessary (e.g., when there’s a remainder).
4. Variable Naming Overhaul Renaming gold_per_player to base_gold was critical. The original name implied every player received that amount, which was false when remainders existed. Clear names prevented logical errors in future expansions. Final Thoughts This project taught me that good game design hinges on trust. Players must feel rewards are calculated fairly, transparently, and immutably. By transforming a simple loot system into a polished, player-first experience, I deepened my appreciation for the intersection of programming logic and human-centered design. 🎮✨

Built With

• amazon
• nova
• python