Month: May 2026

In my sixteenth video of the “Building a Game Development Framework” series, I focus on adding background image handling and implementing mouse-controlled movements for game objects.

I introduce a formalized approach to handling game backgrounds via a new Background interface and a FixedBackground implementation.

• Separation from Collisions: Backgrounds are treated as purely visual elements. They are rendered behind all other objects (such as game pieces), and the system does not test for physical collisions with them.
• Tiling and Stretching: The FixedBackground can either “stretch” to fill the entire screen or “tile” an image (repeat it) if the original asset is smaller than the display area. I demonstrate this by using a checkerboard pattern.
• Viewport Syncing: The background logic includes a screenOrigin setting to keep the background fixed relative to the player’s view, even if the game camera moves.

I have updated the core feature with a specialized movement class that lets users move actors with the mouse. In this video, I show how to “pick up” a chip and move it.

• Selection Logic: The system uses a contains(x, y) check to determine if the user’s mouse click is physically over the actor’s bounding box.
• Two Interaction Modes:
  • Hold-to-Drag: The actor moves only while the mouse button is held down.
  • Click-to-Toggle: Clicking once “attaches” the actor to the cursor, and clicking a second time “drops” it.
• Offset Handling: To prevent the actor from “snapping” its top-left corner to the cursor, the movement class calculates the exact offset of where the user clicked relative to the sprite’s center. This ensures the drag feels smooth and natural.

I show how the drag movement interacts with the framework’s existing collision system:

• Physics Reversion: If you drag a game piece into another object, the framework detects the collision and “reverts” the movement, effectively blocking the drag.
• The “Overlap” Bug: In early testing, dragging one piece over another would cause the system to accidentally “swap” control to the second piece. I fix this by strictly tracking the “Active” state of the specific actor being dragged, ensuring input isn’t stolen by overlapping sprites.

To support this functionality, I have updated several base classes:

• SpriteUpdate & BoundingBox: Added the contains(x, y) method to allow actors to sense when they are being hovered or clicked.
• SimpleScreen: The rendering loop was slightly reorganized to ensure backgrounds are drawn first, followed by actors and UI elements, preventing game objects from being hidden behind the board.

By the end of the video, I demonstrate a functional board game setup where red and black checker pieces can be naturally dragged and dropped onto a tiled game board while obeying physical boundaries.

The Gdx2DGameFramework can be found here on github.

In my fifteenth video of the “Building a Game Development Framework” series, I demonstrate the Framework by creating a Shoot’em-up game. I implement a sophisticated Visual Effects API, introduce Enemy Projectiles, and streamlines the framework’s actor management.

I updated the “Color Effect” system into a more generic Effects API.

• Stacked Effects: Instead of a single color slot, every animation and motion now maintains a list of effects. This allows a sprite to simultaneously flash red (when damaged) and become transparent (when dying).
• Translucency Effect: A new effect class is added that controls the “Alpha” of a sprite over time. This is used to make obstacles fade away once they are destroyed.
• Global Resets: A reset() method is added to actors, motions, and animations to ensure that all active effects are cleared when an actor is pulled back into the Object Pool for reuse.

To reduce repetitive boilerplate code, I created the ForgedActor class and an updated ActorFactory:

• Automatic Registration: Previously, developers had to manually call factory.actorRemoved(this) in their code. Now, by extending ForgedActor, the actor automatically notifies its factory when it is “removed” from the game play, significantly simplifying the logic in the Laser and Obstacle classes.

The enemy ship is upgraded with offensive capabilities:

• Bullet Factory: Similar to the player’s lasers, enemy bullets use an ActorFactory with pooling (starting with a queue of 20 bullets).
• Burst Fire Logic: The enemy ship uses a timer in its updateChild method. Every 2 seconds, it enters a “firing state” where it launches a burst of 10 bullets, spaced 0.2 seconds apart.
• Weapons Positioning: The code calculates the ship’s width and fires two bullets simultaneously from different positions on the ship’s hull.

New sound effects are integrated to distinguish between player and enemy interactions:

• Varying Hit Sounds: Distinct .wav files are added for the player’s ship taking damage versus the enemy’s ship being hit.
• Explosion Timing: The obstacle’s “hit” sound now triggers as soon as the collision is detected, coinciding with its red color flash and fade-out effect.

I demonstrate the new features in action, showing:

• Projectile Interactions: Logic is added so that enemy bullets don’t collide with the enemy’s own falling obstacles or lasers.
• Difficulty Adjustments: The enemy spawning time is reduced from 100 seconds to 5 seconds to get the action started sooner.
• Visual Polish: Obstacles now smoothly fade out into transparency when hit, rather than instantly vanishing.

By the end of this video, the framework supports a full combat loop where both the player and AI exchange fire, receive visual and auditory damage feedback, and utilize an efficient memory-management system for high volumes of objects.

The Gdx2DGameFramework can be found here on github.

In my fourteenth video of the “Building a Game Development Framework” series, I continue developing the Shoot ‘Em Up game, introducing more complex enemy behaviors, advanced movement scripting, and visual color effects.

To improve the game feel, I add an immediate audio-visual feedback when an obstacle is destroyed:

• Explosion Sound: A new sound effect is triggered the moment an obstacle is “hit.”
• State Management: The hit() method sets the obstacle’s state to “destroyed,” plays the sound, and swaps its visual representation to a red box while it executes its scripted “easing out” death animation, where it slows down and disappears.

I create a new organizational class, the Enemy Manager, to oversee the spawning of both obstacles and the enemy ship.

• Dynamic Spawning: The manager waits 10 seconds before spawning the first enemy ship from the top of the screen.
• Randomized Patrols: To make the enemy ship more unpredictable, I build a Random Destination Action. This action uses “Suppliers” (a Java functional interface) to generate new random (X, Y) targets every time the ship reaches its previous goal.
• Infinite Loops: By chaining the random movement with a GoToAction from the ScriptMovement, the enemy ship permanently patrols the top of the screen, weaving between random left and right positions.

I introduce a sophisticated Color Effect System to visually indicate damage without needing new sprite art:

• Color Cycling: The ColorCycleEffect gradually transitions an actor’s color from its base color (e.g., Blue) to a “hit” color (Red) and back again over a set duration.
• Linear Interpolation (Lerp): The system calculates the percentage of time elapsed and adjusts the RGB values incrementally. This creates a smooth “flash” effect rather than a jarring color swap.
• Framework Integration: The BaseAnimation and Motion classes were updated to support these effects, ensuring that any actor—whether a single-frame sprite or a multi-directional animation—can utilize the Effects. The Effects can be translucency to color changes.

A BaseShip abstract class is created to centralize the logic for both the player and the enemy:

• Hit Protection: A “hit” flag ensures that if a ship is hit multiple times rapidly, the color flash effect doesn’t constantly restart; it must finish its cycle before flashing again.
• Max Hits (HP): Each ship now has a MaxHits variable. The player is given 10 HP, while the enemy ship has 5 HP. When HP reaches zero, the Actor is removed from the screen.

I refined the collision checks to ensure that game objects only interact with what they are supposed to:

• Laser Logic: Lasers now check if they’ve hit an EnemyShip. If so, they trigger the ship’s hit() method and remove themselves.
• Obstacle Logic: Obstacles check if they’ve collided with the player’s ship to deal damage, but they ignore the enemy ship so that the enemies don’t accidentally destroy their own falling obstacles or get destroyed by them.

By the end of this session, the game has a sophisticated AI enemy that patrols the screen, takes damage with a visual flash, and eventually dies after a set number of hits.

The Gdx2DGameFramework can be found here on github.