almasb / fxgl Goto Github PK

Or style JavaFX ones if the functionality satisfies game requirements

Hold the actual binary data (serializable), timestamp (as filestamp from NIO.2), other convenient info

This allows consistent error reporting. Possibly in the form of Dialog<>

The "com/almasb/fxgl/asset/Music" class lacks a portion of the MediaPlayer's functionality. Volume control is one of them.

The order of init for managers, scenes, stage must be clearly defined and then organized

Possibly have a way of storing default ones in the packaged jar

Main thing that's stopping the port is really Java 8 API, so when core is ready just need to switch back to 7. Lambda syntax is fine, gradle retrofits it during build

This will be especially useful for key rebindings in menu, so that players can re assign keys to actions dynamically

When displaying dialog with unhandled exception, we should log that exception to file and ask the user to report the error.

Similar to JavaFX Duration API + allows us to change implementation internally without breaking client code

This will also help all users to see how a feature should be used/coded. The demos must be minimalistic and precise, ideally reusable in user code.

Are there any other use cases?

pause() and resume() will speed up the internal timer, this must be avoided as games' logic is based on that. If pause() is called, then we can't call resume() from user input as it is processed in the same thread (timer), which is currently sleeping

This will waive the need for delegating each getter from GameApplication to GameSettings. The read-only version must include all get* but no set*. However, we still need to give clients GameSettings which can be modified from within initSettings

Possibly through use of Settings::setWindowIcon(String)

JavaFX objects are not Serializable, so need a way of allowing clients to capture state of the game / entities into a file easily. This should be approached from the "game save" perspective.

This is an on-going goal. At some point prior to version 0.5, the code will need to go through peer review, so that after 0.5 the API is more consistent across versions

This should allow clients to change scene dimensions dynamically in code. In addition, the entire game scene, including menus must scale accordingly.

This could make code a lot easier to maintain, especially the event handlers and scene graph

Any other use cases?

e.g. to avoid unnecessary casts to PhysicsEntity, more natural interface between Vec2 and Point2D, remove packages/classes which are of no benefit to FXGL, i.e. not used in game dev

Similar to StaticAnimatedTexture but clients should be able to control the state of texture (play, stop). Also the texture must support several channels, i.e. "walk", "stand", "run", etc

This is needed for fullscreen support, as Alert or any other Stage styles without window owners will temporarily exit fullscreen

Various internal, e.g. menu open / close