TCP and Threading

NOTE: I completed this work the week of October 28 - November 1. But I got behind on my blog posts so I just split up my previous work by weeks.

As mentioned back in the blog post about Database Design ( http://benvdevelopment.blogspot.com/2013/10/database-design.html ) Parse can only respond to requests and cannot directly send data to a player. This makes it difficult to build a responsive game by using Parse alone.

The solution is to have the clients take to each other through a peer to peer connection. This way when a player plays a card or ends their turn they can inform their opponent that they need to ask the server what has changed. This ensures that the game is responsive without removing the security of having a server validate all actions taken by players.

Unfortunately, in Unity the networking is not built to handle peer to peer networking so I had to write my own code using the C# TcpListener class and sockets. In order, for this networking code to work effectively I also had to make it threaded - so I created a thread utility heavily inspired by the Loom thread utility documented http://unitygems.com/threads/ .

Card Collection Management

NOTE: I completed this work the week of October 21 - October 25. But I got behind on my blog posts so I just split up my previous work by weeks.

Since our project is a collectible card game one of the most important features of the game, other than the core game play itself is the ability for players to see and manage their card collection. This is where the card collection screen show below comes into play.

The card collection screen - shows all cards that are in the game that can be put into a deck. In addition, cards which the player owns has a number underneath them signaling how many of that card the player owns.

Cards are also split into pages of a maximum of six cards that can be navigated through. In a finished product we would want to be able to search and filter the collection but that is not likely to get done during this semester.

Also, on the right side of the collection is a deck view control. Which is a reusable control that shows the different decks the player has built. This control will be the topic of its own post later as it is currently not entirely finished.

Each card is represented in a consistent way as shown in the image below:

Friend List

NOTE: I completed this work the week of October 14 - October 18. But I got behind on my blog posts so I just split up my previous work by weeks.

Like most online games, we want to make our game easy to play with friends. To allow this we have a friend list integrated into the game. Once users are friends they can chat or play matches together. All of this is managed by the social panel in the game.

The social panel, shown above, has your display name at the top. Next is a list of all of the users in your friends list. If the user is online they have a green status icon and when clicked allows the user to invite them to a match, chat with them, or remove them from their friend's list.

The add friend button at the bottom allows users to add new friends by bring up the add friend dialog.

The add friend dialog can handle a variety of problems that can occur when trying to add a friend. Some of these include trying to add yourself as a friend, trying to add a user that doesn't exist, or trying to add an existing friend.

Once a user has added a friend they have to wait that user to respond to their request. This helps reduce online harassment. While the user waits for a response they see the following entry in their friends list.

The user who received the request see a different entry in their friends list that allows the user to either accept the request, decline the request, or report the user.

Database Design

NOTE: I completed this work the week of October 7 - October 11. But I got behind on my blog posts so I just split up my previous work by weeks.

Since our project is an online game with some persistent elements such as card collections and decks we needed to come up with a database design for the Parse server to use.

Our requirements were to store information on every user such as what users they were friends with, what users they wanted to block, what cards they owned, and what decks they had constructed. Additionally, we choose to store information on each card and ability in the database to reduce cheating. Since the card data is not stored on the local client it cannot be altered to give a player an advantage. These requirements led to the following design for information that must always be kept on the server:

However, not all of the information used by the game needs to be stored by the server all the time. The biggest example of this is the data used while a single match of the game is being played. Once the match is over the data is no longer needed. For that data we have the following design:

Lastly, some information doesn't need to be stored at all but still needs to be transmitted between players. Since we choose to use Parse as our server it doesn't make sense to use the server to send data between players so we needed to make separate networking code that would communicate through TCP/IP. This networking code will be covered in a different blog post.

Parse / NGUI Upgrade

NOTE: I completed this work the week of September 30 - October 4. But I got behind on my blog posts so I just split up my previous work by weeks.

As mentioned in previous post that shortly after I finished writing code to communicate to Parse from within Unity, Parse released an official plugin for Unity. In addition, NGUI the user interface plugin we were using got a major upgrade so we decided to quickly redo our work using the new version of NGUI and the official Parse plugin. This process didn't take very long due to being able to mitigate most of the code / user interface created before very easily.

The Unity Parse plugin quickly resulted in a huge productively boost for a number of reasons. Including:

1. Support for all Parse Features = The code I wrote to communicate with Parse only supported the small subset of the features of Parse that we needed and I was adding to it as needed. The official Parse plugin gave us support for every feature of Parse right away.
   
2. Built-In JSON Support = Since Parse uses JSON for requests and responses - my own code had to have a way of communicating via JSON. The code I wrote was passable - supporting most features of JSON but the official Parse plugin handles all the JSON stuff out of sight making our code much more readable.
   
3. Documentation = Lastly, the official Parse Plugin has very good documentation.

The NGUI plugin upgrade also gave plenty of benefits:

1. Less Clipping Issues = The version of NGUI we were using had some issues with text clipping through textures and required manually adjusting Z values in order to try to find a spot where clipping would not occur.
   
2. Quicker User Interface Creation = With the clipping issues solved user interfaces could be created more quickly and with greater confidence that they would look good in the game. In addition, the upgraded NGUI plugin provided an easier way of sending events from user interface elements to our code. Before the upgrade any code that wanted to received a user interface event would have to have a public method with the name of the event. For example to receive a button click, our code would have to have a OnClick method in the code. After the upgrade, the button could invoke the method of our choosing without any additional code.

User Login

As with any online game - our players have to log in into order to be able to play the game. This was my task - since I am handling the server / graphics.

Thankfully, since we are using Parse most of the server security work is handled for us. So I just had to write code to talk to Parse from within Unity. Unfortunately, shortly after I finished writing all the code to talk to Parse - Parse.com released an official Unity plugin. We will likely be switching to using the official plugin instead of my code when I have time to make the switch.

Once the code to talk to parse was done - we had to decide how users should log in to the game. We considered three options:

Display Name / Password

The first option discussed was using Display Name / Password for log in, but there are too many problems with this approach. For one, anyone you play against online would immediately know your display name - one part of your log in. Also, we may want to allow display names to change if only so that we could force renames on offensive display names.

Account Name / Password

The second option discussed was using Account Name / Password for log in, where Account Name was something different from Display Names. But the problem with this is that since Account Name has to be unique for each player - someone could use registration process to discover what Account Names exist. Also, account names can be difficult for players to remember - and so we would need a method of retrieving account names.

Email / Password

The third option discussed was using Email / Password for log in. We choose to go with this route for a variety of reasons. The first reason, is that this approach doesn't have any of the downsides of the above two options and automatically gives us a way of forcing email verification. Email verification can be automatically handled by Parse and gives us some real benefits such as making it harder for us to be targeted by bots as only accounts with a verified email can do anything and we could just ban that account. Additionally, having a verified email allows us to send password resets to users.

Result

After we decided on a log in method I created the log in and related user interface elements and wrote the code to talk to parse to perform log in logic. As stated before, thankfully Parse has many useful user management methods which handles password requests, email verification, and security. This allowed the code written to be fairly simple HTTP requests to Parse.

Online Collectible Card Game

Brief Details:

Project Title = Online Collectible Card Game

Team Members = Ben Versaw, Travis Anderson

Semester = Fall 2013

Introduction:

Our semester project is a collectible card game that can be played against people online. The technology we are going to be using is Unity3D for the client side development and Parse as our server. The core idea behind the project is to allow users to buy / win cards that can be used to collect decks that can be used to play against other players.

To play a game players take turns drawing cards from their deck and playing cards from their hand to the ‘battlefield’. Each card on the battlefield can have special effects that active on various triggers, and take / do damage to other cards and the opposing player. The first player to reduce the health of the other player below one wins.

The goal is that we will have simple rules that can be gradually built on to perform complicated strategies. This benefits both us as developers, by making the project easier to develop and manage, and to the players by making the game easier to learn but hard to master.