A reader-oriented guide to setting up a real development workflow, understanding GUI programming in Java Swing, working with Git and GitHub, and building a Snake game with both inline and agentic AI.
In this course, Snake is not just a game project. It is the vehicle for learning how modern software is actually built: with editors, terminals, repositories, libraries, prompts, tests, debugging, and revision.
Read these slides as a textbook chapter. Every major term is defined when it first matters.
What this project is really teaching about software, tools, and workflow.
Before installing tools, define the vocabulary. If the terms are vague, the workflow becomes vague too.
The most common beginner confusion is the difference betweencommitandpush. A commit saves history on your machine. A push sends that history to GitHub.
The point of setup is not to collect tools. The point is to make sure your machine can compile and run Java reliably before the project gets more complex.
For this class, the only safe beginner rule is simple: install the JDK, not just a runtime.
This is where the work stops being "a file on my laptop" and becomes a real project with history.
You should see the snake-game folder and its files in the Explorer panel.
README.md is visible.Source Control should be available in the sidebar because the open folder is a Git repository.
If the folder is not recognized as a repository, stop and fix that before writing project code.
A useful commit message should say what changed. Avoid vague messages such as fixed stuff.
GUI code can look unfamiliar at first, but it is still ordinary Java plus a library for building windows and drawing components.
The main application window. If the program opens a visible window, that outer window is often a JFrame.
A rectangular area inside a window. For a simple game, the panel is often where drawing happens.
A visible GUI element. Frames, panels, buttons, and labels are all components.
A method that Swing calls when a panel needs to redraw itself.
An object that gives drawing commands such as rectangles, colors, and text.
Something that happens while the program is running, such as a key press, a mouse click, or a timer tick.
A Swing object that can trigger code repeatedly after a chosen delay. In Snake, that repeated trigger becomes the game loop.
A request that tells Swing a component should be drawn again. It does not draw directly; it asks Swing to schedule a redraw.
import java.awt.*;
import javax.swing.*;
public class SimpleWindow extends JPanel {
@Override
protected void paintComponent(Graphics g) {
super.paintComponent(g);
g.setColor(Color.GREEN);
g.fillRect(40, 40, 120, 40);
}
public static void main(String[] args) {
JFrame frame = new JFrame("Simple Window");
frame.setSize(400, 300);
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
frame.add(new SimpleWindow());
frame.setVisible(true);
}
}
Read this code as ordinary Java. The only major new thing is what kinds of objects are being created and what those objects know how to do.
This is where the difference between a small local edit and a larger structured request becomes concrete.
SnakeStarter.java
import java.awt.*;
import javax.swing.*;
public class SnakeStarter extends JPanel {
private final int gridSize = 20;
private final int cellSize = 25;
@Override
protected void paintComponent(Graphics g) {
super.paintComponent(g);
g.setColor(new Color(22, 28, 39));
g.fillRect(0, 0, gridSize * cellSize, gridSize * cellSize);
}
}
This file does not do much yet. That is intentional. Small, stable starting points are easier to extend safely.
In SnakeStarter.java, add a main method that opens a 600x600 JFrame titled Snake Starter. Keep everything in one file. Add a starting snake that is three segments long and draw it in green on the panel. Do not add movement yet.
Here the prompts are written out explicitly. Each one has a software-design purpose, not just a coding purpose.
I'm building a Snake game in Java using Swing. Create a single file called SnakeGame.java. It should have a main method that opens a JFrame window that is 600 by 600 pixels and titled Snake. Inside the frame, add a JPanel subclass called GamePanel. Do not add any game logic yet. Just get the window to open correctly.
It creates a shell you can run immediately. If the shell does not work, you should not move on to game logic yet.
Now extend SnakeGame.java. Keep it as one file. Add a dark background grid and draw a starting snake that is three segments long near the center of the board, facing right. Each cell should be a 30x30 pixel square. Draw the snake in green and the background in dark gray. Do not add movement yet.
This prompt is about representation. Before a game can move, it needs a way to store where things are.
Make the snake move automatically using a Swing timer that ticks every 150 milliseconds. Add arrow key controls so the player can steer, but don't allow the snake to reverse direction. For now, have the snake wrap around the edges instead of dying. Make sure the panel can receive keyboard input.
This is the central loop of the game. The loop is small, but it is conceptually important: update state, then redraw.
Add a food pellet that spawns at a random empty cell. When the snake eats it, grow by one segment and spawn new food. Add collision detection: hitting a wall or the snake's own body should end the game, stop movement, and show a "Game Over" message with the final score. Display the current score in the top-left corner during play. When the game is over, let the player press R to reset everything and play again.
A project is not complete when code exists. It is complete when the code can be run, explained, debugged, and revised deliberately.
The key word here is evidence. Good follow-up prompts include the actual error message or the actual incorrect behavior.
Once the baseline game works, growth should still be controlled. Better projects are usually the result of disciplined additions, not random accumulation.
Everything you built for Snake lives in one file and one class. The same pattern transfers directly to classic Atari-era games — each one is a step up in complexity, not a different kind of problem.
Two paddles, one ball, collision detection, and a score counter. A natural first step: the only new idea over Snake is that two objects can both move independently.
LLM prompt strategy: describe the game state as fields first, then ask for the game loop, then drawing, then key input — one step at a time.
A paddle, a bouncing ball, and a grid of destructible bricks. Adds a 2-D array for the brick layout and angle-based bounce logic.
LLM prompt strategy: prompt for the brick grid and collision first. Once destruction works, add the paddle and ball. Commit each working milestone.
A ship that rotates and thrusts, asteroids that split on impact, and limited bullets. Introduces double velocity, trigonometry for movement, and object lists.
LLM prompt strategy: ask for ship rotation and thrust before asteroids exist. Add one asteroid that wraps the screen. Then add splitting. Then bullets.
A frog moves up a screen of moving traffic and river obstacles. Adds lanes of objects moving at different speeds and a lives system.
LLM prompt strategy: start with a single lane of cars. Once the frog can collide and die, add a second lane moving the opposite direction. The pattern repeats.
Missiles fall toward cities; the player intercepts them with explosions. Introduces mouse input, line-segment math, and a growing / shrinking explosion radius.
LLM prompt strategy: ask for a single falling missile and a click-to-explode response. Add the blast radius check before adding multiple missiles or cities.