The food bitmaps would sometimes be placed underneath the score text,
which was a bit hard to see. Use a statusbar like we do in other games
like Solitaire.
Note the default height change of the Snake window is to make the inner
game widget fit exactly 20x20 cells.
Unfortunately, GML widget registration requires a non-fallible construct
method to create the widget. So this does a bit of manual error checking
when loading the food bitmaps.
The former is required for GML, and the latter is to avoid the verbosity
and redundancy of Snake::SnakeGame (and matches most other games in the
system).
Before this patch, all key down events except arrow keys or WASD were
not propagated, so keyboard shortcuts in the application didn't work.
This patch fixes this :))
This patch adds a m_snake_base_color variable which dictates the color
of the head of the snake and from which the rest of the snake color's
are derived from by darkening the base color.
This patch adds an action in the Snake's game menu that allows for easy
pausing/unpausing of the game state.
In order to do this, the commit adds new pause()/start() functions in
the SnakeGame class ;)
After improving the mine field generation method, fields with greater
than 50% mines no longer take too long to generate. So, the mine limit
for a given size can be increased to its maximum possible value.
In reset() function, the icons of labels in the game area were initially
set as mine icon or null. And then, after generation, only the number
icon was set. In the old field generation algorithm, this did not cause
a very visible issue (The displayed mine icons in the game over screen
were from a previously generated game field, which was only slightly
wrong).
However, the newer field generation caused a "no mine icons are shown in
the game over screen" issue. To fix that, the label icon is set to null
initially, and then it is set to a mine or number bitmap.
The existing method was simply using a "randomly generate until it fits
our criteria" method to generate a game field. While this worked OK in
most cases, the run time was increasing seriously in boards whose
mine count / board size ratio was too big.
The new approach simply generates every possible mine location, shuffles
the array and picks its head. This uses more memory (shouldn't be a big
deal since minesweeper boards are generally miniscule) but runs much
quicker. The generation could still use some improvement (regarding
error handling), though :^)
Previously, the word was highlighted red in case it was not found in the
dictionary. That color was repurposed as a general "invalid input" color
to nudge the player that something was wrong with the last input.
Accordingly, the field m_last_word_not_in_dictionary was renamed to
m_last_word_invalid
In the "inspiration" for this game, messages are displayed on top of the
game area in case an invalid guess is inputted. After a few seconds,
they disappear. In a similar fashion, a statusbar is created on the game
window and similar messages are outputted there.
This will make it easier to support both string types at the same time
while we convert code, and tracking down remaining uses.
One big exception is Value::to_string() in LibJS, where the name is
dictated by the ToString AO.
We have a new, improved string type coming up in AK (OOM aware, no null
state), and while it's going to use UTF-8, the name UTF8String is a
mouthful - so let's free up the String name by renaming the existing
class.
Making the old one have an annoying name will hopefully also help with
quick adoption :^)
Otherwise, we end up propagating those dependencies into targets that
link against that library, which creates unnecessary link-time
dependencies.
Also included are changes to readd now missing dependencies to tools
that actually need them.
We previously put the generated headers in SOURCES, which did not mark
them as GENERATED (and did not produce a proper dependency).
This commit moves all generated headers into GENERATED_SOURCES, and
removes useless header SOURCES.
This was only used for asking the stack if it is the one we are moving
cards from. We now have a better way to do that, by comparing against
`CardGame::moving_cards_source_stack()`, which doesn't require manually
telling a stack that it is/isn't focused.
As part of this, made a const overload for `Card::rect()`. We need the
non-const one too as it's used for modifying the position of a card
that's being dragged. I plan on changing that soon but we'll see.