One of the oldest feature requests for FrontierNav was to have a community forum. A place to ask questions and network with other users. I've finally decided to introduce this feature, albeit in a primitive state.
FrontierNav's focus has mainly been to introduce interactive guides (e.g. maps) for games that aren't available on other websites. However, there are other ways FrontierNav can improve a user's experience. One of them is the question and answer flow.
So you've decided to create a forum... using Firebase. Let's go through the entire process. This guide assumes you already have some knowledge using Firebase so it's mainly focused around modeling the data to work with Firebase's limited access controls.
Unlike traditional databases, Firebase's Real-time Database is accessed directly from the browser by users. This allows real-time push updates whenever the data changes without the user needing to manually reload.
Data is written individually by users. A user can attempt to write into the database, and the database can say who's allowed to write there and restrict the data with simple rules. For example, "a property can only be changed by User A and it must be a number".
However, due to the nature of Firebase, it cannot enforce complex rules. For example, "you can only add a new post if you haven't created a post in the last minute". This generally requires going through all posts for a given user and finding the timestamp of the most recent one. Not possible in Firebase.
Now that FrontierNav is open source, it's a lot easier to share changes for the month. You can find a list of changes on GitHub.
However, it's a bit low-level so to summarise:
FrontierNav is now open source! I've spent most of the month planning this switch over and thinking about what it means for the project going ahead.
By virtue of being open source, I'll be more open about priorities and plans. There's an Issue Tracker for feature requests, planned changes and bug reports. I've also written some documentation for people to get started so that they can make their own code contributions.
You can find the code repository on GitHub.
For Xenoblade 2's map, legend toggles have been implemented, allowing you to choose which map markers to show. However as the data bundle now contains substantially more data -- roughly doubled by adding all enemy spawn points -- the current approach to data management may not be feasible. So I've spent some time looking into alternative approaches.
After years of writing log lines and trying to find a perfect format, I've come to a conclusion: Always log JSON.
Logging to JSON makes your code read more consistently, you save time thinking about how to log your message and it allow you to separate concerns between logging data from processing it for various use cases like debugging, generating reports and performance.
I'll be using JavaScript as an example here, but my opinions apply to all languages.