[Feature]: Refactor achievement system for better scalability

[Sowmya-kc]

👉 Please confirm the following

• I agree to follow the Code of Conduct that this project adheres to.
• I checked the current issues for duplicate features.

🤔 Is your proposal related to a problem?

Problem

The current achievement system, while functional, has scalability concerns:

1. registerAchievements() method grows linearly : Adding 20 achievements means 20+ lines in one method
2. Multiple notify methods : Each event type requires a new notify method in AchievementManager
3. Tight coupling: Adding a new achievement type requires modifying multiple files

😍 Describe the solution you'd like

Proposed Solutions

Option 1: Configuration-based Registration:

• Store achievement definitions in JSON/XML
• Load and instantiate achievements dynamically
• Example:

{
"achievements": [
{"type": "KillCount", "target": 10, "reward": 50},
{"type": "Score", "target": 5000, "reward": 75}
]
}

Option 2: Event Bus Pattern

• Replace individual notify methods with a generic event system
• Achievements subscribe to specific event types
• Eliminates need for new notify methods per event type

Option 3: Observer Pattern

• Achievements observe game state changes directly
• More decoupled from AchievementManager
• Each achievement defines what it observes

Benefits

• Adding new achievements becomes configuration, not code
• Reduced code duplication
• Easier to maintain and test
• More scalable for future growth

👍️ Describe alternatives you've considered

No response

✍ Additional context

• Related PR: feat: add diverse achievement types for enhanced gameplay #357
• Current code: src/main/java/com/dinosaur/dinosaurexploder/achievements/
• Maintainer suggestion: @jvondermarck in PR feat: add diverse achievement types for enhanced gameplay #357

[github-actions]

👋 Hello @Sowmya-kc, thank you for your interest in Dinosaur Exploder 🦖! Please visit our ⭐️ Discord server if you need help about something.

If this is a 🐛 Bug Report, please provide a minimum reproducible example to help us debug it.
If this is a 🆕 feature request, please provide all your ideas, or better yet: a model of what you'd like to improve in the game.

• ✅ Verify that you have well fill out the different checkboxes in the issue template.

[jvondermarck]

Thanks for this issue created! @Sowmya-kc And thanks for the great description you wrote!

[Teo418]

Hi! I'd love to contribute to this issue.

After reviewing the current AchievementManager code, I can clearly see the three pain points mentioned:

• registerAchievements() grows linearly with every new achievement added
• Each new event type requires a new notifyXxx() method
• AchievementManager is tightly coupled to concrete achievement classes

Regarding the proposed solutions, I'd like to share my analysis:

• Option 1 (JSON config) decouples data from code, but still requires concrete classes and a parser layer
• Option 2 (Event Bus) is the strongest solution for eliminating the notify method explosion
• Option 3 (Observer) offers the most decoupling but adds implementation complexity
• Option 4 (my suggestion — Reflection + annotations): achievements could be annotated with a custom @RegisterAchievement annotation and auto-discovered at startup via classpath scanning, removing the need to ever touch registerAchievements() again

My personal take would be combining Option 2 + Option 4: an Event Bus to replace the notify methods, and annotation-based auto-registration to solve the linear growth problem. This would address all three issues at once.

Before I start working on this, could you share which direction you'd prefer? I want to make sure the approach aligns with the project's architecture before opening a PR.

Thanks!

[jvondermarck]

Hey, I am happy of your analysis, and thanks for your message.

Option 2 and 4 could be really great, I also like it , as the goal is to decouple, remove redundancy and make it easy to extend, add new feature to the class in the future.

There is this open Pull Request: #389, the contributor changed a bit the code of the achievements. I will probably merge it ASAP, so maybe let's way to be merge if you work on it ? I think he also tried to make it a bit more cleaner, but you could still implement your suggestions once it is merged. What do you think ? Can you have a look? Thanks :)

[Teo418]

Hi! Sorry for the late reply, and thank you so much for the assignment, really appreciate it!

I had a look at PR #389 and I can see the improvements made. I'll wait for it to be fully merged and then sync my fork before starting to implement options 2 and 4 on top of the updated code.

I'll keep you posted on my progress. Thanks again! :)