Arkalogica Game Suite

This project is interesting, to say the least, because building the software was only one part of my responsibility. I was the Head of the Arkalogica competition at Arkavidia, HMIF ITB's annual technology event.

Arkalogica combines Arkavidia with logika, reflecting a competition built around mathematical reasoning and creative problem-solving. I helped develop the format, coordinate the team, prepare the games, and make sure everything could operate reliably during the event.

For the semifinal, we did not want participants to spend the entire round answering another collection of written problems. My team and I designed two games that still tested logic and mathematics, but made participants decide under pressure.

The first game is a one-versus-one arithmetic board game. Two players compete on a 9 by 9 grid, placing coins only when a cell's value can be produced from two movable numbers using multiplication, addition, subtraction, or division. The first player to create a line of four wins.

I prefer this game because its simple rules create many possible strategies. Players must consider which values become available, where an opponent might play next, and how moving a number changes the board for both sides. A mathematically valid choice is not always the strategically correct one.

The second mode is Reach the Target, or RTT. The game itself was played physically, while the application served as an operator console for our staff. It tracked the target, remaining time, team scores, purchased clues, and round state.

Teams spent points to reveal information such as the target's range, digit sum, divisibility, or primality. Because clue costs came from the same balance used to determine the winner, teams had to use logic and mathematical knowledge to identify the number with as little information as possible.

I built the application in a single day. That is the part I am proudest of. We needed software that could support the competition quickly without creating another operational problem for the team.

There was no backend, database, account system, or complicated deployment process. Every staff member needed to be able to clone the repository and open a working copy without a long setup. For a live competition, that simplicity was more valuable than an elaborate architecture.

A browser might refresh, a laptop might fail, or a staff member might close the page. Losing the board, timer, score, or clue history in the middle of a semifinal could interrupt the competition and make the round unfair.

The application stored its state locally so an organizer could recover after an interruption. It taught me that even a small browser application needs a recovery plan when people depend on it in a real room.

Participants later told us the semifinal game was one of the most enjoyable parts of the event. Watching them discover strategies and compete made the work feel worthwhile.

The website did not need to impress them with technical complexity. It needed to disappear into the experience and let the game remain the focus.

Arkalogica taught me that building software for an event is as much a managerial problem as a technical one. I needed to understand the rules, communicate with the operators, anticipate failures, and make the interface clear enough that staff did not need technical knowledge to use it.

If I revisited the project, I would improve the UI and information hierarchy. A live-event interface must be intuitive because staff do not have time to interpret confusing controls while participants are waiting and a timer is running.