Saving Game Options
UE4 provides some pre-built functionality for saving game information. The process involves extending the SaveGame object type with custom fields for the values you want to store. Once one of these objects has been created there are methods which allow for simple read / save functionality. The system saves to binary files.
To make the save process as easy as possible, I created a custom Enumeration for quality settings which maps to the default UE settings values (low, medium, high, epic). The file written to disk contains 3 int values (one for each of the quality settings--shadows, textures, and resolution), 3 float values (one for each of the volume categories), and a string (for the player's leader board name).
To load settings, the game save file is read and its values are simply piped into setters for each setting. This happens when the Main Menu is loaded.
Overall, this set-up works well, but there is one drawback: if a new setting has to be added, then several files need to be modified. New variable needs to be added to the extended GameSave object, and both the read and write functions need to be modified to be made aware of the new variable.
The load and save graphs can be seen in the images below.
Relevant Journal Entries:
Source Control Management
To get the source-control ball rolling, I set up a remote repository on BitBucket in the first week, and pushed the initial menu implementations. This repository was used as the master branch for the Proof of Concept release, with all team members pushing to branches which were merged weekly, or as needed. Myself and Ronan took responsibility for maintaining the repository and ensuring branches were merged.
BitBucket was chosen as all team members have unlimited accounts through their student registration, and this allows us to keep the repository private and add as many team members as needed. For Alpha and Beta releases we created a dedicated team account. Unfortunately, the user allocation on this account is limited and we have not been able to add lecturers. Screen shots of all commits can be found in the image gallery to the right.
Binary File Issue
All UE4 assets are saved in binary file format. At the project level this makes no difference to the normal Git workflow. However, at the file level this causes issues. Git is unable to resolve merge conflicts in binary files. If more than one person has made changes to a individual file, these changes cannot be merged. The only facility provided by Git in these circumstances is an either-or choice between the two versions. Because of this, some manual management and merging of work is still required.
Additionally, branches are rendered mostly useless. For Alpha and Beta releases, all team members pushed directly to the master branch, and access to individual files had to be carefully rationed and coordinated.
Large Repository Issue
UE4 projects have a tendency to grow in size very rapidly. Additionally, because of the exclusive use of binary files, the repository history also grows rapidly. BitBucket has a soft limit of 1GB (warnings issued) on repositories, and a hard limit of 2GB (repository functionality disabled). By the end of each release, we have hit the hard limit. Because of this, we have had to create fresh repositories for each release (later we used GitLab which has a 10GB "limit").
Source Control Training
As some of the team weren't overly-familiar with Git, myself and Ronan spent some time with the other team members and went through the basics of using git from a command line. As part of this process, we explained the concept of branching, covered all of the basic workflow commands (branching, checkouts, local and remote pushing and pulling, adds, commits, etc.)
As we're working through Git Bash, we also went over the basics of Vi which is the bundled text-editor (swapping between edit and command mode, and the only Vi command a person ever needs to know: esc :wq to save commit messages).
Since doing this, all team members have been regularly pushing to their own working branches and all seem to be very comfortable with the process.
Team members have also started using Git Bash over inferior solutions for their other projects.
Source Control Screen Shots
Alpha Texture Modifications
In the lead-up to Alpha, textures and post-processing were pushed in the direction of creating an "overcast" look for the Stage Ireland level. Unfortunately, the end result was a very washed-out, desaturated, "noir" looking level. We took to calling the game Tim Burton's All the Way Down.
Before submitting the Alpha release, I worked with Brian to restore some colour to the level's post-processing settings. I then modified the level's tree textures, replacing their grey bark and earthy leaves with exaggerated, vibrant browns and greens.
A before and after comparison can be seen in the header above.
Outside of the game proper, I also worked on several process and house-keeping tasks for the team. One of the most time-consuming and visible examples of this was the creation of presentation slides for each release. An example of these slides can be seen on the team's Alpha Page on Mahara.
I also developed the presentation format which the team used for their Proof of Concept and Alpha releases. This format broke the team into 2 groups of 3 and had the following running order:
Sub-group 1 (Presentation)
- Overview of presentation / game
- Overview of major game components including work done in the release, and work planned for the next iteration. Each member of the sub-group presented 2 of 6 core components
- Notes on process for the release (specifically: Scrum usage)
Sub-group 2 (Demonstrations)
- Full, uninterrupted, play through of the current state of the level
- 5-10 minutes of demonstration of each of the major components and features. Each member of the sub-group explained an equal share of the features being demonstrated.
Relevant Journal Entries:
As part of the house-keeping and process tasks, I also created several of the pages for the team's Mahara portfolio. To complete this task I had to develop a layout for the introduction / overview page, and select the content to be added to the alpha page (this was largely informed by the presentation layout). I also wrote short biographies for each of the team members. Various other team members contributed assets for these pages (screen shots, screen casts etc.)
As we are developing the game in 3 distinct releases, and the team has six members, it made sense to break the pages up into 3-column rows. This resulted in a magazine layout for all pages, and the final result was well received by the team.
Relevant Journal Entries: