This creates a new component HardwareKeyboardDetector, which is a more advanced version of the KeyboardEvents mixin:
HardwareKeyboardDetector is a component instead of a mixin, which means it can be added/removed by the user at any point;
multiple such detectors can be attached to a game - for example, in a 2-player game one component may be paying attention to arrow keys, while another to WASD keys;
the new component uses Flutter's HardwareKeyboard interface, bypassing the need for a Focus widget;
the component keeps the ordered list of keys that are currently being pressed, which is helpful for games where this order is important;
there is the ability to temporarily pause the reception of key events using keyEventsPaused property.
The new property camera.visibleWorldRect gives the Aabb of the world region visible through the camera. This can be useful for culling the render pipeline, or similar purposes.
Before this PR, the return type of onLoad() was Future<void>?, after this PR the return type is FutureOr<void> -- both for classes Component and Game.
Reasons:
The use of FutureOr is more idiomatic in Dart, this class was specifically created in order to be used in situations like ours.
This makes learning Flame easier for beginners, since you no longer need to explain what asynchronous programming is from the start (and onLoad() is one of the first methods the user encounters in Flame).
The code can be cleaner in case when onLoad doesn't need to be async.
With new approach, the onLoad() method can be overridden as either
@override
Future<void> onLoad() async { ... }
or
@override
void onLoad() { ... }
Of course, it can also be overridden as
@override
FutureOr<void> onLoad() { ... }
but this is rare, only for components that are designed to be further subclassed, or for mixins.
The documentation was updated to show the new recommended usage.
This adds a proposal for a new API for flame, the ComponentNotifier.
This API offers the user change notifiers classes that are tied to FlameGame and its components so the user can be notified when a component is added, removed or updated.
This will enable users to:
Take the benefit of reactive programming inside the game
Have a simple way of watching certain states from the game, on Flutter Widgets
One important note here is that this proposal does not mean to replace integrations like flame_bloc, but rather provider an simple and out of the box solution, without any need of additional packages, since change notifiers are provided by flutter itself.
Opening this as draft for now to get feedback on the implementation, will write tests and docs once we have the final implementation.
Adding a bridge library for integral_isolates adding support for components to run CPU intensive code with a function similar to Flutter's compute function, but with a long lived isolate. Lifecycle is handled by the game loop, where the isolate would live between onMount and onRemove.
This PR continues the work for enabling rich text support within Flame.
Here I add support for different text fragments having different TextStyles, and allow those styles to be inheritable within the text node tree.
This PR adds an optional parameter to raycast API called maxDistance. Using this parameter users can control the limit within which raycast scans for hits.
This PR adds a new method called lookAt for PositionComponent. It is a convenience method which rotates the component to make it point towards/look at the given target position.
Additionally, this PR also adds a angleTo method which can be used to get the calculated angle for lookAt. It will be useful if someone want to smoothly rotate towards target using effects or manual lerping.
This PR adds two updates.
It updates the flame_forge2d to latest version i.e on pub.dev in examples and padracing projects.
Adds a bouncing ball example in the collision detection examples demonstrating a simple example of collision and bouncing of a ball from the walls around it.
This PR implements raytracing and raycasting for the built-in hitboxes.
If you pass in your own collision detection system to the HasCollisionDetection mixin you have to change the signature of that to: CollisionDetection<ShapeHitbox>instead of CollisionDetection<Hitbox>.
This PR introduces the notions of structured text, and text styles, to support rendering of rich text bodies.
Specifically, we recognize that sometimes in games one needs to render pieces of text that are larger than a single word or even a single paragraph. These pieces may include: books, quest descriptions, mission objectives, tutorials, in-game help system, dialogues, etc. Rendering such a piece of text is non-trivial, however. In order to tackle this problem, I break into the following parts:
Text structure, represented as a tree of Nodes. The nodes describe the logical structure of the text, for example the document may contain a header, and then several paragraphs, and a list, where the list contains some list items, some of which having possibly several paragraphs, etc. This structure is similar to how in HTML the text is marked up with HTML tags.
Text styles are struct-like classes that contain properties describing how the text is to be styled: font size, font renderer, borders, backgrounds, margins, padding, etc. This representation is also tree-like, so that for example text inside paragraphs can have different style than text within headers, and paragraphs within lists can have different margins. A text style is similar to a stylesheet in HTML.
Text elements are the result of applying the document style to a document node: they are the "prepared" and laid out pieces, ready to be rendered. Elements are a bit like mini-components, or perhaps text "particles" in a particle system.
This simple refactor allows us to write class MyGame extends Game, instead of a more awkward class MyGame with Game. However, using ... with Game still continues to work, so no changes necessary for the users.
This PR adds a new event system based on the componentsAtPoint delivery mechanism. These events allow for a proper support of components that implement renderTree() method. The CameraComponent is one such component, with more planned in the future.
Additionally, the following improvements compared to the current tap events added:
- the same component can be tapped with multiple fingers simultaneously;
- a component that received onTapDown is guaranteed to receive onTapUp or onTapCancel later;
- a component that moves away from the point of touch will receive onTapCancel instead of onTapUp (even though the game widget receives onTapUp from Flutter).
Due to the fact that the switch from the current event system to the new event system is potentially a significant breaking change, the new event system is introduced as parallel to the existing one. This way we have more time to test the new system before recommending the switch and deprecating the old one; and the switch itself should feel more gradual.
Created a mixin to handle the margin to the viewport, mostly to remove the code duplication in ButtonComponent and HudButtonComponent, but it can also be useful in other cases when you don't want to wrap your component in HudMarginComponent.
Once the new camera system is in place this will of course have to be replaced.
- Added option align in the TextBoxComponent which controls the alignment of text.
- Added option for the TextBoxComponent to have a fixed size (before the only mode was for the textbox to automatically expand/shrink to fit the text).
