摸鱼这事儿讲究的是“看起来忙得不行实际上脑子已经放空一半”。同事用网页版2048容易被浏览器历史记录出卖装个完整GUI游戏又显得太高调。我的方案是用Python在终端里直接跑一个2048终端窗口小字体调暗远远望去就是一堆日志在滚动手指微动就能控制左右非常适合带薪放松。当然说正经的2048也是一个极其经典的算法练手项目——二维数组操作、方向变换、状态判断、随机数生成几乎覆盖了Python基础阶段的全部重点用来巩固逻辑思维比刷一百道填空题强得多。这篇文章我会把整个实现过程完整拆开讲包括数据结构怎么设计、移动和合并的算法细节怎么处理、完整的可运行代码怎么组织、以及我实际调试过程中踩过的几个坑。无论你是想交期末作业还是想找个能跑起来不依赖第三方库的小项目练手这篇内容都够用了。1. 项目概述与整体设计思路1.1 为什么选终端版2048先把话说明白市面上现成的2048项目一大把Python版从Pygame图形版到网页版都有现成仓库我自己也维护过好几个版本但最终用得最顺手、改起来最快、讲给别人听最容易的还是这个终端版。原因很简单它不需要任何第三方依赖不用Pygame、不用Numpy一个纯标准库就能跑起来。这一点在真实工作环境里特别重要。很多公司的电脑对软件安装有严格管控Pip装个numpy还好说装个带图形界面的Pygame可能会触发安全审批。而用Terminal跑一个纯Python脚本既不需要额外解释也不需要权限申请扔到任意一台Python 3.6以上的机器上都能直接运行。从算法学习的角度看终端版还有一个隐藏优势没有图形渲染的干扰所有核心逻辑都被迫暴露在明面上。2048的真正难度从来不在画格子、画数字而在“方块如何合并”“四个方向的移动如何用一套逻辑统一处理”“游戏何时结束”这三个问题上。Pygame版本里很多逻辑被GUI事件掩盖了但终端版的每个按键、每次刷新棋盘背后都是纯逻辑代码在跑这反而是最好的教学状态。1.2 技术方案选型的两个关键取舍写这个项目前我反复权衡过两个技术方案一是纯标准库的终端渲染方案二是Pygame图形化方案。最终选了前者但这不是说后者就不好而是两者的定位完全不同。终端渲染方案的全部代码加起来不超过两百行主循环就是一个while接键盘输入每次按键后清屏重绘。这种方式代码量小、逻辑集中、跨平台性好而且在任何一台机器上都能解释——因为你只需要一个Python解释器。缺点也很明显界面比较朴素没有平滑移动动画数字跳变时手感略生硬。Pygame方案则能做出很像样的动画效果方块滑动时有缓动、合并时有缩放特效玩起来体验完全不输手机版。但缺陷是代码量会翻好几倍还要额外处理窗口事件、字体渲染、图片素材库对初学者来说复杂度会陡然上升。我给的建议很直接如果你是第一次写2048或者说你的核心诉求是理解算法逻辑或者你连Pygame都没装过直接选终端版。如果你本身对Pygame已经比较熟悉只是想做个更完整的作品那可以考虑用后面“优化扩展”章节里给的Pygame核心逻辑改造方案那段代码只替换了渲染层算法层是百分百复用的。1.3 程序架构的顶层拆解终端版2048的架构非常克制我把它分成了四个逻辑层虽然代码里没有刻意做分层封装但阅读时按这个思路走会清晰很多数据层一个4×4的二维列表表示整个棋盘状态。之所以用二维列表而不是一维列表或字典是因为二维列表最直观board[row][col]直接对应屏幕上第几行第几列理解成本和操作成本都最低。逻辑层移动、合并、判断游戏状态这三个核心函数负责修改棋盘数据。渲染层把棋盘数据打印到终端用\033控制光标位置实现原地刷新。输入层接收键盘上的方向键或WASD映射成四个方向的移动操作。这种分层的好处是如果以后想改成Pygame版只需要替换渲染层和输入层逻辑层一行都不用动。反过来如果你想把棋盘从4×4扩成5×5只需要修改数据层的初始化代码和一个判断边界的地方其他完全不用改。这就是分层设计的价值。2. 数据结构设计与初始化细节2.1 棋盘的数据结构选择2048的棋盘是4×4我用的数据结构是列表的列表即一个包含四个子列表的列表每个子列表的长度也是4board [ [0, 0, 0, 0], [0, 0, 0, 0], [0, 0, 0, 0], [0, 0, 0, 0] ]每个格子要么是0代表空白要么是2的幂次数如2、4、8、16等。选取0作为空白值是因为数字判断更简单——if board[row][col] 0就能判断格子是否为空不需要额外的布尔状态表。你可能会问为什么不直接用numpy的二维数组毕竟矩阵操作方便得多。原因很简单第一是保持零依赖第二是Python原生的二维列表在元素遍历和修改上足够快2048这种规模的数据量只有16个元素远远到不了性能瓶颈numpy在这里属于杀鸡用牛刀。2.2 初始化时如何生成初始数字游戏启动时棋盘上应该有两个随机数字这是2048系列的经典开局配置。实现上需要写一个“在空白格随机生成数字”的函数import random def add_new_number(board): empty_cells [(r, c) for r in range(4) for c in range(4) if board[r][c] 0] if not empty_cells: return False row, col random.choice(empty_cells) board[row][col] 2 if random.random() 0.9 else 4 return True这里有个细节很多人第一次写时会忽略就是新生成数字10%的概率是490%概率是2。这个比例是从原版2048继承下来的。如果全部生成2游戏进程会拖得很长因为合成高阶数字需要太多步数如果4的概率太高前期就很容易合成出较大的数字难度陡增反而失去渐进体验。0.9和0.1这个配比是经过无数玩家验证过的平衡点。初始化时调用两次add_new_number即可。我建议初始棋盘上两个数字不要放在同一行同一列但随机生成也够用——因为如果前两步就出现重叠甚至相邻相同数字最难开局也不过如此程序员要相信随机数。2.3 方向与索引的映射关系在设计移动函数前先明确一个底层约定我们把问题统一到“向某一方向移动所有数字并在移动过程中进行合并”这个单一动作上。这个约定是2048算法层面的核心后面所有的方向处理都建立在它之上。为了让这个约定可操作我建立起一组方向映射向左Left处理第0列到第3列逐行处理整行。向右Right把每行反转后再执行向左的逻辑。向上Up把矩阵转置后执行向左的逻辑。向下Down把矩阵转置并反转每行后执行向左的逻辑。这个办法在开源社区的2048实现里非常经典它避免了写四套独立的移动逻辑。对初学者而言刚开始可能觉得转置、反转会绕弯子不如直接写四个循环来得直白。但当你真正写完全部四个方向的代码后就会意识到用旋转统一处理只需要维护一份核心合并逻辑bug数量直接减少75%因为同一个逻辑不需要同步修改四次。3. 核心算法拆解移动与合并的底层逻辑3.1 一行内的“剔除空格→合并→补回空格”三步法这是整个项目的灵魂。无论最终游戏判断玩家按的是哪个方向落在某一行或某一列上的操作本质都可以抽象成三个连续步骤剔除空格把一个带零的元素序列压缩成非零元素的有序序列。相邻合并从最靠近移动方向的一端开始两两比较相等则合并。补回空格把合并后不足4位的部分用0补齐保持序列长度为4。我用一个最简单的例子先建立直觉假设当前某一行的状态是[2, 0, 2, 4]玩家按键方向是向左那么——剔除空格后得到[2, 2, 4]合并后第一个2和第二个2相等合并成4得到[4, 4]补空格后变成[4, 4, 0, 0]。这就是一次完整的向左移动结果。再举一个更进阶的例子[2, 2, 2, 2]向左移动。剔除空格后还是[2, 2, 2, 2]合并阶段从最左侧开始配对前两个2合成4后两个2也合成4最终得到[4, 4, 0, 0]。注意它不会一次合成[8, 0, 0, 0]因为每次移动只能让同一组相邻数字合并一次不能连锁合并。这个规则很多人第一次写都会写错总想用递归实现“合并到底”结果把2048玩成了合成大西瓜。3.2 合并函数的具体实现与防坑处理我给出一个完整的单行合并函数def merge_single_row(row): # step 1: 剔除零 non_zero [num for num in row if num ! 0] # step 2: 相邻相同的数字合并 merged [] i 0 while i len(non_zero): if i 1 len(non_zero) and non_zero[i] non_zero[i 1]: merged.append(non_zero[i] * 2) i 2 else: merged.append(non_zero[i]) i 1 # step 3: 补零到长度4 return merged [0] * (4 - len(merged))代码的核心是while循环里的i 2。当相邻两个数字相同时合并后的结果只保存一个并且指针直接跨过两个位置这样[2,2,2,2]才会得到[4,4,0,0]而不是[4,2,2,0]。这个函数有一个隐含假设传入的行一定是从靠近移动方向的那一端开始处理的。比如向左移动时传入的就是原始的row向右移动时需要先把row做reverse处理完后再reverse回来。上面的函数不感知方向它永远按传入顺序从左到右处理。统一方向后这个函数可以被四个方向复用。3.3 四个方向的统一处理范式只要写好了merge_single_row四个方向就变得非常工整def move_left(grid): new_grid [] for row in grid: new_row merge_single_row(row) new_grid.append(new_row) return new_grid def move_right(grid): new_grid [] for row in grid: new_row merge_single_row(row[::-1])[::-1] new_grid.append(new_row) return new_grid def move_up(grid): # 先转置相当于把列变成行 transposed [list(col) for col in zip(*grid)] moved move_left(transposed) # 再转置回来 return [list(col) for col in zip(*moved)] def move_down(grid): transposed [list(col) for col in zip(*grid)] moved move_right(transposed) return [list(col) for col in zip(*moved)]这段代码看着简单但里面每句话都有它存在的理由。row[::-1]是把行反转因为向右移动时最右边的元素才是“队头”只有反转后才能用统一的merge_single_row从左到右合并。合并完再[::-1]反转回来才能还原成正常顺序。用zip(*grid)转置是在处理矩阵时十分经典的手法。zip把每行的第一个元素抽出来组成新行正好就是原矩阵的列。由于zip返回的是元组需要再用list()转回来保证每行依旧是列表类型才能顺利做反转操作。考虑到有的读者初学这里我再强调一下“转置”这个概念第一次见会有点迷糊但你就把它理解成“把行变成列把列变成行”。比如[[1,2],[3,4]]转置后变成[[1,3],[2,4]]。这个操作本身不改变数字的相对位置关系只是给它们换了坐标系所以我们在转置后做“向左移动”效果就等价于在原棋盘上“向上移动”。3.4 核心算法易错点深度分析写2048合并且逻辑时最常见的失误有三个。先说第一个合并前忘了剔除零。如果直接遍历原始行遇到两个相同的非零数字中间夹着一个零比如[2, 0, 2, 0]你可能会误判为两个2相邻并合并。正确的做法是先把零挤掉让非零数字靠拢然后再做合并。这也是为什么第一步必须是剔除空格而不是直接遍历。第二个容易出错的地方是合并过程中出现连锁合并。如前面提到的2048的原始规则是每一次移动中每个格子最多参与一次合并。你在写代码时必须用指针跨步的方式保证这一点否则[4,4,4,4]会直接合成[16,0,0,0]这就违背了游戏规则。第三个问题是重组棋盘时不慎改动原引用。因为Python里列表是可变对象如果你直接new_grid grid再修改某项就会连带修改调用方持有的原始棋盘。所以在move_left等函数中我全部使用遍历创建新列表的方式保证每次移动都返回一个全新的棋盘对象原来的棋盘保持不可变。这种“函数式更新”的写法虽然多占用一点内存但能极大地避免调试时因引用共享导致的诡异bug。4. 完整代码实现与运行效果4.1 全部代码一屏构览我把整份可运行代码贴在这里注释尽量写全便于直接复制跑通import os import random import sys BOARD_SIZE 4 def init_board(): board [[0] * BOARD_SIZE for _ in range(BOARD_SIZE)] add_new_number(board) add_new_number(board) return board def add_new_number(board): empty_cells [(r, c) for r in range(BOARD_SIZE) for c in range(BOARD_SIZE) if board[r][c] 0] if not empty_cells: return False row, col random.choice(empty_cells) board[row][col] 2 if random.random() 0.9 else 4 return True def merge_single_row(row): non_zero [num for num in row if num ! 0] merged [] i 0 while i len(non_zero): if i 1 len(non_zero) and non_zero[i] non_zero[i 1]: merged.append(non_zero[i] * 2) i 2 else: merged.append(non_zero[i]) i 1 return merged [0] * (BOARD_SIZE - len(merged)) def move_left(grid): return [merge_single_row(row) for row in grid] def move_right(grid): return [merge_single_row(row[::-1])[::-1] for row in grid] def transpose(grid): return [list(col) for col in zip(*grid)] def move_up(grid): moved move_left(transpose(grid)) return transpose(moved) def move_down(grid): moved move_right(transpose(grid)) return transpose(moved) def has_blank(grid): return any(0 in row for row in grid) def can_merge(grid): for r in range(BOARD_SIZE): for c in range(BOARD_SIZE - 1): if grid[r][c] grid[r][c 1]: return True for r in range(BOARD_SIZE - 1): for c in range(BOARD_SIZE): if grid[r][c] grid[r 1][c]: return True return False def game_over(grid): return not has_blank(grid) and not can_merge(grid) def has_won(grid): return any(2048 in row for row in grid) def draw_board(grid, score): os.system(cls if os.name nt else clear) print(score: {}.format(score)) for row in grid: cells [] for num in row: if num 0: cells.append(.) else: cells.append(str(num)) print(----------------) print(| {:^4}| {:^4}| {:^4}| {:^4}|.format(*cells)) print(----------------) print(W/A/S/D or arrow to move, Q to quit) def get_action(): 尝试读取方向键或WASD。 在Windows下方向键读取为特殊的扩展键需要先读两个字节 在Unix下用curses或sys.stdin也可以处理。 这里简单兼容Win和Linux/macOS两种环境。 if os.name nt: import msvcrt key msvcrt.getwch() if key w or key W: return up elif key s or key S: return down elif key a or key A: return left elif key d or key D: return right elif key q or key Q: return quit elif key \x00 or key \xe0: # 方向键是扩展键再读一个字符 second msvcrt.getwch() arrow_map {H: up, P: down, K: left, M: right} if second in arrow_map: return arrow_map[second] return invalid else: import termios import tty import select fd sys.stdin.fileno() old_settings termios.tcgetattr(fd) try: tty.setraw(fd) if select.select([sys.stdin], [], [], 0.5)[0]: ch sys.stdin.read(1) if ch \x1b: seq sys.stdin.read(2) mapping {[A: up, [B: down, [C: right, [D: left} if seq in mapping: return mapping[seq] else: if ch w or ch W: return up elif ch s or ch S: return down elif ch a or ch A: return left elif ch d or ch D: return right elif ch q or ch Q: return quit return invalid finally: termios.tcsetattr(fd, termios.TCSADRAIN, old_settings) def main(): grid init_board() score 0 while True: draw_board(grid, score) action get_action() if action quit: print(bye!) break if action invalid: continue old_grid [row[:] for row in grid] if action left: grid move_left(grid) elif action right: grid move_right(grid) elif action up: grid move_up(grid) elif action down: grid move_down(grid) # 只有当棋盘实际发生变化时才添加新数字 if grid ! old_grid: add_new_number(grid) # 分数简单累加进阶版可在此处计算合并得分 total sum(sum(row) for row in grid) score total if has_won(grid): draw_board(grid, score) print(你赢了2048) break if game_over(grid): draw_board(grid, score) print(游戏结束) break if __name__ __main__: main()4.2 关键实现要点解说这份代码里有一个非常重要的细节写在主循环里每次移动后只有在棋盘状态发生变化时才生成新数字。这样设计的理由是如果玩家按了一个方向但棋盘上所有数字已经全部贴边、没有任何可移动空间这次按键就是“无效操作”不应该白白消耗一个甚至是多个随机生成的数字。我见过不少初学者在写这个步骤时忽略了这个判断直接在函数调用后无脑调add_new_number结果就出现了一个反直觉的现象按了几次无效方向键之后棋盘反而凭空多出好几个数字游戏难度莫名其妙提升。我这份代码用old_grid [row[:] for row in grid]先做一份深拷贝比较变化前后的值是否一致再做生成新数字的决策。这里的[row[:] for row in grid]不是多余动作不拷贝的话old_grid和grid会指向同一份数据比较就永远为真了这是Python引用语义下的一个典型陷阱。另一个值得展开的是分数计算。我这份代码里的分数只是棋盘所有数字之和非常粗糙真实2048的计分规则其实是“每次合并时累加本次合并产生的数值”。要实现原版计分需要改造merge_single_row让它返回(新行, 本次合并得分)两个值。这个属于进阶改造我会在后面的扩展部分给一个更完整的思路。4.3 运行效果与输入方式说明启动后屏幕上会先画出一个4×4的空棋盘初始状态下已经有一个或两个数字了。终端会持续等待你的输入支持W/A/S/D和方向键两种操作方式。代码里我花了不少篇幅处理跨平台键盘输入的问题这是终端程序最麻烦的地方尤其方向键在Windows下和Linux下编码格式完全不同。Windows下方向键会产生两个字节的转义序列第一个字节是\x00或\xe0第二个字节才是真正的方向标识因此必须分两次读取Linux/macOS下方向键则产生\x1b[A这样的三字符序列一个ESC加两个字符。这段处理逻辑虽然看起来啰嗦但它是保证这个游戏“在任何终端都能跑”的必要部分否则你会听到用户抱怨键盘按了方向键没反应、游戏完全没法玩。如果你用不上方向键只认WASD那这部分代码可以裁剪到很短。5. 常见问题与排查思路这一节汇总了我自己实际运行这个脚本时遇到的、以及身边同事和学生在复现时踩过的一些高频问题按“症状→原因→解法”的顺序排好遇到麻烦可以直接对照查表症状可能原因解决办法按方向键没反应终端编码方式和当前平台不一致尤其时Windows下方向键读取为扩展键码改用WASD操作或检查msvcrt分支是否被正确执行按下按键后游戏直接退出读取输入时进入了原始模式raw mode退出时没有恢复终端设置检查finally块中的termios.tcsetattr是否被调用确保终端配置还原子移动后棋盘上的数字凭空增加在无效移动棋盘未变化时也调用了add_new_number在移动完成后比较新旧棋盘状态仅当状态有变化时才生成新数字一行四格全是相同数字却合并异常合并时没有处理“每次移动每个格子只允许合并一次”的规则使用指针跨步法即i 2跳过已经合并的数字生成的初始数字偶尔会有3个init_board调用add_new_number次数设计不对或初始化时误把先行填充残留检查初始化函数只调用两次add_new_number分数结算不如预期用棋盘总和代替合并得分显示数值略大或时高时低改为合并得分累加修改merge_single_row返回合并产生的分数棋盘显示错位或数字被切掉终端窗口宽度过窄或中文字符显示了额外宽度增大终端窗口或用纯英文/数字作为界面文本在Jupyter或其他Web IDE里无法运行Jupyter内核和终端交互机制不一致原生的sys.stdin读取不可用使用命令行方式运行例如直接python 2048.py除了上面表格里的问题还有一个实际运维层面的坑非常值得单独列出来如果你在Visual Studio Code的集成终端里运行需要确认当前终端是“终端Terminal”而不是“输出Output”面板。输出面板是只读的所有键盘输入都无法被程序读取玩家会感觉自己按什么键游戏都没反应。这是一个非常常见、但不太可能从程序代码层面解决的错配问题。有个调试小技巧也分享出来如果你怀疑某个操作后的棋盘状态不对劲可以在move_left这类函数里加一行临时调试代码打印当前网格的快照再对比理论上的预期结果。通过这种“差分对比法”几分钟内就能定位是合并那步出错还是方向翻转那步出错。6. 进阶优化方向从“能跑”到“更好用”6.1 面向对象重构让代码更模块化上面给出的函数式版本已经足够清晰但如果你想把项目做得更正式一点可以像下面这样把棋盘封装成一个类class Game2048: def __init__(self, size4): self.size size self.board [[0] * size for _ in range(size)] self.score 0 self.reset() def reset(self): ... def move(self, direction): ... property def is_game_over(self): ...类封装带来的最大收益是语义边界更清晰。棋盘状态、分数、游戏是否结束这些概念从“函数参数”变成了“对象属性”主循环调用时不再需要反复传递大列表。这对刚学过面向对象的同学来说是一个很好的练习场景从函数式版本向类版本迁移的过程能直观地感受到“状态归对象”这种设计思想的优势。当然如果你的目标就是期末交作业函数式版本完全够用不必强行套OOP。程序设计的第一原则永远是“能用最简单的方式解决问题就是好方案”。6.2 把分数改造成真实合并计分我在前面提过用sum(board)当分数太粗糙。原版2048的计分规则是每次移动产生的合并数值会完全累加进总分。比如这一行从[2,2,4,0]向左合并成[4,4,0,0]得分应该是前两个2合并产生的4而不是这行所有数字总和8。改造方法很简单只需要让merge_single_row返回两个值def merge_single_row(row): non_zero [num for num in row if num ! 0] merged [] score 0 i 0 while i len(non_zero): if i 1 len(non_zero) and non_zero[i] non_zero[i 1]: merged.append(non_zero[i] * 2) score non_zero[i] * 2 i 2 else: merged.append(non_zero[i]) i 1 return merged [0] * (4 - len(merged)), score然后在move_left等函数中把每次合并产生的score累加到全局总分变量上。这样一个看似微小的改动会让你的版本和原版2048计分体验完全一致。6.3 更高阶的扩展从终端到图形界面如果你想把终端版升级成带GUI的版本核心算法一行都不用改只要替换渲染层。以Pygame为例思路大致是给每个数字匹配一个背景色比如2是淡黄、4是橙、8是红按颜色深浅渐变。定义界面尺寸为400×400每个格子边长100像素格子间距5像素。监听KEYDOWN事件中的方向键调用已有的move_left等方法。每次移动后调用add_new_number然后刷新整个窗口。由于Pygame需要处理的事件类型更多代码量会比终端版大不少但核心的合并且算法完全不需要改变。这也是为什么我在文章开头强调“核心逻辑才是2048的灵魂”的原因。6.4 改变棋盘尺寸与游戏规则最后留一个可玩性拓展的思考方向把棋盘从4×4改成5×5甚至6×6。改动点只有两个。将BOARD_SIZE常量改成5或6所有用range(4)的地方都会自动适配。同时需要调整merge_single_row中补零的数量——它用的是BOARD_SIZE - len(merged)而不是硬编码4所以也自动适配了。另外一个要注意的点是胜利条件5×5棋盘上合成2048的难度会大幅降低你可以把胜利目标调整到4096或8192这会带来全新的策略深度。我这里有个朋友把棋盘改成6×6之后玩出了新体验——因为格子变多了随机生成数字时不容易“堵死”游戏的容错率大幅上升但另一方面要凑齐大数字需要移动更多次一局玩下来耗时明显变长。所以说棋盘尺寸和游戏节奏是强相关的怎么选完全取决于你的偏好。我觉得这个项目最迷人的地方就是上限极高、下限极低。刚入门的人两小时就能把代码跑通体验到“自己写的游戏”带来的成就感有经验的人则可以在上面不断打磨把终端版改成GUI、加入AI自动求解、引入更复杂的计分规则当一个长期练手项目来维护。我自己在写这个脚本的过程中最大的收获其实不是这份代码而是彻底搞懂了“列表引用与深拷贝”“状态变化的检测”“矩阵操作的坐标变换”这三个Python难以绕开的基础概念这些都是在做业务需求时很难专门训练到的底层能力。
摸鱼这事儿讲究的是“看起来忙得不行实际上脑子已经放空一半”。同事用网页版2048容易被浏览器历史记录出卖装个完整GUI游戏又显得太高调。我的方案是用Python在终端里直接跑一个2048终端窗口小字体调暗远远望去就是一堆日志在滚动手指微动就能控制左右非常适合带薪放松。当然说正经的2048也是一个极其经典的算法练手项目——二维数组操作、方向变换、状态判断、随机数生成几乎覆盖了Python基础阶段的全部重点用来巩固逻辑思维比刷一百道填空题强得多。这篇文章我会把整个实现过程完整拆开讲包括数据结构怎么设计、移动和合并的算法细节怎么处理、完整的可运行代码怎么组织、以及我实际调试过程中踩过的几个坑。无论你是想交期末作业还是想找个能跑起来不依赖第三方库的小项目练手这篇内容都够用了。1. 项目概述与整体设计思路1.1 为什么选终端版2048先把话说明白市面上现成的2048项目一大把Python版从Pygame图形版到网页版都有现成仓库我自己也维护过好几个版本但最终用得最顺手、改起来最快、讲给别人听最容易的还是这个终端版。原因很简单它不需要任何第三方依赖不用Pygame、不用Numpy一个纯标准库就能跑起来。这一点在真实工作环境里特别重要。很多公司的电脑对软件安装有严格管控Pip装个numpy还好说装个带图形界面的Pygame可能会触发安全审批。而用Terminal跑一个纯Python脚本既不需要额外解释也不需要权限申请扔到任意一台Python 3.6以上的机器上都能直接运行。从算法学习的角度看终端版还有一个隐藏优势没有图形渲染的干扰所有核心逻辑都被迫暴露在明面上。2048的真正难度从来不在画格子、画数字而在“方块如何合并”“四个方向的移动如何用一套逻辑统一处理”“游戏何时结束”这三个问题上。Pygame版本里很多逻辑被GUI事件掩盖了但终端版的每个按键、每次刷新棋盘背后都是纯逻辑代码在跑这反而是最好的教学状态。1.2 技术方案选型的两个关键取舍写这个项目前我反复权衡过两个技术方案一是纯标准库的终端渲染方案二是Pygame图形化方案。最终选了前者但这不是说后者就不好而是两者的定位完全不同。终端渲染方案的全部代码加起来不超过两百行主循环就是一个while接键盘输入每次按键后清屏重绘。这种方式代码量小、逻辑集中、跨平台性好而且在任何一台机器上都能解释——因为你只需要一个Python解释器。缺点也很明显界面比较朴素没有平滑移动动画数字跳变时手感略生硬。Pygame方案则能做出很像样的动画效果方块滑动时有缓动、合并时有缩放特效玩起来体验完全不输手机版。但缺陷是代码量会翻好几倍还要额外处理窗口事件、字体渲染、图片素材库对初学者来说复杂度会陡然上升。我给的建议很直接如果你是第一次写2048或者说你的核心诉求是理解算法逻辑或者你连Pygame都没装过直接选终端版。如果你本身对Pygame已经比较熟悉只是想做个更完整的作品那可以考虑用后面“优化扩展”章节里给的Pygame核心逻辑改造方案那段代码只替换了渲染层算法层是百分百复用的。1.3 程序架构的顶层拆解终端版2048的架构非常克制我把它分成了四个逻辑层虽然代码里没有刻意做分层封装但阅读时按这个思路走会清晰很多数据层一个4×4的二维列表表示整个棋盘状态。之所以用二维列表而不是一维列表或字典是因为二维列表最直观board[row][col]直接对应屏幕上第几行第几列理解成本和操作成本都最低。逻辑层移动、合并、判断游戏状态这三个核心函数负责修改棋盘数据。渲染层把棋盘数据打印到终端用\033控制光标位置实现原地刷新。输入层接收键盘上的方向键或WASD映射成四个方向的移动操作。这种分层的好处是如果以后想改成Pygame版只需要替换渲染层和输入层逻辑层一行都不用动。反过来如果你想把棋盘从4×4扩成5×5只需要修改数据层的初始化代码和一个判断边界的地方其他完全不用改。这就是分层设计的价值。2. 数据结构设计与初始化细节2.1 棋盘的数据结构选择2048的棋盘是4×4我用的数据结构是列表的列表即一个包含四个子列表的列表每个子列表的长度也是4board [ [0, 0, 0, 0], [0, 0, 0, 0], [0, 0, 0, 0], [0, 0, 0, 0] ]每个格子要么是0代表空白要么是2的幂次数如2、4、8、16等。选取0作为空白值是因为数字判断更简单——if board[row][col] 0就能判断格子是否为空不需要额外的布尔状态表。你可能会问为什么不直接用numpy的二维数组毕竟矩阵操作方便得多。原因很简单第一是保持零依赖第二是Python原生的二维列表在元素遍历和修改上足够快2048这种规模的数据量只有16个元素远远到不了性能瓶颈numpy在这里属于杀鸡用牛刀。2.2 初始化时如何生成初始数字游戏启动时棋盘上应该有两个随机数字这是2048系列的经典开局配置。实现上需要写一个“在空白格随机生成数字”的函数import random def add_new_number(board): empty_cells [(r, c) for r in range(4) for c in range(4) if board[r][c] 0] if not empty_cells: return False row, col random.choice(empty_cells) board[row][col] 2 if random.random() 0.9 else 4 return True这里有个细节很多人第一次写时会忽略就是新生成数字10%的概率是490%概率是2。这个比例是从原版2048继承下来的。如果全部生成2游戏进程会拖得很长因为合成高阶数字需要太多步数如果4的概率太高前期就很容易合成出较大的数字难度陡增反而失去渐进体验。0.9和0.1这个配比是经过无数玩家验证过的平衡点。初始化时调用两次add_new_number即可。我建议初始棋盘上两个数字不要放在同一行同一列但随机生成也够用——因为如果前两步就出现重叠甚至相邻相同数字最难开局也不过如此程序员要相信随机数。2.3 方向与索引的映射关系在设计移动函数前先明确一个底层约定我们把问题统一到“向某一方向移动所有数字并在移动过程中进行合并”这个单一动作上。这个约定是2048算法层面的核心后面所有的方向处理都建立在它之上。为了让这个约定可操作我建立起一组方向映射向左Left处理第0列到第3列逐行处理整行。向右Right把每行反转后再执行向左的逻辑。向上Up把矩阵转置后执行向左的逻辑。向下Down把矩阵转置并反转每行后执行向左的逻辑。这个办法在开源社区的2048实现里非常经典它避免了写四套独立的移动逻辑。对初学者而言刚开始可能觉得转置、反转会绕弯子不如直接写四个循环来得直白。但当你真正写完全部四个方向的代码后就会意识到用旋转统一处理只需要维护一份核心合并逻辑bug数量直接减少75%因为同一个逻辑不需要同步修改四次。3. 核心算法拆解移动与合并的底层逻辑3.1 一行内的“剔除空格→合并→补回空格”三步法这是整个项目的灵魂。无论最终游戏判断玩家按的是哪个方向落在某一行或某一列上的操作本质都可以抽象成三个连续步骤剔除空格把一个带零的元素序列压缩成非零元素的有序序列。相邻合并从最靠近移动方向的一端开始两两比较相等则合并。补回空格把合并后不足4位的部分用0补齐保持序列长度为4。我用一个最简单的例子先建立直觉假设当前某一行的状态是[2, 0, 2, 4]玩家按键方向是向左那么——剔除空格后得到[2, 2, 4]合并后第一个2和第二个2相等合并成4得到[4, 4]补空格后变成[4, 4, 0, 0]。这就是一次完整的向左移动结果。再举一个更进阶的例子[2, 2, 2, 2]向左移动。剔除空格后还是[2, 2, 2, 2]合并阶段从最左侧开始配对前两个2合成4后两个2也合成4最终得到[4, 4, 0, 0]。注意它不会一次合成[8, 0, 0, 0]因为每次移动只能让同一组相邻数字合并一次不能连锁合并。这个规则很多人第一次写都会写错总想用递归实现“合并到底”结果把2048玩成了合成大西瓜。3.2 合并函数的具体实现与防坑处理我给出一个完整的单行合并函数def merge_single_row(row): # step 1: 剔除零 non_zero [num for num in row if num ! 0] # step 2: 相邻相同的数字合并 merged [] i 0 while i len(non_zero): if i 1 len(non_zero) and non_zero[i] non_zero[i 1]: merged.append(non_zero[i] * 2) i 2 else: merged.append(non_zero[i]) i 1 # step 3: 补零到长度4 return merged [0] * (4 - len(merged))代码的核心是while循环里的i 2。当相邻两个数字相同时合并后的结果只保存一个并且指针直接跨过两个位置这样[2,2,2,2]才会得到[4,4,0,0]而不是[4,2,2,0]。这个函数有一个隐含假设传入的行一定是从靠近移动方向的那一端开始处理的。比如向左移动时传入的就是原始的row向右移动时需要先把row做reverse处理完后再reverse回来。上面的函数不感知方向它永远按传入顺序从左到右处理。统一方向后这个函数可以被四个方向复用。3.3 四个方向的统一处理范式只要写好了merge_single_row四个方向就变得非常工整def move_left(grid): new_grid [] for row in grid: new_row merge_single_row(row) new_grid.append(new_row) return new_grid def move_right(grid): new_grid [] for row in grid: new_row merge_single_row(row[::-1])[::-1] new_grid.append(new_row) return new_grid def move_up(grid): # 先转置相当于把列变成行 transposed [list(col) for col in zip(*grid)] moved move_left(transposed) # 再转置回来 return [list(col) for col in zip(*moved)] def move_down(grid): transposed [list(col) for col in zip(*grid)] moved move_right(transposed) return [list(col) for col in zip(*moved)]这段代码看着简单但里面每句话都有它存在的理由。row[::-1]是把行反转因为向右移动时最右边的元素才是“队头”只有反转后才能用统一的merge_single_row从左到右合并。合并完再[::-1]反转回来才能还原成正常顺序。用zip(*grid)转置是在处理矩阵时十分经典的手法。zip把每行的第一个元素抽出来组成新行正好就是原矩阵的列。由于zip返回的是元组需要再用list()转回来保证每行依旧是列表类型才能顺利做反转操作。考虑到有的读者初学这里我再强调一下“转置”这个概念第一次见会有点迷糊但你就把它理解成“把行变成列把列变成行”。比如[[1,2],[3,4]]转置后变成[[1,3],[2,4]]。这个操作本身不改变数字的相对位置关系只是给它们换了坐标系所以我们在转置后做“向左移动”效果就等价于在原棋盘上“向上移动”。3.4 核心算法易错点深度分析写2048合并且逻辑时最常见的失误有三个。先说第一个合并前忘了剔除零。如果直接遍历原始行遇到两个相同的非零数字中间夹着一个零比如[2, 0, 2, 0]你可能会误判为两个2相邻并合并。正确的做法是先把零挤掉让非零数字靠拢然后再做合并。这也是为什么第一步必须是剔除空格而不是直接遍历。第二个容易出错的地方是合并过程中出现连锁合并。如前面提到的2048的原始规则是每一次移动中每个格子最多参与一次合并。你在写代码时必须用指针跨步的方式保证这一点否则[4,4,4,4]会直接合成[16,0,0,0]这就违背了游戏规则。第三个问题是重组棋盘时不慎改动原引用。因为Python里列表是可变对象如果你直接new_grid grid再修改某项就会连带修改调用方持有的原始棋盘。所以在move_left等函数中我全部使用遍历创建新列表的方式保证每次移动都返回一个全新的棋盘对象原来的棋盘保持不可变。这种“函数式更新”的写法虽然多占用一点内存但能极大地避免调试时因引用共享导致的诡异bug。4. 完整代码实现与运行效果4.1 全部代码一屏构览我把整份可运行代码贴在这里注释尽量写全便于直接复制跑通import os import random import sys BOARD_SIZE 4 def init_board(): board [[0] * BOARD_SIZE for _ in range(BOARD_SIZE)] add_new_number(board) add_new_number(board) return board def add_new_number(board): empty_cells [(r, c) for r in range(BOARD_SIZE) for c in range(BOARD_SIZE) if board[r][c] 0] if not empty_cells: return False row, col random.choice(empty_cells) board[row][col] 2 if random.random() 0.9 else 4 return True def merge_single_row(row): non_zero [num for num in row if num ! 0] merged [] i 0 while i len(non_zero): if i 1 len(non_zero) and non_zero[i] non_zero[i 1]: merged.append(non_zero[i] * 2) i 2 else: merged.append(non_zero[i]) i 1 return merged [0] * (BOARD_SIZE - len(merged)) def move_left(grid): return [merge_single_row(row) for row in grid] def move_right(grid): return [merge_single_row(row[::-1])[::-1] for row in grid] def transpose(grid): return [list(col) for col in zip(*grid)] def move_up(grid): moved move_left(transpose(grid)) return transpose(moved) def move_down(grid): moved move_right(transpose(grid)) return transpose(moved) def has_blank(grid): return any(0 in row for row in grid) def can_merge(grid): for r in range(BOARD_SIZE): for c in range(BOARD_SIZE - 1): if grid[r][c] grid[r][c 1]: return True for r in range(BOARD_SIZE - 1): for c in range(BOARD_SIZE): if grid[r][c] grid[r 1][c]: return True return False def game_over(grid): return not has_blank(grid) and not can_merge(grid) def has_won(grid): return any(2048 in row for row in grid) def draw_board(grid, score): os.system(cls if os.name nt else clear) print(score: {}.format(score)) for row in grid: cells [] for num in row: if num 0: cells.append(.) else: cells.append(str(num)) print(----------------) print(| {:^4}| {:^4}| {:^4}| {:^4}|.format(*cells)) print(----------------) print(W/A/S/D or arrow to move, Q to quit) def get_action(): 尝试读取方向键或WASD。 在Windows下方向键读取为特殊的扩展键需要先读两个字节 在Unix下用curses或sys.stdin也可以处理。 这里简单兼容Win和Linux/macOS两种环境。 if os.name nt: import msvcrt key msvcrt.getwch() if key w or key W: return up elif key s or key S: return down elif key a or key A: return left elif key d or key D: return right elif key q or key Q: return quit elif key \x00 or key \xe0: # 方向键是扩展键再读一个字符 second msvcrt.getwch() arrow_map {H: up, P: down, K: left, M: right} if second in arrow_map: return arrow_map[second] return invalid else: import termios import tty import select fd sys.stdin.fileno() old_settings termios.tcgetattr(fd) try: tty.setraw(fd) if select.select([sys.stdin], [], [], 0.5)[0]: ch sys.stdin.read(1) if ch \x1b: seq sys.stdin.read(2) mapping {[A: up, [B: down, [C: right, [D: left} if seq in mapping: return mapping[seq] else: if ch w or ch W: return up elif ch s or ch S: return down elif ch a or ch A: return left elif ch d or ch D: return right elif ch q or ch Q: return quit return invalid finally: termios.tcsetattr(fd, termios.TCSADRAIN, old_settings) def main(): grid init_board() score 0 while True: draw_board(grid, score) action get_action() if action quit: print(bye!) break if action invalid: continue old_grid [row[:] for row in grid] if action left: grid move_left(grid) elif action right: grid move_right(grid) elif action up: grid move_up(grid) elif action down: grid move_down(grid) # 只有当棋盘实际发生变化时才添加新数字 if grid ! old_grid: add_new_number(grid) # 分数简单累加进阶版可在此处计算合并得分 total sum(sum(row) for row in grid) score total if has_won(grid): draw_board(grid, score) print(你赢了2048) break if game_over(grid): draw_board(grid, score) print(游戏结束) break if __name__ __main__: main()4.2 关键实现要点解说这份代码里有一个非常重要的细节写在主循环里每次移动后只有在棋盘状态发生变化时才生成新数字。这样设计的理由是如果玩家按了一个方向但棋盘上所有数字已经全部贴边、没有任何可移动空间这次按键就是“无效操作”不应该白白消耗一个甚至是多个随机生成的数字。我见过不少初学者在写这个步骤时忽略了这个判断直接在函数调用后无脑调add_new_number结果就出现了一个反直觉的现象按了几次无效方向键之后棋盘反而凭空多出好几个数字游戏难度莫名其妙提升。我这份代码用old_grid [row[:] for row in grid]先做一份深拷贝比较变化前后的值是否一致再做生成新数字的决策。这里的[row[:] for row in grid]不是多余动作不拷贝的话old_grid和grid会指向同一份数据比较就永远为真了这是Python引用语义下的一个典型陷阱。另一个值得展开的是分数计算。我这份代码里的分数只是棋盘所有数字之和非常粗糙真实2048的计分规则其实是“每次合并时累加本次合并产生的数值”。要实现原版计分需要改造merge_single_row让它返回(新行, 本次合并得分)两个值。这个属于进阶改造我会在后面的扩展部分给一个更完整的思路。4.3 运行效果与输入方式说明启动后屏幕上会先画出一个4×4的空棋盘初始状态下已经有一个或两个数字了。终端会持续等待你的输入支持W/A/S/D和方向键两种操作方式。代码里我花了不少篇幅处理跨平台键盘输入的问题这是终端程序最麻烦的地方尤其方向键在Windows下和Linux下编码格式完全不同。Windows下方向键会产生两个字节的转义序列第一个字节是\x00或\xe0第二个字节才是真正的方向标识因此必须分两次读取Linux/macOS下方向键则产生\x1b[A这样的三字符序列一个ESC加两个字符。这段处理逻辑虽然看起来啰嗦但它是保证这个游戏“在任何终端都能跑”的必要部分否则你会听到用户抱怨键盘按了方向键没反应、游戏完全没法玩。如果你用不上方向键只认WASD那这部分代码可以裁剪到很短。5. 常见问题与排查思路这一节汇总了我自己实际运行这个脚本时遇到的、以及身边同事和学生在复现时踩过的一些高频问题按“症状→原因→解法”的顺序排好遇到麻烦可以直接对照查表症状可能原因解决办法按方向键没反应终端编码方式和当前平台不一致尤其时Windows下方向键读取为扩展键码改用WASD操作或检查msvcrt分支是否被正确执行按下按键后游戏直接退出读取输入时进入了原始模式raw mode退出时没有恢复终端设置检查finally块中的termios.tcsetattr是否被调用确保终端配置还原子移动后棋盘上的数字凭空增加在无效移动棋盘未变化时也调用了add_new_number在移动完成后比较新旧棋盘状态仅当状态有变化时才生成新数字一行四格全是相同数字却合并异常合并时没有处理“每次移动每个格子只允许合并一次”的规则使用指针跨步法即i 2跳过已经合并的数字生成的初始数字偶尔会有3个init_board调用add_new_number次数设计不对或初始化时误把先行填充残留检查初始化函数只调用两次add_new_number分数结算不如预期用棋盘总和代替合并得分显示数值略大或时高时低改为合并得分累加修改merge_single_row返回合并产生的分数棋盘显示错位或数字被切掉终端窗口宽度过窄或中文字符显示了额外宽度增大终端窗口或用纯英文/数字作为界面文本在Jupyter或其他Web IDE里无法运行Jupyter内核和终端交互机制不一致原生的sys.stdin读取不可用使用命令行方式运行例如直接python 2048.py除了上面表格里的问题还有一个实际运维层面的坑非常值得单独列出来如果你在Visual Studio Code的集成终端里运行需要确认当前终端是“终端Terminal”而不是“输出Output”面板。输出面板是只读的所有键盘输入都无法被程序读取玩家会感觉自己按什么键游戏都没反应。这是一个非常常见、但不太可能从程序代码层面解决的错配问题。有个调试小技巧也分享出来如果你怀疑某个操作后的棋盘状态不对劲可以在move_left这类函数里加一行临时调试代码打印当前网格的快照再对比理论上的预期结果。通过这种“差分对比法”几分钟内就能定位是合并那步出错还是方向翻转那步出错。6. 进阶优化方向从“能跑”到“更好用”6.1 面向对象重构让代码更模块化上面给出的函数式版本已经足够清晰但如果你想把项目做得更正式一点可以像下面这样把棋盘封装成一个类class Game2048: def __init__(self, size4): self.size size self.board [[0] * size for _ in range(size)] self.score 0 self.reset() def reset(self): ... def move(self, direction): ... property def is_game_over(self): ...类封装带来的最大收益是语义边界更清晰。棋盘状态、分数、游戏是否结束这些概念从“函数参数”变成了“对象属性”主循环调用时不再需要反复传递大列表。这对刚学过面向对象的同学来说是一个很好的练习场景从函数式版本向类版本迁移的过程能直观地感受到“状态归对象”这种设计思想的优势。当然如果你的目标就是期末交作业函数式版本完全够用不必强行套OOP。程序设计的第一原则永远是“能用最简单的方式解决问题就是好方案”。6.2 把分数改造成真实合并计分我在前面提过用sum(board)当分数太粗糙。原版2048的计分规则是每次移动产生的合并数值会完全累加进总分。比如这一行从[2,2,4,0]向左合并成[4,4,0,0]得分应该是前两个2合并产生的4而不是这行所有数字总和8。改造方法很简单只需要让merge_single_row返回两个值def merge_single_row(row): non_zero [num for num in row if num ! 0] merged [] score 0 i 0 while i len(non_zero): if i 1 len(non_zero) and non_zero[i] non_zero[i 1]: merged.append(non_zero[i] * 2) score non_zero[i] * 2 i 2 else: merged.append(non_zero[i]) i 1 return merged [0] * (4 - len(merged)), score然后在move_left等函数中把每次合并产生的score累加到全局总分变量上。这样一个看似微小的改动会让你的版本和原版2048计分体验完全一致。6.3 更高阶的扩展从终端到图形界面如果你想把终端版升级成带GUI的版本核心算法一行都不用改只要替换渲染层。以Pygame为例思路大致是给每个数字匹配一个背景色比如2是淡黄、4是橙、8是红按颜色深浅渐变。定义界面尺寸为400×400每个格子边长100像素格子间距5像素。监听KEYDOWN事件中的方向键调用已有的move_left等方法。每次移动后调用add_new_number然后刷新整个窗口。由于Pygame需要处理的事件类型更多代码量会比终端版大不少但核心的合并且算法完全不需要改变。这也是为什么我在文章开头强调“核心逻辑才是2048的灵魂”的原因。6.4 改变棋盘尺寸与游戏规则最后留一个可玩性拓展的思考方向把棋盘从4×4改成5×5甚至6×6。改动点只有两个。将BOARD_SIZE常量改成5或6所有用range(4)的地方都会自动适配。同时需要调整merge_single_row中补零的数量——它用的是BOARD_SIZE - len(merged)而不是硬编码4所以也自动适配了。另外一个要注意的点是胜利条件5×5棋盘上合成2048的难度会大幅降低你可以把胜利目标调整到4096或8192这会带来全新的策略深度。我这里有个朋友把棋盘改成6×6之后玩出了新体验——因为格子变多了随机生成数字时不容易“堵死”游戏的容错率大幅上升但另一方面要凑齐大数字需要移动更多次一局玩下来耗时明显变长。所以说棋盘尺寸和游戏节奏是强相关的怎么选完全取决于你的偏好。我觉得这个项目最迷人的地方就是上限极高、下限极低。刚入门的人两小时就能把代码跑通体验到“自己写的游戏”带来的成就感有经验的人则可以在上面不断打磨把终端版改成GUI、加入AI自动求解、引入更复杂的计分规则当一个长期练手项目来维护。我自己在写这个脚本的过程中最大的收获其实不是这份代码而是彻底搞懂了“列表引用与深拷贝”“状态变化的检测”“矩阵操作的坐标变换”这三个Python难以绕开的基础概念这些都是在做业务需求时很难专门训练到的底层能力。
