Learning Block · Detail

Bomberman light: Grid Bomb

This learning block introduces central concepts of grid-based game development in Python 2 using frameCraft. The focus is on step-by-step modeling of the game field, movement, bomb logic, explosions, and game states in a deliberately small Bomberman-light project.

Time 90 minutes

Format AI-Coding

Technology frameCraft

Tasks 21

Preview image: Bomberman light: Grid Bomb

Project development with KI support

Structured programming with KI-Coding and ProtoTypeFirst

This course was specifically developed for learners who want to program structuredly with KI support and further develop existing code.

KI-Coding in the project state

KI-Coding integrates a context-aware KI directly into CodeRoom. It extends existing code, explains errors, sets targeted changes, and supports further development in the current project state.

Transparent code development

The course focuses on didactically embedded support, transparent changes, and immediately testable results. Prompts, changes, and versions remain transparent for instructional guidance.

ProtoTypeFirst format

All content starts with a functioning prototype that is gradually developed using AI coding, so each extension begins at a visible starting point.

Introduction

The following excerpt shows the entry of the lesson module in abridged form.

You don't start with a finished game, but with a prepared construction site. The scene is already running, showing a title, a simple rectangular playing field, a placeholder figure, and a marker. The actual Bomberman game is created only through your changes using the Structured Programming with AI Coding and ProtoTypeFirst.

Didactic classification

The module is compactly classified in terms of content and instructional practice.

Subjective objective

The module makes the development of a raster-based game visible as a result of small, testable modeling steps. Central concepts are raster-pixel conversion, state-based game logic, data lists for game objects, and the separation of startup rules and runtime rules.

Competence development

Modeling: Grid fields, game figures, bombs, and blocks are represented as structured data in the project.
Algorithmization: Movement, blocking, countdown, explosion, and victory conditions arise from clear rule checks.
Abstraction: A helper function for raster-to-pixel positions reduces repetitions and makes coordinate logic understandable.
Test: Each extension can be checked and ranked in its effect on the visible prototype.

Teacher's added value

The functioning start prototype provides a clear starting point for step-by-step extensions.
The task sequence breaks down a game system into manageable sub-mechanisms.
Extension tasks enable differentiation through enemies, target states, restarts, and points.

Sequence of the lesson unit

The tasks are presented in the order of the JSON and summarized as development steps of the project.

Make raster lines visible

The existing game field area is supplemented with simple raster lines. This turns the placeholder field into a clearly structured game surface without already building rules or collisions.

Design the player like a Bomberman figure

The placeholder figure is graphically developed into a small Bomberman-like game figure. Position and logic remain unchanged, so that representation and behavior can be worked on separately.

Save the player's raster position

Own scene values for column and row are created for the player. This data structure prepares the later field-by-field movement in advance without automatically moving the figure yet.

Align the player with the raster field

The figure's starting position is calculated from the grid column, grid row, and field size. This makes the game piece visible on the grid model of the game board for the first time.

Convert raster position to pixel position

A helper function calculates the pixel center of a grid cell from column and row. This central conversion is then used for the player's position and forms the basis for further objects.

Implement one-step grid movement

Direction actions change the stored raster position each time by one field. The figure is then repositioned using the conversion function, without wall check or animation yet.

Unstick movement

A simple movement lock prevents a held direction button from triggering further steps in every frame. Only after releasing will a new single step be possible.

Prepare fixed walls

A list of fixed wall fields is created and displayed on the grid. The walls do not yet block movement, but are introduced as separate game objects first.

Lock movement against walls

The movement rule checks before each step whether the target field is in the wall list. The player can then only move to free fields.

Display destructible blocks

In addition to fixed walls, a list of destructible blocks is added. These fields receive their own display, but initially lack explosion or removal logic.

Place bomb as data object

When placing a bomb, an entry with the current player position is stored. Initially, only one bomb is allowed at a time; visibility, counter, and explosion will follow later.

Place a bomb only once per key press

A bomb lock prevents a held bomb button from repeatedly creating new entries. The placement is only freed up again after releasing the action.

Make bomb visible during runtime

Existing bomb entries are rendered as characters during gameplay. The task clearly shows that dynamic objects cannot be set up only at scene start.

Add bomb counter

Each bomb receives a temporal counter that decreases with frame time. After expiration, it is marked for explosion without drawing the explosion yet.

Show cross-explosion

From a prepared bomb, a short cross-form of explosion fields arises. Removing blocks and damage are still excluded so that the explosion geometry can be displayed isolated.

Remove blocks through explosion

The explosion fields are compared with the destructible blocks. Only affected blocks are removed from the list; solid walls remain unchanged.

Show points for destroyed blocks

A point value and a HUD display are added. The points increase when a destructible block disappears through an explosion.

Check player damage

The game logic checks if the player position is on a explosion field. In this case, a loss status is set and a simple Game Over message is displayed.

Add simple enemies

An enemy is added as its own grid field and displayed in the game field. It does not move yet and causes no damage, but expands the object model of the game initially.

Add level goal and win condition

A simple goal is defined: If all removable blocks are removed, the game status changes to won. A visible victory message makes the end of the level recognizable.

Restart by key and touch

A start or restart action is connected with keyboard and touch. After a won or lost status, a key press starts the scene safely new.

Code snippet

The fragment shows the prepared state structure and the place where movement, bombs, and rules will be added step by step later.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
SZENE(
    'start',
    punkte=0,
    spiel_status='baustelle',
    raster_spalten=11,
    raster_zeilen=9,
    feld_groesse=16,
    bomben=[],
    bloecke=[],
    gegner=[]
)
def baustellen_regel(ctx):
    spieler = figur_von(ctx, 'spieler')
    if spieler is None:
        return
    status = wert_von(ctx, 'spiel_status', 'baustelle')
    if status == 'baustelle':
        # TODO: Hier entstehen später Bewegung, Bombe und Spielregeln.
        if aktion_aktiv(ctx, 'bombe'):
            pass

A visible prototype is gradually turned into a playable grid game with clear states and verifiable rules.

The building block supports a clear lesson organization because each extension is based on an ongoing project and produces verifiable results. Differentiation is possible through additional opponents, target conditions, points, or restart logic.

Request a demo access and test the building block in your own course context.