An Open Source RollR and a Wary Tale of Two Links

If you don’t know, Rollis the web app prototype I have been working on for several months now as a result of a university assignment. You can visit it here.

Feel free to play with the site, if you have any comments please feel free to contact me via twitter.

The code explanation and data flow will follow soon however first I’m about to craft you a tale of how I messed up real bad.

I have been developing this website over at my dev.- sub-domain and everything was going swimmingly. Then I decided to port it over to my root domain, this is when it went to crap town….

I did not extensively test the migrated version; this was my crux. This was the link I submitted – it did not work. To cap it all off I didn’t notice until I got the lower than expected mark.

I contacted my lecturer and he said, and I quote:

it is too late

So that’s all nice. Still got an A but its a personal thing I guess… Anyway moral of the story is check your god damn code works especially if you’ve moved it about.

Anyway onto the code stuff!

This is directly taken from my written documentation.

RollR is a lightweight website application to provide a companion to table top games when you may not be in the same room or require services you don’t have physically. This is aimed at people who are familiar with a room based concept and are comfortable using online features such as share boxes and messaging clients. The intended audience is also people that enjoy playing table top or roll playing games. The general age range is around 16-35 of those I would expect to use this website, however due to the wide community that enjoy these games there is certainly no limit on who can and cannot use the website.

The website can be seen live here http://dev.colinroitt.uk/rollr/

Feature list:

  • Create a room
    • A user can log onto the website and select the create room option. This allows them to set up a chat room with a room name and password (if desired). They can then distribute this information to their friends and have them join then in their chat room.
  • Join a room
    • A user can log onto the join room option of the website. This allows them to input a previously existing room name and password (if required). This will launch them into the chat room with their friends that are already in the room.
  • Set your personal nickname in a room
    • In chat room a user has a name that shows against their messages in the chat log. Upon selection of the set nickname button an input box comes up to request their new name. The user may select whatever they choose to put into the chat room. The user is also asked to select a nick name when they first join a room.
  • Roll a room’s dice
    • A live dice will appear on screen and the following buttons will be selectable bellow it:
      • D4
      • D6
      • D8
      • D10
      • D12
      • D20
      • D100
    • Upon selection of each button it will roll the respective dice and show the result of the roll to them and everyone else in the chat room. It will also add it to their personal die log. This is a local list of all the die you have rolled and the outcome of said roll.
  • Send a message to a room
    • Within each chat room a chat window is centre. With the pre-specified nickname the user can enter send a message to a group chat window which is visible to everyone throughout the chat room and will also show to users who join the room at any time. Any user can send a message to this chat log.
  • Share an image link with a room
    • Users can submit a link (as long as it is a picture URL) to be displayed and act as a hot link aside the chat log and die area. This means that they are able to share things such as a map or a list. It is simple for a user to upload a document to an image sharing site such as Imgur and paste the link within the website.

Technical descriptions

Ensuring new rooms names are unique

In the head of the website the function funcProcess() is called on body load. This performs a simple AJAX operation.

Above this we set up a xml HTTP Request Object and assigned it to XMLHttp.

If the object is ready it will get the name of the rom form ‘nameInput’ and submit an HTML GET request to checkValidRoomName.php. If it’s not ready and there is not change to check we simply call the same function again after 1 second (line 40).

Figure 1 validateName.js

We then echo back the XML prerequisites to the file so it has the correct structure. We send out query off to the function runFetchQuery()

Figure 2 checkValidRoomName.php

After connecting to the database, we check if the connection is made otherwise issue an error.

Figure 3 checkValidRoomName.php

We run the query we passed in, extract the results as an array and return the result

Figure 4 checkValidRoomName.php

Returning to the main body of code we check if it returned a result like the given room name. If so we return not valid otherwise we return the delimiter 0.

Figure 5 checkValidRoomName.php

Once the response is received the HandleServerResponse() function is called and after checking the response object is read we handle the result.

We extract the first child from the XML in the response.

If it’s a 0 we assume everything is fine and we enable the button otherwise we state, the name is not valid as an error message and we disable the button.

If we don’t get a ready response from the server, we issue an error message.

Figure 6 validateName.js

Create room

This is a process with a few simple steps

We first determine if the user has come from the make page or the join page as we need to do different things in each instance.

Figure 7 playroom.php

We then call the genRoomId() function and get the date. This is inserted into an insert query string which we will use later.

Figure 8 playroom.php

We create each file log for the three main functionalities in write mode (this will overwrite a file there if it already exists).

Figure 9 playroom.php

Finally, we run the insert query function which returns a Boolean result on a successful command. If it’s successful we will render the rest of the page otherwise we will not and later an error message will be shown.

Figure 10 playroom.php

The code in this function is much the same as the fetch query code excluding the bottom half. If the query is run successfully it sets response to rue otherwise its false and prints an error. $response is returned at the bottom of this function.

Figure 11 playroom.php

Join room

We first determine if the user has come from the make page or the join page as we need to do different things in each instance.

Figure 12 playroom.php

If we did not come from the create page we run this code.

We set up the fetch query string and run the query (with the same code as in runFetchQuery(), from figure 3 and figure 4).

Figure 13 playroom.php

If the result turns back nothing we issue an error and stop the rendering of the rest of the page.

Figure 14 playroom.php

If the result turns back a room, we check the password hash matches and based on this result we continue or issue an error.

If we continue we echo some JavaScript to set the roomId variable to the correct roomId for later.

Figure 15 playroom.php

Send message

When the send button is clicked the function send() is called.

In much the same way as the AJAX before a request is sent off to a function in sendMsg.php. This appends the username and the message body to the log file as follows.

Figure 16 sendMsg.php

Receive message

Every one second this log is updated in the same way the AJAX worked for the room name validation. A request is sent to get the contents of the chat log and the chat is updated.

Roll/get dice

This uses the same method as above however the live dice log is a single digit that is overwritten when a new die is thrown. This updates every second along with the chat log.

Set/get image

This method works the same way as the dice log, however a user submits a single image link.

 

Link Dump:

My Twitter
The live site
The Git Repo

Leave a Reply

Your email address will not be published. Required fields are marked *