Suggestion: Integrate the game client into Vuex store state management

[erezvish]

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.

[djasnowski]

Could you expand more on this? I'd like to know exactly how we should use Vuex to accomodate the game better. Essentially, you mean make the game/engine use the Vuex store to pull from there instead of relying on the game prop.

I also know that I'd like to rewrite the game object because right now, I'm storing locally the tile map (40,000!) elements of an array and am in more than one place that is used by the map/engine.

In the previous iteration of Delaford (4 years ago when it was written in jQuery and Angular 1), what I did was only display the viewport (15x10) plus 3 layers on all 4 sides. Then, when they moved one way, one layer was generated (if not already), sort of like procedural generation, and thus, the only thing that was stored for the map to do its work was was absolutely needed (240+ tiles instead of 40,000).

[erezvish]

So far I've only been thinking about it at a very high level without going into the details much but basically what I was thinking is that game should have it's own section in the store. Something along the lines of (I'm generalizing the object}:
state: { account: accountStuff, game: allGameState }

We can also divide the store to modules and have account and game still handled on separate files, yet be part of the state object.

Since the store is available to all child components we can quite conveniently point stateful components only to their part of the game (and let them pass the rest as props).

Instead of instantiating a game object, starting a new game can perform an asynchronous action that when completed mutates the store with the relevant data (if we want we can do that via a service that handles the game's async actions in general). When the store is mutated we can say for example that login is done, or use some other flag that renders the rest of the components.

I'm guessing that overtime as the game progresses, we'll find the store more useful as we can set getters that computes the same data for several components (instead of taking care of it individually) and mapGetters will pretty up our code a bit.

In my opinion we'll also be gaining a good pattern for updating the state via the dispatch/commit methods of the store.

I admit I haven't looked much at the map but what you wrote about the previous iteration makes sense to me. Loading only what you need sounds great. I think that way the active map is also very much a state of the game. Maybe it can be a good idea to work with the same concept you already implemented before and just make loading new map parts (and unloading old one) something that works asynchronously in the background?

[djasnowski]

@erezvish I wholly agree with this approach. As time goes on, other components will need work and passing around objects is bound to backfire.

Just need to draw up the spec and see how we can tackle it from here.

As for the map approach, I believe that may what is needed eventually.

[erezvish]

Sounds good. If it's alright with you, I'll see if I can come up with a design we further discuss?

[djasnowski]

Sounds good to me. El dom., 31 de mar. de 2019 22:10, erezvish <[email protected]> escribió:

…

Sounds good. If it's alright with you, I'll see if I can come up with a design we further discuss? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#79 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAlngBgeHZVFWn62Be7vfcn-cNJRBHBeks5vcXiigaJpZM4cUc_x> .

[DylanC]

@erezvish @naknode - When I started with Vue I would rely on emit but for bigger projects its really not great. The power of Vuex should definitely be used here and I can help if you need it.

[erezvish]

Hi,
I started working on it a couple months ago but got a little bogged down, then life intervened and (to my shame), I kind of stopped.
You're more than welcome to take over this item.

[DylanC]

@erezvish - Alright. Well first I will need some time to investigate what objects your project uses and see what I can do from that point onwards.

At the moment from a quick glance I can see you would have objects for:

• CanvasEvents
• Player
• Player.inventory
• Bank(s)
• Map
• All_Items

Let me know if you have any more details on what objects you expect in the game. 👍

[djasnowski]

@DylanC I think you got it! Thanks for taking a stab. Will be keeping an eye out.

[DylanC]

@naknode @erezvish - I've a copy of master here:
https://github.com/DylanC/game/commits/master

I converted the project to use Vuex modules as this will make future development easier. However, I'm running into a strange error at the moment:

Uncaught Error: [vuex] getters should be function but "getters.account" in module "account" is {"username":"dev","password":"qwertykeyboard"}.

I feel its just an issue with how files are getting pulled in together or a missing export. Should be able to get to the bottom of it hopefully. 👍

[DylanC]

@naknode @erezvish - Fixed that issue. Progress can be tracked on the PR.
#90

However, this PR could take some substantial time.