“零经验 Java 程序员”做游戏最容易卡住的不是引擎不是美术资源也不是那套看起来很高深的技术方案而是“到底先干什么”。这篇文章想说的是如果完全没有游戏开发经验第一件事不是选引擎不是找素材而是新建一个文件夹给自己搭一个可以反复改、可以提交、可以回滚的开发环境。这篇开发日志记录了从空文件夹到一个能跑的 Java 游戏窗口的完整过程技术选型、Maven 工程结构、Swing 游戏循环、键盘输入、问题排查和下一步计划。适合那些写过 Java 后端或 CRUD 业务代码、但从来没碰过游戏开发的程序员也适合正在犹豫要不要用 Java 做一个 2D 小游戏的人。1. 为什么零经验的 Java 程序员会想做游戏做游戏这件事对 Java 程序员来说一直有一种又近又远的感觉。说近是因为 Java 本身就能写图形界面、做网络通讯、处理多媒体从理论上讲做一个 2D 游戏并不缺基础能力。说远是因为日常业务开发里大家写的都是接口、事务、报表、定时任务很少有机会接触渲染、游戏循环、碰撞检测这些概念。一旦切换到游戏开发很多熟悉的 Java 经验不一定直接适用甚至会变成认知包袱。这里真正要解决的不是“用 Java 做游戏行不行”的问题而是“一个零游戏开发经验的人怎么迈出第一步又不被第一步吓退”。常见的失败路径是上来先选一个重量级引擎看一堆架构概念写了半个月代码最后连一个能动的方块都没跑出来。更稳妥的路径是先做最小闭环把“窗口、循环、输入、渲染”这四个最基本的游戏元素跑通再逐步往里面加内容。开发日志的价值就在这里。日志本身不是 TODO 列表也不是工作总结它记录的是决策过程。比如为什么这个版本用了 JFrame 而不是 LibGDX为什么绘制角色用的是 JPanel 而不是直接画窗口为什么输入状态要用布尔变量而不是监听按键事件后立即移动这些问题如果不记录下来下周再看代码时你只会看到一堆“能跑但不知道当初为什么这么写”的代码。如果你也在犹豫给自己定一个非常小的目标今天只做一个黑色窗口窗口里有一个方块这个方块能用键盘控制移动。做完这个再讨论“做游戏”才不心虚。2. Java 游戏开发的技术选型先别急着上引擎零经验做游戏最容易在技术选型上浪费大量时间。Java 生态里能做游戏的技术方案不少但各自解决的方向完全不一样。方案类型上手难度适合场景是否需要额外资源Swing / AWT桌面 GUI 框架低学习 2D 渲染、事件、线程的入门 demo不需要JavaFX桌面 GUI 框架中做小游戏 UI 混合应用自带动画和媒体支持需要 JavaFX 依赖LibGDX跨平台游戏框架中高2D/3D 小型游戏、Android/Desktop 发布需要理解生命周期、资源管理LWJGL底层图形绑定高OpenGL/Vulkan 学习、自研引擎需要图形学基础jMonkeyEngine3D 游戏引擎高中型 3D 游戏需要模型、场景、渲染管线知识如果目标是“用 Java 完整做一款能发布的 2D 游戏”LibGDX 是一个更合理的长期选择它有生命周期、场景管理、纹理加载、音频播放比 Swing 更像游戏引擎。但如果是零经验第一次开发日志就直接上 LibGDX学习负荷会集中在框架本身而不是游戏逻辑。你会同时面对“游戏怎么循环”“贴图怎么加载”“场景怎么切换”“输入怎么映射”几个新问题很容易无从下手。所以我的决定是第一个版本用 Swing 做一个最简 Demo。这个选择有三个理由Swing 是 JDK 自带的零额外依赖它的事件模型和绘制模型能帮助理解游戏循环的底层逻辑后续换成 LibGDX 时游戏状态、输入状态、更新逻辑这些经验完全可以迁移不会白做。这个决定的代价也很直接Swing 不是正经游戏框架做复杂游戏后期会比较吃力。但这篇文章只解决“起步”问题不需要为未来两年买单。3. 环境准备与前置条件这次开发日志只用 Java 和 Maven不引入第三方库。环境要求非常简单只要你的电脑能编译普通 Java 项目就可以。3.1 需要准备的工具有哪些JDK建议使用 17 或更新的长期支持版本。Maven 3.8 或更高版本用于统一构建路径。IDEIntelliJ IDEA、Eclipse、VS Code 都可以。一个干净的目录用来存放这个项目。版本方面有一点提醒不要一上来就用最新非 LTS 版本除非你很清楚新特性在做什么。对零经验来说稳定比新鲜更重要。JDK 17 的语法支持足够覆盖本文所有代码。3.2 先检查环境打开命令行工具执行下面三条命令确认基础环境可用java -version javac -version mvn -version如果java -version能正常输出版本信息说明 JDK 已安装。如果mvn -version提示找不到命令说明 Maven 没有安装或者没有配置环境变量。这个阶段不需要追求最新版本只要能正常编译运行即可。3.3 创建项目文件夹从准备一个空目录开始。这个目录就是整个开发日志的物质载体。mkdir zero-game-log-01 cd zero-game-log-01这一步看起来很傻但它真的是一个项目的起点。接下来所有的依赖、源码、测试、文档都会从这个文件夹开始不断积累。同时把git init顺手做掉能让你在接下来的每一步改动里都留下提交记录这对开发日志来说尤其重要。git init4. 项目结构设计用一个最小可运行方案代替脑补很多零经验刚做游戏时会在脑海里先设计出几十个类Player、Enemy、Bullet、GameMap、AnimationManager。这类设计当然很好但对第一次跑通的 demo 来说过度设计比缺少设计更危险因为你会把大量时间花在类与类之间的关系上而不是验证游戏是否真的能跑。这个项目第一版只需要三个东西一个入口类负责创建窗口、启动游戏循环。一个面板类负责保存游戏状态、处理键盘输入、绘制画面。一份 pom.xml让 Maven 能把项目编译起来。先把目录结构建出来zero-game-log-01 ├── pom.xml ├── .gitignore └── src └── main └── java └── com └── example └── game ├── Main.java └── GamePanel.java这个结构对应 Maven 的标准目录约定。src/main/java是源码根目录pom.xml保存项目配置。为了后续调试方便我最少会再加上一个.gitignore避免把 IDE 配置和编译产物提交到仓库里。.gitignore内容先写这几行target/ .idea/ *.iml .vscode/ .DS_Store4.1 pom.xml先用最小配置跑通第一版不要加任何游戏库只保留 Maven 编译插件和项目基础信息。这样能保证项目在任何没有特殊依赖的 CI 环境里都能编译。?xml version1.0 encodingUTF-8? project xmlnshttp://maven.apache.org/POM/4.0.0 xmlns:xsihttp://www.w3.org/2001/XMLSchema-instance xsi:schemaLocationhttp://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd modelVersion4.0.0/modelVersion groupIdcom.example/groupId artifactIdzero-game-log-01/artifactId version0.1.0-SNAPSHOT/version packagingjar/packaging properties maven.compiler.source17/maven.compiler.source maven.compiler.target17/maven.compiler.target project.build.sourceEncodingUTF-8/project.build.sourceEncoding /properties /projectcom.example是示例的 groupId实际项目可以换成公司或个人域名倒写。artifactId是项目名称对应文件夹名。Maven 的编译插件在 JDK 17 下可以使用maven.compiler.source和maven.compiler.target属性来指定 Java 版本不需要写完整的插件版本号。这段配置不需要联网下载任何游戏引擎依赖只要把 Maven 的本地仓库加载好基本都能编译通过。5. 核心代码实现最小窗口 游戏循环 键盘移动这一节走到真正写代码的阶段。目标是跑起来一个 800x600 的黑色窗口里面有一个青色方块按方向键或 WASD 能移动方块不会跑出窗口边界。5.1 入口类 Main.java入口类负责创建 JFrame添加游戏面板然后启动一个定时循环。// 文件路径src/main/java/com/example/game/Main.java package com.example.game; import javax.swing.JFrame; import javax.swing.SwingUtilities; import javax.swing.Timer; public class Main { public static void main(String[] args) { SwingUtilities.invokeLater(Main::createAndShowWindow); } private static void createAndShowWindow() { JFrame frame new JFrame(开发日志#1会移动的方块); frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); frame.setResizable(true); GamePanel gamePanel new GamePanel(); frame.setContentPane(gamePanel); // 根据面板的大小调整窗口尺寸 frame.pack(); frame.setLocationRelativeTo(null); frame.setVisible(true); // 16ms 一帧约 60FPS Timer timer new Timer(16, event - { gamePanel.update(); gamePanel.repaint(); }); timer.start(); } }这段代码里有几个关键点需要解释。SwingUtilities.invokeLater把窗口创建放到 Swing 事件派发线程EDT上。Swing 并不是线程安全的所有 UI 组件的创建、修改、绘制都应该在 EDT 上完成。main 方法本身不是 EDT所以不要直接在 main 里创建窗口。frame.setContentPane(gamePanel)直接把游戏面板设置成窗口内容。这个面板负责显示游戏画面。frame.pack()会让窗口根据面板的 preferredSize 自动调整到合适大小这也是为什么后面 GamePanel 里需要设置 preferredSize。Timer是 Swing 提供的定时器它的回调事件在 EDT 上触发。每 16ms 执行一次update和repaint。粗看就是游戏循环更新状态再绘制画面。这里的 16ms 不是硬实时但它足够作为一个入门 demo 的帧率控制方式。5.2 游戏面板 GamePanel.javaGamePanel 是核心。它至少要承担三件事保存玩家位置、响应键盘输入、每帧绘制画面。// 文件路径src/main/java/com/example/game/GamePanel.java package com.example.game; import javax.swing.JPanel; import java.awt.Color; import java.awt.Dimension; import java.awt.Graphics; import java.awt.event.KeyEvent; import java.awt.event.KeyListener; public class GamePanel extends JPanel implements KeyListener { // 玩家初始位置 private int playerX 100; private int playerY 100; // 玩家大小和移动步长 private static final int PLAYER_SIZE 40; private static final int STEP 10; // 方向输入状态 private boolean leftPressed; private boolean rightPressed; private boolean upPressed; private boolean downPressed; public GamePanel() { setPreferredSize(new Dimension(800, 600)); setBackground(Color.BLACK); setFocusable(true); addKeyListener(this); } // 每帧更新游戏状态 public void update() { if (leftPressed) { playerX - STEP; } if (rightPressed) { playerX STEP; } if (upPressed) { playerY - STEP; } if (downPressed) { playerY STEP; } // 边界限制防止方块移出窗口 if (playerX 0) { playerX 0; } if (playerX getWidth() - PLAYER_SIZE) { playerX getWidth() - PLAYER_SIZE; } if (playerY 0) { playerY 0; } if (playerY getHeight() - PLAYER_SIZE) { playerY getHeight() - PLAYER_SIZE; } } // 绘制画面 Override protected void paintComponent(Graphics g) { super.paintComponent(g); g.setColor(Color.CYAN); g.fillRect(playerX, playerY, PLAYER_SIZE, PLAYER_SIZE); } // 按下按键时记录状态 Override public void keyPressed(KeyEvent e) { int code e.getKeyCode(); if (code KeyEvent.VK_LEFT || code KeyEvent.VK_A) { leftPressed true; } if (code KeyEvent.VK_RIGHT || code KeyEvent.VK_D) { rightPressed true; } if (code KeyEvent.VK_UP || code KeyEvent.VK_W) { upPressed true; } if (code KeyEvent.VK_DOWN || code KeyEvent.VK_S) { downPressed true; } } // 松开按键时取消状态 Override public void keyReleased(KeyEvent e) { int code e.getKeyCode(); if (code KeyEvent.VK_LEFT || code KeyEvent.VK_A) { leftPressed false; } if (code KeyEvent.VK_RIGHT || code KeyEvent.VK_D) { rightPressed false; } if (code KeyEvent.VK_UP || code KeyEvent.VK_W) { upPressed false; } if (code KeyEvent.VK_DOWN || code KeyEvent.VK_S) { downPressed false; } } // KeyListener 要求实现的方法这里不需要处理 Override public void keyTyped(KeyEvent e) { } }这段代码的核心逻辑可以拆成四个部分第一部分是游戏状态。playerX和playerY表示玩家方块在面板坐标系中的位置PLAYER_SIZE是玩家尺寸。坐标系统从窗口左上角开始向右为 X 增加向下为 Y 增加。这跟数学课上常见的“Y 轴向上”不太一样是新手最容易困惑的地方。第二部分是键盘输入。这里用leftPressed、rightPressed、upPressed、downPressed四个布尔变量保存按键状态。为什么不用按键回调里“按一下走一步”的逻辑因为按住方向键时操作系统只会在刚开始按下时通知一次并不能模拟持续按住的效果。用布尔变量记录当前是否按住然后在update里根据状态持续移动这才是游戏键盘控制的正确姿势。第三部分是更新逻辑。update是模拟游戏演进的入口。每次先根据按键状态计算坐标变化再做边界限制。这里调用的getWidth()和getHeight()是面板当前的实际宽高不是写死的 800 和 600这样窗口缩放后边界限制仍然有效。第四部分是渲染。paintComponent是 Swing 绘制组件内容的方法。super.paintComponent(g)先清掉上一帧画面然后重新画一个青色矩形。如果不调用super.paintComponent旧的绘制内容不会被清理快速移动时会出现拖影。5.3 为什么这里不用 while 循环加 Thread.sleep很多人第一次了解游戏循环时会自然想到while (true) { panel.update(); panel.repaint(); Thread.sleep(16); }这个写法在逻辑上也是“循环、更新、重绘”但它有一个严重问题如果这个循环跑在 main 线程上那么 EDT 会被反复重绘请求淹没窗口的事件处理、键盘监听等操作都会被抢占。一旦循环过于紧密窗口会直接卡死或响应迟钝。使用 Swing 的Timer可以避开这个问题因为 Timer 的回调在 EDT 上按固定间隔执行不会阻塞界面事件。对于零经验版这是最稳妥的写法。以后转到 LibGDX 时再学习真正的“固定时间步长 插值渲染”才不迟。6. 启动与验证第一个可运行的游戏循环写完成代码后先编译再运行mvn clean compile java -cp target/classes com.example.game.Main如果使用 IDE直接运行Main类也可以。重点不是用什么方式启动而是确认启动后是不是符合预期。正常情况你会看到一个 800x600 的黑色窗口窗口标题是“开发日志#1会移动的方块”里面有一个青色方块位于初始坐标 (100, 100) 附近。按键盘 W/A/S/D 或方向键可以让方块移动当方块到达窗口边缘时会被限制住无法移出画面。如果你看到窗口弹出说明项目已经具备一个最基本“游戏”的形态程序以一定频率刷新画面读取用户输入并且画面根据输入发生变化。这就是游戏循环的最小模型。启动失败时需要迅速判断问题发生的位置。命令找不到是环境变量问题编译报错是代码问题窗口弹不出来可能是 EDT 线程上的异常窗口显示但没有方块可能是绘制逻辑没有执行。先看控制台异常不要直接从游戏逻辑排查。7. 第一次返工这项 demo 暴露出的三个关键经验代码跑通只是第一步真正有价值的是搞清楚为什么这样写以及哪些地方将来一定会重写。第一个经验是关于“状态连续性”。很多第一次写游戏键盘控制的程序员会以为keyPressed里直接写playerX STEP就够了。这样做的结果是每次按键只能移动一次位置连续移动的体验非常生硬。正确做法是把“是否被按下”作为状态存下来然后在游戏循环的update阶段统一消费。这个思路跟后端常见的事件驱动模式有一点区别游戏里的很多输入不是一次性消息而是持续作用在状态上的“力”。第二个经验是关于“UI 线程安全”。Swing 的绘制、事件处理都在 EDT 上游戏状态如果跨线程访问将来会出现各种难以复现的异常。第一版 demo 里用 Swing Timer 不是为了性能而是为了规避线程安全这个大坑。第三个经验是关于“固定步长”。目前移动逻辑直接依赖 STEP 和 Timer 的 16ms但如果 Timer 在一段时间内被延迟游戏速度就会变慢。这个 demo 能接受正式游戏必须使用基于时间差的 delta 值或者固定物理步长。开发日志里应该写清楚当前版本是“假固定步长”后续改成 delta 驱动。这些经验不一定立刻影响当前代码但它们是开发日志最重要的部分。等到开发日志#3 或 #5 再回头看你会发现很多坑其实早就出现过只是当时没记录。8. 常见问题与排查思路零经验做 Java 游戏大概率会遇到下面几个高频问题。问题现象可能原因排查方式解决方案java或javac不是内部或外部命令JDK 未安装或环境变量未配置执行echo %JAVA_HOME%检查变量安装 JDK 并配置 JAVA_HOME 和 PATHmvn不是内部或外部命令Maven 未安装或 PATH 未配置执行mvn -version安装 Maven检查环境变量编译时报“非法字符”文件编码不是 UTF-8查看代码文件右下角编码格式设置项目编码为 UTF-8pom 中已配置运行后窗口空白看不到方块paintComponent 没执行或绘制坐标越界在 paintComponent 打断点检查面板尺寸、玩家坐标是否在可视范围按键没有反应JPanel 没有焦点或 KeyListener 未注册点击窗口后再按键测试调用setFocusable(true)并设置requestFocusInWindow()方块移动后画面拖影没有调用super.paintComponent(g)查看 paintComponent 第一行在绘制前先清空背景按住方向键只移动一次keyPressed 后没有持续状态检查 update 中是否按布尔状态处理改用按键状态布尔变量驱动移动窗口卡死或 CPU 占用过高循环用 while 且没有控制帧率Task Manager 查看 CPU改用 Swing Timer 或增加 sleep/delta这里最值得注意的是“按键没有反应”。这个问题在 Swing 里经常出现原因是JFrame的内容区域可以拥有焦点但JPanel默认并不接收焦点。如果setFocusable(true)仍然偶尔失效可以在窗口显示后调用一次gamePanel.requestFocusInWindow()。更稳妥的方式是使用 InputMap 和 ActionMap 而不是 KeyListener但那是开发日志后面的内容。9. 最佳实践与工程建议9.1 先把版本控制做起来开发日志本质上是一系列变更记录Git 就是开发日志最好的物理存储。第一版跑通后直接提交一次git add . git commit -m 完成开发日志#1Swing 窗口 方块移动提交信息不要太长但要写明这个版本解决了什么问题。以后每次改动都能通过git log看到游戏逐步演化的轨迹。9.2 约定好代码结构这个 demo 的代码只有两个类结构看起来非常简单但它已经隐含了一个模块边界GamePanel 既承担了状态更新又承担了渲染还承担了输入处理。对最小的 demo 来说没问题但如果继续加功能应该逐渐把“状态”和“渲染”分离。比如后面可以拆出 Player、GameState、InputController让 GamePanel 只负责显示画面。对零经验来说不需要第一天就搞出复杂的架构但要有“未来会越来越复杂”的意识。每次提交尽量只改动一个职责点。9.3 别让“运行依赖”越来越多开发日志#1 最明显的优势是零第三方依赖。项目可以拷贝到任何装有 JDK 和 Maven 的机器上直接编译运行。后续加贴图、加声音、加第三方库时务必要考虑这些资源是不是打包进最终产物。比如后期如果要切换 LibGDX项目结构会完全变化但“最小可运行闭环、固定帧率、按键状态驱动移动”这些原则不变。9.4 及时更新 README在项目根目录写一个 README.md记录当前版本能做什么、如何运行、下一步计划。点击 README 时你会知道到应该从哪里继续。第一篇 README 不需要长几行就够了# zero-game-log-01 开发日志#1一个可移动的方块。 ## 运行 mvn clean compile java -cp target/classes com.example.game.Main ## 当前功能 - 800x600 黑色窗口 - 方向键/WASD 控制方块移动 - 边界限制这么做的价值在几周后会非常明显。很多项目写着写着就忘了当初为什么要用某个方案有个 README 能帮你快速找回上下文。9.5 给新手的安全提醒虽然这只是本地 demo不涉及生产环境但既然用了键盘监听、图形绘制、线程定时器仍然要遵守一个通用原则任何涉及窗口、输入、状态更新的代码都要在改动前想清楚是否影响 EDT。另外如果你的电脑是多显示器窗口定位使用了setLocationRelativeTo(null)这个行为比较保守但也最稳定。10. 开发日志#2 的路线图从“有方块”进化到“有游戏感”开发日志#1 跑通的是一个最小闭环它距离“游戏”还有很长的路。接下来的方向可以从三个维度选一个第一个方向是丰富渲染。把青色方块换成角色贴图加背景图片加动画帧。这个方向会逼着你处理图片资源、坐标对齐、动画计时器是视觉反馈最明显的升级。第二个方向是增加游戏内容。比如让方块模拟简单重力增加地面、跳跃、平台或者让画面里出现第二个会主动移动的物体。这个方向会让你接触物理模拟和碰撞检测。第三个方向是重构代码。把玩家状态、键盘输入、画面绘制拆得更开甚至引入简单的状态机。这个方向偏向工程结构适合以后想往正式游戏框架迁移的做法。开发日志#1 的目的是建立一个能持续运行的“游戏雏形”。如果你从零经验出发最合理的下一步不是立刻做一个完整的《超级玛丽》而是先让这个方块做更复杂的事能跳、能碰到东西、能被对象阻挡。等到这些逻辑都成立再考虑有没有必要切到 LibGDX。我自己的计划是开发日志#2 将让方块具备“速度”和“重力”再把画面从满屏黑色变成有地面、有背景的双层结构。这样改动不会很大但每个改动都能被看见。零经验 Java 程序员做游戏最值得记住的只有一句话先创建一个能跑的文件夹再慢慢往里面塞想法。这个文件夹现在已经不再空了里面有窗口、有方块、有移动逻辑还有一个能持续更新的开发日志。