Introduction

We recreated Yutnori on an LED game board with an accelerometer-based controller input system.

The purpose of our project is to construct an interactive board game that displays the output directly on the game board built with many LED's.  The display system we chose was a game board in which the positions of the player's pieces are indicated by lighting up the LED's on the corresponding stations.  The input will be given by the virtual tossing motion of the Yut stick with an accelerometer attached to it.  The result of the toss will be virtually simulated and displayed on the LED game board and the LED status panel.  The game board features a single player mode with against an AI in addition to the classic 2-player mode.  This game board will provide the users an easy mean of enjoying the board game without physical constraints since the game board automatically processes all the moves for the players.

High Level Design   

Rationale

Considering that most board games require a number of players to play the game and that the players need to physically move the game pieces themselves, we wanted to construct a strategic board game with an automated game board that not only moves the game pieces automatically but also provides an AI interface that enables a single player mode.

The game we chose to implement is Yutnori, a Korean traditional board game, which requires the users to toss four Yut sticks to determine the spaces earned to move forward on the board.  Yutnori was an attractive choice because it is a strategic board game that is not too simple or overly complicated to program the game mechanism and the AI, and the physical fabrication of the game board itself seemed interesting.  Also, there are many gaming devices such as Nintendo Wii and Smartphones that contain accelerometer-based controllers.  Given that Yutnori could be played by simulating a virtual tossing motion, we imagined that our LED game board could further be expanded to interact with various kinds of aforementioned controllers.  The extensive scalability of the platform also applies to the LED game board, which could also be modified to implement other popular board games such as Monopoly and chess.

About Yutnori

Background

Yutnori is a traditional Korean board game that is typically played during traditional holidays.  Like most board games, rules can vary.  We will design according the most common set of rules.

<Figure 1: General Yutnori set>

Before describing the rules, there are some sets of terms that the player has to be familiar with in order to understand the rules.

<Table 1: Yutnori Terminology>

The Yut stick has one flat side and one curved side. A typical Yut stick is designed so that the probability of flat side facing up is around 60%.  The Scoring system of the Yutnori is as below.

<Figure 2: Side view of a typical Yut stick and the scoring system>

Game Rules

•     Objective: Bring all four mals home first.
•     Equipments: 4 mals (tokens) per team, 1 malpan (board), 4 Yut sticks 
•     Procedure: Each turn consists of tossing Yut sticks and then advancing the mal(s) according to the space earned by the tosse(s).
•     Rules:

            o   Player earns

                    §   BACKDO = -1; DO = 1; GAE = 2; GEOL = 3; YUT = 4; MO = 5 spaces

        §  Landing on own mal = “ub,” stack the two mals together as a one big unit

        §  Landing on opponent’s mal = capture; captured mal must return back to starting position

            o   Player may move a new mal or ones already on the board.

                    §  Landing on big stations = changes the route of the mal (shortcut)

        §  Landing on own mal = “ub,” stack the two mals together as a one big unit

        §  Landing on opponent’s mal = capture; captured mal must return back to starting position

            o   Extra turn is achieved by:

            1.    Tossing a YUT or MO

            2.    Capturing opponent's mal(s)

        §  Capturing with YUT or MO earns only one extra turn.

        §  For case 1, the player is not required to move immediately, but instead can save YUT(s) and MO(s) and decide later on which sequence to move the mal.. 

            o   BACKDO can be obtained by tossing a DO with a specially marked Yut stick

        §    Player must move one space backward along its travelled route

        §  Route4 is possible if a mal is on the “DO” spot

        §  Skip a turn if no mal is on board

            o   “Nak” = tossing one or more Yut sticks off the designated tossing boundaries.

        §  Player immediately loses current turn.

        §  All saved tosses are lost.

            o   Mal must advance extra spaces past the last station to score

        §  Beginning position = off the board

        §  First (do) position = first station

        §  Finishing position = last station

        §  Scoring position = any spaces past last station

<Figure 3: Possible routes in Yutnori>

Background math

Determining the optimal probabilities for the Yut toss simulation

For simulating the toss results, we randomized the result of each simulation by assigning a probability of 0.46 for each Yut stick landing flat side down and 0.54 for flat side up.  The rationale behind this choice of probabilities was to make the game as dynamic as possible within a reasonable spectrum.  Let q = probability of a Yut stick landing flat side down.  From “A study on probability of the Korean board game Yut” by Changhuyck Oh,

           (1.1)

<Figure 4: Cross sectional diagram of semi-circular Yut stick with a cutting angle of θ>

Based on (1.1) and numerous experimental data, the probability of a Yut stick landing flat side down can be presumed by a regression line,

                       (1.2)

Because each toss result yields a different distance, people intuitively expect the following event frequency relation: DO > GAE > GEOL > YUT > MO.  In other words, since DO earns less distance than GAE does, DO should occur more often than GAE, and so on.  This relation translates mathematically into: Pr(DO) > Pr(GAE) > Pr(GEOL) > Pr(YUT) > Pr(MO).  The relation that most closely satisfies the preference relation above occurs with 0.4 < q < 0.5, which yields: Pr(GAE) > Pr(GEOL) > Pr(YUT) > Pr(MO).

Now, let X1, X2, X3, and X4 be independent and identically distributed Bernoulli random variables.  Then, Y represents the distance earned by tossing a set of four Yut sticks. 

Assuming that a set of four Yut sticks are identical, the probability of landing flat side down for each Yut stick will be equal.  The corresponding probability mass function is:

For  Y~TB(q), the expected value is as follows:

Let S = the expected value of the distance earned during a single turn.  Considering that a player earns an extra toss if YUT or MO is tossed,

In order to make the game most dynamic, we want to maximize the expected value of the distance earned during a single turn, so we solve for the highest value of S.  We find that the maximum S = 2.74 for 0.4 < q < 0.5 is obtained with q = 0.46. Substituting this value into (1.2), we can see that a set of Yut sticks with will yield the desired probability.  Below is the frequency of the toss results expected from our game with q = 0.46.

Controlling LED's using Charlieplexing

Considering that our game board consists of many LED's and that we have limited number of I/O pins, we decided to use Charlieplexing method. Chalieplexing method uses the tri-state logic capabilities of microcontroller pins to drive an array of LED's.  We can set a pin as an input, which effectively gives a high impedance to the pin, and the circuit will see the pin as open circuit, or we can set the pin to output and give either a high (5 V) or a low voltage (ground).  These three different states comprise the tri-state of a pin.  Below is a simple example of how Charlieplexing method works in a 3-pin case.  Each set of two pins will have at most two LED's connected with different anode and cathode direction.  We can toggle any LED on the figure by appropriately setting the target set of two pins as output and setting rest of the pins as inputs.  We can then choose which one to light between the two LED's connected to two output pins depending on which pin we set as a high or a low voltage pin.

<Figure 5: 3-pin Charlieplexing case>

In the same manner, the number of LED's we could control through Charlieplexing is same as getting the number of cases of choosing 2 pins from multiple numbers of pins, resulting in the following equation: [# of LED's we could control] = [# of pins] × [# of pins -1]

Logical Structure

Our Yutnori game consists of the input components, the MCU, and the output display components.  There are two input system consisting of the accelerometer Yut stick and switch buttons.  The simplified high level structure of the game is given below.

<Figure 6: Logical Structure of our project>

The virtual toss of the accelerometer Yut stick will be fed through the comparator to Mega644, which will recognize the toss and consequently compute and simulate the toss result.  The toss result will be displayed on the status panel.  Since there are two mals to control for both sides, there needs to be a toggle button to select which mal to move.  Once this decision is fed into the microcontroller, the MCU performs the route computations to actually move the selected mal and blinks the appropriate set of LED's on the LED game board to represent the result of the move.  After the move has been processed, many conditions are checked before the turn ends, and the program loops until one of the players wins the game.

Hardware/software tradeoffs

Our game board has a total of 66 LED’s to control, and at most four of those 66 LED’s have to be lit simultaneously. One of the drawbacks of using the Charlieplexing method is that only one set of LED’s sharing a common anode or cathode can be controlled at any given time. Since we did not have any LED’s share a common anode or cathode, only one LED can be controlled at any given time.  Since the LED’s appear as if they are lit simultaneously to the human eye if the flickering occurs fast enough at a refresh rate greater than 50 Hz (or a refresh period of 20 ms), we used time division multiplexing access (TDMA) in order to light up multiple LED’s simultaneously.  In essence, one LED is lit briefly, then another, then another, until the cycle repeats. 

However, utilizing TDMA thwarted our initial plan to display the game status messages on the LCD.  From testing, it seemed that it requires a few milliseconds to write to the LCD.  In order to update the game status messages, we must clear the LCD and write two lines of message.  During this process, the MCU cannot control the LED’s, so this delay due to LCD update is added directly to the period of the refresh cycle.  This extra delay addition increased the period of the refresh cycle past the threshold period of 20 ms, so the resulting flickering was too visible, an undesirable effect.

Our next plan was to add another set of eight LED’s to display the game status: two for indicating current player’s turn and six for indicating the toss result.  Again, using the Charlieplexing method seemed appropriate, however, doing so effectively increased the number of LED’s to be controlled to 10, since a maximum of six LED’s could be lit up simultaneously for the game status.  Again, trying to control 10 LED’s resulted in a refresh period of around 20 ms, and the undesirable flickering was somewhat visible.  We compromised by deciding to display the game status with a set of eight LED’s as described above, but instead directly feeding from all eight port pins without using the Charlieplexing method, which was acceptable since we had enough idle port pins.  This eliminated the flickering issue completely.

Game rule modification

Originally, Yutnori is played with four mals on each side.  However, in order to be able to display all four mals, we would need four LED’s for each station for each side, which accumulates to approximately 260 LED’s on the game board.  From the perspective of the hardware design, this was a bit excessive, so we decided to reduce the number of mals on each side to two. 

             Additionally, if YUT or MO is tossed, a player may save that toss and later use it, not necessarily in order, in combination with other tosses at the end of the turn, which makes the game strategically interesting but very difficult to design.  We would have to prepare another mechanism to store such tosses and allow the player to later select them later.  We could not devise an efficient scheme to implement such system, so we simply forced the player to make the move right after the toss even if YUT or MO is tossed.  Besides the two rule changes, the original rules of Yutnori were kept intact.

Hardware design

             Our hardware consists of two main input components and two main input components.  The input components are the accelerometer Yut stick and the switch buttons that the user interacts with, and the output components are the LED game board and the status panel that display the situation of the game through the entire process.

LED Game Board

The role of the LED game board is to display where the mals are for both sides at a given time during the game.  There are 29 stations, each of which will have one green and one red LED for each side.  Also, there are the indicator LED’s named HOME and SCORE.  HOME LED shows the mal(s) that have not yet left, and SCORE LED refers to the mal(s) that have successfully made a full trip around the board.  The player who scores both mals first will win the game.  Since there are total of 66 LED’s to control, using the equation from previous section, we determined that 9 pins are required to perform the Charlieplexing method.  We used 8 pins from port A.0-7 and port D.0 as the 9th pins.  The schematic of the 9-pin Charlieplexing along with the corresponding LED address on the LED game board is as below.

<Figure 7: Charlieplexing with 9 pins to control 66 LED's>

All LED's we used for this project are 5mm LED's with maximum current rating of 15 mA.  We connected two 330 ohm resistors in series to each of the pins so that the LED that is to be toggled on will not receive a current that exceeds 15 mA.

<Figure 8: Circuitry of the LED toggled on>

To connect the LED's to the correct pins, we first soldered wires to the ends of the LED's and inserted them through the holes drilled onto the plastic box.  Then we used a soldering board placed inside the plastic box to connect the LED wires to appropriate pins.  We drilled a small opening at the front of the plastic box so that the nine wires could stick out and be connected to the 9 pins easily.

<Figure 9: LED Board Connections>

Status Panel

To connect the LED's to the correct pins, we first soldered wires to the ends of the LED's and inserted them through the holes drilled onto the plastic box.  Then we used a soldering board placed inside the plastic box to connect the LED wires to appropriate pins.  We drilled a small opening at the front of the plastic box so that the nine wires could stick out and be connected to the 9 pins easily.

As indicated above, because of the refresh rate issue of the LED's, we decided to use 8 pins on Port C.0-7 to indicate the current player and the toss result on the status panel.  The number of yellow LED's lit up indicates the space(s) earned by the toss result simulation.  The leftmost red LED indicates BACKDO.  The top two LED's indicate current player’s turn.  The status panel and the LED game board are given some delay amounts from the program so that the player has time to check the toss result for analyzing the board situation and verify the move result on the LED game board.

<Figure 10: Circuitry of the status panel and its picture>

Accelerometer Yut Stick

We will use a wired Yut stick with an accelerometer, MMA1260D, attached inside the carved portion of the Yut stick.  Once the LED on the status panel indicates that it is the player’s turn, the program will wait for the player to perform a virtual toss.  Once the player performs a virtual toss motion, the accelerometer connected to the comparator will give a high signal to the MCU and the status panel will display the simulated toss result.  Below is a picture of how our accelerometer Yut stick looks like.

<Figure 11: Accelerometer Yut stick>

The output voltage from the accelerometer is fed into the comparator, LM358, by using pins 4, 6, and 7 for Vout,Vcc, and gnd, respectively, with an appropriate setting of the reference voltage, which we set at around 0.5 V.  The virtual tossing motion of the Yut stick can be read through dynamic acceleration mode.  The comparator should correctly debounce any small noise movements on the Yut stick and only read the “acceptable virtual toss” of the Yut stick and send the signal to the MCU port D.4.  The safe circuitry of the comparator is shown below.  The reference voltage can be adjusted using the trimpot attached on the circuit.

<Figure 12: Accelerometer MMA 1260D and the circuitry for 1260D to MCU>

Switch Buttons

We connected switches 6 and 7 on the STK500 board to pins B.0 and B.1.  Pin B.1 serves as a toggle button that enables the users to toggle between the two mals to select for moving.  Pin B.0 serves as an enter key that lets the users to finalize their decision of the mal to move.

Software Design

Overall, the game program is divided into three phases: toss, select, and move.  The three phases, in that order, constitute a single turn cycle.  Toss phase prepares for the user input of Yut toss.  Once tossed, the toss result is simulated.  Select phase enables the player to select which mal to move.  AI automatically selects on its own during this phase.  Move phase simply moves the selected mal according to the toss result.  The special cases are checked and processed.  At the end, the program returns back to toss phase.  The program loops until one of the two players score both its mals.  The fundamental logical flow diagram of the overall architecture is shown below. 

<Figure 13: Logical flow diagram of the program>

In general, translating the rules of Yutnori to a logical structure presented a decent challenge because there were so many corner cases to consider and many property fields and flags to keep track of due to those corner cases.  Therefore, majority of the focus and effort were concentrated on the initial layout of the program as all the necessary variables and function blocks were planned out and revised several times well before the first line of code was written.  Specifically, the location on the game board and the position on the route arrays, as well as the mal status and the station occupancy status, had to be updated in perfect synchronization in order to facilitate the debugging process.  Below is the listing of all the functions integrated into the program:

lab5.c – The main program to run the game 

int main(void):  The necessary hardware and the header files are encapsulated through #include command.  Appropriate amounts of delays, from 500 ms to 1500 ms, are inserted between the phases to give clear distinctions for phase transitions and allow the players to properly observe and analyze the situation.

defVar.h – Contains all defines and global variables

There are two adjustable defines: SEED and AI.  Since the random generator used in the program is pseudorandom, randomly assigning an int value to SEED for each game is necessary to avoid a same sequence of Yut toss results.  AI can be assigned to either P1 (player 1) or P2 (player 2) to play the game against an AI, or not assigned at all for a 2-player game.  The rest of the defines and variables deal with the station occupancy status, toss result values, mal properties, mal status, various state flags, time counters, and predefined routes.

Specifically, the 29 stations on the game board may be occupied by P11 (player 1’s first mal), P12 (player 1’s second mal), P21 (player 2’s first mal), P22 (player 2’s second mal), DOUBLE1 (player 1’s both mals), DOUBLE2 (player 2’s both mals), or EMPTY.  Each mal has the following properties: loc (location of the mal on the board), route (route array the mal is following), routePos (the position on the applicable route array), and status (SINGLE for without ub, DOUBLE for with ub, SCORE for scored mal).  The location is usually determined by looking at the route position of the mal on its route.  The status fields are usually needed to process the results after the move.

<Figure 14: LED addresses on LED game board>

initialize.h – Initializes all hardware and SFR’s

void initialize(void):  All the ports necessary for the operations of the game are set up: pins A.0-7 and D.0 for the LED’s on the game board, pin B.5 for the Yut trigger accelerometer, pins C.0-7 for the LED’s on the status display, and pins B.0-1 for the switch buttons on the SKT500 board.  Timer0 is set up with a prescalar of 64:1.  Timer0 interrupts when the counter matches OCR0A of 250 and resets to 0, effectively making timer0 interrupt every 1 ms.  Additionally, time counters, stations, mals, other flags and variables are initialized to default settings.  Finally, the random generator is seeded and ISR is initiated.

timerISR.h – Runs ISR

ISR (TIMER0_COMP_vect):  Timer0 overflow ISR runs to generate interrupts every millisecond.  At each interrupt, timer0 decrements the three counters – time1, time2, and time3 – for refresh rate, blink rate, and count extender, respectively.  The count extender is further extended by acting in conjunction with four additional counters – time4, time5, time6, and time7 – for two delay rates, move rate, and debounce rate, respectively, since 256 ms is the highest delay one counter can track otherwise.

toss.h – Simulates toss result

void toss(void):  The program waits until the user input from the Yut stick accelerometer.  Once tossed, the toss result for each individual Yut stick is simulated using the random generator.  The total toss result is calculated by adding up the individual results.  Upon the completion of the calculation, the toss result is displayed on the status panel.

select.h – Enables the player/AI to select which mal to move

void select(void):  The select phase begins with a listing few cases in which the mal selection is not possible:

• End turn if both home for BACKDO

• End turn if one home and one score for BACKDO

• Cannot select a mal at home for BACKDO

• Cannot select a mal that already scored

After the initial block of code that prevents selecting the non-selectable mal(s), the player is presented with two active-low button options: toggle and enter.  Toggle is debounced by allowing the toggle button to activate only once every 500 ms and change the selected mal.  Once enter button is pushed, the game moves on to the move phase with the currently selected mal.  If an AI is playing, AI mal selection algorithm is called.

move.h – Moves the selected mal according to the toss result

void move(void):  Prior to moving the mal, the station at the starting location becomes EMPTY, and the incremental moving procedure loops until the station at the destination location is reached.  The position of the selected mal’s route is incremented, and the mal is moved accordingly.  At the end of each incremental move, if the selected mal has scored, the move phase terminates since no more moving is required.  Once the station at the destination location is reached, possible route changes are checked, and the station occupancy status at the destination location is updated.

moveMal.h – Processes the move and updates the routes 

void moveMal(char mal):  After determining the route of the inputted mal(s), it moves the mal(s) along the route by pointing at the route position on that route.  The result is stored into the location field of the mal.

void updateRoute(char mal):  Route changes, if any, are performed.  Route changes are processed by updating both route of the mal and the route position on the new route.  Below shows all possible route changing scenarios.

<Table 2: Route changes>

void checkDest(char mal, signed char space):  The destination of the selected mal for AI is checked.  The toss result is added to the route position along the route of the selected mal.  The value returned is equivalent to the resulting location on the board.  If the value is not greater than zero, it is defaulted to zero.

moveResult.h – Checks for special cases after the move 

void checkStation(void):  Mal conditions are changed according to the station occupancy.

• If own mal is present at the landing station, update for ub sequence.  If the toss result is YUT or MO, continue turn; Otherwise, end turn.
• If enemy mal is present at the landing station, update for capture sequence.  Continue turn.
• If the landing station is empty, update for empty sequence.  If the toss result is YUT or MO, continue turn; Otherwise, end turn.

void endTurn(void):  Current turn is ended by switching current player, preparing for the toss phase, and turning off the toss result on the status panel.  Scored mal cannot be selected.

void continueTurn(void):  Current turn is continued by keeping current player, preparing for the toss phase, and turning off the toss result on the status panel.  Scored mal cannot be selected.

void checkScore(void):  Mals are checked to see if they have scored.  If any mal has reached the location 30, which corresponds to the scoring position, the status of the mal updates to SCORE.  The winning condition is checked immediately afterwards.  If the winning condition is not met, turn is ended or continued depending on the toss result.

void checkWin(void):  Winning condition is checked.  Either player wins if both mals have SCORE as their status.  The game enters an infinite loop with the winner indicated on the status panel and the final position of the game remaining lit up on the game board.

blink.h – Turns on and blinks LED’s

void blink(void):  Through TDMA that uses a looping flag system, it essentially cycles through four states, each dedicated to P11, P12, P21, and P22.  In each state, the LED representing the dedicated mal is lit up for 2 ms, unless the mal is a selected mal, which then only lights up half the time to produce a blinking effect.  Using this scheme, the selected mal blinks and the other remaining mals are turned on. 

void blink2(signed char n):  The player indicator and the toss result are displayed on the status panel.  PORTC is set to one, which make the pin output 5 V, according to the inputted toss result to turn on the appropriate set of LED’s.  The port pins C.6-7 represent the player indicator section and the port pins C.0-5 represent the toss result display section, with C.5 for BACKDO and C.0-4 for the rest of the toss results.

locate.h – Locates and lights up mal according to its board address

void locate(char mal, char n):  The two inputs, the mal and its location, determine the game board addresses that map to the corresponding LED’s.  In order to light up the correct LED, the port pins A.0-7 and D.0 are configured according to the inputted mal’s location on the game board by changing DDRA, PORTA, DDRD, and PORTD.  Since setting DDR bit to 0 makes the pin an input (open), setting DDR bit to one makes the pin an output, and PORT bit to one makes the pin output 5 V, an easy way to configure DDR and PORT is to set the sum of the two game board address bits to DDR and the first game board address bit to PORT.

ai.h – Selects the mal to move based on the board situation

void ai(void):  If there are no selections available (e.g. one of the mals already scored, BACKDO with one mal at HOME, mals with ub status), indicated by the flag “change,” the game moves straight into the move phase with the current selected mal.  However, if there are selections available, the AI obeys the following prioritized list (a series of one if statement and many else if statements) of decision making.  The AI decision path is shown below.

(1) Capture if possible.  In case of multiple possible captures, capture the furthest travelled mal.

(2) Run if threatened (A mal is threatened if it is located one or two spaces in front of an enemy mal).  Run the mal located one space in front of an enemy mal.  In case of threats on multiple mals, run the furthest travelled mal.  Run the mal located two spaces in front of an enemy mal.  In case of threats on multiple mals, run the furthest travelled mal.

(3) Ub if possible

(4) Route change if possible with the following priority: route4 > route3 > route2 > route1

(5) If none of the cases apply, randomly select through random generator.

<Figure 15: AI decision path>

Results

Execution and Accuracy

The speed of execution is within the target of 50 Hz.  In order to avoid the blinking effect of the Charlieplexing method, the entire program must loop at least once every 20 ms, and since the LED’s always appear as if they are lit all the time, we can deduce that the program is executing at a rate faster than 50 Hz.  We inserted several delays within the game program loop to enhance the game play.  These delays range from 500 ms to 1500 ms, generally for the transitions between different phases.  These delays are accurate, but the game may be slightly fast paced when playing with the AI for the first few times.  The logic behind a fast paced game play was to keep the average game time low and to eliminate unnecessary waiting as the user gets more accustomed to the game and is able to read the toss results and the board situation more quickly.

The toggle button is very weakly debounced.  Because the toggle button triggers every 500 ms upon pressing, holding down the toggle button for longer than 500 ms results in the selected mal switching more than once.  However, if the user simply taps the toggle button, 500 ms is an appropriate amount of delay.  Even if the user does not follow this convention, it is not very difficult to land on the mal the user wants to select.  Also, the accelerometer Yut stick triggers toss results very reliably as long as the user takes precaution not to hold it upside down, as it will trigger the toss simulation right away.  Any kind of gentle upward jerk will trigger the comparator and begin the toss simulation, so the user will hardly ever need to try to toss more than once.

Because we have not been able to test the overall system thoroughly for every single corner cases, it is difficult to quantify the accuracy of the program precisely, but the overall game mechanism seems to perform consistently with the set of game rules.  We tested directly by actually playing over 50 games against each other and against the AI.  As far as we know, the program performs very accurately in conjunction to the intended behavior.  All the move processing, condition updates after each move, route changes, mal selection, status panel display, and other general aspects of the game all work perfectly.  The AI rarely makes move that are questionable since we could not consider all the specific cases that could occur during the game.  Also, when none of the selection cases apply for the AI, the AI is supposed to randomly choose one of the mals to move, but it seems to play the first mal a lot more often than the second.  In general, however, the AI performs very well against the human player who often times fall to the AI, so playing against the AI may not be the toughest challenge, but definitely not an easy win either.

Safety and Usability

We did our best to augment the safety of the game by applying electrical tape to all the exposed wires and enclosing all the main circuitry inside the plastic box.  However, the two ends of the LED’s are not completely protected from human contact, though extremely unlikely.  Around 7 mA of current is running through the LED at roughly 5 V, so safety is not a huge issue for our game. 

             In terms of usability, once the user gets acquainted with the rules of Yutnori, our game is very easy to play.  The level of difficulty of the game itself is fairly low to begin with, and the user interface is very intuitive and simple since there are only two buttons and the accelerometer Yut stick to interact with.  The only down side is that the accelerometer Yut stick must be oriented flat side down before the toss.  It helps if the player becomes familiar with the flow of the game phases so that the player knows what to expect.  Most games can be finished within 5 to 7 minutes, so our game qualifies as a quick recreation in which the players are not committed to a time intensive endeavor.

Conclusion

Meeting Expectations

We had a slightly different vision for the completed project initially, which involved using NTSC video as a medium for displaying the game.  The original goals for this project were:

• Implement a basic 2-player mode
• Strictly follow the rules of Yutnori
• Simulate Yut tossing using accelerometer
• Implement an AI
• Incorporate aesthetically appealing graphics
• Expand the game up to 4-player mode
• Include appropriate sound effects

While most of the basic goals were met, our finished product differed drastically from the initial inspiration.  We went through many different revisions and ultimately decided on an LED board as our display method.  As a result, we could not physically build a system that strictly followed all the rules of Yutnori and incorporate animated graphics.  Expanding the game up to 4-player mode was only possible with the TV since the expansion would require mostly software efforts.  However, with the LED board, there existed a few physical limitations to expanding the number of players as it required many additional LED’s, which translated into building a more complex circuit and using more port pins to control all the LED’s.  We decided that it is not worth the effort to physically implement the 4-player mode.  Adding sound effects could have been implemented, but we ran out of time to realize this goal.

Overall, we exceeded our expectations in terms of playability and AI implementation.  We focused on developing a system that was fun to play.  Many times while debugging, we found ourselves really enjoying a few games of Yutnori, especially against the AI that would often make smart choices to win the game.  Our game has received positive reactions and reviews from our friends who took part in testing the system by participating in the game play.

Future Improvements

One of the possible improvements we would like to further integrate is the AI enhancement.  While the current AI follows a somewhat general guideline of decision path, an improved AI could include a lot more specific cases.  Also, a weighted randomness could be incorporated into the decision path so that the AI would not always behave as expected.  This concept of weighted probability could also be applied in the toss result simulation in which depending on the initial orientation and the acceleration of the toss, the probability of the toss result could be slightly influenced.  The ultimate goal would be to fully enable playing all four mals to conform more closely to the original game of Yutnori and improve the strategic aspect of the game.

Intellectual Property Considerations and Applicable Standards

While the game of Yutnori is not our original invention, it is a widely played Korean traditional board game, so there are no intellectual property violations caused by the development of this project.  Except for the comparator design from Lab 4, all the coding and designing were completely original.  Since the game is constructed purely for enjoyment and learning, we did not really look into any patent opportunities.  Also, considering that Yutnori is a widely known board game in the Korean culture, we highly doubt that there are patent opportunities for this project.  However, using the concept of the accelerometer Yut stick, Yutnori could be implemented by a console system like Wii using the equivalents of Wii remotes as the controller.  There are no applicable standards that we needed to follow.  All the resources we utilized as references are catalogued in the appendix.

Ethical Considerations

While working on our project, we tried to be consistent with the IEEE Code of Ethics.  Because the development of this project primarily took place in a learning setting with many other students sharing a common lab space, we mainly focused on the two following codes:

1. To accept responsibility in making decisions consistent with the safety, health and welfare of the public, and to disclose promptly factors that might endanger the public or the environment.  We paid particular attention to the safety of ourselves and other classmates in the lab by making sure that power is turned off after using soldering iron and drilling tools so as to reduce the chances of accidents occurring.  We took all necessary precautions that may seem excessive such as putting on goggles for soldering and drilling and wearing gloves for mechanically working on the hardware.  Another safety concern we tried to concentrate on was to maintain our workspace clean.

7. To seek, accept, and offer honest criticism of technical work, to acknowledge and correct errors, and to credit properly the contributions of others.  It was of a great importance for us to regularly communicate with the professors, TA’s, and peers about the project.  Very often, they were able to provide ideas and feedbacks that we have not previously considered, which was very valuable in all areas of design, manufacturing, and debugging processes.  We also returned our share of advices and constructive criticisms by showing genuine interest towards some of the other projects and providing our perspectives.

Legal Considerations

Since our game does not involve any wireless devices nor require any RF signals, it will not cause any interference with other electronics.  Thus, our project is not constrained by any common legal restrictions.

Appendix

A. Commented Code

• lab5.c - The main program to run the game   
• ai.h - Selects the mal to move based on the board situation  
• blink.h - Turns on and blinks LED’s  
• defVar.h - Contains all defines and global variables  
• initialize.h - Initializes all hardware and SFR’s  
• locate.h - Locates and lights up mal according to its board address  
• move.h - Moves the selected mal according to the toss result  
• moveMal.h - Processes the move and updates the routes   
• moveResult.h - Checks for special cases after the move   
• select.h - Enables the player/AI to select which mal to move  
• timerISR.h - Runs ISR  
• toss.h - Simulates toss result

B. Schematics

<Figure 16: Schematic of the entire system>

C. Cost Details

<Table 3: Cost details>  

D. Task Division

<Table 4: Task division>  

E. References

Data sheet

• Atmega664 - http://www.atmel.com/dyn/resources/prod_documents/doc2593.pdf

• MMA 1260D - http://courses.cit.cornell.edu/ee476/FinalProjects/s2006/wl228hl336/New%20Folder/mma1260d.pdf

• LM358 - http://www.national.com/ds/LM/LM158.pdf

Vendor sites

• Electronics123 - http://www.electronics123.com

Background sites / Paper

• “A study on probability of the Korean board game Yut” by Changhuyck Oh - http://img.kisti.re.kr/originalView/originalView.jsp?url=/soc_img/society//kdiss/DJGHBY/2010/v21n4/DJGHBY_2010_v21n4_719.pdf

• ECE 4760 website - http://people.ece.cornell.edu/land/courses/ece4760

• Charlieplexing (Wikipedia) - http://en.wikipedia.org/wiki/Charlieplexing

F. Acknowledgements

We would like to thank Bruce Land for his great lectures and lab contents that helped us to succesfully complete the final project.  His advices and feedbacks were very helpful in progresssing through our project.

We would also like to thank Rohan Sharma who helped us a lot throughout the semester in the lab.  His weekly progress checks and advices were very helpful in pacing ourselves and finishing our project.

We would like to thank everyone who participated in testing of your system by playing our game.