Technical Design
We are making a geo location based route walker, with interactable object where you can make photos of with your phone.
List of big features:
Writen by Bas
We aim to provide precise real-time user location within the game. This is achieved by retrieving latitude and longitude coordinates from Google Maps and converting them into meters. We utilize the formula:
This methodology ensures an accurate navigation experience for users exploring Amsterdam-Oost within the game world.
Our geolocation system performs flawlessly on its own. However, when we integrate our map, an issue arises: the map fails to account for the Earth's curvature. Consequently, the locations are not accurately represented. Refer to the image below for a visual illustration.
Below are two images that highlight the differences between our system and the map. The system aligns with the first image, while the map aligns with the second.
Map with curvature
Map without curvature
We tried multiple methods to resolve this issue. First, we attempted various calculations for converting latitude and longitude into meters without accounting for the Earth's curvature. This didn't work because flattening a sphere is impossible. Next, we considered scaling the positions by placing the coordinates as usual and then adjusting them with a scaling factor to fit the map visually. However, this approach failed because everything became incorrect when the player moved between points.
Ultimately, we fixed the issue by manually placing every object and importing some crosswalks, then redrawing the map. This ensures that the points, the route, and the player are always accurately represented on the map.
New map in the making
Written by Martijn
The game makes use of a visual route to guide the user along the path that the app takes them on. The line stretches out from the user's current location to the next 'waypoint'. The waypoints are in a list that decides in which order they are. When the user reaches said waypoint, the waypoint gets removed and the line adapts to guide the user to the next waypoint. This repeats itself until the user is at the end of the route.
If for any reason the app would crash, restart, or stop working in any way, and the user would have to launch the app again, the route would be reset. To counteract this from happening, the only thing to do was implement a save and load system.
During the designing of the save and load system, there were multiple ways to store and read the data that needed to be saved in order to make sure the user's walking progress would not be reset accidentally. The initial idea was to take the list of waypoints and save that list to JSON, then update that list when the player would reach the next waypoint. This however proved to be too difficult and time consuming to properly implement into the app.
The solution to this problem would be to implement a number. This number goes up every time the user reaches a waypoint. When the user reaches a waypoint it will also save that number as data in the PlayerPrefs. If the user would have to restart their app, the app would look at the number of waypoints reached, and consequently remove that many waypoints from the appropriate list. This also made it so the data wouldn't have to be translated every time it would be saved or loaded.
Written by William
Our game heavily depends on the correct usage of User Interfaces. The user should be able to efficiently move from one state of the UI to the other. To prevent any issues with multiple states being opened we've decided to create a Statemachine for the UI.
During testing we've found out that due to some weird trick, the user was able to open almost all of the UI elements at once. They would open the Photobook and the introduction causing various bugs. This is why we as a team decided to create the statemachine.
The Statemachine has four different scripts that work in tandem with each-other. The first script is a simple Enum that's responsible for the various states of the statemachine. The second script is another very simple script which wraps the Enum in a class. This script allows for us to assign the state to various objects. The third script is also very simple and allows the usage of Unity events to change the state. The third script is the actual UI Manager. This script is responsible for telling which state can flow into which, what happens in the various states and keeping track of which state you're currently in by displaying it in the editor.
