Walaoeh: Farming Simulation

Walaoeh was our first major OOP assignment. The teaching assistants provided the farming game, roles, commands, and required concepts. Our six-person team designed the software and implemented it in C++.

The name came from our reaction to receiving the assignment while several other tasks were already competing for our attention. The situation felt chaotic enough for an Indonesian walawe, which eventually became Walaoeh.

C++ did not force us to organize everything around objects. Choosing OOP required us to see the problem differently, asking what each object represented and where each behavior belonged.

The game supported farmers, ranchers, and mayors. Farmers grew crops, ranchers raised animals, and mayors collected taxes, constructed buildings, and could add players while the game was running.

My favorite role was the mayor because I liked building and managing a city. It also became one of my main responsibilities, together with the shared player model, command handling, shop, and game coordination.

Our team noticed that inventories, farms, and ranches needed the same grid behavior. We designed a generic Storage<T> template that changed the stored type while reusing insertion, removal, location, and display logic.

This was when templates stopped feeling like a language feature and started feeling like a design tool. We found one reusable structure inside several apparently different systems.

The Git history shows that I worked heavily across the coordinating layers. I implemented most of the command dispatcher, player foundation, mayor role, shop transactions, and substantial parts of GameWorld, along with build and integration fixes.

That suited how I like to work. I enjoy understanding central abstractions and connecting separate parts into one functioning system.

Memory management was the hardest part. Early development produced many segmentation faults because a pointer referenced the wrong object, an item was deleted too early, or an invalid location was accessed.

C++ made ownership impossible to ignore. We had to decide who created each object, who could reference it, when it should be cloned, and who was responsible for deleting it. That made later OOP work in Java feel much safer.

The course required custom exceptions, so we created a large hierarchy and may have overdone it. Some failures carried useful detail, such as an exact money shortage or a map of missing building materials.

The exercise showed why structured failures are better than vague return values. A command could fail, explain the problem, and allow the game to continue.

The collaboration went smoothly because our team had strong chemistry. Different people built the sellable hierarchy, storage, farming, ranching, configuration, persistence, and terminal presentation.

My role increasingly became connecting those pieces and resolving problems at their boundaries. The project showed how shared abstractions can help six people reason about one system.

Walaoeh directly influenced how I approached Kelola Kerajaan. It taught me to choose object-oriented structure deliberately before Java made many of those conventions feel natural.

If I rebuilt it, I would use smart pointers, simplify some overloaded operators, clarify the boundary between rules and terminal input, and add automated tests. Walaoeh was chaotic and full of segmentation faults, but it made OOP real for me.