FrontierNav Report: November 2018

Progress Report

Changes in November

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:

Architecture Improvements

Xenoblade 2

Open Source is Productive

Since FrontierNav is open source, I feel more obliged to share what I'm doing. I try my best to create new Issues in the GitHub repo to show what needs to be done and I'm generally a lot more organised since I'm making public commitments, even though it's to a silent audience.

This is a known benefit of coding in the open and it's nice to experience it first hand with a large codebase.

FrontierNav's Potential

I recently finished Nier: Automata, found all the fish, upgraded all the weapons, did all the quests, etc. And I noticed something. The wikis were all inconsistent, contradictory and even just plain wrong. I had to start my own spreadsheet and jump between it and the wiki to keep track of the data I need.

This isn't anything new, I've had to do the same thing with pretty much every RPG. It's the main reason I'm making FrontierNav, and it's easy to forget when I'm not playing any specific game.

So next time I end up in a similar place, I'll try to stop my existing habit and try to build the features I need into FrontierNav. It'll be an interesting exercise and hopefully improve my post-game enjoyment for future games.

dweb: Between a Rock and a Hard Place

As I've mentioned a lot in my previous updates, I've always kept the mindset of having a minimal back-end when building FrontierNav. By doing so, unlike a lot of gaming websites in the past, I hope FrontierNav can move over to the distributed web (dweb) and exist forever, its data never lost.

The problem is that the dweb is still pretty new and not ready. I could invest in things like IPFS or Dat / Beaker, but doing so has a risk. These are still technologies in their alpha stages and I don't have the time to keep up with their unstable releases and breaking changes. I have no doubt that the dweb is the future, it's just not there yet.

So my current plan is to keep everything relatively static. FrontierNav doesn't change between releases. To change the data or add a new game, a new release has to be made. It's one big application that's loaded as-needed, much like a torrent, making it easy to move to the dweb when the time comes.

User data however does change and so there's a central database. That's terrible since I'm one guy responsible for keeping it all safe and accessible. Ideally, users should own their data, and there are technologies in the works to do just that. But again, it's not there yet. Right now, users expect their data to magically be available on all their devices (like Firefox Sync), and a central database is the only realistic way to do it.

For my own sanity, maybe it's worth forgetting about the dweb for now. There's not much I can do about it and having it nag constantly at the back of my head is just slowing me down.

Next Steps

For December, I'll continue to rolling out architecture changes and Xenoblade 2 features.

Another feature to look into again is data editing. At least something to get the ball rolling. Right now I have my own spreadsheets which I maintain, but it'd be nice for users to be able to change data themselves.

Last time, I tried implementing a wiki. But I found a wiki format is not the right approach for editing FrontierNav's flexible data structure. Wikis are text documents first and foremost, while FrontierNav's data is a graph of nodes, properties and relationships. Most of the text is either static or templated based on this data to avoid manual errors and inconsistency.

So this time around, I'll be using my own gameplay flow as a use case (the one I described above for Nier: Automata). That way, I'll have a user flow that works for FrontierNav.

Thanks for reading.