When the game is backgrounded and then resumed, the update function is called with a very large dt time step.
This might cause the physics engine to hit the maximum translation per timestep, causing moving bodies to slow down to almost-zero velocities.
This PR makes the game pause if the game is backgrounded. If you'd like to change this behaviour, set the pauseWhenBackgrounded flag to true (default) or false.
class MyGame extends FlameGame {
MyGame() {
pauseWhenBackgrounded = false;
}
}
This is currently not working on the web, see flutter/flutter#53107.
You can view previous discussion about this here: flame-engine/forge2d#84.
Improve our spellchecker (cspell) configuration and dictionary file
organization.
# Rationale
This is a proposal to establish a few changes:
* better separate our dictionary files into different categories of
types of words we are including
* improve the cspell regexes to be more aggressive
* be less lenient to what kinds of words we are adding to our
dictionaries
* have the dictionary file also serve as an explanation for obscure
references that cannot be easily derived from the word
Essentially my goal is that either when reviewing a PR that adds a new
entry to our dictionary, or when reading the dictionary files
themselves, it is immediately obvious what the entries are and why they
are there. Currently it can be just a dumpster we throw anything into if
spellcheck fails.
# Proposal
This PR-as-a-proposal essentially do the following changes.
## Split Dictionary Files
Proposes a better separation for our dictionary files. Currently we have
3 that are a bit broad and not super clear on what goes where. This
breaks it down a bit more and adds a comment to each file explaining
what kinds of terms should be added to each; that also serves as a
general guidance for what kinds of words should be added to the lexicon
in general, and makes it harder for mistakes to make into it.
* `flame_dictionary`: remains pretty much unchanged; it is dedicated to
Flame-related words, including companies, tools, and libraries (and
their associated concepts) mentioned on our codebase. Basically a
collection of proper-nouns relating to companies and libraries we
mention.
* `dart_dictionary`: new file for Dart and Flutter related terms
* `sphinx_dictionary`: unchanged, for Sphynx related terms
* `people_dictionary`: specific for people names and usernames
referenced on the codebase (in TODOs, mentions, etc)
* `words_dictionary`: actual English-language words (or common
abbreviations) missing from CSpell
* `gamedev_dictionary`: this was our biggest file that contained all
sort of things. it has been mostly broken down and now only contains
general development-adjacent terms and expressions
## Include definitions
Except for the `words` dictionary, which should be self-explanatory (as
it basically covers for "holes" in CSpell standard dictionary, which I
have been finding a bit lacking), every other file will contain terms in
the form:
```
word # definition of the word
```
What exactly the definition is can slightly vary depending on which
dictionary file we are talking about, but the examples should be
self-explanatory.
As an example, for the gamedev file, it should provide some simple
guidance as to what the term means, or if it's an acronym or
abbreviation, what it stands for. The goal is not to teach the entire
concept to someone unfamiliar, but allow them to "google" it for
themselves by giving enough context, so they can confirm their
suspicions. For example, if they see `LTRB` somewhere by itself, they
are not able to "just google that" because it is too vague. The
dictionary file provides enough context for the user to figure out
however much deeper information they want about any particular subject.
It will also disambiguate from any non-Flame related homonyms. For
people on the people file and companies on the flame file, the
description will provide links to clearly disambiguate what they are;
for tools, a brief description of what the tool is for is also included.
And so on.
The goal is not to build a comprehensive, in depth-guide to each word we
use, but rather to give the bare minimum of context on what this term
"is doing" on our codebase.
## Be less lenient with terms
My idea with these two major changes combined, is that we are overall
more tactical about which terms we want to add to the dictionaries.
Adding a word to the dictionary file is essentially giving carte blanche
to anyone in the future to reuse that term anywhere. I think we should
see spellchecker violations as "warnings"; we decide on the set of
warning rules we want to enable for the entire project (hopefully all
the ones that make sense; or have a reason for disabling the ones that
don't). We might need to violate these warnings sporadically, for
example, we ban `print` on the codebase but might need to allow it
specifically in a couple places. But we would not disable the entire
warning to do that, rather we would add a specific comment-bypass on the
smallest possible scope that encompasses all the relevant lines. We
would also add a proper comment explaining why we are bypassing the
general rule in this specific place.
Similarly, we should not have one-off violations on the dictionary file,
even if they make sense in the one place they occur, but we should
encourage more liberal use of scoped bypasses for such cases. These
Ukrainian words are required in this file, but should not be on the
dictionary as it does not make sense to use foreign languages anywhere
else:
```
// used as examples of Ukrainian words on the documentation below
// cSpell:ignore рушниця, рушниці, рушниць
```
It might look inelegant to have to include that, but just like a
warning-bypass comment, accompanied by the explanatory proper-comment,
this actually provides helpful guidance and context for the reader that
might be confused with the usage of incomprehensible terms.
This also encourages people to avoid obscure terms that are not already
in our dictionary (i.e. that we have already "bought in" and paid the
mental load investment cost), making our code (and docs) easier to parse
and read for everyone. I want to be extremely clear that that **does
not** mean we need to "dumb down" anything whatsoever, or do any sort of
gymnastics to avoid the wrath of an incompetent spellchecker.
But, for example [when spelling "cave
ace"](https://github.com/flame-engine/flame/pull/2304) in variable names
in a random example, having it typed as `caveAce` instead of `caveace`
can slightly help with readability, specially for non-native speakers
(like most of us). It is an extremely minor insignificant gain, but
having the dictionary file require a brief description will nudge us to
give a bit more thought into each "bypass" we are adding.
(note: a similar issue that I have not yet addressed is "spine boy", but
I will leave that for followups and just added that one to the
dictionary for now, as I am still over the fence on that one since it is
an actual "known" character with a dedicated page, so it is more like a
proper noun - as a specific decision I think it is out-of-scope of the
broader discussion).
The issue with GitHub killing out test pipeline might be due to the running on the latest ubuntu image, this commit tries to use the older one (which I read could be a solution somewhere...)
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.
Update PR template so "Migration instructions" is after the breaking
change checkbox.
I believe that was where it was intended to be, but please assess if
this makes sense.
This:
* Deprecates the NoiseEffectController that is based on the deprecated
vector_math library impl
* Adds a new bridge package `flame_noise` to bridge fast noise
Note: the *goal* of this PR is to allow the immediate deprecation of the
old NoiseEffectController by providing an experimental, suitable
replacement. I believe the package flame_noise will look nothing like
this at all if I am able to land [some improvements to the underlying
fast_noise lib](https://github.com/frankpepermans/fast_noise/pull/5). We
will be able to have for example a generic NoiseEffectController.
However I believe we should merge this as an experimental package for
now to unblock removing the current implementation from Flame which is
negatively affecting our scores on pub. Therefore I would advise we
don't spend any time discussing specifics of how the API/impl provided
for the flame_noise, and just go with _something_ instead of nothing.
This is the beginning of work on Flame Studio. In this PR we add a simple UI, which shows the game itself, an info panel, and a toolbar with 2 buttons: start/pause. The UI is able to control the embedded game; in particular the toolbar buttons can pause or resume the game engine.
This PR migrates us to the prerelease version of Melos (3.0.0-dev.0) and our pipelines to Flutter 3.7.1
It's a golden opportunity for us to test the upcoming version of melos and give them any feedback that we might have. :)
The migration instructions can be read here:
https://melos.invertase.dev/guides/migrations
I am on a crusade to improve our spellchecking. I have a big PR that I am now going to break down into very small chunks to for review.
zwaldowski's cspell-action has been deprecated in favor of streetsidesoftware/cspell-action.
This PR:
updates to use the new recommended cspell action
update to use checkout v3, because why not
fixes a few violations the new action caught
Note: I think we should make a distinction between things that should be in a dictionary (e.g. AABB, a standard industry acronym that we expect people to know what it is) and specific edge-cases/ignore rules for specific parts of specific files (e.g. something like fccc which is meaningless outside of the very specific context in which it is used). For the latter, I believe we should use case-by case exceptions.
I am on a crusade to improve our spellchecking. I have a big PR that I am now going to break down into very small chunks to for review.
This is another hopefully not controversial one - broken links referencing the old Fire Slime.
Updating the links means we no longer need that word in our dictionary file.
I am on a crusade to improve our spellchecking. I have a big PR that I am now going to break down into very small chunks to for review.
Here I am renaming an asset to include a word separator, as the combined word "caveace" doesn't exist. This not only allows us to remove one unclear entry in our dictionary, but make our example code easier to read for new users.
Note: in order to easily update the internal name of the atlas (unrelated to file name), that is stored in the binary, I used this pending feature from Fire Atlas.
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.
Adds a link to https://zapp.run/edit/flame-zh006agh106 in the issue template, since Flame is already set up in there it is incredibly easy to share and run MREs from there.
Include the list of allowed Conventional Commit prefixes into the PR template, and into the title validator action; otherwise this information is too hard to hunt down (https://github.com/commitizen/conventional-commit-types/blob/master/index.json)
The title validator now checks that the PR title starts with a capital letter.
Removed checklist item "The title of my PR starts with a Conventional Prefix", since this is now enforced automatically.
