The main focus of this project was to look at appropriate solutions to online applications that have some sort of user-based systems, whether as a multiplayer game or as an online service for users.
We looked at many approaches and solutions to different problems in the area before deciding upon what application we were going to design and create. Before starting the project we had a test that consisted of twenty user tests created by the lecturer. The test consisted of attempting to get all of the tests to pass without changing anything within the test files. This was very easy to do however I could not get the last 3 to pass as the test was looking for a specific way of checking for a certain key (i.e e.keycode over e.which) as such I did not know the number associated with the e.keycode. The tests were also set up in a way that did not allow for the next test to be carried out if the previous failed so the final two may have been correct.
Moving on to the project, I decided I would build a 2D top-down shooter with multiplayer functionality using Node.js and was uncertain of what service I would use to host the database and server. I was looking forward to this as I had not attempted any multiplayer or otherwise co-operative games before that relied upon online functionality. At first, I decided to have quite a big scope (with the bigger goals being a stretch goal) and set up all of the planning and time management details on a Trello board. I also used version control to ensure backups to the source code if anything went wrong during a work session.
I started by creating some simple shooter functionality that allowed for two people (albeit locally) to play together, with deaths, lives and points. I then focused on getting a login system in place so the (eventual) server would know who is scoring x amount of points.
After this was in place, I looked into setting up a database, as I had never done this before I searched Youtube for research purposes and found out about MongoDB. This looked very promising and easy to use so I attempted to set up a database through mLab. After importing the necessary files through console into my project folder this worked great and with some tweaks to the code allowed for database access from any computer.
I then added some chat and scoreboard functionality to the game. The chat functionality allowed for users to use a general chat to everyone on the server as well as direct message a particular user although they would have to know their username. I did not have time to add a friends list feature although this would likely have been quite simple using the database to store the friends and clicking on a friend in the list would automatically fill out the necessary information to allow the user to message them (i.e. @RyanWildish: (message here)).
The scoreboard functionality checked the players score against their best stored in the database, on death and on closing the app. This allowed for me to update the users best score if they had a better one. This was quite tricky to set up as the MongoDB API was hard to follow and was made even harder by my lack of scrolling down the page to the examples at the bottom.
As this had been running through a local host still I started to look into hosting a server that would allow for true online multiplayer functionality. I found some different services that provided what I needed but the first free one that I found was Heroku. Setting up the server was very easy and intuitive with this service and even allowed me to update the server everytime I committed to my GitHub repository, which was a great feature. After setting up the server the online multiplayer worked very well and didn’t seem to have much lag/ping.
As the end of the project neared, I started to look at profiling and extra features that could be added. With the profiling, I was only able to locally profile as I was unable to get an online-profiler addon to work as it was “out of date”. I found a few parts of the code that were taking up a little to much resource usage and tidied them up a bit to reduce any small stress that may be applied to any machines running the application.
I then decided to add a secondary fire to the game that allowed players to shoot three bullets at once in three directions (forward, forward-left, forward-right). This added some much needed extra functionality to the game. After introducing this, however, it became apparent that the code would allow users to spam the primary fire faster than the fire rate should allow (once every half second, instead of firing 60 a second). I couldn’t find what the actual problem was due to my lack of multiplayer knowledge but it was likely something to do with the server side not registering that the player had not clicked the left mouse button after an initial click and hold. I sorted this out with setting a boolean to false on the server side after a bullet was fired. This, however, meant that the user would have to click the mouse each time they want to shoot, instead of holding and being able to shoot at the fastest allowed speed.
There was definitely a lot more functionality that I could have implemented into this application and may do in the future, however, I ran out of time to implement any other features before the hand-in of this module.
To show our understanding of what we had created and our processes used, we also had to provide some documentation of this which can be found below.