Two Game Projects: Object-Oriented Meets Functional Programming

As a way to deepen my understanding of different programming paradigms, I developed two games—one using Java and object-oriented design principles, and another using Haskell, a purely functional language. While both games are relatively simple, they each pushed me to learn and apply core concepts in design and language features.

---

Encounter Game (Java)

The first project, Encounters Game, is a lightweight Java-based encounter system where players can engage with randomly generated characters in a small, turn-based environment.

What made this game interesting wasn’t the gameplay itself, but the way I structured the system using classic object-oriented design patterns. These included:

• Factory Pattern – For creating different types of enemy entities and weapons without hardcoding specific types.
• Observer Pattern – To notify the UI or other systems when the game state changed (e.g., player health or enemy defeated).
• Singleton Pattern – For managing the game state and ensuring a single source of truth across the game session.

This project gave me hands-on experience applying software engineering concepts beyond just getting something to work. It helped me think in terms of extensibility, loose coupling, and maintainability—lessons that continue to inform how I structure larger codebases today.

---

Solitaire in Haskell

In contrast to the Java game, my second project was an implementation of Solitaire in Haskell. This marked my first real dive into functional programming, and building a complete card game helped solidify many abstract concepts that can be tough to grasp at first.

Rather than relying on mutable state or object hierarchies, I had to shift toward using:

• Immutable data structures
• Recursive logic for managing game flow
• Monads and pure functions to encapsulate state transitions cleanly

The solver logic, shuffling mechanism, and overall architecture were written with Haskell’s emphasis on purity and type safety in mind. Writing the game in this way was both frustrating and rewarding—it forced me to think differently and embrace declarative problem-solving.

While the source code isn’t online, I’m happy to share more about how it works or walk through some of the implementation choices if you're interested.

---

Why Build Games?

Games are an excellent way to explore programming concepts because they require a bit of everything: logic, design, architecture, user interaction, and sometimes even AI. These two projects provided a great contrast between the object-oriented and functional approaches:

• Java emphasized encapsulation, inheritance, and runtime flexibility.
• Haskell emphasized purity, immutability, and composability.

Working in both styles helped me develop a better intuition for when and why to choose a particular paradigm—and how to communicate those choices when working with a team or building more complex systems.

---

If you're curious about the code behind either project, the Java project is available on my GitHub. For the Haskell Solitaire, feel free to reach out—I’d be happy to discuss the details.