Omweso Computer Game

By

Semakula Abdul
Lead Developer
Elmot Ltd
BSc. (Computer Science) (Mak)

A Project Report Submitted to the Faculty of Computing and IT In Partial Fulfillment

of the Requirements for the Award of the Degree of Bachelor of Science in Computer
Science of Makerere University

June, 2006
 Declaration

I Semakula Abdul do hereby declare that this Project Report is original and has not been published
and/or submitted for any other degree award to any other University before.

Signed………………………………………
Date……………………………………
Semakula Abdul

Approval

This Project Report has been submitted for Examination with the approval of the following supervisor.

Signed:………………………………… Date:………………………………………
Mrs. Mulenga Charity Basaza
Department Of Computer Science
Faculty Of Computing And Information Technology

i
 Dedication
This Omweso project is dedicated to my family members especially my dear parent Mr. Haruna Kato
and Mrs. Hajara Nakimbugwe, and my grandmother Mrs. Namatovu. My Brothers Farook Lubinga,
Ndugwa Hassan, Ssemwogerere Abubakr, Umar Katende (the kid) sisters Nalweyiso Zaituni, and
Nabiryo Mariam, cousins Katende Richard, Selujoba Faisal, Maganya Christopher, Ssekkadde Ronald,
Pamela, Nanyanzi Lillian among others.

I also dedicate this Omweso software to the man who taught me how to play Omweso after I had
conceived the idea of developing a computer game for Omweso. I.e. Mr. Sam of Lumumba hall
(Makerere University) who told me dreams of the moves in Omweso before engaging in a game the next
day.

ii
 Acknowledgement
I would like to convey my sincere appreciation to my parents who have especially My Father been
extraordinarily supported my education since I was a kid singing the alphabet, up to when I can write
such a study report. They both have been supportive in all aspects (financial, social, welfare, religious
among others) of life and they never letdown whatsoever when I always ran to them for help. I really
appreciate their parental care I have received and take this opportunity to apologise for anything small
and big, intentional and unintentional that might have happened between them and me, forgive and
forget like Allah does to human kind (born of sin).

I also herein take this opportunity to cast my sincere thanks to Professor Llwanga Llwanga (Retired
Professor of Mathematics Seattle University), for the technical advice he rendered to me about some
mathematical functions within the implementation of Omweso, the business ideas he rendered to me on
how I can benefit from the Omweso project through marketing it to have a fortune from it.
I also thank Mr. Mugerwa Martin for the assistance he rendered to me when my computer broke down,
and he helped me acquire another one on top of a printer which waived my printing costs, all these
helped me to complete the project.

Nonetheless the impact of the advice and tolerance of my supervisor Mrs. Mulenga Charity Basaza
cannot be underrated and is really appreciated for without it such a report would not be available of
course bearing in mind that almighty Allah is the overall architect of whatever we do and nothing is
possible without Allah‟s consent.

iii
 Table of Contents:
Declaration ................................................................................................................................................... i
Dedication ................................................................................................................................................... ii
Acknowledgement ..................................................................................................................................... iii
List of Tables ......................................................................................................................................... vi
List of Appendices ............................................................................................................................... viii
Abstract .................................................................................................................................................. ix
Chapter One ................................................................................................................................................ 1
1.0 Introduction ....................................................................................................................................... 1
1.1 Background Of The Study ................................................................................................................ 1
1.2 Statement Of The Problem................................................................................................................ 3
1.3 Objectives ......................................................................................................................................... 3
1.3.1 General Objective ...................................................................................................................... 3
1.3.2 Specific Objectives .................................................................................................................... 3
1.4 Scope ................................................................................................................................................. 3
1.5 Significance....................................................................................................................................... 4
Chapter Two................................................................................................................................................ 5
2.0 Literature Review.............................................................................................................................. 5
2.1 Omweso`s Complexity.................................................................................................................... 5
2 .1.1 State-Space Complexity .......................................................................................................... 5
State-Space Complexities Of 'World' Games In Comparison With Omweso .................................... 6
2.1.2 Game Tree Complexity ....................................................................................................... 7
2.1.3 Mutational Complexity ........................................................................................................... 9
2.2 Magic Numbers ............................................................................................................................. 10
Never Ending Moves ........................................................................................................................ 11
Chapter Three............................................................................................................................................ 12
3.0 Methodology ................................................................................................................................... 12
3.1 Requirements Engineering ............................................................................................................ 12
3.1.1 Feasibility Study .................................................................................................................... 12
3.1.2 User Interface Design Requirements. .............................................................................................. 12
3.1.3 Rules Of Play ........................................................................................................................... 12
3.2 Requirements Specification ...................................................................................................... 13
3.2.1 Requirements Specification Document.................................................................................. 13
3.2.1.1 User Interface Design Requirements. ................................................................................... 13
3.2.1.2 Rules Of Play ................................................................................................................ 14
Chapter Four ............................................................................................................................................. 15
4.0 Game Analysis ................................................................................................................................ 15
4.0.1 Basic Game Theory.................................................................................................................. 15
4.0.2 A Move ............................................................................................................................. 15
4.0.3 Game Complexity ............................................................................................................. 16
4.0.4 State-Space Complexity .................................................................................................... 16
4.0.4 Game Tree Complexity ..................................................................................................... 16
4.0.5 Mutational Complexity ..................................................................................................... 16
4.1 Game Design ................................................................................................................................... 17
4.1.1 Architectural Design ......................................................................................................... 17
4.1.2 Detailed Design ................................................................................................................. 17

iv
 4.1.2.1 User Interface Design ................................................................................................... 17
4.1.2.2 Board Actions ....................................................................................................................... 19
4.1.2.3 Board Manager...................................................................................................................... 20
4.3 Implementation ............................................................................................................................... 25
Fig 4.15 ..................................................................................................................................................... 27
4.3.2.2 The Options Menu ................................................................................................................ 29
4.3.3 The Board Panel ....................................................................................................................... 30
4.3.4 The History Panel .................................................................................................................... 30
Chapter 5 ................................................................................................................................................... 31
5.0 Discussion ....................................................................................................................................... 31
5.1 Conclusion ...................................................................................................................................... 31
5.2 Recommendation ............................................................................................................................ 31
References ................................................................................................................................................. 32

v
 List of Tables
Table 1.1 ……………………………………………………………………………… 6
Table 1.2 ……………………………………………………………………………… 8

vi
 List of Figures
Fig 3.1 ....................................................................................................................................................... 14
Fig. 4.1 ...................................................................................................................................................... 17
Fig. 4.2 ...................................................................................................................................................... 18
Fig. 4.3 ...................................................................................................................................................... 19
Fig. 4.4 ...................................................................................................................................................... 19
Fig. 4.5 ...................................................................................................................................................... 20
Fig. 4.6 ...................................................................................................................................................... 20
Fig. 4.7 ...................................................................................................................................................... 20
Fig. 4.8 ...................................................................................................................................................... 21
Fig. 4.9 ...................................................................................................................................................... 21
Fig. 4.10 .................................................................................................................................................... 22
Fig. 4.11 .................................................................................................................................................... 24
Fig. 4.12 .................................................................................................................................................... 25
Fig 4.13 ..................................................................................................................................................... 26
Fig. 4.14 .................................................................................................................................................... 26
Fig 4.15 ..................................................................................................................................................... 27
Fig 4.16 ..................................................................................................................................................... 28
Fig 4.17 ..................................................................................................................................................... 28
Fig. 4.18 .................................................................................................................................................... 29
Fig. 4.19 .................................................................................................................................................... 29
Fig 4.20 ..................................................................................................................................................... 30
Fig. 4.21 .................................................................................................................................................... 30

vii
 List of Appendices

Appendix A …………………………………………………………………35
Appendix B ………………………………………………………………… 36
Appendix C ………………………………………………………………… 40

viii
 Abstract
Omweso can now be played as a computer game as a readily accessible alternative to the original
physical Omweso board. Ugandans who cannot find time to physically play Omweso, mostly those who
have access to computers can now enjoy Omweso as a means of relaxation.
The Omweso computer game report contains five chapters. Chapter one contains a brief introduction of
the game, a general overview and comparison of the Mancala family of games, the objectives of the
study and the significance of the Omweso computer game and games at large. It also states the
problem(s) that triggered the study. Chapter two contains a detailed literature review mainly from
Wernham`s paper and other local literature from Kasubi Tombs. Professor Mayega of the Mathematics
department Makerere University also made some Mathematical analysis (Magic numbers) in Omweso
and a brief review of his work is in this chapter.

Chapter three is about the methodology used for implementing the computer game. It lists the
requirements of the game got after a careful feasibility study that was carried out at various local social
centers. The requirements therein include the rules of the game, the user requirements among others.
Chapter four deals with the analysis of the Omweso game, the design and implementation of the game.
Screenshots of the Omweso computer program are shown in the implementation section.
The last chapter contains a brief discussion, recommendation and conclusion of the project as a whole.

The results of this project are numerous on my side as I got a lot of experience in designing and
implementing software in a formal way. I also got experience working with Java classes, IDEs like
Eclipse 3.1.2 which where used during the implementation among others.

In a nutshell the whole Omweso project was a great experience though not an easy one as I experienced
a number of problems during the implementation. The implementation on the Omweso herein is a
human versus human game, as time didn‟t allow for the implementation of Artificial Intelligence in the
game so that the human can play with the computer.

ix
 Chapter One

1.0 Introduction
1.1 Background Of The Study
Omweso is a Mancala1 game popular in the East African country of Uganda, with major tournaments
being held in the capital city of Kampala in the Kingdom of Buganda. Unlike the Mancala games played
on the West coast of Africa, Omweso is a „re-entrant‟ game. That is to say that all the seeds remain in
play – captured seeds are re-entered onto the winner‟s side of the board. In Omweso the players start
with 64 seeds in play, and set-up freely at the start.

The objective of the game is to capture opponent‟s seeds until he is unable to move, or to gain a
knockout by „Cutting off both his heads‟ (that is to capture seeds from both ends of his board in one
move).

There are two ways to win.

1. Normal - the loser is immobilised and cannot move (only has empty holes and singleton seeds)
2. Cutting off at 2 heads. Capture of both extreme pairs of holes in one move
“Okukoneeza” is a special tournament rule: if a hole has 3 seeds during the opening before first capture 2
seeds into next hole, final seed into next but one
Winning by Akakyala - capturing seeds from the loser in two separate moves before the loser has even
made his first capture of the game.

In large parts of the world, board games of the Mancala group are being played in different versions for
a very long time (Russ, 2000). All Mancala games share the following properties:
 the board has of a number of holes, usually ordered in rows;
 the game is played with indistinguishable counters (pebbles, seeds, shells);
 players own a fixed set of holes on the board;
 a move consists of taking counters from one hole and putting them one-by-one in subsequent
holes (sowing), possibly followed by some form of capture;

1
Mancala is a family of board games played around the world, sometimes called sowing games or count and capture games,
which comes from the general gameplay. The best-known games of this family in the West are Oware, Kalah, Omweso, and
Bao. Mancala games play a role in many African and some Asian societies comparable to that of chess in the West.

1
  the goal is to capture the most counters.

Mancala games differ in the number of players (1, 2 or more), the size and form of the board, the
starting configuration of the counters, the rules for sowing and capturing, and in the way the game ends.
The games of the Mancala group are known by many names (for instance Wari, Awele, Bao, Dakon,
and Pallankuli).

Until recently, the western world has had very little experience with Mancala games. In the Middle
Ages, Arabic traders might have shown a game called Mancala to their European customers, but only
very vague references exist of Europeans playing the game. In later times, African slaves played Wari in
the Caribbean, but in the United States, slaves were forbidden to play their traditional games. European
colonists in Eastern Asia and India must have observed Mancala games being played, but appearingly
they were not interested enough to bring it back to Europe, (Donkers et al 2003).

Recently, Western interest in Mancala games increased. In the 1950s William J.Champion invented the
game Kalah (1963). It is a relatively simple version of a Mancala game intended as an educational game
for children. Although the game was immediately commercialised, it only got widely known when the
International
Red Cross adopted and spread the game. In the USA the game of Kalah has reached the pubs and
African immigrants in Europe took the game Awari with them. Nowadays, several Mancala games are
played on the Mind Sports Olympiad (Wari, Omweso, and Bao).

Finally, I note that there is great similarity between the Omweso-like games of Southern DRC/Zaire
(Nsumbi), Rwanda (Igisoro), Sudan (Ryakati) and Western Ethiopia (Baré) as earlier shown. These
games vary to the extent that they have different reversing holes (e.g. Igisoro) or that they allow both
players to start the first move simultaneously (e.g. Ryakati). But all require a capture by landing on a
marked hole on the inside row opposite two occupied opponent‟s holes. In this respect they are quite
different from Bao as played on the Swahili coast, and inland somewhat in a band from Lake Victoria
to Malawi Geographical relationship to other games.

2
 1.2 Statement Of The Problem

The study seeks to produce a closer alternative of the Omweso board game to the people of Uganda and
the world at large. Most people cannot access boards to enjoy the prominent local board game yet with
the growing technology, the historical game can be played as a computer game if its well programmed
with all the game‟s rules incorporated.

1.3 Objectives
1.3.1 General Objective
To develop a user-friendly Omweso computer game so that the unique and interesting board game can
easily be accessed and played by more people.
1.3.2 Specific Objectives
1. To carryout a feasibility study about the game to determine and specify all the necessary
requirements of the board game incorporating all the rules.

2. Develop a design of the different parts or modules of Omweso required to come up with a user-
friendly Omweso computer game.

3. Implement by writing code all the designed parts of the proposed computer game.

4. Integrate and test all the coded parts of the game to ensure a fully functional quality Omweso
computer game.

1.4 Scope
The project is to include all the presently defined rules of the Mancala game “Omweso”. Other
functionalities will be added to make the game friendlier and enjoy full. It targets the computer literate
Ugandans and the world at large.

3
 1.5 Significance
Board games have been an integral part of human life for thousands of years. They have entertained and
educated us in countless ways. Unfortunately, many of today's best board games are not available in the
mass-market stores where many of us shop, but that is where the Internet comes in to make these games
available to most people. Hence the need to build a computer game for Omweso.

The Omweso computer game will promote Ugandan culture among the learned Ugandans. As far as
board games are concerned, relatively very few people know about Omweso and how to play it. This is
mainly because it has not been addressed of late and people have gone in for western board games like
chess, ludo, draughts (checkers) among others, which are not only common as both physical games but
also as computer games.

Board games provide an excellent forum in which to gather friends and family for an intriguing,
challenging and stimulating social experience. I can't think of very many other activities, which provide
the opportunity to gather with others and spend quality time together with wonderful amounts of social
interaction.

Further more, many board games actually challenge us in a number of ways. They force us to think, use
our intellect, and often match wits with our fellow gamers. Omweso being a very fast game, it develops
and sharpens skills, which aid us in many other facets of life. And as a developmental tool, the skills and
lessons learned by children while playing good, quality board games are invaluable. Truly, the board
game of Omweso`s experience is usually an extremely rewarding one, socially, intellectually and
developmentally.

The Mancala games Awari and Kalah have been studied in Artificial Intelligence research for a long
time. After the recent solving of Kalah and, only very recently, Awari, the time has come to consider
other, more complex, Mancala games, (Uiterwijk, 2002) Hence the need for an artificial intelligence
solution for Omweso.

4
 Chapter Two
2.0 Literature Review
Mancala games have a relatively long track in artificial-intelligence research on games. Kalah has
already been investigated a decade after its invention as an example of game programming (Slagle et al,
1970). The game of Kalah has been solved in 2000 (Donkers, 2000). Awari has been studied since the
early 1980s (Van der Meulen, et al 1990) and has been played at the Computer Olympiads for some time
now. In the research on Awari, much effort is put on the construction of endgame databases. This has
led to the complete solution of Awari in May 2002 (Bal, 2002). However little has been done on
Omweso with no full solution to the Ugandan game.

Nsimbi (1991) notes that in the past games were slower, with players thinking for many minutes to find
the right move. Modern play, however, requires very fast play, with only 3 seconds thinking time per
turn. The referee counts “one”, “two” and if the player does not choose a hole to start his move he loses
his turn to the other player.

Mugerwa (1994) maintains that Omweso was Mutesa‟s favourite game. Can one then postulate a
hypothesis that as Mwanga‟s reign was a period of economic and cultural isolation, then any swapping
or adoption of Mancala rules between Baganda people and others must have taken place in and before
Mutesa‟s reign, before 1884? Further research is required in this area. By concentrating on the rule
variants of 16 holes Mancala in various villages from the Swahili Coast all the way to DRC (Zaire) some
inferences could be draw. Such fieldwork outside of the major cities where people have lived in stable
communities for hundreds of years should surely be the next step in tracing the evolution of the game.

2.1 Omweso`s Complexity

2 .1.1 State-Space Complexity
The state-space complexity of a game is defined as the number of legal game positions reachable from
the initial position of the game. Because (Lemmens, 2005) calculating the exact state-space complexity
is hardly feasible it is necessary to make an approximation of it.
The state-space complexity (Allis, 1994) of Mancala games can be computed from the number of holes
and number of counters involved. This complexity does not predict the difficulty of the game for
humans or computers.

5
A formula for game state-space complexity:
C (h,s,k) = (h-1+ s)! _ k……………………………………………………(1)
(h-1)! x s
Where:
h = number of holes
s = number of seeds
k = number of illegal/improbable positions
An illegal position in chess might be where a King and Queen share the same square. An improbable
position in Awari would include 47 seeds in one hole, and the remaining seed in another. An example of
an improbable position in Omweso would happen when a player sets up 29 seeds in one hole and the
other 3 in the next holes in a row.
State-Space Complexities Of 'World' Games In Comparison With Omweso
Game Initial setup As play starts Mid game End game
Awari 1 Slowly rising 2.8 x 1011 Falling
Bao 1 Very slowly Rising 1025 --
Omweso 5.6 x 1023 Rising quickly 1025 --
Chess 1 Rising slowly 1050 Falling
Go 1 Rising quickly 10160 to 500 Falling
Table 1.1 Adapted from Omweso: The Royal Mancala Game Of Uganda.
(Jochen, 2003) made experiments on Omweso with the following results.

His deduction was;

Number of possibilities f (x, n) = f (n-1, x) + f (n, x-1)…………………………………(2)

With f (n, 0) = 1 and f (1, x) = 1.

6
In Omweso, each player has 32 seeds to set up in 16 holes, therefore using equation 2 with f (16, 32)
gives 7.5 x 1011 possible positions for the first player to setup, which can be countered by the other
player in 7.5 x 1011 ways giving 5.6 x 1023 combinations. In tournament play there are no illegal set-up
combinations, and very few improbable ones.

The „k‟ factor for Mancala games is lower than in positional games since many pieces may share the
same „hole‟ in Mancala. The fact that pieces are white or black in positional games, and have different
attributes (e.g. knight, King etc.) which increases the combinations in those games. State-space
complexity in Omweso rises rapidly after the first captures, and remains high throughout as the seeds
become redistributed in large numbers quasi-stochastically from one player to the other.

Note that different games have different numbers of pieces in play at different stages. For example, in
Bao seeds are introduced throughout the initial phase of the game, with captures re-entered onto the
board. In chess captured pieces are removed. In Go new pieces are added until the end of the game,
when areas of stability appear in „safe‟ areas. Therefore all these calculations have many implicit
assumptions, and are only roughly comparable.

De Voogt (1995) has pointed out that games with high theoretical state-space complexity, such as
Songka may be less „intricate‟ for humans as the outcomes are beyond mental calculation and require
„brute force‟ calculations of no finesse. This implies that only games which are on the edge of human
capacity for calculation and tactics and especially those that show high degrees of chaotic behavior are
„interesting‟.

2.1.2 Game Tree Complexity

The complexity of many Mancala games for computer play is better estimated by the game-tree
complexity (Allis, 1994). To characterize the game-tree complexity, we have to study the game length
and the branching factor of the game.

7
Game Tree Complexities Of Mancala Games.
Game Initial setup By end of game (no forced moves)
Awari 1 1032
Boa 1 2 x 1032
Omweso 5.6 x 1023 (5.6 x 1023) x (5 x1050) =2.8 x1074

Table 1.2 Adapted from Omweso: The Royal Mancala Game Of Uganda.
Game-tree complexity can be calculated as:
i1 x i2 x (b) p………………………………………………………………………………………………(3)
Where:
i = branches in set-up of game for players 1 and 2
b = branches per move
p = plays in game length
Awari and Omweso do not have forced moves (except where in Awari one must „feed‟ the opponent if
all his holes are empty). However, in Bao forced moves are very common, perhaps 1/10 in master-level
play, and more common amongst less experienced players who do not know how to avoid or take
advantage of these situations. One must also take into account the increased choices a Bao player has in
choosing where to re-enter captured seeds (left or right) in the initial stage of the game. In Omweso the
player has no choice where to re-enter the seeds, but he/she has greater choice over where to begin
sowing to make a capture.

The average (Wernham, 2002) in a sample game from the Kampala 2000 tournament is 5.4 anti-
clockwise possibilities plus the possibility of deciding to reverse capture in about 20% of sowings.
Therefore the number of branches per player turn in Omweso is well above six. However, when the
other player is susceptible to a reverse capture, the possibility of further reverse captures often appears
(say 50% of cases). An example of this is shown at one point in the sample game. If one assumes that
there are 7 branches per turn with an average game being 60 turns, then the branching complexity would
become 760 = 5 x 1050.

There are, however, many assumptions in the above calculations. For example, using an average for the
branching complexity “b” will overstate the branches if b is sometimes low and sometimes high. For

8
example, if a two-turn game has 5 branches per turn, then the number of end positions is 25. However if
the first turn is forced (i.e. b=1) and the second turn has, say, 9 possibilities, then only 9 outcomes exist.
But the average of 5+5 is the same as 1+9.

Wernham (2002) notes that a comprehensive analysis of tournament games is required before one can
come to any conclusion about the relevance of these sorts of calculations in relation to branching
complexities.
2.1.3 Mutational Complexity
De Voogt (1995) has introduced the concept of „mutational complexity‟ with respect to the number of
changes on the board due to a single move. These moves change the nature of the board by changing the
state-space not just in moving from one „position‟ to another, as in Chess, but by changing all the
intervening numbers due to the sowing process.

In Omweso the average number (Wernham, 2002) of changed holes in the sample game was exactly 3
per move for the first 9 moves whilst the players positioned themselves without laying themselves open.
The next stage had an average of 7.1 moves per player turn as one player maintained a large position
ready to strike, and thereafter 13.4 per turn. This count of mutational complexity does not however take
into account lapping the board, in which many holes are changed more than once, and the additional
changes to holes already visited that occur when captured seeds are re-entered onto the board. If these
are counted, then in one single move Ddamba not only changes the state of 6 holes on his opponent‟s
side of the board, but also sows 47 times into the holes on his side of the board, changing their seed
count in some cases 5 times.

Wernham (2002) maintains that we need to move beyond simple combinatorial statistics into definitions
of „finesse‟, „chaos‟ and non-computational complexities that human beings find difficult, such as
„mutational complexity‟ and „memory complexity‟. Other human characteristics such as dexterity and
speed of play are pronounced in Mancala games, especially where thinking time is curtailed as much as
it is in Omweso. Does this lead to a lessening of depth of play, or does it enhance a player‟s use of
subliminal „Zen-like‟ techniques and „feel‟ for play that „Go‟ dan-grade players exhibit?

9
 2.2 Magic Numbers
Prof. Mayega (1991) presented some statistical analysis in his paper, together with some work on
applying matrix theory to the Omweso problem to create a goal-seeking program driven by a points
scoring system. In 1992 Professor Ilukor took a different approach by investigating the „magic
numbers‟ within Omweso rather than crunching away at traditional statistical and matrix bound
techniques. He made several simple observations, some of which are illustrated below. These
observations help introduce us to a new form of mathematics that may solve many complex problems
in Mancala.

10
Among other magic numbers are those of 9,17 and 25.
Never Ending Moves
It is possible for a move to lead to a never-ending sowing sequence. In tournament play, a player is
allowed up to three minutes to finish his move - if this cannot be done, the game is annulled. Never
ending Omweso moves have been of some mathematical interest. The Mayer Test can be used to
determine whether a position can lead to a never-ending sowing.

11
 Chapter Three
3.0 Methodology
The project followed the predefined discipline of software development during the development of the
Omweso computer game. The waterfall model was employed during the development process because
of it is a step-by-step process and documentation intensive nature.

3.1 Requirements Engineering

3.1.1 Feasibility Study
Different places were visited to find out about all the necessary requirements of the Omweso computer
game through interviewing different experts at both playing the game and game programming to get a
thorough understanding of the project so as to make correct deductions on the requirements. Among the
places to visit are historical and cultural sites like Kasubi Tombs in Kampala, Bulange Mengo, the
Kabaka`s palace in Banda, and the Uganda museum. This was intended to elicit the necessary
requirements (rules) and to familiarise with the game, know the tricks, principles and the logic and
artificial intelligence of the game, and get to know the criterion used in organizing tournaments. Below
are the requirements of the Game

3.1.2 User Interface Design Requirements.

 The computer game shall present a 4x8 playing board.
 Each of the two players will have 32 seeds at the start.


3.1.3 Rules Of Play

 Players will arrange seeds into the holes on their respective sides in an arrangement they deem
strategic.
 To make a move, a player clicks on any hole with non-singleton seeds he/she wishes and the
seeds will be dropped one by one in each hole beginning from the adjacent hole in an
anticlockwise direction.
 Singletons (one seed in a hole) cannot be moved.
 A players turn ends when the last seed is dropped in an empty hole and the other player starts
playing.

12
  If a player‟s last seed is dropped in a non-singleton hole of their inner row, and the holes exactly
opposite (the hole in which they dropped last), on the opponent‟s side both contain seeds the
player always remove all of them from both holes. He then starts dropping again from the hole in
which he started before.
 Reversing: - A player is allowed to reverse only if the target seeds are from the first two columns
on either sides of their board, and only if they are in a position to capture an opponent in their
reverse move.
 A win is determined when a player has only singletons on his side of the board, which cannot be
moved.
 Winning is also determined when both sides of the first columns of either sides of a player‟s
board are captured in a single move.
3.2 Requirements Specification
3.2.1 Requirements Specification Document
3.2.1.1 User Interface Design Requirements.
 The computer game shall present a 4x8 playing board, 2x8 for each of the 2 players, i.e. 16
holes each.
 The game play with either be animated or not. With the animation, a red ring will be used to
show the way seeds are dropped by enclosing the currently affected hole.
 Seeds as used herein will be represented by numbers.
 Players will be allowed to make an initial seed arrangement of their choice.
 Players will left click to increase the number of seeds and right click to reduce the number of
seeds during the initial play.
 The program will be able to allow a user to deal again i.e. produce a new game.
 The program shall alert the players of illegal moves and alert them of wins or losses incase one
wins or loses respectively.
 The game shall provide an option of saving the current game.
 The game shall also provide an option for loading a saved game.
 The history of the previous moves will be shown in a panel.
 There shall be an option to allow the board be rotated through 180o.

13
3.2.1.2 Rules Of Play
 Players will arrange seeds into the holes on their respective sides in an arrangement they deem
strategic, i.e. by left clicking to increase the number of seeds and right clicking inside the holes
to decrease the number of seeds.
 To make a move, a player will click on any hole with non-singleton seeds he/she wishes and the
seeds will be dropped one by one in each hole beginning from the adjacent hole in an
anticlockwise direction.
 A player‟s turn shall end when the last seed is dropped in an empty hole and the other player
starts playing.
 If a player‟s last seed is dropped in a non-singleton hole of their inner row (Fig. 3.1), and the
holes exactly opposite (the hole in which they dropped last), on the opponent‟s side both contain
seeds the player shall always remove all of them from both holes. He shall then start dropping
again from the hole in which he started before.
 Reversing: - A player shall be allowed to reverse only if they are to pick seeds from the first two
columns on either sides of their board, and only if they are in a position to capture an opponent in
their reverse move.
 A win will be determined when a player if a player has only singletons on his side of the board
that cannot be moved.
 Winning will also be determined when both sides of the first columns of either sides of a player‟s
board are captured in one move.
Player A
W W
Inner Rows
Player B
Fig 3.1
For instance Player A loses in the figure below if player B captured seeds in W in a single move.

14
 Chapter Four
4.0 Game Analysis
4.0.1 Basic Game Theory
Formal Definition of a Game
 A game has at least two players.
o Example: Solitaire is not considered a game-by-game theory.
 An instance of a game begins with a player choosing from a set of specified (by the game rules)
alternatives. This choice is called a move.
 After the first move is made, the new situation determines which player is to make the next
move and the alternatives available to that player.
o Example: In many two-player board games, the player making the next move is simply
the other player.
o Example: In many multi-player card games, the player making the next move depends
on who dealt, who took the last trick, won the last hand, etc.
 The moves made by a player may or may not become known to the other players. Games in
which all the moves of all players are known to everyone are called games of perfect
information.
o Example: Most board games are games of perfect information.
o Example: Most card games are not games of perfect information.
 Every instance of the game must end.
 When an instance of a game ends, each player receives a payoff. A payoff is a value associated
with each player's final situation. A zero-sum game is one in which the elements of the payoff
matrix sum to zero.
o Example: In chess, win = 1 point, draw = ½ point, loss = 0 points.
o Example: In a typical zero-sum game, win = 1 point, draw = 0 points, loss = -1 points.
o In Omweso a draw is not well defined and not probable.
4.0.2 A Move
Represent a move as a discrete expression in which the number of holes reached by sowing new seeds is
given by n and the x (k) denote the number of seeds in hole k at the beginning of iteration 1 and y(k) the
number of seeds in hole k at the beginning of iteration 2.

15
Therefore: y(k) = x( y)+ n…………………………………………………………. (4)
The content of a hole will increase by 1 due to sowing if the integral value n is large enough to
reach the hole after depositing seeds in its predecessor holes.

4.0.3 Game Complexity

The complexity of a board game provides an indication of the degree of difficulty involved to play the
game and to convert its rules into software format. Four views on the complexity of games can be
expressed as:
• State – space complexity
• Game – tree complexity
• Mutational complexity and
• Computational complexity of the algorithms used in its software production
4.0.4 State-Space Complexity
The state-space of a board game is the various pattern of distribution of seeds on the board, from
initiation to the end of the game. The current state space is used as an input to an evaluation function
that is used to evolve a game. The output of the evaluation function is also be used in a mini-max search.
State-space complexity can calculated using equation 1 in chapter 2.

4.0.4 Game Tree Complexity

Each board game forms a tree that evolves as the game is being played. A tree is formed when a series
of operations lead to others and those steps can be represented pictorially as logical growth of the tree
from one node to the next. Game tree complexity provides an estimate of the number of branches in the
tree at set-up used to represent the game based on a number of players, the branches per move and the
length of the play.
Equation 3 shows how game tree complexity can be calculated.

4.0.5 Mutational Complexity

Like in genetic mutations, the state spaces of games mutate. This concept was first pinpointed by
De Voogt (1995). The mutational complexity of a game is the number of changes on the board due to a
single move. Moves change the nature of the board by changing the state-space, the positions and the
number of seeds in the holes due to captured and planted new seeds.

16
4.1 Game Design
4.1.1 Architectural Design
The high level design of Omweso is rather simple. The main data of the game is the state of the board
i.e. the seed count of both sides of the board. The whole game is divided into four parts or components
each with a different function. The various parts of the game and the relationship between them are
shown in Fig 4.1. The arrows indicate that a particular part needs or uses the services of the other. For
instance Board Actions needs services of the User Interface.
The Different Parts Of The Game

User Interface

Board Actions Board Manager

Move Manager

Fig. 4.1

4.1.2 Detailed Design

4.1.2.1 User Interface Design
 User Interface – this is the part of the game that interacts with the users.
The user interface has the Omweso class, which has the main method and inherits from the awt
(abstract windowing toolkit) package of the java API. It uses the Board class that inherits from the
GridBagLayout class of the java Container class. The Omweso class also uses other classes as
shown in the class diagram in Fig. 4.2.

17
 Class Diagram For The User Interface Design

JPanel Seed
64
awt
GridBagLayout
MouseEvents
32

Board Omweso

JButton
JMenuComponent JComponent

JMenuBar JMenuItem JChoice

JMenu JCheckboxMenuItem

Inheritance Uses Relationship

Fig. 4.2 Relationship

Each class offers services to itself or other classes through its states and behaviors described in the
variables and methods that it has. The various methods in each class are shown in Fig. 4.3

18
 Primary Classes And Their Methods

Omweso Board

createMenuBar() createAndShowBoard()
createContentPane() addComponentsToPane()
createAndShowGUI() setLayout()
addActionListener() GridBagConstraints()

Seed Hole

draw() seedCount()
seedCount()
location()

Fig. 4.3

4.1.2.2 Board Actions

This is the part of the game that is responsible with the actions that occur on the board. These include
among others mouse events, moving of the red ring around the holes to change their state.
Fig. 4.4 illustrates, which classes there are in the Board Actions and how they are linked.

Class Diagram For Board Actions

MouseEvents

Actions MouseMotionListener

Fig. 4.4

Animate

19
The classes and their respective methods that offer services to other methods are shown in Fig. 5.
Primary Classes And Their Methods In The Board Actions

Action MouseMotionAdapter
MouseEvents

pickSeeds() mouseDragged()
getX() mouseMoved()
getY() dropSeed()
isPopupTrigger moveSeeds()

Animate

moveLeft()
moveRight()

Fig. 4.5

4.1.2.3 Board Manager.

This is the part that is responsible for the state of the board. It uses a hash table to store the states of
the table. The state of the board is determined by the count of the seeds in each hole at a given time
after a players turn. The classes in the Board Manager are shown in Fig. 4.6.
Class Diagram for the Board Manager

SearchTable HashTable
Fig. 4.6

The classes and their respective methods that offer services to other methods are shown in Fig. 4.7.

Primary Classes And Their Methods In The Board Manager

HashTable SearchTable

createHashTable() alphaBetaSearch()
callState() getResult()
addState()
removeState()
Fig. 4.7

20
 4.1.2.4 Move Manager
The Move Manager is responsible for enforcing the rules of play of Omweso. The Move class
herein validates a given move by a player. The Win class returns a win message for the winner of
the game and loss message for the loser. Fig. 4.8 shows the classes in this part and their
relationship.

Class Diagram For The Move Manager.

Hole Win

Move Turn

Fig. 4.8

The services offered by the methods in the above classes are the main rules of the local game being
enforced in the computer game. The methods herein are shown in the Fig. 4.9.
Primary Classes And Their Methods In The Move Manager

Hole Turn

seedCount() setCurrentPlayer()
capture() getCurrentPlayer()

Win Move

singletons() anticlockwise()
twoHeads() capture()
tebuka()
Fig. 4.9
startingMove()

21
 Scenario Diagram Of The Move Manager.
The scenario diagram in Fig. 4.10 expresses and verifies the identified methods and classes in the Move
Manager.

startingMove()
Hole
2

capture()
5
anticlockwise()
3 Move setCurrentPlayer()
1

singletons()
seedCount() Turn
7
4
twoHeads()

Win 6
Fig. 4.10

22
 Algorithm Of The Move Manager In Pseudo-Code
Below is the pseudo code for the Move Manager.
do

pick all non-singleton seeds from a hole of your choice,

drop the seeds in the adjacent holes anticlockwise, 1 in each hole.

if

 your last drop is in a non-empty hole of the inner row, and opponent’s

directly opposite column are non-empty, capture all seeds in both hole.

 drop the seeds beginning from the hole adjacent the one from which you last

picked your seeds.

while (you have last seed dropped in an empty hole)

relinquish turn to the other player.

while (not win);

23
 Flow Chart Of The Move Manager

Pick Seeds from Tray

and arrange them in the
holes on your side

Your No Wait For Your Turn

Turn

Yes

While False End Game

Not Win

True

Pi ck Non-singletons
from hole of your choice

Drop Seeds in adjacent Capture Seeds in Holes

anticlockwise holes one Directly Opposite
in each
Yes

Last Drop is Both Directly

No
in empty hole Opposite holes
are non-empty

Yes
No
Relinquish Turn to
Opponent Pi ck Seeds From
Fig. 4.11
hole you Last
Dropped

24
4.3 Implementation
Omweso was implemented using java. The tools used include JSDK1.5_06, Eclipse SDK 3.1 as an
Integrated Development Environment and as a linker to produce the executable. Mainly the java AWT
(Abstract Windowing Toolkit) and javax.swing packages were used to implement the interface
(Fig 4.12)
Photoshop CS 8.0 was also used to design the jpeg image of the board that holds the holes. Photoshop
was used because of its flexibility and its good features like the „filters‟ that render a real world view of
the objects being drawn.

Fig. 4.12
4.3.1 The User Interface
The user interface was contains three java components namely:
i. The Menu Bar
ii. The panel that holds the playing board
iii. The panel that keeps track of the history or the previous moves.

25
 Fig 4.13

4.3.2 The Menu Bar

The menu bar from javax.swing`s JMenuBar component consists of two menus also from javax.swing`s
JMenu class. The menus here are the „Game‟ and the „Options‟ menu.
4.3.2.1 The Game Menu
The Game menu also contains five menu items from javax.swing`s JMenuItem class. They are;
i. New. This loads a new game when clicked or when Mnemonic keys “Ctrl + N” are pressed. When
pressed, the event handler calls the new_Game object that loads a form where players` names and the
starting player can be specified. (Fig. 4.14) shows the scenario.

Fig. 4.14

26
ii. Load. This loads a saved game from the storage media. When pressed, the event handler calls
the FileChooser object, which navigates to where the user to saved the game they want to open.
Fig 4.15 shows the scenario. The file to be opened should be a “.omw” file.

Fig 4.15

iii.Save. Like load, save also calls the FileChooser object but this time to save the current game to the
locations of the user‟s choice. The game is saved as a “.omw” file.

iv.Export To Html. This is intended to show and maybe print the results of the play at any time after
start. When clicked, this also calls the FileChooser object to save the game first before displaying the
HTML view as shown (Fig. 4.16) in a sample game played earlier.

27
 Fig 4.16

v.Abort Game. This is meant to end the current game and close the window for the game. Before the
window is closed, the user is asked to be certain that they want to exit the game window. (Fig 4.17)
shows this scenario. When one clicks „No‟, the game window is not closed else it is closed.

Fig 4.17

28
 4.3.2.2 The Options Menu
The options menu (Fig. 4.18) has two menu items namely;
i.Rotate Board. This rotates the board through 180o. The result is that if player one was at the bottom,
and player two at the top, player one goes to the top and player two to the bottom.
ii.Animations. This puts a red ring around the moves being made when checked other than just numbers
being changed simultaneously it is slower and more elaborate on the move made. Fig. 4.18 shows the
ring at a particular point of play.

Fig. 4.18

Fig. 4.19

29
4.3.3 The Board Panel
The panel that contains the jpeg board is a JPanel from the swing package. It also contains the two
components i.e. a text area to enter a move, an OK button to accept the move input. If an invalid move
is input, an error message is shown “Incorrect Input (input)”. Fig 4.19 shows the scenario.

Fig 4.20
Another button appears when a new game is started i.e. the “Apply to current initial setup” which
ascertains and records the initial setup of the game in the History panel. (Fig. 5.9) shows this button.
4.3.4 The History Panel
Also from the JPanel class of the swing package, is used to list each and every move that the players
make in sequential order of play. (Fig 5.7) above shows some of the listed moves from a game that
was played earlier. The convention used in recording is shown in Fig. 5.10.

Direction of play
b8 b7 b6 b5 b4 b3 b2 b1
a8 a7 a6 a5 a4 a3 a2 a1
A1 A2 A3 A4 A5 A6 A7 A8
B1 B2 B3 B4 B5 B6 B7 B8
Fig. 4.21
Appending an F after the name of the location on board e.g. (B7F) represents a normal move while a
capture is represented by appending FF e.g. (B7FF).

30
 Chapter 5

5.0 Discussion
Mancala games have not been widely addressed especially in the field of computing and artificial
intelligence save a few like Kalah and Bao which have been solved to but a little extent. Hence there is
a need to encourage further study into the Mancala games.

5.1 Conclusion
In conclusion the Omweso project was not an easy one though an adventure in the fields of both game
logic especially Mancala and programming in the object oriented technology. The local game of
Omweso can now be played as a computer game as a readily accessible alternative to the current
physical Omweso board. Ugandans who cannot find time to physically play Omweso, mostly those
that have access to computers can now enjoy Omweso as a means of relaxation. The implementation
for this report of a play between humans and doesn‟t include artificial intelligence, which involves
making the computer think and play like humans would. Implementing artificial intelligence was not
possible because of the limited time there was to get the project done.

5.2 Recommendation
The implementation herein does not include Artificial Intelligence. I made a simple research on
implementing Artificial Intelligence in the game of Omweso but time did not allow for its
implementation. I recommend the use of the Minimax and alpha-beta algorithms for the implementation
of Artificial Intelligence in the game of Omweso.

31
References
1. De Voogt, A. (1995). Limits Of The Mind: Towards A Characterisation Of Bao Mastership
Leiden. Research School, CNWS.
2. Donkers, J. Uiterwijk, J. and De Voogt, A. (2000). Mancala Games – Topics in Mathematics and
Artificial Intelligence: Board Games in Academia IV. University of Fribourg, Switzerland.
3. Donkers, J. and Uiterwijk, J. Programming Bao. IKAT, Dept. of Computer Science, Universiteit
Maastricht, Maastricht, The Netherlands.
4. Ilukor, Y. (1992). The Game Of Amwesoro. Dept. of Physics, Makerere University, Kampala.
5. Lemmens, N.P. (2005). Constructing An Abalone Game-Playing Agent
http://uk.abalonegames.com/. Accessed on Wed 12/21/2005.
6. Lewis, J. and Loftus, W. (1998). Java Software Solutions: Foundations Of Program Design.
Addison Wesley Longman, Inc.
7. Mayega, J.V. (1991). Omweso – A Mathematical Investigation Of an African Board Game.
Dept. of Mathematics, Makerere University, Kampala.
8. Mugerwa, and Kigongo, R. (1991). Kasubi Tombs. RMK Associates, Kampala.
9. Nsimbi, M.B. (1991). Omweso – A Game Ugandans Play. Banana Books, Kampala.
10. Russ, L. (2000) The Complete Mancala Games Book New York. Marlowe & Co.
11. Wernham, B. (2002). Omweso: The Royal Mancala Game Of Uganda.
International Omweso Society.
12. Zaslavsky, C. (1999). Africa Counts – Number and pattern in African Cultures Chicago.
Lawrence Hill.

32
 Appendix A
Tools Used
Java, an object oriented programming language was used entirely for the development of the Omweso
Project. The following software tools were used during the implementation of the Omweso project;
 jdk1.5.0_01 was used as a compiler for the source code.
 jre1.5.0_04 was used as a run-time environment for testing the program
 Eclipse 3.1 was used as Integrated Development Environment (IDE)

33
 Appendix B
Program implementation codes
Part of the main class that loads the panel and board

package omweso;
import java.awt.*;
import java.awt.event.*;
import javax.swing.JMenu;
import javax.swing.JMenuItem;
import javax.swing.JCheckBoxMenuItem;
import javax.swing.JRadioButtonMenuItem;
import javax.swing.ButtonGroup;
import javax.swing.JMenuBar;
import javax.swing.KeyStroke;
import javax.swing.ImageIcon;
import javax.swing.JButton;
import javax.swing.JPanel;
import javax.swing.JTextArea;
import javax.swing.JScrollPane;
import javax.swing.JFrame;

/* Omweso.java is a 1.4 application that requires images/middle.gif. */

/*
* This class Displays Menu bar and uses event listeners.
*/
public class Omweso implements ActionListener, ItemListener {
JTextArea output;
JScrollPane scrollPane;
String newline = "\n";

34
public JMenuBar createMenuBar() {
JMenuBar menuBar;
JMenu menu, submenu;
JMenuItem menuItem;
JRadioButtonMenuItem rbMenuItem;
JCheckBoxMenuItem cbMenuItem;

//Create the menu bar.

menuBar = new JMenuBar();

//Build the first menu.

menu = new JMenu("Game");
menu.setMnemonic(KeyEvent.VK_G);
menu.getAccessibleContext().setAccessibleDescription(
"The menu that displays actions on the game as a whole");
menuBar.add(menu);

//Add JMenuItems to this menu

menuItem = new JMenuItem("New",
KeyEvent.VK_T);
//menuItem.setMnemonic(KeyEvent.VK_T); //used constructor instead
menuItem.setAccelerator(KeyStroke.getKeyStroke(
KeyEvent.VK_1, ActionEvent.ALT_MASK));
menuItem.getAccessibleContext().setAccessibleDescription(
"Loads New Game");
menuItem.addActionListener(this);
menu.add(menuItem);

ImageIcon icon = createImageIcon("images/hole.gif");

menuItem = new JMenuItem("Undo Move",icon);
menuItem.setMnemonic(KeyEvent.VK_Z);

35
 menuItem.addActionListener(this);
menu.add(menuItem);

menuItem = new JMenuItem("Open",icon);

menuItem.setMnemonic(KeyEvent.VK_D);
menuItem.addActionListener(this);
menu.add(menuItem);

menuItem = new JMenuItem("Save",icon);

menuItem.setMnemonic(KeyEvent.VK_D);
menuItem.addActionListener(this);
menu.add(menuItem);
//Build the third menu in the menu bar
menu = new JMenu("Help");
menu.setMnemonic(KeyEvent.VK_N);
menu.getAccessibleContext().setAccessibleDescription("Display Help About Omweso.");
menuBar.add(menu);
//Add an item to this menu.
menuItem = new JMenuItem("How To Play");
menuItem.setMnemonic(KeyEvent.VK_S);
menuItem.addActionListener(this);
menu.add(menuItem);
//Add an item to this menu.
menuItem = new JMenuItem("About Omweso");
menuItem.setMnemonic(KeyEvent.VK_S);
menuItem.addActionListener(this);
menu.add(menuItem);

return menuBar;
}

36
public Container createContentPane() {
//Create the content-pane-to-be.
JPanel contentPane = new JPanel(new BorderLayout());
contentPane.setOpaque(true);

//Create a scrolled text area.

output = new JTextArea(5, 30);
output.setEditable(false);
scrollPane = new JScrollPane(output);

//Add the text area to the content pane.

contentPane.add(scrollPane, BorderLayout.CENTER);

return contentPane;
}

public void actionPerformed(ActionEvent e) {

JMenuItem source = (JMenuItem)(e.getSource());
String s = "Action event detected."
+ newline
+ " Event source: " + source.getText()
+ " (an instance of " + getClassName(source) + ")";
output.append(s + newline);
output.setCaretPosition(output.getDocument().getLength());
}

public void itemStateChanged(ItemEvent e) {

JMenuItem source = (JMenuItem)(e.getSource());
String s = "Item event detected."
+ newline
+ " Event source: " + source.getText()

37
 + " (an instance of " + getClassName(source) + ")"
+ newline
+ " New state: "
+ ((e.getStateChange() == ItemEvent.SELECTED) ?
"selected":"unselected");
output.append(s + newline);
output.setCaretPosition(output.getDocument().getLength());
}

// Returns just the class name -- no package info.

protected String getClassName(Object o) {
String classString = o.getClass().getName();
int dotIndex = classString.lastIndexOf(".");
return classString.substring(dotIndex+1);
}

/** Returns an ImageIcon, or null if the path was invalid. */

protected static ImageIcon createImageIcon(String path) {
java.net.URL imgURL = Omweso.class.getResource(path);
if (imgURL != null) {
return new ImageIcon(imgURL);
} else {
System.err.println("Couldn't find file: " + path);
return null;
}
}

/**
* Create the GUI and show it. For thread safety,
* this method should be invoked from the
* event-dispatching thread.

38
 */
private static void createAndShowGUI() {
//Make sure we have nice window decorations.
JFrame.setDefaultLookAndFeelDecorated(true);

//Create and set up the window.

JFrame frame = new JFrame("Omweso");
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);

//Create and set up the content pane.

Omweso mwesoGUI = new Omweso();
frame.setJMenuBar(mwesoGUI.createMenuBar());
frame.setContentPane(mwesoGUI.createContentPane());

//Display the window.

frame.setSize(450, 260);
frame.setVisible(true);
}

public static void main(String[] args) {

//Schedule a job for the event-dispatching thread:
//creating and showing Omweso's GUI.
javax.swing.SwingUtilities.invokeLater(new Runnable() {
public void run() {
createAndShowGUI();
}
});
}
}

39
 Appendix C
Part of the Javadoc of the Omweso package generated using Eclipse 3.1.2
C:\Users\Elmot\AppData\Local\Documents and Settings\diploma.FCIT-117EC8B563\My
Documents\Documents and Settingsdiploma.FCIT-117EC8B563workspaceomwesodocomweso" l -
skip-navbar_top
Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS FRAMES NO FRAMES All Classes All Classes
SUMMARY: NESTED | FIELD | CONSTR | METHOD DETAIL: FIELD | CONSTR | METHOD

omweso
Class Omweso
java.lang.Object
omweso.Omweso
All Implemented Interfaces:
java.awt.event.ActionListener, java.util.EventListener, java.awt.event.ItemListener

public class Omweso

extends java.lang.Object
implements java.awt.event.ActionListener, java.awt.event.ItemListener

Constructor Summary
Omweso()

Method Summary
void actionPerformed(java.awt.event.ActionEvent e)

java.awt.Container createContentPane()

javax.swing.JMenuBar createMenuBar()

void itemStateChanged(java.awt.event.ItemEvent e)

static void main(java.lang.String[] args)

Methods inherited from class java.lang.Object

40
equals, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Constructor Detail
Omweso
public Omweso()

Method Detail
createMenuBar
public javax.swing.JMenuBar createMenuBar()

createContentPane
public java.awt.Container createContentPane()

actionPerformed
public void actionPerformed(java.awt.event.ActionEvent e)
Specified by:
actionPerformed in interface java.awt.event.ActionListener

itemStateChanged
public void itemStateChanged(java.awt.event.ItemEvent e)
Specified by:
itemStateChanged in interface java.awt.event.ItemListener

main
public static void main(java.lang.String[] args)

C:\Users\Elmot\AppData\Local\Documents and Settings\diploma.FCIT-117EC8B563\My

Documents\Documents and Settingsdiploma.FCIT-117EC8B563workspaceomwesodocomweso" l -
skip-navbar_bottom
Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS FRAMES NO FRAMES All Classes All Classes
SUMMARY: NESTED | FIELD | CONSTR | METHOD DETAIL: FIELD | CONSTR | METHOD

41