Open samreid opened 8 years ago
As I mentioned during Thursday's status meeting, Build an Atom's game is powered by a finite state machine that is less amenable to state capture/playback than the Property-based system in many of the other instrumented simulations. This is not a failing in Build an Atom--it is using a paradigm suited for the game but which is not currently supported by the state features of PhET-iO. I suspect it will take a long time to figure out the best way to handle this. The main goal is to be able to choose a state to load the simulation in, but we may need to do something game-specific for this anyways. I'm putting this on hold and I'll see if I have time to look into this before my next project ramps up.
I've used a state machine approach in pretty much all the games I've implemented for PhET, so this problem with instrumenting the game portion of the sim is probably not specific to Build an Atom, but will likely come up in many if not all games in PhET simulations. Off the top of my head, I would say that Balancing Act, Area Builder, and Arithmetic all use a similar state-driven approach. @samreid - you might want to consider moving this issue to the together repository and calling it something like, "Current approach not working well with state-driven games".
Also, the Expression Exchange simulation is currently in development, and it has a game screen. I normally would use a state-driven approach to implement this, since it has worked well in the past. Should I consider an alternative design? If so, we should discuss and document a game structure that is more compatible with the way that phet-io works.
Proceed as per usual for Expression Exchange, I'll look into how PhET-iO should deal with the game states.
It seems that this comment is ominous from @samreid
This is not a failing in Build an Atom--it is using a paradigm suited for the game but which is not currently supported by the state features of PhET-iO. I suspect it will take a long time to figure out the best way to handle this.
It seems we should discuss at PhET-iO since for games this seems like a major feature of PhET-iO
Both Build an Atom and QuizGameModel use axon, so that is amenable to existing PhET-iO structure, we just need a way to save/load the challenge instances. That will be the first place to investigate this.
May also be possible to serialize all challenge types by using:
ProblemSetFactory._createProblem
I'm going to wait until @andrewadare and I have a chance to discuss save/load in phet-io as part of https://github.com/phetsims/phet-io/issues/319
I know this issue is old, but the state wrapper is throwing quite a few errors using the legacy pattern for dynamic elements (using ~
). I am going to comment out a few instrumented Properties here until we work on this sim again.
From #120