State placement

[parkm]

I'm thinking that State should get its own file. It depends, are we going to have our actual game states (i.e. menu, level, etc) in the same file as the State prototype? If so then I think it should have its own file. If not then where will the game states be placed?

[dgpt]

I'm not sure I understand what you mean. But I'm now thinking it might be a good idea to do that. We could put State and all of its derivatives into a file. What would be the point of bpm.js then?

[parkm]

bpm.js would be state management and anything global to the game.

[dgpt]

What do you mean by state management? Why not keep that in with the state prototypes?

[parkm]

It's just the updating of the state and keeping track of the current state.

[dgpt]

That's what main.js is for when it starts the loop, though. Will bpm.js contain 6 lines of code?

On Fri, May 2, 2014 at 8:41 PM, Parker Miller notifications@github.comwrote:

It's just the updating of the state and keeping track of the current state.

— Reply to this email directly or view it on GitHubhttps://github.com/despondentdonkey/bpm/issues/13#issuecomment-42094248 .

[parkm]

main.js will be the one that has 6 lines. main.js is kinda pointless, maybe bpm.js should replace it.

[dgpt]

Well we can just get rid of bpm.js then. I think we should keep main.js as the entry point.

Where is the logic going to be? All of the game logic will be in the update method of instantiated States.

[parkm]

Let's just have main.js as the entry point and then it starts the loop in bpm.js. I think it would look better in code if the module was bpm than main.

This is how the logic works:

bpm.js
    update
        currentState.update
            objects.update

We're going to instantiate states as we set them so to go to a new state:

bpm.setState(new states.MyState());