This week this project had to take a back seat to other projects with sooner deadlines, and I only accomplished part of what I had originally planned.

This week, I finished implementing Redis for caching and Amazon’s S3 for long-term and cross-instance storage. In addition, I added a administration page with a login page to allow developers to have a simple centralised control system for their server.

---

Redis and S3

This week I spend the majority of my time working on the Redis and S3 code to cache data locally and store data across instances in the long term. During this process I again encountered race conditions, which slowed development. Both my Redis and S3 functions were returning undefined objects instead of the data they were supposed to fetch.

I solved this issue by sourcing and implementing an alternative library for Redis: Async-Redis. This library promisifies the functionality of the standard Redis library, such that it is usable with async/await.

With this sorted, I looked into different libraries to perform the same promisification of the AWS-SDK. After some time of looking, I was not able to find a library to do this for me, so I experimented with restructuring my code. Shortly into restructuring, I discovered that the AWS-SDK has promise methods for many of its functions, which allowed me to neatly solve the race condition issue with S3.

Admin Page

While working on the Redis and S3 code, I found myself wishing for a simpler way to run my testing code. I slowly came to the conclusion that a simple Web page served by the server might be the best option to fill that need.

This page setup was relatively quick and easy to implement, as I was able to repurpose work from other projects. I added a page to ask for login details, and check those details on the server side before sending a response to the browser. When polished, this will act as an administrative tool for developers to manage the server from a user-interface instead of a command line.

Until Submission

The plan for the next week includes finishing the GitHub implementation, adding the Discord API calls, then writing the C++ calls to contact this server from the Feedback Panel. Beyond this point, I plan to move on to polishing the Feedback Panel with some textures and animations, and documenting the installation procedures for both the server and the panel. Ideally, I will end this next week with all necessary features implemented and polished.

Industry Project: Server

For the remaining time until submission, I will be undertaking the same tasks as last week, as I was not able to see them to completion within the week.

This last week I spent working on the back-end server as described in last week’s update. This mostly went well, but is taking longer than expected.

---

What made it in?

For next week, I am planning to build the back-end server and test the GitHub and Discord API calls through it, write and test calls to the back-end server in C++, and link those calls to the Feedback Panel in the Unreal Engine.

Industry Project: Rework

So far of my previous list, GitHub API through Octokit REST has been mostly implemented (as seen in the demonstration video above). All of the necessary API calls have been written and are in the process of being logically structured and tested. While writing and testing these calls, it became clear that a setup command and a local data cache would become necessary very quickly. To that end, I have begun implementing Redis as a caching service, and writing a server endpoint to set up a project board with minimal developer work.

What’s not in?

From the above quote, Discord’s API calls have not yet been implemented but have begun to be investigated, and the C++ code necessary to link the Unreal Feedback Panel to the back-end server has not yet been written either.

Plan for next week

The plan for the next week includes finishing the GitHub implementation, adding the Discord API calls, then writing the C++ calls to contact this server from the Feedback Panel. Beyond this point, I plan to move on to polishing the Feedback Panel with some textures and animations, and documenting the installation procedures for both the server and the panel. Ideally, I will end this next week with all necessary features implemented and polished.

As the chart above shows, this week I worked for less hours than planned but achieved significantly less progress than intended. This lack of progress is due to unforeseen issues with making API calls in C++, and the amount of time spent tackling the bug of screenshots not displaying.

The images below show the final state of the project at the end of these two weeks: all proposed user interface elements have been successfully implemented, and a new solution for managing the API calls has been designed.

• 

• 

---

Sentiment Radio-Buttons

Radio Buttons proved to be more complex than I had originally anticipated, as they are not a default UI feature within the Unreal Engine. So instead, I constructed my own radio-buttons using check boxes and a surprising amount of blueprinting. The final implementation below will report the user’s sentiment in a range of -2 to 2, as depicted by emotive faces in the mock-up.

• 

• 

• 

Getting the Screenshot Working

This was to be the first of two unfortunate hurdles: the screenshot wasn’t appearing on the UI but was demonstrably updating correctly on the debugging block in the level. I spent a significant amount of time scouring the internet for answers and experimenting with different variations on the blueprints, before finally arriving at the solution.

• 

• 

The solution was something that I had experimented with as part of the problem solving process, but hadn’t seen due to inexperience with the Unreal Engine: the UI can’t render a render texture, but it can render a UI material. With that revelation, it became clear that the rest of my blueprint was working!

C++ and PC Info

The last element of my proposed UI design was retrieving and optionally sending some PC info to help developers. To do this, I started down the path of learning C++ to write my own blueprint functions.

Thankfully, C++ has some built-in functions for retrieving PC details, so my first foray into C++ was mostly learning from examples.

Thus, as seen below, my proposed UI was all implemented and functioning as intended.

C++ and API Research

The last part of my week was to explore my chosen API’s and begin creating API calls in C++ to be executed from inside the game. This quickly ground to a halt as it became clear that making these API calls wouldn’t take the form that I was familiar with. In other projects I have primarily used URL based calls, like those of the YouTube API. The GitHub and Imgur APIs are both written primarily for use with CURL which I am not familiar with using in code.

So, I turned to finding a C++ library which could be used to make these calls more easily. While looking for GitHub libraries I discovered that there were many language options, but there was not a library for C++. Instead, I began to look for a CURL library for C++ and found curlPP which seemed to be what I needed.

I downloaded and attempted to install curlPP by bringing it’s code into the source files of my Unreal project, and found that the Unreal Engine didn’t recognise them. After some searching online, I found a few answer posts detailing ways to include libraries into Unreal projects. While following these instructions, I found myself continually hitting build errors in the project. I attempted to separately build the curlPP files to include them, on the recommendation of a different answer post, to no avail.

Finally, I attempted to find examples of creating HTTP header requests from the ground up in C++. Many of these examples suggested using a library first, but I found some which had example code written with only the standard C++ libraries. While attempting to implement some of their code I found that I continued to run into build errors, leading to the realisation that writing this all in C++ manually would be time-inefficient and continue to hold back development.

Rework: Server

After discussing the C++ issues with a friend, I came to the conclusion that a slight rework of my original idea would cut down on the problems I was facing and speed up development. Originally, it was intended for the game to GET and POST to the different API’s directly to cut-down on developer setup time.

The approach I now intend to take is to create a back-end web-server written in JavaScript which will handle the various API calls, and cut down the number of calls made directly from the game client. This change means that instead of making six or more unique API calls in C++, I will only be writing two: one to post feedback information to the server, and one to post the image to the server.

I believe that this redesign will reduce the remaining time on the API calls by approximately three hours due to my familiarity with JavaScript and the availability of API libraries.

The above diagram demonstrates the intended flow of the tool from the user through the game and server to the various APIs. The game will send the feedback and the screenshot to the server, where the screenshot will be saved in an Amazon S3 Bucket for later reference. This screenshot’s URL will then be retrieved and passed to the feedback section.

While the screenshot uploads, the server will simultaneously request a project board of the submitted feedback type and retrieve a summary card from that board. The player’s feedback will then be posted as a new card to that board with the screenshot URL, and the summary card will be updated to include the new feedback.

Finally, the server will perform some analysis on the feedback data to find hot-spots in levels where players have been sending reports most and the average sentiment of reports in that area. The server will then post that analysis with the summary information to a discord server of the developer’s choosing at regular intervals.

This rework has a few benefits. Firstly, many APIs have official or third-party libraries for making use of the API significantly simpler. This will speed up development by cutting down the amount of work required to implement and test each call. Secondly, this removes the security risk of publishing work with API keys to the public as the remote server will have these keys instead. Finally, this reduces processing and networking load done in the game client. Originally, it was intended to perform some analysis and generate summaries from within the game client before posting, where now the server will bear this load.

For Next Week

For next week, I am planning to build the back-end server and test the GitHub and Discord API calls through it, write and test calls to the back-end server in C++, and link those calls to the Feedback Panel in the Unreal Engine.

Unfortunately, due to other work the week prior, this project had to be started in what was intended to be the second week of development and is a catch-up week. Though I didn’t completely catch up this week, I managed to make up about one third of the last week’s time. For more detail, see the project board.

• 

This gif demonstrates the state of the UI elements of the project at the end of the week. So far, the UI is opening and closing,

---

Learning Unreal

The beginning steps of working on my industry project is starting to learn how to interact with the Unreal Engine. I decided to start my journey into Unreal by exploring it’s built-in tutorial system through the lens of unity, which guided me through all the elements of the editor.

Building the Prototype UI

The next step for the week was beginning the prototyping process for the UI elements of the project, as per my initial mock-ups. This process expanded upon my rough understanding of the Unreal Engine’s Blueprints, and by the end of the process I felt very comfortable programming visually.

• 

• 

• 

• 

Taking the Screenshot

Taking the screenshot felt like the perfect next step as conceptually it was the next most complex part of the design. This proved itself quickly true, as I encountered difficulties in trying to keep frame overhead low, mismatched type errors, and determining which type of camera to use.

I discovered that the SceneCapture2D camera was the camera which would serve my purpose best, and that it was not able to be spawned and destroyed in code. This was solved by creating a blueprint of the object, finding it by class, then manually capturing the scene.

Finally, when I had reworked my screenshot functions, I tested it by creating a material from the render texture and applying it to a cube in the scene demonstrating that the rendertexture is only updated when the submit feedback panel is opened.