This PR improves the Space Shooter Tutorial as a whole by moving the
setting of component's attributes from their `onLoad` method, to their
constructors.
After a long time, the PR with the step 3 for the space shooter
tutorial!
Replace or remove this text.
---------
Co-authored-by: Lukas Klingsbo <me@lukas.fyi>
```
The following 17 packages will be updated:
Package Name Current Version Updated Version Update Reason
flame 1.11.0 1.12.0 updated with minor changes
flame_riverpod 5.0.0 5.1.0 updated with minor changes
flame_test 1.15.0 1.15.1 dependency was updated
flame_tiled 1.18.0 1.18.1 dependency was updated
flame_oxygen 0.1.9+4 0.1.9+5 dependency was updated
flame_isolate 0.5.0+4 0.5.0+5 dependency was updated
flame_fire_atlas 1.4.4 1.4.5 dependency was updated
flame_audio 2.1.4 2.1.5 dependency was updated
flame_spine 0.1.1+6 0.1.1+7 dependency was updated
flame_bloc 1.10.6 1.10.7 dependency was updated
flame_lottie 0.3.0+4 0.3.0+5 dependency was updated
flame_markdown 0.1.1+4 0.1.1+5 dependency was updated
flame_rive 1.9.7 1.9.8 dependency was updated
flame_forge2d 0.16.0+1 0.16.0+2 dependency was updated
flame_noise 0.1.1+9 0.1.1+10 dependency was updated
flame_svg 1.8.6 1.8.7 dependency was updated
flame_network_assets 0.2.0+9 0.2.0+10 dependency was updated
```
The objective of this fix is to make a tap on a card more
positive-feeling for the player and not to disappear silently if it is
interpreted as a drag.
It adds a Base Card to make an empty Stock Pile behave as a Card and use
the tap and drag logic of the `Card` class. Any attempted drag on a
Stock Pile card, including the Base Card, is now changed to a tap in
onTapCancel() and the drag is not followed. The Base Card is rendered in
outline only and does *not* take part in gameplay.
In other Piles a short drag is either treated as a tap or ignored. Only
the Waste and Tableau Piles allow such taps. As before in Klondike
Step5, they result in the tapped card moving automatically to its
Foundation Pile if it is eligible to "go out".
As before in Klondike Step4 and Step5, all piles except the Stock Pile
allow drags to start on them and they can finish on a Foundation Pile or
a Tableau Pile.
Closes#2890.
When testing, try sliding the finger or mouse slightly while making a
tap.
---------
Co-authored-by: Lukas Klingsbo <me@lukas.fyi>
When the cards are dealt at the start of a Klondike Step 5 game there
are multiple occurrences of unrealistic behaviors:
- Several cards being dealt may come from the middle of the Stock Pile,
- Cards that are dealt early can be seen moving in front of cards that
are dealt later.
Each card dealt should be rendered on the top of the Stock Pile and
should be seen to come from there. During the deal, later cards dealt
are placed on top of earlier ones, so later cards should be seen to move
in front of earlier ones when they are travelling from the Stock Pile to
their positions in the layout.
Co-authored-by: Lukas Klingsbo <me@lukas.fyi>
This adds `DisplacementEvent` to fix delta coordinate transformations
for drag events, to be used instead of `PositionEvent`.
Drag Events now expose the start and end position, as well as the delta,
correctly transformed by the camera and zoom.
This also ensures that drag events, once starts, do not get lost if the
drag update leaves the component bounds.
* if you are using `DragUpdateEvent` events, the `devicePosition`,
`canvasPosition`, `localPosition`, and `delta` are deprecated as they
are unclear.
* use `xStartPosition` to get the position at the start of the drag
event ("from")
* use `xEndPosition` to get the position at the end of the drag event
("to")
* if you want the delta, use `localDelta`. it now already considers the
camera zoom. no need to manually account for that
* now you keep receiving drag events for the same component even if the
mouse leaves the component (breaking)
---------
Co-authored-by: Lukas Klingsbo <lukas.klingsbo@gmail.com>
Primarily this PR is completing Step 5 of Flame's Klondike Tutorial and removing the tbc.md file ("To be continued...").
As at the end of Step 4, the Klondike Game had no animation, other than the drag-and-drop moves to play the game. It also had no ways to detect a win, react to a win or play again without re-loading and re-running the whole app. Step 4 played the Klondike Draw 3 variation of Klondike. Step 5 introduces the easier Klondike Draw 1 variation and provides buttons to:
Choose between Draw 1 and Draw 3,
Start the game again with a new deal, or
Start again with the same deal as before.
The new code and step5.md tutorial text cover Effects and EffectControllers in some detail, with complex examples of their use. The animations include:
Returning dropped but misplaced cards to the places they came from,
Settling dropped and validly placed cards into position,
Flipping cards from Stock Pile to Waste Pile,
Turning cards over on the Tableau piles when the cards above them are moved away,
Collecting multiple cards when the game is over,
Dealing and re-dealing multiple cards,
Allowing a card to be auto-moved onTapUp() to its Foundation Pile if it is ready to go out,
Providing a display of moving cards when/if the player wins.
This small PR adjusts:
1. some `backticks` (`) in the platformer tutorial in order to have a
proper highlight of the file names.
2. replaces backslash (`\`) with slash (`/`) in order to be consistent
with the other file paths used in the tutorial.
3. renames the variable `_xOffset` to `xOffset` in order to be
consistent with the rest of the code.
Co-authored-by: Rodrigo Castro <rodrigo.desouzacastro@bahag.com>
Previously, as part of Issue #2798, I fixed the Klondike Tutorial app's
step4 executable to use the Flame 1.9.x `world` and `camera` built-in
objects and described the new code in the Step 2 tutorial, where it
first appears in the discussion. However, the Step 2 and Step 3 tutorial
texts have options to execute code and those did not include the new
code. Accordingly, I have cloned the relevant code into
`app/lib/step2/klondike_game.dart` and
`app/lib/step3/klondike_game.dart`. I have also checked that there are
no `*.md` files to be updated. The `step2.md` tutorial file covers Issue
#2799 AFAICS.
Firstly, (re Issue #2799) Flame 1.9.x broke the Klondike Tutorial, which was not set up to use the new built-in world and camera. So I modified the KlondikeGame's onLoad() code to use the built-in world and camera and no longer create its own World and CameraComponent. I also updated the step2.md documentation file, which instructs new users of Flame on how to use the world and the camera, how to set up a game-oriented co-ordinate system and how to fit it into the device screen.
Secondly, (re Issue #2798) Klondike was not adhering to the design stated in the Tutorial, that all 52 Card objects would be owned by the KlondikeGame. During the shuffle and deal sequence it was using removeLast() on the List\<Card\>cards, where the cards are kept, the result being that only 24 of the 52 cards were left in the list after the deal. I have fixed the bug and updated the Tutorial documentation (step4) which discusses how the deal is coded.
This bug does not affect the gameplay as it stands, but it does block the way to future features at the game level, such as an option to re-deal or a win-animation where all cards fly off the screen.
It doesn't make any sense for HasGameReference to have Game as a base instead of FlameGame since the mixin is on Component and clearly in a component tree context, so this PR sets the base to be FlameGame (like HasGameRef).
This is a first step towards enabling DCM for Flame. Though I have tested with all rules, and am working on selecting, assessing, and fixing violations, as a first step, we can merge the infrastructural changes to flame_lint to and GitHub actions.
As a proof of concept, I am enabling two rules for which we have no violations.
I will followup with enabling more rules, adding discussions for controversial changes, and fixing non-controversial violations.
I have just finished steps 1-4 of the Klondike tutorial and noticed a
couple of minor things that look to be outdated with the current dart /
flame versions.
### Step 3 - `late` keyword isn't required
When following this step the analyser hightlight this rule
[unnecessary_late](https://dart.dev/tools/linter-rules/unnecessary_late)
(introduced in Dart 2.16.0) which states:
> Top-level and static variables with initializers are already evaluated
lazily as if they are marked late.
I updated the notes around why the laziness is important so the reader
can still understand the reasoning.
The update method should end up with the code in this order, otherwise the velocity is never set to 0.
Probably obvious but the rest of the steps were precise on where to include these code blocks.
May wanna add this full block to the end of this step as well, I spent a few minutes trying to figure out why it wasn't working propely.
It just removes a deprecated line that is in the tutorial for building a Klondike game. The final code does not have it and it is no longer necessary to have it in the KlondikeGame class.
This PR adds the following lint rules to our list:
```
always_put_required_named_parameters_first
avoid_multiple_declarations_per_line
avoid_positional_boolean_parameters
avoid_returning_null_for_void
avoid_returning_this
avoid_unnecessary_containers
enable_null_safety
library_private_types_in_public_api
no_leading_underscores_for_library_prefixes
no_leading_underscores_for_local_identifiers
prefer_null_aware_method_calls
tighten_type_of_initializing_formals
unnecessary_late
use_setters_to_change_properties
```
And these rules were considered, and some changes were made according to
them as a clean-up, but in many places they didn't make sense
(`prefer_asserts_with_message` I would have included, but there were too
many places that needed to be changes):
```
collection_methods_unrelated_type
prefer_asserts_with_message
avoid_renaming_method_parameters
```
