get scoreboard/points/health/gameover/waves working

[ngokevin]

Originally Redux, now no Redux. Now updated game state to get health/scoreboard working with simple solution with below problems addressed.

Debug panel:

Decoupling between game state and components:

Before, components had to manually grab the game state from the game system. This heavily couples components to the game system.

For instance, the counter/scoreboard was directly accessing the game state, meaning this component could not be used in any other context. Now we have a game state, a binding layer (redux-bind), and a standalone counter/scoreboard component.

Another instance, the enemy system was also directly accessing the game state to determine enemy strength. That has also been decoupled, the enemy system no longer is aware of the game state and relies on its data.

Unidirectional data flow:

Data should flow down, not up.

Before: [game state] <--access-- [components] ... [entity] <--talk--> [entity] After: [game state] --flow down--> [components]

Centralized game state:

Rather than game state being updated from multiple locations, components now dispatch actions. In one place, we define how every action transitions the game state.

Debugging opportunities:

We'll be able to easily display entire game state within VR as well.

[dmarcos]

Before introducing something like redux I would try to manage state without any external dependency and identify what our needs are.

[ngokevin]

I think @fernandojsg has said the game state management was already getting a bit messy.

[dmarcos]

I'm ok with using redux if we end up determining our problems really match what redux solves. It feels a bit backwards to adopt a dependency before exploring ourselves the problem / solution space.

[ngokevin]

I outlined in the description the issues with game state management we had. I'm not sure if @fernandojsg still feels the same, but he reached out to me in June to improve game state management. If it's not Redux, we could create something similar to Redux (like we were), but it'd be reinventing the wheel.

I'll get the PR polished in a bit and we can compare.

[fernandojsg]

I agree with @dmarcos what about decoupling the changes related to the core code itself and the states from redux? So we could have a clean version of the base code to work with and after that we could iterate on how to deal with the states. My main concern to use redux with the shooter is the extra knowledge that people will need to have to understand this as a showcase example of aframe, or the message that we can give them in the way that people could think is not possible to do this kind of games if you don't have a states manager like redux and that's why we ended up using it. I believe redux is something that could help us in many ways, for example in the inspector is probably a must and we'll earn plenty of nice features having everything clearer and undo/redo for free, but having so simple states here maybe we could give it a try using a custom solution without adding an external dep?

[ngokevin]

I can abstract the Redux pieces even further so we don't even know we're using Redux. I could do everything within the core code, but aren't we worried that I'll pretty much be duplicating Redux, which is a fairly thin library?

[dmarcos]

We might or might not end up reproducing redux. If it's that simple it won't take much effort and we can make it in a way that feels less foreign to aframe.

[ngokevin]

If we reproduce it, the API will still look the same (getState, subscribe, dispatch, bind). What becomes clearer?

[fernandojsg]

I like it, is looking good to me. @ngokevin can we merge? Or do you still need to fix something else?

[ngokevin]

Can merge it, should be ok state

[fernandojsg]

Cool! thanks you