1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
|
%global _empty_manifest_terminate_build 0
Name: python-py2048base
Version: 0.48
Release: 1
Summary: Python clone of the famous 2048 game.
License: GPL
URL: https://github.com/dasld/py2048base
Source0: https://mirrors.nju.edu.cn/pypi/web/packages/bc/a3/2ee7cd0a65aaa179da7f997f7c9df6c0a6269f7f794efd68ec55cac85c0f/py2048base-0.48.tar.gz
BuildArch: noarch
Requires: python3-appdirs
Requires: python3-pytest
%description
The backend takes input (in the form of a `py2048.Directions` object),
processes it, and waits for the next input.
This loops until
the player exits, or
the player wins for the first time in this session, or
the player runs out of valid movements.
It's a pure-Python implementation of the original game logic:
it makes equal numbers merge into their sum, "moving" from one tile into
another, and so on.
The backend deals only with plain Python data, such as `int` and `dict`;
it is up to each frontend to actually collect the input and display the
updated game state as a (hopefully) pretty interface.
To write such frontend, subclass `py2048.basefrontend.Base2048Frontend`
and override the following methods:
* `choose_direction`
* `on_player_quit`
* `on_player_victory`
* `on_player_overvictory`
* `on_player_loss`
`choose_direction` must return exactly one `py2048.Directions` object.
If writing a graphical frontend (a GUI), you'll probably want to create a "worker"
thread that runs the backend's loop and waits for a condition when it reaches
the `choose_direction` call.
The main thread will then be responsible for storing user input somewhere accessible
by the worker thread and "waking it up".
The other overriden methods shouldn't return anything.
`player_quit` is called when the player exits the game before winning or
losing.
An "overvictory" is what happens when the grid "jams" (runs out of valid movements)
but the player had already won (had already reached the target goal number).
%package -n python3-py2048base
Summary: Python clone of the famous 2048 game.
Provides: python-py2048base
BuildRequires: python3-devel
BuildRequires: python3-setuptools
BuildRequires: python3-pip
%description -n python3-py2048base
The backend takes input (in the form of a `py2048.Directions` object),
processes it, and waits for the next input.
This loops until
the player exits, or
the player wins for the first time in this session, or
the player runs out of valid movements.
It's a pure-Python implementation of the original game logic:
it makes equal numbers merge into their sum, "moving" from one tile into
another, and so on.
The backend deals only with plain Python data, such as `int` and `dict`;
it is up to each frontend to actually collect the input and display the
updated game state as a (hopefully) pretty interface.
To write such frontend, subclass `py2048.basefrontend.Base2048Frontend`
and override the following methods:
* `choose_direction`
* `on_player_quit`
* `on_player_victory`
* `on_player_overvictory`
* `on_player_loss`
`choose_direction` must return exactly one `py2048.Directions` object.
If writing a graphical frontend (a GUI), you'll probably want to create a "worker"
thread that runs the backend's loop and waits for a condition when it reaches
the `choose_direction` call.
The main thread will then be responsible for storing user input somewhere accessible
by the worker thread and "waking it up".
The other overriden methods shouldn't return anything.
`player_quit` is called when the player exits the game before winning or
losing.
An "overvictory" is what happens when the grid "jams" (runs out of valid movements)
but the player had already won (had already reached the target goal number).
%package help
Summary: Development documents and examples for py2048base
Provides: python3-py2048base-doc
%description help
The backend takes input (in the form of a `py2048.Directions` object),
processes it, and waits for the next input.
This loops until
the player exits, or
the player wins for the first time in this session, or
the player runs out of valid movements.
It's a pure-Python implementation of the original game logic:
it makes equal numbers merge into their sum, "moving" from one tile into
another, and so on.
The backend deals only with plain Python data, such as `int` and `dict`;
it is up to each frontend to actually collect the input and display the
updated game state as a (hopefully) pretty interface.
To write such frontend, subclass `py2048.basefrontend.Base2048Frontend`
and override the following methods:
* `choose_direction`
* `on_player_quit`
* `on_player_victory`
* `on_player_overvictory`
* `on_player_loss`
`choose_direction` must return exactly one `py2048.Directions` object.
If writing a graphical frontend (a GUI), you'll probably want to create a "worker"
thread that runs the backend's loop and waits for a condition when it reaches
the `choose_direction` call.
The main thread will then be responsible for storing user input somewhere accessible
by the worker thread and "waking it up".
The other overriden methods shouldn't return anything.
`player_quit` is called when the player exits the game before winning or
losing.
An "overvictory" is what happens when the grid "jams" (runs out of valid movements)
but the player had already won (had already reached the target goal number).
%prep
%autosetup -n py2048base-0.48
%build
%py3_build
%install
%py3_install
install -d -m755 %{buildroot}/%{_pkgdocdir}
if [ -d doc ]; then cp -arf doc %{buildroot}/%{_pkgdocdir}; fi
if [ -d docs ]; then cp -arf docs %{buildroot}/%{_pkgdocdir}; fi
if [ -d example ]; then cp -arf example %{buildroot}/%{_pkgdocdir}; fi
if [ -d examples ]; then cp -arf examples %{buildroot}/%{_pkgdocdir}; fi
pushd %{buildroot}
if [ -d usr/lib ]; then
find usr/lib -type f -printf "/%h/%f\n" >> filelist.lst
fi
if [ -d usr/lib64 ]; then
find usr/lib64 -type f -printf "/%h/%f\n" >> filelist.lst
fi
if [ -d usr/bin ]; then
find usr/bin -type f -printf "/%h/%f\n" >> filelist.lst
fi
if [ -d usr/sbin ]; then
find usr/sbin -type f -printf "/%h/%f\n" >> filelist.lst
fi
touch doclist.lst
if [ -d usr/share/man ]; then
find usr/share/man -type f -printf "/%h/%f.gz\n" >> doclist.lst
fi
popd
mv %{buildroot}/filelist.lst .
mv %{buildroot}/doclist.lst .
%files -n python3-py2048base -f filelist.lst
%dir %{python3_sitelib}/*
%files help -f doclist.lst
%{_docdir}/*
%changelog
* Tue May 30 2023 Python_Bot <Python_Bot@openeuler.org> - 0.48-1
- Package Spec generated
|
