So this is my final blog regarding the Season of KDE 2025, I’m feeling happy for what I accomplished. Over the past few weeks, I’ve implemented PvP system for mancala game, this project has been a deep dive into game development, networking and user experience.

Summary of work done so far

1. Move tracking Mechanics

At the heart of this project lies the MankalaEngine, an engine designed to handle rules and gameplay of various mancala variants. I’ve added some more feature in the engine:

• Move tracking: The lastMoveMethod() method allows to retrieve the last move played by the player and computer.

2. PvP Mode

It allows the real-time multiplayer gameplay using XMPP. Following is a brief summary:

• XMPP Integration: Players connect to each other using their jabber IDs and exchange move using the established chat room in real-time.
• Turn Management: The Player 1 always start, and turns alternate between the two players.
• Board Syncing: Players manually update their boards based on the opponent’s move, ensuring both the players have accurate view of the game state.

3. Man Page Documentation

To make the game accesible, I’ve created a man page for bohnenspieltui. This man page provides the information abou the game, including:

• Synopsis and Description: A brief overview and explanation of the game variant.
• Usage: Instructions for running the PvP mode.
• Added a minor improvement of card view in Mancala GUI.

Future Work

While the task for this term is completed, their are several areas for improvement:

• Automated board syncing by replacing the current manual one.
• Integrating the engine to the mancala GUI.
• Extending the PvP to other variants.

Final Words

Thanks to KDE community, XMPP community and Benson Muite and João Gouveia and Blue from Macaw.me for the guidance and support. And I encourage the aspiring contributors to take part in Season of KDE to learn and grow as a developer.

Implemented the PvP mode by leveraging XMPP for communication, enabling the played to exchange moves. The code for this are implementd in connection.h, connection.cpp and bohnenspieltui.cpp.

Setting up the PvP mode

The player select the game mode they desires to play, for PvP the choice would be option P.

Connecting to XMPP server

To establish the chat room and enable the communication the player must provide their jabber id and password and the opponent’s JID (This should be done from both players side).

The program then establishes a connection to the XMPP server using the entered credentials. The game proceeds only when the credentials are verified.

Host and Turn Order

The program determines who will play first in a simple manner i.e., by comparing the lexicographical order of their jabber IDs.

Sending a move

When it’s player turn, they are prompted to enter their move. The move is validated and sent to opponent via the established chat room.

The board is updated locally and then the turn is passed to the opponent.

Receiving a move

When the move is received from the opponent, the program prompts the player to sync the board manually.

This is to ensure that both the players have their board in sync. Then the program prompts the user to enter their move and it game will be continued.

What’s next

• Automatic move sync
• The man page to explain the working to players.

Move tracker for PvC game

Implemented the code for tracking the move played by player and computer in bohnenspiel TUI game.

It is achieved using getLastMove method initialized and defined in mankalaengine.h and mankalaengine.cpp. This method returns a pair containing the last moved as int played and the player as Player who made it.

During each iteration of the game loop, the above method is called for both player and computer to retrieve their respective last moves.

The above code in TUI file of bohnenspiel game variant is used to display the move played in the terminal.

The player move is tracked using user.getLastMove() and the computer move is tracked using opponent.getLastMove(). The game loop alternates between the player and the computer, updating the board and tracking moves after each turn. The last moves are printed after each turn. The computer’s move are adjusted by adding 6 to align it’s side of board(move 6-11).

How it works?

1. Player’s Turn:
   • The player select the hole to play.
   • The move is played, and the board is updated.
   • The move is tracked using user.getLastMove().
2. Computer’s Turn:
   • The computer select the hole to play.
   • The move is played, and the board is updated.
   • The move is tracked using opponent.getLastMove().

After each turn the last moves played are displayed.

What’s next

The next goal moving forward is to create a PvP game mode for two different users.

My project focuses on enhancing the GUI and adding Player vs. Player (PvP) multiplayer functionality to a Mancala game.

Mancala is a popular board game played worldwide. The proposed plan is to use Kirigami for improving the GUI and making the application cross-platform. Multiplayer functionality will be integrated using XMPP. The game will operate over a communication channel established by XMPP over UDP. The updated game board will be reflected graphically using data binding. The XMPP server being used is Prosody.

Work done so far

Setting up the prosody locally

Setting up Prosody is fairly straightforward. I installed it from Fedora’s official repository using the command:

sudo dnf install prosody

Alternatively, Prosody can be built and installed from its source code available on GitHub.

Configuring prosody

Prosody’s configuration is contained in a single file: prosody.cfg.lua. On Linux distributions, this file is typically located at /etc/prosody/prosody.cfg.lua..

For now the clients are connected over same LAN using the virtual host @mancala.local as the domain id.

The image above illustrates how to edit your virtual host configuration.

The next step is to configure a chat room, which is done similarly to the virtual host configuration.

Both configurations require an SSL certificate to secure the communication channel.

After completing these steps, we restart and check the status of Prosody using the following commands:

sudo systemctl restart prosody
sudo systemctl status prosody

If everything is configured correctly, the state will be “active.” You can verify this by checking the log file using: sudo tail -f /var/log/prosody/prosody.log we can check the log file. If configured successfully, the output will resemble this:

Adding users and communicating via a XMPP client

The plan is to allow users to either use their existing Jabber ID or create a new one through our server. For testing purposes, I manually added users to the server using the following command:

sudo prosodyctl adduser <username@domain_name>

After executing the command, you will be prompted to set a password for the user.

For communication, I used the Pidgin client.

As shown in the image above, I have added two users, user11 and user12.

To test communication, I sent a message from user11 to user12 by addressing it to user12@mancala.local. Below are the results:

Since I used the Pidgin client on the same device, both user tabs appear in the interface. The screenshots confirm that I successfully established a user-to-user communication channel over LAN.

What’s next

For the next week, I plan to:

• Implement in-band registration.
• Enable communication over the internet.
• Develop the logic for the game invitation system.