Kelola Kerajaan: Card Game

This project was fun because we were making a game. Our teaching assistants designed the rules, while our four-person team had to turn the specification into a working application using the object-oriented concepts from the course.

Kelola Kerajaan was inspired by Harvest Moon but transformed into a competitive card game. Players planted crops, raised animals, produced goods, earned money, and used item cards to improve their own field or interfere with an opponent.

I owned much of the core game model because I enjoy abstracting systems and making them modular. Cards shared a common foundation, then separated into plants, animals, products, and items with different capabilities.

The abstractions directly controlled what players could do. Plants and animals were both harvestable but matured differently. Products could be sold or used as feed. Items could target a player's own field or an opponent's field. It was satisfying to see object-oriented theory become something playable.

My favorite mechanic was the bear attack because it introduced chaos into an otherwise strategic game. A bear could target part of a player's field, begin a countdown, and destroy the cards inside the selected area.

The mechanic came from the course specification to give us practical experience with Java multithreading. UI updates had to return safely to the JavaFX thread. A trap could reverse the disaster by capturing the bear and turning it into an animal card.

Playtests produced exactly the chaos the mechanic promised. A player could spend several turns building a valuable field only for a bear to attack the worst possible area. Sometimes a trap turned it into a reward. Other times the field simply disappeared.

Those moments made the game memorable while testing whether countdowns, protection, traps, state changes, and interface updates worked under pressure.

The hardest part was connecting the core model with the JavaFX interface described through FXML. Drag-and-drop actions had to identify the card, validate its destination, and invoke the correct game rule.

A correct model was not enough. Every state transition had to appear correctly on screen, and every interaction had to reach the appropriate object without duplicating rules inside the controllers.

The course required a plugin-based save system. Plain text was built in, while JSON and XML support could be added by loading external JAR files at runtime.

It was my first practical experience with extending an application after compilation. Like the card hierarchy, the plugin system showed how a clear abstraction allows new behavior without rewriting the rest of the application.

I am proudest of how the core game came together. Card types, feeding, growth, harvesting, item effects, turns, money, shops, attacks, and saving all had to cooperate without turning every class into special cases.

Our responsibilities were clearly divided, which let us work on the model, interface, persistence, shop, and audio while agreeing on the boundaries connecting them.

If I rebuilt Kelola Kerajaan, I would strengthen the architecture, reduce behavior inside UI controllers, and add broader automated tests for interactions between cards and phases.

The project taught me that abstraction is not only about organized code. A useful abstraction makes a system easier to understand, extend, and divide across a team. Sometimes the best test is whether it survives a bear attacking the player's field.