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.