John P. Mysliwiec
[email protected]
CIS 587: Game Design and Implementation
Dr. Maxim
Final Project
Octrix
1. Overview
Octrix is a 3D cube strategy game for the personal computer. It is a 3D version of the
classic game Columns for the Sega Genesis. The premise of the original game is to match
three or more of the same shape or colored blocks vertically, horizontally, or diagonally.
The addition of a third dimension makes the game move involved.
This game thought of as an eight base gene simulation. The player acts as a scientist
whose goal is to match the 3 identical genes of the eight different genes (colors) that falls
in three space. The player’s main job is to see how many genes can be reduced for how
long without anything spilling out of the cubed grid (beaker) and to accumulate a high
score.
Figure 1. - The 8 Different Color Cubes Used In Game
Octrix audience is aimed for those have played Columns or a game similar to it. The age
group is assumed to be ages 10 and up.
2. Game Mechanics
2.1 Overview
Octrix is a 3D puzzle strategy game that is modeled after the classic 2D game
Columns for the Sega Genesis. The premise of the original game is to match three
of the same colors or shapes. To extend the original game into three dimensions
involves other additional functions and key commands.
2.2 Camera Position
Camera position in this puzzle is integral to game play. There are three main
functions of the camera; general view, zoom, and specific cube color view. For
the sake of programming, the camera position will be described in terms of left
handed Cartesian coordinates.
The standard default view, or front view sets the camera facing the cube grid from
the positive Z-axis (0, 0, depth) into the negative Z-axis. The cubes (genes) that
are visible are those in front of the negative Z-axis. Any cubes that are blocked by
another cube that is in the front (where the depth increases) will either be partially
shown or blocked depending on positions of the other cubes. For example, two
cubes in the same row with increasing depth will show the front and top of the
first, and just the top of the second cube. An example of this camera view is
shown in Figure 2.
Figure 2- Forward (Fork Pattern) View of Grid
The next viewpoint is the “left” side of the cube. This view is from the negative
X-axis (-rows, 0, 0) into the positive X-axis. The cubes that are visible are those
in front of the negative X-axis. Any cubes that are blocked by another cube
(where the row increases) will either be partially shown or blocked depending on
the positions of the other cubes. In this case, two cubes in the same column with
increasing rows will show the front and top of the first cube, and just the top of
the second cube. An identical cube formation is shown in Figure 3 with a view
from the left matrix.
Figure 3- Left (Fork Pattern) View of Grid
The view from behind reverses the viewpoint from the negative Z-axis (0, 0, depth) into the positive Z-axis. Therefore, in the examples in the figures, there
would be one cube in the front, and three cubes in the back.
The right view sets the camera facing the cube grid from the positive X-axis
(rows, 0, 0) into the negative X-axis. This view is the opposite of the left view
since the depth is considered as decreasing columns.
The camera zoom depends on the camera default position. All camera functions
are standard. When the camera zooms, it moves into the beaker. If the camera is
backing off, it moves away from the beaker.
The camera also possesses the function of viewing the positions of either one type
or all of the different colored cubes. The reason is that if a cube is completely
blocked, but can be used in reduction, it ought to be visible some how.
For example, if the user chooses to view the first color cube, those cubes with that
color will be visible while all others will be hidden. If the camera view is filtered,
only the color blocks that are picked are shown, however all of the falling blocks
are shown.
In all cases, the camera has the ability to go back to its default position by rotating
the camera viewpoint by a user key command.
2.3 User Interface Design
The game’s screen is made out of a single window that takes up most of the
computer screen. The game can be maximized to take up the whole screen if
needed. Most of the game area, depending on the size of the Rx32xD matrix takes
up most of the space on the screen. The complexity of this game as well as the
time constraints limits the development of other nifty utilities that would be
beneficial, but not necessary (i.e. control number of rows and depth of the grid).
The user menus contain three different controls, “New Game…,” “Exit…” and
“About…” Other options like choices of levels would have been added, however
this game for all practical purposes is going to be further developed into a massive
multiplayer game.
Visually, the game play is on the center of the screen. The scores are listed to the
right of the cubed grid. The display is listed in order by score, blocks, and level.
In order for the player to have an idea where the default camera view is, the
scoring only shows when the view is either into or out of the Z-axis.
The cubed grid is centered on the middle of the screen. It is a checkerboard
matrix. When a block falls, the portion of the checkerboard is lit in white
whenever the items are over a certain grid. If a cube is over another cube, the top
of the cube is lit as well. The checkerboard itself is a red and black checkerboard
on a blue background.
The game contains different kinds of sounds that will be played at different
points:




“Are You Ready?” – plays before the game items are shown on the screen.
J.S. Bach’s BWV 525 Trio Sonata #1 is the background music that is
playing throughout the game.
Boom – plays when a block that is falling hits the surface.
Click – is played whenever a player is reshaping the cubes.
The game ends with a female voice saying “Try Again.” The text on the screen is
in red with the writing “Game Over.” The text following it lists the score, the
blocks destroyed and the level.
2.4 Replaying and Saving
As in the original 2D Columns game, saving the game state does not exist. As far
as replaying the game, the game starts from the beginning with cubes falling
down. The basis for this one player game is to reduce the cubes and to accumulate
points.
2.5 Control Summary
The controls in Octrix are arraigned so that one can play it either with just the
keyboard or a keyboard and game pad combination. Since there were time
constraints on creating this game, neither key controls nor joystick controls are
modifiable. As far as development considerations, the Saitek P880 12-button
game pad was used as the test controller. It was chosen to mock the general
controllers of the common systems (i.e. Playstation).
Saitek P880 – Test Joystick Model
Note, in general, all the commands are described from the default camera
position. As the views switch, the directions of the keys switch to reflect the
viewpoint.
Keyboard Commands
Game Dialog
 ALT + /, ALT + ? - About Dialog Box
 CTRL + N – New Game
Keypad Direction
 Up Arrow – Move blocks forward (into the negative Z-axis)
 Down Arrow – Move blocks backward (into the positive Z-axis)
 Left Arrow – Move blocks left (into the negative X-axis)
 Right Arrow – Move blocks right (into the positive X-axis)
Game Play Keys
 J – Rotate blocks left (into the negative X-axis)
 K – Rotate blocks right (into the positive X-axis)
 N – Rotate blocks forward (into the negative Z-axis)
 M – Rotate blocks back (into the positive Z-axis)
 U – Shift cubes positions negative

I- Shift cube positions positive
Cube Rotation View
 Q – Rotate cube view left
 W – Rotate cube view right
Game Position View
 A – Move camera up (positive Y-axis)
 Z – Move camera down (negative Y-axis)
 S – Move camera forward (negative Z-axis)
 X – Move camera backward (positive Z-axis)
Cube Color View
 NumKey 1 through NumKey 8 – Single cube color view in complete beaker
 NumKey 9, NumKey 0 – View all cubes
Saitek Joystick Commands
8-Way D-PAD:
 Up Arrow – Move blocks forward (into the negative Z-axis)
 Down Arrow – Move blocks backward (into the positive Z-axis)
 Left Arrow – Move blocks left (into the negative X-axis)
 Right Arrow – Move blocks right (into the positive X-axis)
Note: This example assumes default view
6- Fire Buttons:
 Button 1 – Rotate blocks left (into the negative X-axis)
 Button 2 – Rotate blocks forward (into the negative Z-axis)
 Button 3 – Rotate blocks back (into the positive Z-axis)
 Button 4 – Rotate blocks right (into the positive X-axis)
 Button 5 – Shift cubes positions negative
 Button 6- Shift cube positions positive
2- Triggers:
 Button 7 (L) – Rotate cube view left
 Button 8 (R) – Rotate cube view right
2.6 Game Play Details
The beginning of the game starts with the player selecting a new game. The future
of this game is being modified into a massive multiplayer game.
This is a single player game (for now). The player selects “New Game..” and a
sound says “Are you ready?” Music starts to play. A 1x3 cube starts to fall. The
block can be moved forward, backward, left and right. They can also be flipped
horizontally from its vertical start position and horizontally again from its
horizontal position. When the block hits a surface, then the game looks to see if
any blocks can be collapsed. If there are collapsible blocks, the game keeps
collapsing the matrix until no more collapsible blocks are found.
The basic strategy of this game is to reduce the cube matrix before the cube grid
(beaker) overflows. Since there are many different ways to reduce a matrix, the
game can be very interesting as far as the destructions are concerned. The player
has to keep track of where the different color cubes are. Since this is a 3D game,
there are times when the player must switch camera view in order to
accommodate their game play. Also, there are times when the player must view
only certain colors to destroy the matrix. The caveat up to this point is the
direction is dependant on the default view of the camera.
The game has infinite possibilities as far as levels and arrangement of the cubes.
The game ends when the beaker overflows. The player’s score, level, and number
of cubes that were destroyed are displayed after the game has ended.
2.7 Cut-Scenes
Cut scenes are non-existent in this game since it is trying to mimic its 2D
predecessor as close as possible.
2.8 Level Summary
See Section 2.6 Game Play Detail and 6.4 Level and Scene Details.
3. Artificial Intelligence
3.1 Opponent AI
There is no opponent in this single puzzle game. The AI is in terms of cube
reduction and scoring. The code is for the reduction AI is:
do{
tripletsExist = false;
findTriplets();
reduceNumericalMatrix();
findTriplets();
for(int i = 0; i < rows; i++)
for(int j = 0; j < cols; j++)
for(int k = 0; k < depth; k++)
if(tripletMatrix[i][j][k])
tripletsExist = true;
clearTripletMatrix();
}while(tripletsExist);
The reduction algorithm handles the scoring and the level of the game.
3.2 Player Detection
This is a single player game. Player detection is in terms of game controls through
DirectX. See Section 2.5 Control Summary, and Section 3.8 Traps and
Limitations.
3.3 Motion
Motion in this game is in terms of position in the matrix. Cubes can move
anywhere in the matrix under the assumption that it does not go out of bounds
either hitting another cube or hitting and end. This is all done using a numerical
matrix and a coordinate position matrix.
The numerical matrix houses all the cubes in the game. The boundaries are
acquired by the rows, columns, and depth of the matrix as well as the information
contained in it.
The coordinate position matrix is 3x3 matrix that houses the row, column, and
depth of each of the cubes. These coordinates are compared against the numerical
matrix. If the numerical matrix has a –1 then there is nothing in the matrix. If the
numerical matrix has a 0 – 7, then it is a bound. If the coordinate position hits the
ground (x,0,z) or another cube, then the numerical matrix is filled with the
references to the colors. When that happens, a reduction algorithm is called which
finds all the cubes that can be reduced. After the algorithm is called, the cube grid
is collapsed and reduced until no more reductions.
3.4 Path Finding
Path Finding in Octrix is in terms of cube reduction. All cubes can be reduced
vertically, horizontally, and diagonally in by rows or increasing depth. Matrix
path finding for all non-boundary positions (where either rows, columns, or depth
in the array is not equal to 0 or limit – 1) are thought in terms of below:
[k = 0]
NW N NE
W 0 E
SW S SE
[k = -1]
BNW B N BNE
B W B B E
BSW B S BSE
Directions:
North:
(i,j+1,k);
North West: (i-1,j+1,k);
[k = 1]
FNW F N FNE
F W F F E
FSW F S FSE
North East: (i+1,j+1,k);
North(F):
(i,j+1,k+1);
North West: (i-1,j+1,k+1);
North East: (i+1,j+1,k+1);
North(B):
(i,j+1,k-1);
North West: (i-1,j+1,k-1);
North East: (i+1,j+1,k-1);
South:
(i,j-1,k);
South West: (i-1,j-1,k);
South East: (i+1,j-1,k);
South(F):
(i,j-1,k+1);
South West: (i-1,j-1,k+1);
South East: (i+1,j-1,k+1);
South(B):
(i,j-1,k-1);
South West: (i-1,j-1,k-1);
South East: (i+1,j-1,k-1);
East:
East(F):
East(B):
(i+1,j,k);
(i+1,j,k+1);
(i+1,j,k+1);
West:
West(F):
West(B):
(i-1,j,k);
(i-1,j,k+1);
(i-1,j,k+1);
Forward:
Backward:
(i,j,k + 1);
(i,j,k - 1);
As far as edges and boundaries, they are treated in terms of pivot points:
N-N
NW-NW
NE-NE
S-S
SE-SE
SW-SW
W-W
E-E
NF-NF
NWF-NWF
NEF-NEF
SF-SF
SEF-SEF
SWF-SWF
WF-WF
EF-EF
NB-NB
NWB-NWB
NEB-NEB
SB-SB
SEB-SEB
SWB-SWB
WB-WB
EB-EB
B-B
F-F
This algorithm makes it possible to find the reductions points and collapse the
matrix using a reduction algorithm.
3.5 Special Actions
A feature of this game because of the multithreaded environment has to do with
rotations. The cubes start off in a solid 1x3 matrix. As the cubes fall, they can be
rotated, however the rotations can sometimes lag and it can split the positions of
each of the cubes. This ought not to be considered as a bug, but it is practical
since the cubes do break off as they hit a surface. Also, times can exist in which a
cube can be reduced if it was scattered. Reductions can form either together where
the cubes fall or a singularly by each cube.
Scoring is dependant on how many items reduced and the level to which they are
reducing at. The equation is as follows:
if(reductionCounter > 1)
score+=(reductionCounter << 2)*level*25;
else
score+=reductionCounter*level*25;
, where the reduction counter is the total number of cubes to be reduced divided
by three and the level is the current level of the game.
The level increases in increments of ten. Each time the level increases the scoring
values increase.
3.6 Combat
Octrix is a non-combat game as far as violence is concerned. The type of combat
that exists is strategy. The player must think of how to reduce grid under the
assumption: unlike the 2D version, the player does not know the next type of
cubes to fall. The player must act as if any cube that falls will be potentially be
destructive to the extent that the cube cannot be reduced. Also, since levels define
“speed” the player must think and react quickly before the beaker overflows.
3.7 Non-player Characters
There are no non-player characters in this game. The player is the only active
person who exists in the game.
3.8 Traps, and Limitations
There are some limitations in this game due to the use of both DirectX and
OpenGL as well as the Windows multithreaded environment. In general, if the
game does not have the resources like all programs, it will slow down or even
lock up until the resources are granted. This very rarely happens, however it is
worth mentioning.
The use of Direct Input for the keyboard and the joystick creates some system
slowdowns. For example, a multithreaded environment can lead to the keyboard
being unavailable. If the keyboard is not available in the beginning, the program
will not execute. This is the approach that was described in most of the tutorials
dealing with Direct Input. Acquisition of the keyboard causes the game to pause
until the keyboard can be acquired again.
Whether or not the joystick is attached to the game is irrelevant. All primary
functions of the game can be done through the keyboard. However, the limitation
with the joystick is that it requires a Timer function to operate. The timer causes a
problem setting the rates so that the keyboard and the joystick will send messages
at the same rate. The problem with acquisition of devices also exists with the use
of this device.
The only hang up with OpenGL is the resources in the multithreaded
environment. When a cube falls from the top, at some points the cube stops falling
until a key is pressed. This rarely happens, however it has been noted as a
limitation.
4. Game Elements
4.1 Items
Game Grid: It is a 16x16x32 checkerboard where all the 3D action takes place.
Cubes (Genes): See Figure 1 for the 3D cubes used in this game.
Falling Cubes: 1x3 matrix of different color cubes.
4.2 Character Bibles
The player is thought of as a scientist who is trying to match three different
colored genes of an eight base pair. The color cubes represent genes that when
three or more interact, they dissolve.
5. Story Overview
5.1 Storyboard
The storyline is dependant on the player. The placement of the columns can make
the game last either a short time or long time. The game always starts with cubes
falling from the top middle portion of the beaker. The game play is based on the
skill of the player. For every ten cubes that are reduces, the level and speed of the
game increases.
5.2 Background / Plot Summary
The plot of this game is to reduce the cubes (genes) until reduction is impossible
and cube grid overflow occurs. The player in this game is playing against him or
herself in the sense that this is a thinking game. The goal of this game is to see
how many cubes can be reduced and how many points a player can attain.
6. Game Progression
6.1 Settings
There are not any special settings in this game since it is trying to mimic the
classic 2D game. Future settings of this game dealing with the fact that it will be
ported to multiplayer.
6.2 Introduction
This game starts with the player choosing a new game. The game plays a wave
file that says “Are you ready?” The game clears all the data in from the previous
game if played. The game music loads. The game starts with random block falling
from the top. The player has the option of moving, rotating, and shifting block as
well as switching viewpoints. When one portion of the blocks detects a surface,
another block falls.
6.3 Flowchart
Here is the general flowchart of this game from start to finish.
6.4 Level and Scene Details
Technically, the only scene that exists is the game grid. The control of the grid
and the objects are dependant on the player. Wherever the player drops a cube or
arranges the cube reflects whether or not the beaker will reduce. The more cubes
that are reduced, the faster the game becomes. The difficulty depends on where
the cubes are placed on the grid, and speed to which the cubes fall. There is
infinite number of ways a cube can be arranged for maximum game play.
7. Bibliography
DirectX Programming References
LaMothe, Andre. Tricks of The Windows Game Programming Gurus 2nd Edition.
Indianapolis: Sams Publishing, 2002.
Microsoft. DirectX 9.0 SDK: DirectX Sample Browser. 2003.
DirectInput: Keyboard, Joystick
DirectShow: Wav, Midi, MP3.
Microsoft. “Introducing DirectX.” (2003)
<http://msdn.microsoft.com/library/default.asp?url=/library/enus/directx9_c/directx/intro/dx9intro.asp> 27 November 2003.
AndyPike.com “DirectX Tutorial 13: Sound and Music.”
<http://www.andypike.com/Tutorials/DirectX8/013.asp> 6 December 2003.
OpenGL Programming References
GameDev.net “GameDev.net – OpenGL.“ (1999-2003)
<http://www.gamedev.net/reference/list.asp?categoryid=31> 27 October 2003.
Game Tutorials. “OpenGL Tutorials.” (2000-2003)
<http://www.gametutorials.com/Tutorials/OpenGL/OpenGL_Pg1.htm> 27
October 2003
Hewgill, Adam. “Setting Up Microsoft Visual Studio .NET for OpenGL/GLUT.” 2003.
<http://www.cosc.brocku.ca/Offerings/3P98/course/MSVC/msvcnetglut.html> 27
October 2003.
Hodges, Blane. “OpenGL Win32 Tutorial.” (25 August 2001)
<http://www.nullterminator.net/opengl32.html> 27 October 2003.
Neon Helium Productions. “NeHe Productions: OpenGL Tutorials.” (1997-2003)
<http://nehe.gamedev.net/> 27 October 2003.
Reierstad, Ronny. “Apron Tutorials: OpenGL.” (2003)
<http://www.morrowland.no/apron/tut_gl.php> 27 October 2003.
Windows API and Visual C++ Programming References
Horton, Ivor. Beginning Visual C++. Birmingham: Wrox Press Ltd, 1998.
Petzold, Charles. Programming Windows Fifth Edition. Redmond: Microsoft Press,
1998.
Music and Sounds
“Flashkit SFX: Home.” <http://www.flashkit.com/soundfx/> 18 Dec 2003.
- All Wav Files
Pressler, James & Brent Milian. Bach. J.S. BWV 525 – “Trio sonata #1 BWV 525.”
<http://www.virtuallybaroque.com/track141.htm> 1 November 2003.
- bwv525_mph.mp3