Programmer Mac Clemmens
CST 232: Introduction to Visual Basic
Professor Dorsey
Not just a simple game of checkers, but a
multimedia experience!
F I N A L
P R O J E C T
Submitted on May 23, 2002
.
.
.
.
.
.
.
.
.
Table of Contents
Project Goals ............................................................................................................................................ 3
Project Documentation ................................................................................ 3
Complete the Visual Basic Program ........................................................... 4
Checkers! Infrastructure ........................................................................................................................ 5
Additional Features during Development ................................................... 6
Project Development Timeline .................................................................... 7
Checkers! Game Logic ........................................................................................................................... 7
Logic Flow Chart ..................................................................................................................................... 8
2
.
.
.
.
.
.
.
.
.
1
Version
A Multimedia Experience
Project Goals
The Checkers! Project was created to fulfill the basic requirements for the CST232 Visual Basic
Programming ILP Portfolio Piece. The outcomes for the piece are listed below.
1) Given a complex problem, decompose the problem into manageable steps which together
provide a design for the problem solution.

Provide a design for the problem solution

Design and document the problem solution detailing each step to completion
2) Use basic design principles in creating a user interface
3) Utilize programming terminology and describe general concepts in event-driven
programming

Identify and use eight components of the Visual Basic environment, state their purpose
4) Translate design documents into a Visual Basic program using VB code

Demonstrate programming competency in input/output operations, control structures,
storage management, data structures, dynamic memory allocation, arithmetic
operations, and object oriented methodologies.
Project Documentation
Also, required by the ILP piece for this project is thorough documentation which will include all
of the following:

An analysis table that identifies the input, processing, and output needs of the program
based on the general description provided in the proposal/description document, the
table identifies Input Needs, Processing Needs and Output Needs

Design of the user interface, a table that lists the Input Controls, Processing Controls,
and Output Controls with a brief explanation of the properties that are the deciding
factor in the choice.
3



Also, include a sketch of the user interface with a brief explanation of
the design choices

User-interface design specification table that lists the control/control
name, the relevant properties for each control, and the value of each
property
Macro-level logic identifying Object-Event relationship, an organizational chart or
diagram, with a single, top-level node, labeled with the name of the program

Below the top node are nodes that correspond to each of the controls
in the form.

For each control that has events with processing steps, include at
third level. At this level specify the event by which the processing will
be activated.
Micro-level flowchart identifying the detailed program logic using the 8 standard
symbols, the flowchart will have the following characteristics:

Clearly marked, single starting point

Clearly marked, single ending point

Downward flow

Use of standard symbols

Use connectors to avoid crossing lines

Decisions are blocked to make it easier to see consequences at a
glance

Decisions are drawn using consistent branching

A test plan table. The table lists sample inputs with corresponding expected outputs

Source Code documentation that is clearly documented.

A brief journal of debugging techniques used during the course of the development of
the program.

List at least two debugging tools/techniques that was required to
make the program work correctly are described with a brief
description of what the outcomes were.
Complete the Visual Basic Program
After completing the project planning phase and all initial documentation, the project
development phase begins to develop a program which:
4

Appropriately utilizes the following Visual Basic controls: TextBox, Label, Command
Button, Frame, Common Dialog, Menus, as well as any one or more of the following:
OptionButton, CheckBoxes, ListBox, ComboBox

Demonstrates understanding of data types, operator precedence, and scope of
variables and sub-procedures

Utilizes Visual Basic conversion functions, multiple forms, simplification techniques,
such as modularization, decision, case, and repetitive structures, and error handling
techniques

Conducts data validation

Create, search, sort, and manipulate arrays in conjunction with user-defined type
structure

Identify and use at minimum a comma-separated value sequential file for maintaining
records
Checkers! Infrastructure
The key to developing a program as seemingly complicated is proper planning, clear
and impeccable logic, and seamless implementation. Throughout the course of the
project, I tried numerous techniques, and ended up with the following key functions
and subroutines that do the bulk of the work.
1) Board(1 to 64) – an array of type integer that stores what each pieces is on each
board space. The concept is relatively simple. Each Array index is assigned a value for the
state of that square.

Const Error = 0

Const Red = 4

Const Black = 1

Const RedK = 5

Const Grey = 2

Const Marble = 6

Const GreyK = 3
So, if square #3 has a Grey King, Board(3) = GreyK or Board(3) = 3. The array is the single
and primary data source for the program. To change the status of what piece is on what
square, you can change the value.
1
9
17
25
33
41
49
57
2
10
18
26
34
42
50
58
3
11
19
27
35
43
51
59
4
12
20
28
36
44
52
60
5
13
21
29
37
45
53
61
6
14
22
30
38
46
54
62
7
15
23
31
39
47
55
63
Board Layout Example:
Let’s assume that there is a grey
checker piece on square #37.
8
16
24
32
40
48
56
64
In this case, Board(37) = 2 and all
other Board() would be either 1 or 6,
depending on whether it was a black
or marble square.
5
Secret Tip: To change the status of any square during game play, simply double-click on a square. This
debugging feature has been left in the program for the entertainment of the player. The code for that function is
simple, too. It just sets whatever space was double-clicked to the value entered by the user. Give it a try!
2) MakeMove(FromSquare As Integer, ToSquare As Integer) – When the
board images are dragged from onto another square, this subroutine is called to check and
see if a move is possible. This subroutine is extensive and abstruse, because it
algorithmically checks for nearly a thousand different movement possibilities. It takes into
account the following variables:

Who’s turn it is:
Turn, SwitchTurn()

If the movement is a jump:
CanJump(ToSquare,
FromSquare)

Checking Mechanisms
CheckForKings()
CheckForWinner()

What a blank board square
should look like: (this is

Update Procedure
UpdateBoard()
more for error-checking)
BlankBoard(Square)
Making a Move:
After a user selects a valid
square to move, the
MakeMove() subroutine is
called. This subroutine is the
most functional in the program,
because it controls the board
image array [imaBoard()], the
[Board()] array, updates the
board after a legal move,
ignores invalid moves, and
plays appropriate sounds.
3) New_Game() and Reset_Board() – These self-explanatory functions are a actually a
little more complicated than one might think. They initialize both the imaBoard() array, the
Board() array, the BlankBoard() default object, and the Turn, NumOfMoves global variables
from the Checkers Module. Without these functions, game play would be impossible.
Additional Features during Development
There were a couple of innovations and algorithms that were added to the Checkers! project
during the project development phase.
Some of these features are outlined on the table on page 7, as well as in the project’s code.
6
Feature
Digital sound effects
Description
Integration
Debugging
Report
Fancy, original sound effects for
jumping, moving, victory, defeat,
and startup.
4 hours:
1 hour
Works great
45 minutes
1 hours
Works great
3 hours:
1 hours
Works great
Could not
complete
Failed
2 for research, 2
for implementation
Technology was added to a
modCheckers.bas module that
calls on a Windows DLL file to
play sounds.
Splash Screen
Welcome screen with fancy,
original 3D game board featuring
grey and red pieces created in
Adobe Photoshop. A pseudo
status label powered by a timer
is also included as a fancy touch.
Victory/Defeat Dialogues
with multimedia and
Statistics
Fancy graphics and
backgrounds accompany a form
that gives a few game
statistics/congratulations screen.
Double Jumping
Capability
Expand MakeMove() and
CanJump() to feature a doublejumping algorithm
2 ½ background
design
Could not
complete
Project Development Timeline
Step
Project Plan (1st 2 Pages)
Develop working Beta
Add extra features #1 and #3
Add extra feature #2
Add extra feature #4
Assemble Completed Project
1.
Documentation
a.
Learning Goals (as outlined)
b.
Infrastructure
c.
Additional Features
d.
Logic Structure
e.
Timeline
2.
Project Code
3.
Project Modules
4.
Project Sound Files
Projected Date
May 4th, 2002
May 14th, 2002
May 17th, 2002
May 19th, 2002
May 21st, 2002
May 23rd, 2002
Actual Date
Completed 5-7
Completed 5-13
Completed 5-16
Completed 5-18
Could not complete
Completed 5-22
Included all components
Included
Included
Included
Checkers! Game Logic
While the architecture of the Checkers! Program is designed in the context of a Graphic User
Interface (GUI) tailored via Event Procedures, The Checkers! game logic can almost be
described as top-down. The only event procedure called during game play (with the exception
of menus, etc.) is the imaBoard_DragDrop() subroutine.
This crucial subroutine, when activated by a user’s moving a piece, calls the key MakeMove()
subroutine, unleashing the vibrant power of the checkers program. (For more information on
MakeMove(), see page 6.) For this reason, I will start the flow chart from the
imaBoard_DragDrop() subroutine.
7
Logic Flow Chart
imaBoard_DragDrop()
1. User makes a move
2. Calls the MakeMove()
subroutine, sending two pieces
of information: ToSquare and
FromSquare.
MakeMove()
3. Conducts a battery of Validations
to ensure that the move is a
legal one. Such validating factors
include Turn, Space, Move
Direction, Piece Type, Board
Parameters, etc.
User’s
request is
ignored
Legal Validations
CanJump()
4. Evaluates whether the move
involves a jump. If true, then
special effects are initiated.
Play Loud Jump
Sound Effect
Play Move
Sound Effect
Processes user’s move as valid by
changing parameters in Board()
5. Board() stores position and
placement of all pieces and
blank squares on board
SwitchTurn
6. Turns are switched after the
valid move
Update Statistics
7. Variables like NumOfMoves are
updated
CheckForKings()
8. Checks for kings and will
upgrade piece if found
CheckForWinner
9. Checks for winners by activating
special routines that
mathematically evaluate Board()
UpdateBoard()
10. Board images and components
are updated
11. Program Terminates
END SUBROUTINE
8