Researching and Setting up the State Machine

At this point I am close to having a working game using local mutiplayer. With that in mind I would like to share what I have accomplished over the past week and a half.

State Machines

Recently my professor, shout out to you Matt you’re awesome, purchased a book for me that I had found online. The Unity 5.x Game AI Programming Cookbook had been a target of interest for a few weeks now, and after seeing a snippet of what the book could provide me, I had to have it. However, I didn’t know just how much information I was going to get out of it.

My initial plan was to use the sixth chapter of the book on Board AI Programming to get me started on my own AI implementation down the road. After finishing chapter six and learning about using decision tree data structures, minmax, and negamax search algorithms, I decided to back track and check out the rest of the book. This was the best decision I have made in a long time as the book had an entire chapter on handling game states.

What was great about this moment was the fact that I was just starting my implementation of my own state machine in my game. Therefore, when I saw this chapter I became beyond ecstatic and dove right in. Immediately my initial design for my state diagram became much smaller.

What once was 7 states or more had now been compacted to the four you see below:


My Finished State Machine to Run the Gameplay

What I had learned from reading the chapter was mostly mechanical, how to initialize and use states, as well as creating a template to move from one state to another. The important part here is that each state needed its own file to be accessed depending on the state of the game.

Referencing the diagram above, my game has 4 distinctive states: The Player Turn, Comparison, AI Turn, and Game Over. The diagram does not do any justice of explaining the full purpose of each step, so I will be explaining them in depth.

Player Turn: 

The Player turn state starts off by enabling the ability to move the players card in accordance to which players turn it is. The way the game is set up at this moment always has Player 1 going first. Therefore, player 1 will have the ability to move their cards, but player 2 will not. When the player picks up a card with the mouse, drags it over a spot on the board, and then releases the mouse press that card will be removed from the players hand and placed on that spot on the game board. At this moment the player changes to either player 2 or the AI (which depends on whether the AI is active or not) and the ability of the cards to be dragged is reversed (player 1 no longer has the ability to move their cards but player 2 or the AI gains the ability to).


The comparison state begins by analyzing the last card played to the board to get and store the values of each cardinal power it possess. Afterwards, by using the location of that card that was played, the function will then evaluate all cards around the last card played. If any of the values from the last card played beat a value of a card around it, then that card will become their if and only if it belonged to their opponent. A card that already belongs to a player will not be evaluated in this situation. The game board updates with the new colors to denote which player owns which cards, and the score in the user interface will update in either corner of the screen.

AI Turn:

The AI turn is very similar to the Player Turn state as it will do most of the things that the player state can do, such as disabling dragging for the other player and moving a card to the gameboard from their hand. The difference here lies in the choosing which card to play to which location on the gameboard. This will initially be done using a search algorithm called minmax that is based on the decision to minimize the possible loss for the worst case. In other words, it runs on making the AI get the maximum score by comparing the best and worst case scenarios when selecting a move. Once the AI selects and finishes their move, the game will move back to the Comparison stage and will continue to loop.

Game Over: 

The game over state is the simplest state of the game. The only thing it does is evaluate if the game board is filled with all 9 cards and if the game board isn’t filled, then continue to the appropriate player/AI state. When all 9 cards are on the game board this state will act as the base case for the recursion that I have implemented in these states, giving the game a way to stop. When the base case is met, the user interface will flash one of four messages on the screen: Player 1 Wins!, Player 2 Wins!, AI Wins!, Tie!. Then the game will end and the player will get a prompt if they would like to play again.

Where I am Currently and My Plan To Move Forward

I have finished the Player Turn state and have it working to the point that each player can play a card then have to wait for the other to play a card before they can play another one. Currently I am implementing the comparison function inside of the Comparison state, although this process is not logically difficult, it is very difficult to keep track of all of the variables that I have floating around inside of this process. This is a slow process as I have to constantly stop and test every little detail as I go to make sure nothing breaks along the way.

Once the Comparison state is complete I will be moving on to the Game over state to get a working local multiplayer game. With that state complete I will be able to add the user interface elements such as the score boards in the corners of the screen, and the game will be completely playable. Once I have a playable game, then I will have to implement the AI opponent. I hope to have the initial AI implemented by next Saturday, but who knows what complications I could run into at this point.


Forward March! Entering the Final 6 Weeks.

FINALLY! After somewhere around two weeks of consistent suffering due to the issues I have been having with Unity, I am able to say that I have conquered the beast and I can finally make forward progress.

The issue I was having was related to me trying to make my scripts interact with each other, mainly changing and checking variables in scripts. When done wrong, my code would infinitely error on me, saying that an object was not set to a single instance of a variable. Considering that I was working with two scripts that were each linked to 9 and 5 objects respectively, I figured that the code I used to call the script was not differentiating from the different instances that I had. It was that thought that pushed me to the limit attempting to fix the problem, and in order to explain how I fixed it, I would like to explain a bit about a concept that I learned about in Unity.

Components: In the Unity interface, a user has the ability to create objects of different types, shapes, and sizes. These objects do not have a lot of functionality at their original creation. This gives the developer complete freedom when giving certain objects specific properties. From applying physics to the infinite imagination that comes with the creation of your own scripts, components are the backbone of functionality in the Unity framework. When working with your own scripts, you are able to call upon any of these components that are attached to individual objects.

This is where the coding concepts began to lose me. In order to pull information from an objects component, a developer will need to first locate the object that the component is attached to and save a reference to it locally in that script. Once the object is locally saved, you must then reference the specific component that is holding the information that you need in your current code. After saving a reference to the specific component, all public variables of that component will be accessible in that local version of the script. A variable can dynamically change across scripts. Using this method will allow multiple scripts to make use of the same variable, giving you flexibility when writing new scripts by being able to reuse old methods and variables.

What I learned: In hindsight this concept makes complete sense to me, and it took me a ton of trial and error, countless hours reading materials on Unity, and watching tutorials to understand where the problem lay in my logic. I have lost a lot of ground due to this and I anticipate that my scope will need to be redefined when I have the chance. Although I may have gotten more familiar with the Unity Interface, I still have a long way to go if I am going to have a working game by mid-December. Only six weeks left for me to work on the project, I have to make every second count now!

Update on Progress: Switching Gears to Research

First off I would like to say that I have not had much time to spend working on my projects due to the number of tests and papers that I have had to complete in the past week. However, that is all behind me now and I can start moving forward once again!

I have been attempting to recreate some of my code in this past week, and because of that, I have not actually made much progress with my project. What has happened, however, is that I have begun to understand a bit more about Unity.

As I mentioned in my last post I was having a lot of trouble trying to get cards to “snap” to a location on the gameboard, and that problem still persists to this day. Snapping is name I have given to the action of a card being placed on the gameboard to one of the 9 possible locations. Though I believed to understand how this process would work, I was completely mistaken. Therefore, before I do anything else this week I will be revisiting the books to understand more about Unity, so I can move forward in a more efficient manner rather than continue to make rookie mistakes.

In order to learn more I will be doing some reading from PDF’s that I have received from Packt Publishing. Some months back, there was a deal based on Unity that gave me some awesome titles that have helped tremendously in this attempt to create a game in unity. These titles can be found on Packt’s website and the specific ones I am using are: Unity 5.X Cookbook, and Unity 5.X by Example.

With these resources, as well as looking to online I will be attempting to understand the following aspects of Unity:

  • How to effectively use scripting to make multiple instances of the same objects behave differently
  • How Pre-Fabs work
  • How to use and change variables from one script in another script
  • How objects interact with the game world
  • How to effectively structure scripts and allow them to interact
  • General good practices when using the Unity system

I cannot keep getting held back like this on smaller issues. In order to complete this project in a timely manner, I need to spend some time exploring resources to increase my knowledge base as much as possible. Basically everything about this project is burning around me, and I need to find some way to put it out.


Until next time!

Card Movement: 1 Step Forward and 2 Steps Back

Well the good news is amazing, my initial dive into coding in Unity has proven fruitful! I have been able to click a card on my screen and drag it anywhere around the gameboard! To add to that functionality I was able to make the card remain in its new location when it was dropped, which was a lot simpler than I thought it would originally be.

This simple movement of the cards is handled in Unity by two built in functions in a C# script:

OnMouseDrag () and OnMouseUpAsButton()

These two functions sense when the mouse has been clicked down on the card and when the card has been released respectively. Focusing on OnMouseDrag, I run two lines of code to make sure that the card object stays with the mouse so long as the player keeps the mouse pressed while dragging it across the screen. The first line is used to grab the coordinates of the mouse as a reference, and the second line takes the mouse coordinates and changes the cards coordinates to match the cards every single frame. These two lines are shown below:

Vector 3 WhereIsMouse = new Vector3 (Input.mousePosition.x, Input.mousePosition.y, distanceFromCamera);

Vector3 objectPosition = Camera.main.ScreenToWorldPoint(WhereIsMouse);

The coordinate values in unity are handled on a 3D plane, with x, y, and z axes. The unity system handles these coordinates using the Vector3 data type, which holds each of these axes as a value in a 3 element list, (x, y, z). By using two of these Vector3 objects I am able to both track where the mouse is in comparison to the camera, and change the coordinates of the object being dragged.

This is my one step forward, and as I promised in the title, I have had some problems that have set me back.

As long as something works, something else has to break. I was ecstatic when I was able to get the card movement to work, so with adrenaline coursing through my veins, I set off to achieve bigger and better things. I Thought “The card moves, now its time to make it snap to a location on the board!” This went well at first, as I was able to use another built in function in unity to detect the collision of a card above a board location (there will be more on that function in my next post). However, when I attempted to make this code work for all 9 board locations, instead of just one, I ran into a multitude of complications.

Everything from the dragging suddenly not working, to the cards in my game bugging out and flying off into space began to happen to my program. Most of these issues I couldn’t explain or even reproduce for others to help me with. So here I am, staring at a bunch of broken code with one thought in mind, “I have to restart”. I have taken this initial dive, and learned a lot in the process. Now its time to put that knowledge to the test, go a little behind schedule, and reproduce a better set of scripts that better suit my needs. Next goal on my list, get all five cards to snap to different locations on the board without my code breaking!

Next time I will be exploring more in depth what I mean by cards “snapping” to the board, as well as showing snippets of my code to explain where I went wrong in my previous iteration. Until next time.


Forward Progression: Hurdles and Achievements.

So for starters, I have made some amazing progress since I have opened Unity and began to work in its environment, all of which will be elaborated on in due time. For this post I will be focusing on what I have achieved thus far: objects creation in the unity environment.


My Game board with 5 card objects placed on it.

The picture above, shows the fruit of my labor this past week. I have succeeded in the creation of two major components of my game: 5 card objects that will be moved around the board, and the game board that they will be moving around on.

At the moment the cards are just static objects with no scripts attached to them. For each of these objects I created a 3D cube and attached an image to it**. In order to complete this process one must import an image into their unity project, and change it to a sprite. Once this new sprite has been created, it can be attached to any object in the scene by simply dragging the sprite and dropping it on the object.

I had an issue with this process originally, as I was confused on how images were attached to Unity objects. So when the interface was not allowing me to drop my .png or .jpeg image on my card object, I became frustrated. A couple hours later, after scouring the internet for answers and nearly giving up to look for another solution all together, I finally found the problem, each image that is imported into the Unity environment defaults to be a texture. Textures cannot be attached to Unity objects in the manner that I was attempting. That is where I learned how to change the image to a sprite. Since changing this one setting, everything has been golden on this front, and all of my base objects are in place.

So what I’ve learned about creating objects in unity with images is that:

  • Create a 3D object
  • Upload an image into the project directory
  • In the unity interface, change the Texture type of the image from “Texture” to “Sprite (2D and UI)”
  • In the unity interface, click and drag the image onto the desired object (either in the Scene window, or the Hierarchy window)
    • Alternatively, each object has a section in their respective inspector windows that is called the Sprite Renderer. In this section of the inpsector window, you can drag the image over the text box named Sprite to get the same result as the previous method.
  • Congratulations, you have created an object with a picture.

In short, this has been a train wreck of a time that has resulted in a lot of fruitful knowledge of the Unity environment.

In my next post I will be exploring my initial dive into the Unity Coding Environment, and what I have achieved on that front. Until next time.

**As a disclaimer, the images that I am currently using are from the original Triple Triad game that is copyrighted by Squaresoft (Square Enix), and will only be used for testing purposes. In the future I will be using custom made images.  

Well, this is Awkward: Past Mistakes and Plans to Move Forward

It is with a heavy heart that I admit to a recent fault of mine. As of today it has been 22 days since my last post on this blog. For a project that requires constant documentation, this is really, really, bad. Many aspects of my personal and academic life have been getting in the way, and to be completely honest, I had completely forgotten to write any posts during this time. That is in the past! I have now set up reminders, on everything that I can to make sure that I write posts regarding the material that I work on! With no more excuses on missing blog posts, I will be planning on sending in at least 2 posts per week that will keep up with the topic that I am working on for that week.

Now that I’ve gotten that off my chest, its time to get right back into business! I have recently created a rough design document that serves as an overview of the project. Inside of this document I explain my purpose of choosing this project, what I expect to learn from it, a rough schedule of how I will be working on the project for the remainder of the semester, and the plans I have for the data models I will be following during the implementation! The best part of this document, however, is that it was completely coded in LaTeX. LaTeX has given me the creative freedom that Microsoft Word just couldn’t give me. I am able to tell the paper to do exactly what I want it to do, format it any way I like, and create these documents all for the low price of FREE. LaTeX aside, my design document is linked below for those who would like to take a look at it. This document is very rough, and shall be expanded on continually in the future. You can read my design document here, and if you have any feedback please let me know!


Digging Deeper: The Data Behind the Scene

TL;DR = Thinking on a much simpler level, I have decided to make use of lists to store my data rather than going over the top with databases, matrices, and dictionaries.

Over the past week I have been creating presentations that have been given to a small group of my peers in order to receive feedback on my Triple Triad project. The comments from the presentations, as well as other conversations with peers and professors alike, have opened my mind to a new way that I could approach creating my project. In other words, I have been overthinking how I would implement the program with the use of the Unity system, and I have decided to take a step back to focus on simplicity rather than complexity.

This affects my project in many ways. First, focusing on a simpler approach allows me to implement my game board using a 9 element list rather than using a 3 element list, where each element of that list is a 3 element list ( a list of lists or a 3×3 matrix). Using the 9 element list allows for a speed boost in search time when trying to keep track of what cards are on the game board as I will only have to search through 9 elements at most. Applying more layers, such as a list of lists, adds more time to the search since it has to go through multiple layers to get to the data that I need. However, even though speeding up the program is nice, the best part about having the simpler approach is that it allows for a simpler implementation of the game. Since there are distinct boundaries on my small 9 slot game board, I do not need to fear hard coding the transitions and comparisons since the game is so small. If the game were much larger, with more possibilities, then hard coding would eventually get out of hand and many algorithms would need to be put in place to handle the sheer amount of possibilities.

Second, the card objects themselves can have their values stored in lists to be applied later. In this case I will be using a 6 element list that will hold the following values for each card: Card Name, North Value, South Value, East Value, West Value, and Ownership Value. The card name will be a string variable that will be used as an identifier when moving the card object around the game screen (from the hand to the board). Each of the Cardinal Values will be integers between 1 and 9, and will denote that cards power in that cardinal direction. The ownership variable will be a string that will denote which player is currently in ownership of the card (ex. the string “player 1” will mean that player 1 owns the card, while “player 2” means player 2 owns the card).

This is only the start of a much more overarching data model. This surprises me to no end that I can theoretically complete this project using such simple data structures and hard coding most of the relationships. At this point, I have to say that I am ecstatic to begin work on this project… after a lot more planning!