Game state enum

Game state enum

BenHumberston 1172024626|%e %b %Y, %H:%M %Z|agohover

Does anybody know a good reason to keep the game state enum (the high level one… only 3 possible states right now) in the MusicMonsters class only? I have added it to the util.cs file for public access by other classes so that they can change the game state back to another location. For example, if I want to exit the music lab state, I need to be able to change the gameState back to main menu state or something, which I do from within the MIDIKeyboardInput class.

Does anybody see some sort of encapsulation problem with putting it in util instead of keeping it privately within MusicMonsters?

Re: Game state enum

Kevinoid 1172059734|%e %b %Y, %H:%M %Z|agohover

Yeah, I find this rather gross. Since the GameState is really the state of the MusicMonsters class it seems to me that it should reside in MusicMonsters. The other problem is that if the state is changed to IN_LEVEL or IN_LAB the MusicMonsters class will not have created a Level object or Lab object (whatever we are calling it) and it will cause poor side effects. But, if you want to do things that way I can write an accessor method for it (C# has some nice features for that sort of thing) so that it can make sure things work. If you want to do it this way, how are you planning to communicate the results of the time in the music lab to the rest of the system? I was planning on having a method in MusicMonsters that would be called when the lab finished (like LabFinished(Attributes)) so that it could pass those along to the in-game Zyk creature and at the same time could mark the Lab object for deletion and change to the next appropriate state… But if we do this by state change, I will add another state _LAB_DONE that will just get lab information and then delete the Lab. Just let me know what you are thinking.

Re: Game state enum

BenHumberston 1172072077|%e %b %Y, %H:%M %Z|agohover

Ah yeah your way is better. It did seem messy in util, but if I have a method to tell MusicMonsters that I'm done in the lab, that's fine then. Actually, for now the "MusicLab" class is actually "MIDIKeyboardInput" (again, it may change, but for prototype purposes I'm busy working on other stuff), just fyi. I know that we eventually plan to have all 3 inputs eventually, but piano and file will have to wait for now as I just try to get algorithms in place for actually affecting the Zyk.