Grav Sync Devlog on Tiziano Basile | Software Engineer

Adding Interactive Cockpit Controls to Grav-Sync

Sun, 09 Nov 2025 00:00:00 +0000

Today I implemented a major visual upgrade to my GitHub Game Off 2025 project, Grav-Sync, by adding an interactive cockpit interface with animated control knobs. This enhancement significantly improves the game’s visual feedback and makes the controls more intuitive and engaging.

What Changed

Animated Control Knobs

The main feature I added today is a fully functional cockpit interface with two animated control knobs:

Red Knob (controlled by A/D keys): Adjusts wave frequency
Blue Knob (controlled by W/S keys): Adjusts wave amplitude

Each knob has a 2-frame animation that advances whenever the player presses the corresponding control keys, providing immediate visual feedback for player input.

New Sprite System Method

To support the knobs, I extended the Sprite class with a new nextFrame() method that allows manual frame advancement. This is different from the existing automatic animation used by the Earth sprite, which continuously cycles through frames. The knobs only animate when the player provides input, making them feel more responsive and connected to the controls.

1
2
3
4


// Advance animation by one frame (useful for manual control)
nextFrame() {
 this.index = (this.index + 1) % this.len;
}

Input Handler Integration

I updated the InputHandler class to trigger knob animations alongside the existing player wave adjustments. Now when you press W/S or A/D keys, not only does your wave change, but the corresponding knob visibly rotates, providing clear visual feedback:

1
2
3
4
5
6
7


w: {
 pressed: keyIsDown(87) || keyIsDown(119),
 action: () => {
 this.player.increaseAmplitude();
 blueKnob.nextFrame();
 },
}

Cockpit Rendering

I created a new drawCockpit() method in the Game class that handles the rendering of the cockpit base image and positions both knobs correctly relative to it. The cockpit is positioned near the bottom of the screen, and the knobs are placed at appropriate positions using a local coordinate system:

The cockpit base is rendered first
Both knobs are positioned relative to the cockpit using push()/pop() transformations
Each knob maintains its current animation frame and scale

UI Repositioning

To accommodate the new cockpit interface, I repositioned the UI elements:

Moved amplitude and frequency displays to be adjacent to their respective knobs
Centered the sync percentage and score displays on the cockpit
Removed some redundant labels to keep the interface clean
Adjusted the Earth sprite position slightly upward to leave room for the cockpit

Configuration Adjustments

I made a small but important change to the configuration: the Earth sprite’s Y position was adjusted upward by 80 pixels (config.earthY = config.screenHeight / 2 - 80) to better center the visible play area above the cockpit.

Technical Implementation

The implementation involved several files:

animations/knob.json - Animation configuration defining two frames for the knob rotation
sprites/ - Added three new images: cockpit.png, red-knob.png, and blue-knob.png
sketch.js - Preloaded new assets and initialized knob sprites
game.js - Implemented drawCockpit() method for rendering
input.js - Integrated knob animations with key press handlers
sprite.js - Added nextFrame() method for manual animation control
ui.js - Repositioned UI text elements
config.js - Adjusted Earth position

Code Organization

After implementing the cockpit feature, I also performed a minor refactoring to better organize global variables in sketch.js, grouping related variables together for improved code readability.

Results

The cockpit addition makes the game feel more polished and immersive. Players now have:

Visual feedback - See exactly when their inputs are registered
Clearer controls - The knobs make it obvious what W/S and A/D keys control
Better aesthetics - The cockpit theme reinforces the space/orbital mechanics concept
Improved layout - UI elements are better organized around the cockpit

This change represents a significant step forward in the game’s visual design and user experience. The cockpit not only looks good but also serves a functional purpose by making the controls more intuitive and providing immediate visual feedback for player actions.

What’s Next

With the cockpit in place, the game is starting to feel more complete. Future improvements might include:

Adding sound effects for knob rotation
Adding a main manu

You can check out the full code on GitHub, and I’d love to hear feedback from anyone who tries it out!

DevLog: Adding Dynamic Waves and Animated Sprites to Grav Sync

Sat, 08 Nov 2025 00:00:00 +0000

Over the past development cycle, I worked on two features for Grav Sync, these updates transformed the game from a static puzzle into a more dynamic and visually engaging experience.

Here’s a detailed look at what was implemented and why.

Branch 1: `random-wave` - Introducing Dynamic Challenge

The Problem

The original game featured a fixed target wave that players needed to match. While functional, this meant that once players learned the solution, the game became repetitive. Every playthrough was essentially the same puzzle.

The Solution: Randomized Target Frequencies

I implemented a system to randomize the target wave’s frequency at the start of each round, making every attempt unique and challenging.

Key Changes:

Random Frequency Generation: Added getRandomInt(10, 30) function to generate target frequencies within a balanced range
Dynamic Target Updates: The target frequency now regenerates each time the target wave resets (when it reaches the player’s orbital radius)
UI Enhancement: Added on-screen display of the current target frequency to give players clear feedback

Implementation Details:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


// Initialize with random frequency in setup()
targetWave.frequency = getRandomInt(10, 30);

// Regenerate on wave reset
if (targetWave.baseRadius === playerRadius) {
 if (sync > 0.8) {
 score++;
 }
 targetWave.frequency = getRandomInt(10, 30); // New random target
 targetWave.baseRadius = 380;
}

Refining the Synchronization System

While implementing randomization, I also overhauled how synchronization is calculated. The original system treated frequency and amplitude equally, but through playtesting, it became clear that frequency matching is far more critical to achieving visual alignment.

The New Weighted System:

80% weight on frequency matching: Ensures players prioritize getting the wave count correct
20% weight on amplitude matching: Fine-tuning for perfect alignment
Phase ignored: Simplified gameplay by removing phase as a factor, making the puzzle more approachable

Technical Implementation:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


function calculateSync() {
 // Frequency score: compare numeric values directly (ignoring phase)
 let freqRange = maxFrequency - minFrequency;
 let freqDiff = abs(targetWave.frequency - playerWave.frequency) / freqRange;
 let freqScore = 1 - freqDiff;

 // Amplitude score: compare amplitude values
 let ampRange = maxAmplitude - minAmplitude;
 let ampDiff = abs(targetWave.amplitude - playerWave.amplitude) / ampRange;
 let ampScore = 1 - ampDiff;

 // Combine with 80:20 weighting
 return freqScore * 0.8 + ampScore * 0.2;
}

This change made the game feel more intuitive, players could immediately see the impact of frequency adjustments while still needing to fine-tune amplitude for perfect scores.

Impact

The random-wave branch transformed Grav Sync from a single-solution puzzle into a replayable game with procedural variation. Each round now presents a fresh challenge, and the weighted sync system provides clearer feedback about what matters most.

Branch 2: `sprites` - Bringing Earth to Life

The Vision

The original Earth was rendered as a simple static circle with basic ellipse shapes for continents. While functional, it lacked the polish and visual interest the game deserved. I wanted Earth to feel like a living, rotating planet at the center of the cosmic waves.

Creating the Sprite System

Step 1: Sprite Sheet Preparation

I found a 94-frame sprite sheet showing Earth rotating (attribution has been made into the repo):

Format: 480×480 PNG
Layout: 10×10 grid (10 frames per row for 9 rows, 4 frames in the final row)
Frame size: 48×48 pixels per frame
Animation style: Flat earth texture scrolling across a circular mask

Step 2: Frame Data Mapping

Created animations/earth.json to map all 94 frames with precise coordinates:

1
2
3
4
5
6
7
8
9


{
 "frames": [
 {
 "name": "sprite-00",
 "position": { "x": 0, "y": 0, "w": 48, "h": 48 }
 }
 // ... 93 more frames
 ]
}

Step 3: Building the Sprite Class

Implemented a reusable Sprite class in sprite.js:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30


class Sprite {
 constructor(animation, x, y, speed, scale = 1) {
 this.x = x;
 this.y = y;
 this.animation = animation; // Array of p5.Image objects
 this.w = this.animation[0].width;
 this.len = this.animation.length;
 this.speed = speed; // Animation speed (frames per draw call)
 this.scale = scale; // Scaling factor
 this.index = 0; // Current frame index
 }

 show() {
 let index = floor(this.index) % this.len;
 push();
 imageMode(CENTER);
 image(
 this.animation[index],
 this.x,
 this.y,
 this.w * this.scale,
 this.w * this.scale
 );
 pop();
 }

 animate() {
 this.index += this.speed; // Advance animation
 }
}

Key Features:

Flexible animation speed: Random speed on initialization creates subtle variation
Scalable sprites: Can match any target size (scaled to 96×96 to match original Earth diameter)
Center-based positioning: Uses imageMode(CENTER) for intuitive placement
Error handling: Validates animation array to prevent crashes

Integration Challenges

Challenge 1: Variable Scope Issues

Initial implementation had bugs where the animation array wasn’t properly declared:

1
2
3
4
5


// Problem: 'animation' not declared
for (let i = 0; i < frames.length; i++) {
 animation.push(img); // ReferenceError
}
earth = new Sprite(animation, 0, i * 75, ...); // 'i' undefined here

Solution:

1
2
3
4
5


function setup() {
 let animation = []; // Properly scoped
 // Load frames...
 earth = new Sprite(animation, earthX, earthY, random(0.1, 0.4), spriteScale);
}

Challenge 2: Sprite Positioning

Initially, sprites appeared in the top-left corner instead of centered. The issue was that p5.js’s image() function defaults to corner-mode positioning.

Solution: Wrapped rendering in push()/pop() and set imageMode(CENTER) to ensure sprites draw from their center point.

Challenge 3: Size Matching

The original hand-drawn Earth had a diameter of 96px (radius 48), but the sprite frames were 48×48.

Solution: Calculate scale factor dynamically:

1
2


let spriteScale = (earthRadius * 2) / 48; // 96 / 48 = 2.0
earth = new Sprite(animation, earthX, earthY, random(0.1, 0.4), spriteScale);

The Result

The sprite system brought immediate visual improvements:

Living planet: Earth now rotates continuously, adding life to the scene
Variable speed: Random animation speeds (0.1–0.4) create subtle uniqueness each game
Smooth animation: 94 frames provide fluid rotation without obvious looping
Maintained aesthetics: Scaled perfectly to match the original Earth size

Code Quality Improvements

Added validation to prevent edge-case crashes:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


if (
 this.animation.length > 0 &&
 this.animation[0] &&
 typeof this.animation[0].width !== "undefined"
) {
 this.w = this.animation[0].width;
} else {
 this.w = 0;
 console.warn("Sprite: animation array is empty or invalid.");
}

Also fixed a stroke bleed issue where wave rendering affected subsequent draws:

1
2
3
4
5


function drawWave(wave, currentTime) {
 // ... draw wave ...
 endShape(CLOSE);
 stroke("black"); // Reset stroke to prevent bleeding
}

What’s Next?

With these two branches merged, Grav Sync now has:

Dynamic, randomized gameplay
Polished visual presentation
Intuitive sync feedback

Future improvements could include:

Audio integration: Frequency-based soundscapes using p5.sound
Difficulty curves: Progressive challenge scaling
Particle effects or shaders: Visual feedback when sync is achieved

Conclusion

These two updates made Grav Sync more engaging: random frequencies add replay value, and the animated Earth sprite improves the visual appeal. The game is now more fun to play than the original static version.

You can check out the full code on GitHub, and I’d love to hear feedback from anyone who tries it out!

DevLog #1 GravSync

Sun, 02 Nov 2025 00:00:00 +0000

This year again, as every November since 2012, GitHub Game Off takes place, the game jam organized by GitHub where you have to develop a video game on a specific theme within a month. This year I decided to participate with the excuse of practicing with JavaScript (specifically I chose to use p5.js, but this might change if I see it doesn’t quite suit my needs).

The theme

This year’s theme is waves (quoting from the jam page)

wave /weɪv/

Noun

A moving ridge on the surface of a liquid (for example, ocean waves or coffee ripples).

A repeating pattern of motion, energy, or sound (for example, sound waves or radio waves).

A sudden burst or surge (for example, a wave of enemies or a wave of emotion).

A gesture of greeting or farewell.

Verb

To move your hand in greeting or farewell.

To undulate or fluctuate (for example, wheat waving in the wind).

To signal or summon (for example, waving someone through a door).

Adjective

Flowing, wavy, or oscillating (for example, wavy hair).

Acronyms (OK, we made these up)

Wizards Accelerating Velocity Every Sunday

Warriors Against Variable Energy Surges

Whales And Vikings Engaging Submarines

Or make up your own—we love seeing how creative you get with it!

My idea

As a space and astrophysics enthusiast, the word “waves” immediately brought gravitational waves to mind, so why not create a mini puzzle game where you have to save Earth from malicious gravitational waves (whatever that means)?

The idea is simple: The player tunes multiple gravitational waves to achieve resonance and stabilize the universe. The challenge is to synchronize the waves under time pressure while maintaining alignment.

But how to implement it?

Initially, since you need to make something small for a jam, I simply thought of showing two sine waves, the first being the target wave and the second controlled by the player, but that would have been incredibly boring, so why not put Earth at the center and make the waves “arrive” on it?

So here’s planet Earth in all its splendor

But how do you create a circular sine wave? Searching a bit on the web, it turns out that the formula for drawing a sine wave on a circumference is this

[ r(\theta) = r_0 + A \cdot \sin(n \theta + \phi) ]

so having defined my JS object to represent the wave like this

1
2
3
4
5
6
7
8


let targetWave = {
 baseRadius: 380,
 amplitude: 15,
 frequency: 10,
 phase: 0,
 animationSpeed: 0.05,
 color: [255, 255, 255, 200],
};

I defined the function to draw it along a circumference like this

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


function drawWave(wave) {
 stroke(wave.color[0], wave.color[1], wave.color[2], wave.color[3]);
 strokeWeight(3);
 noFill();
 beginShape();
 for (let angle = 0; angle <= TWO_PI + 0.1; angle += 0.05) {
 let phaseRadians = radians(wave.phase);

 let baseRadius =
 wave.baseRadius +
 wave.amplitude *
 sin(
 wave.frequency * angle +
 phaseRadians +
 currentTime * wave.animationSpeed * 50
 );

 let radius = baseRadius;
 let x = earthX + radius * cos(angle);
 let y = earthY + radius * sin(angle);
 vertex(x, y);
 }
 endShape(CLOSE);
}

and here’s the result

At this point, however, it seemed more like the circumferences were rotating rather than being sine waves, so I decided to add some disturbance, but only for rendering purposes so as not to influence the player’s synchronization calculation.

The drawWave function therefore became like this

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34


function drawWave(wave, currentTime) {
 stroke(wave.color[0], wave.color[1], wave.color[2], wave.color[3]);
 strokeWeight(3);
 noFill();
 beginShape();
 for (let angle = 0; angle <= TWO_PI + 0.1; angle += 0.05) {
 let phaseRadians = radians(wave.phase);

 // Base wave calculation (for sync)
 let baseRadius =
 wave.baseRadius +
 wave.amplitude *
 sin(
 wave.frequency * angle +
 phaseRadians +
 currentTime * wave.animationSpeed * 50
 );

 // Add subtle disturbance for visual effect only
 let disturbance =
 3 *
 sin(angle * 15 + currentTime * 0.8) *
 cos(angle * 8 + currentTime * 0.6) +
 2 *
 sin(angle * 23 + currentTime * 1.2) *
 cos(angle * 12 + currentTime * 0.9);

 let radius = baseRadius + disturbance;
 let x = earthX + radius * cos(angle);
 let y = earthY + radius * sin(angle);
 vertex(x, y);
 }
 endShape(CLOSE);
}

At this point, the last thing to do before closing the day was to make the target wave circumference reduce over time and once it reached the player’s circumference, calculate the score based on the sync value (for now I add a point to the score if sync > 80%, we’ll see later)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


if (targetWave.baseRadius > 50) {
 targetWave.baseRadius -= 0.5; // Reduce base radius by 0.5 each frame
 targetWave.baseRadius = max(50, targetWave.baseRadius); // Don't go below 50
}

if (targetWave.baseRadius === playerWave.baseRadius) {
 if (sync > 0.8) {
 score++;
 }
 // make the target wave big again to simulate a second wave
 targetWave.baseRadius = 380;
}

Obviously the player can use the keyboard to modify the amplitude and frequency of their own wave to align with the target wave

First day done

For now I’m satisfied, I’ve omitted the technical details on how I calculated the sync and other little things (forgive me, it’s my first devlog). If you want to take a look at the code it’s available on my GitHub profile