What mechanics does this feature affect?
Application architecture (this suggested change has a system-wide effect)

How hard would it be to implement this feature on a scale of 1-10 (10 = hardest)?
7

What is the feature request?
Delaford has a game client with a couple of subs (engine, map) which is an object that is essentially responsible for handling the application state.
The application also uses a Vuex store for state management (I believe it was added later), which also allows persisting the state. It is essentially another object responsible for state and currently handles login and accounts.

Since we have two objects that share some common responsibilities, I suggest merging the client into the store, creating a single source of truth for state.

What will we gain?

1. A single source of truth for state
2. Take advantage of goodies that are part of Vuex (actions / mutations, getters, ect)
3. Refine the data that is passed to components (currently several components get a reference to the game client and I think they all go through the Vue update cycle whenever something changes in the game object. While Vue should be smart enough not to re-render, I think we can spare it some work of going through the updated life cycle hook)
4. We will probably be able to utilize the persistent state for more than accounts and logins (I'm less familiar with the plugin).

@naknode , I'll be happy to hear your thoughts on the matter.