top of page
Search

#2 Tour.Go: Interface, Authentication and Database

  • Oliver
  • Dec 10, 2023
  • 6 min read

Updated: Feb 1, 2024

Over the past few weeks, I have been busy starting to create the first major prototype for Tour.Go. This process has been exciting and rewarding, and I have been able to make good progress so far.


Interface


The first step was building the interface mock-up. Doing so was tedious at times, but I was able to create the core app flow with simple interactivity.


I started by creating the mockup in Figma, to ensure I could captilise on the planning stage. I wanted to avoid designing the UI structure in Unity in the case I mistakenly forgot elements I later needed.


Figure 1: Wireframe created in Figma to define the prototype interface.

Note that the overall design is not meant to be the final version. My core goal in this prototype is functionality, and I didn't want my imagination or creativity to get the better of this aim. The benefits to approaching the app's interface like this, is I can go back later when I have more features and understand what the final app's brand will look and feel like.


Figure 2: An earlier concept created using Adobe XD and a less refined version purely for ideation process.

I have this earlier concept from Adobe XD I created a few months ago. This interface was created before I finalised the proposal. My reasoning for this was to better understand the app features and what it may finally look like. The wireframe was cruical in the creation of the newer concept in Figma, and I reiterated on ideas to establish the prototype's interface. The benefits of this process is to understand what works well and aspects that do not, offering a better footing when implementing the interface in Unity.


Figure 3: A demonstration of the app's interface implemented in Unity. Basic functionality will be built upon for the final version.

After implementing the interface mock-up, I decided to move on to creating an account authentication system using Firebase. Doing so was not my initial plan, and I had prepared to focus on this in the later stage of the project. It was not until I realised that account authentication was essential in this stage to give a clear indication of how the app would achieve the project aims, making a success of the prototype. This development investigation also led to me gaining a better understanding of how the database would work. The monument database is important as one core priority I have for the final implementation is for the app to be scalable and allow for updates without deploying new build versions. I believe this second approach was better for the overall project lifecycle, as I am more prepared to complete the project to a high standing and have space to exceed the expectations I set out in the proposal.


I will continue to refer to the timeline I set out in the proposal, and this minor change should only strengthen development of the software.


Saving/Loading User Data


Figure 4: The user data class represented in JSON format. The screenshot is from the Firebase console in the realtime database browser interface.

I am essentially saving and loading data from a JSON file, but instead of the file being local, it is stored on the realtime database. The database works as a tree-like structure, with the root being the 'users' node. The identification number is the parent for each user. I have initially set up the database values for player profile functionality, but eventually each user will have data for the badge collection system.


When a user creates an account, a new 'users' node is created via a class object. This is advantageous, as I can pull data with the same variable names, and it is an easy process to write and read each user's saved values.


Account Authentication



Figure 5: The sign in process involves authenticator the user's input to sign in to a previous created account.

When the user signs in, the details are quered with the authentication system. When they are correct, the welcome screen is displayed followed by the app's main menu.


Figure 6: After the user has inserted their email, password and username using a UI input field, a new account is created using the Firebase account authentication module. Certain conditions need to be met for successful creation of the user account. Any exceptions will be communicated to the player in a future version for clarification in the account creation process.

Similar to the signing in method, the create account function takes the users input and creates a new account based on given email, username and password. Note that the user database does not involve the account authentication system, and these are seperate Firebase SDKs.


As can be seen by the code snippet above, the 'SaveData' function, called from the save manager class, is responsible for storing a new instance of user data. This creates a new serializable class object and converts it into a JSON file, ready to be stored in the realtime database. The data can then be edited at a later time to update aspects including user level, experience and monuments found.


Figure 7: The interface in Unity for creating a new account. Users use their email and create a password. Users are required to accept the privacy policy and terms & conditons before account creation is complete.

Monument Database


Figure 8: The database of monuments in the Firebase console. These values can be changed within the interface itself or by importing a new JSON file.

The monument database is a cruical element of the app, and will allow monuments to be added across all devices without consumers requiring a single update.


I did investigate Firebase's firestore solution, but ran into some issues when converting data into different variable types. Moreover, the system is very similar to how individual user data is saved, allowing myself to apply the same understanding to each feature.


The database is simple to update within the Firebase console by exporting, editing and importing a JSON file to change values and add new entries. Eventually, the same database will be used to store dialogue for a virtual tour guide encounter and other interactives. The same can be said for updating badge progress.


Figure 9: The monument database converted to be displayed in the inspector. For initial debugging, the process involves fetching the data and then organising it into an array for the individual monuments.


These values have not been manually added in the inspector! Why is this significant? It shows that the system can be used to retrieve the monument database and convert it into readable data inside the Unity editor. This achievement is a significant milestone, and I can now manipulate and display the data for the features in the app.

Figure 10: The function fetches the monument database from the Firebase server. Eventually, the function will be used to populate the virtual world with all the available nearby monuments to be discovered by users.


I will continue to evaluate the success of this implementation, as there can sometimes be a few discrepancys when fetching the monument database. Due to the latency, it can result in an exception being thrown. There are two solutions that I have found that I will pursue in the future.


The first, setting up a listening event that automatically updates the local data when the realtime database recieves a new update. This solution would be effective and resourceful, as it would ensure that the client recieves updates regularly and can prevent unintended data sequencing between connection and disconnection. However, this could lead to the database locally being updated unnecessarily. Using this solution should not be a issue, as the database for monuments will not be updated regularly.


The second solution I have discovered is simply updating the current function to a coroutine with the WaitUntil condition that will return to the thread after satisfying the condition. The condition could hypothetically be when the fetched dictionary length ('_root') is larger than zero. I currently have a few seconds delay to operate on the fetched data. The exception occurs here, if the '_root' is still being read. The benefits to this approach is that the database is only manually updated, ensuring that fetching data is done when only neccessary. This approach benefits the fact that the app will be on mobile, and could help in ensuring the user's mobile data is used sparingly.


Conclusion

I have made some significant progress over the last few weeks, and hope to continue to implement the app's core functionality in the near future. My main priority going forward will be adding the scanning feature for monuments. This core mechanic will involve using geo-location coordinates to populate the world with objects that store monument values. I can then move on to implementing the AR interactivity, including the virtual tour guide, rotation/scaling of objects, and displaying each monument's facts and information.


References
bottom of page