LadybirdBrowser/ladybird
1
1
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-01-08 12:19:37 +03:00
Code Issues Packages Projects Releases Wiki Activity
aa939c4b4b
ladybird/Userland/Games/2048/BoardView.h

62 lines
2.1 KiB
C
Raw Normal View History

Games: Add a 2048 game
2020-08-09 01:10:41 +03:00
/*
* Copyright (c) 2020, the SerenityOS developers.
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
*
* 1. Redistributions of source code must retain the above copyright notice, this
* list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright notice,
* this list of conditions and the following disclaimer in the documentation
* and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
* AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
* SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
* CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
#pragma once
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 16:01:25 +03:00
#include "Game.h"
Games: Add a 2048 game
2020-08-09 01:10:41 +03:00
#include <LibGUI/Widget.h>
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 16:01:25 +03:00
class BoardView final : public GUI::Widget {
C_OBJECT(BoardView)
Games: Add a 2048 game
2020-08-09 01:10:41 +03:00
public:
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 16:01:25 +03:00
BoardView(const Game::Board*);
virtual ~BoardView() override;
Games: Add a 2048 game
2020-08-09 01:10:41 +03:00
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 16:01:25 +03:00
void set_board(const Game::Board* board);
Games: Add a 2048 game
2020-08-09 01:10:41 +03:00
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 16:01:25 +03:00
Function<void(Game::Direction)> on_move;
Games: Add a 2048 game
2020-08-09 01:10:41 +03:00
private:
2048: Tweak cell metrics This makes the game look closer to the original. It also fixes a weird thing where cells were displayed in a wrong order (as if mirrored or something), and to accommodate for that keyboard actions were also mixed up. Now it's all working as intended.
2020-08-18 14:02:09 +03:00
virtual void resize_event(GUI::ResizeEvent&) override;
Games: Add a 2048 game
2020-08-09 01:10:41 +03:00
virtual void paint_event(GUI::PaintEvent&) override;
virtual void keydown_event(GUI::KeyEvent&) override;
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 16:01:25 +03:00
size_t rows() const;
size_t columns() const;
2048: Automatically pick an appropriate font size
2020-08-18 14:05:44 +03:00
void pick_font();
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-19 19:17:17 +03:00
void resize();
Games: Add a 2048 game
2020-08-09 01:10:41 +03:00
2048: Use the original colors
2020-08-18 14:11:42 +03:00
Color background_color_for_cell(u32 value);
Color text_color_for_cell(u32 value);
2048: Tweak cell metrics This makes the game look closer to the original. It also fixes a weird thing where cells were displayed in a wrong order (as if mirrored or something), and to accommodate for that keyboard actions were also mixed up. Now it's all working as intended.
2020-08-18 14:02:09 +03:00
float m_padding { 0 };
float m_cell_size { 0 };
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 16:01:25 +03:00
const Game::Board* m_board { nullptr };
Games: Add a 2048 game
2020-08-09 01:10:41 +03:00
};
Reference in New Issue Copy Permalink