1
Fork 0
mirror of https://github.com/RGBCube/serenity synced 2025-07-06 03:37:35 +00:00
Commit graph

11 commits

Author SHA1 Message Date
Brendan Coles
7c5e488de2 Games: Use GUI::Icon::default_icon to set application icon 2020-11-01 10:29:27 +01:00
asynts
80e23d1b98 Games: Use new format functions. 2020-10-17 23:20:31 +02:00
AnotherTest
5619ed1dc6 2048: Make board size and target tile configurable
This adds a "settings" option that allows the user to configure the
board size and target tile, and optionally save them to a config file.
Closes #3219.
2020-08-21 11:45:46 +02:00
AnotherTest
40c16b3ce5 2048: Do not allow the creation of games with invalid board sizes
The logic only works with nxn grids, so no need to take separate
row_size/column_size arguments.
2020-08-21 11:45:46 +02:00
Sergey Bugaev
4f06cda8f8 2048: Tweak default window size
As requested by @nico
2020-08-18 17:19:52 +02:00
Sergey Bugaev
8dd5b0af4e 2048: Move score to a status bar
See how straightforward this was? That's because, thanks to the separation
between the model and the view, we can tweak the view without modifying the
model in any way.
2020-08-18 17:19:52 +02:00
Sergey Bugaev
05ea144961 2048: Separate game logic from the view :^)
Look Ali, it's simple:

* The *model* (in many cases, an instance of GUI::Model, but it doesn't have to
  be) should implement the "business logic" (in this case, game logic) and
  should not concern itself with how the data/state is displayed to the user.

* The *view*, conversely, should interact with the user (display data/state,
  accept input) and should not concern itself with the logic. As an example, a
  GUI::Button can display some text and accept clicks -- it doesn't know or care
  what that text *means*, or how that click affects the app state. All it does
  is it gets its text from *somebody* and notifies *somebody* of clicks.

* The *controller* connects the model to the view, and acts as "glue" between
  them.

You could connect *several different* views to one model (see FileManager), or
use identical views with different models (e.g. a table view can display pretty
much anything, depending on what model you connect to it).

In this case, the model is the Game class, which maintains a board and
implements the rules of 2048, including tracking the score. It does not display
anything, and it does not concern itself with undo management. The view is the
BoardView class, which displays a board and accepts keyboard input, but doesn't
know how exactly the tiles move or merge -- all it gets is a board state, ready
to be displayed. The controller is our main(), which connects the two classes
and bridges between their APIs. It also implements undo management, by basically
making straight-up copies of the game.

Isn't this lovely?
2020-08-18 17:19:52 +02:00
Tibor Nagy
e3d1ea34ff Games: Add missing separators to the application menus 2020-08-17 17:39:56 +02:00
Linus Groh
2e5c434e22 Misc: Use automatic window positioning in more applications
This is a follow up to #2936 / d3e3b4ae56aa79d9bde12ca1f143dcf116f89a4c.

Affected programs:
- Applications: Browser (Download, View source, Inspect DOM tree, JS
  console), Terminal (Settings)
- Demos: Cube, Eyes, Fire, HelloWorld, LibGfxDemo, WebView,
  WidgetGallery
- DevTools: HackStudio, Inspector, Profiler
- Games: 2048, Minesweeper, Snake, Solitaire
- Userland: test-web

A few have been left out where manual positioning is done on purpose,
e.g. ClipboardManager (to be close to the menu bar) or VisualBuilder (to
preserve alignment of the multiple application windows).
2020-08-15 17:38:19 +02:00
AnotherTest
2336c62901 2048: Move out the 'undo' action to the app menu/action 2020-08-14 15:10:31 +02:00
AnotherTest
872834320a Games: Add a 2048 game 2020-08-09 21:11:50 +02:00