DEVLOG -004: Completed Implementing the Animation Engine

To start, I had a great programming session today. As you can see, I logged almost 4 hours on this feature, and every minute went into building the foundation of the animation system.

As the title suggests, I completed the first version of the animation engine using Pygame. I chose Pygame because I already have experience building games with the JavaScript Canvas API, so all I really needed was a lightweight way to draw graphics and animate objects. From what I found while researching, learning a full GUI framework would have taken significantly longer, so Pygame was the most practical choice for this stage of the project.

I also used ChatGPT to generate a sample conversations object (covered in previous devlogs), which served as mock data while developing the renderer.
From there, I implemented the engine myself.

After spending about ten minutes pacing around my room thinking through the architecture, I settled on an animation loop consisting of four stages.

1. The Setup

The setup stage initializes the application and creates the machines dictionary.

This dictionary acts as a hash lookup, mapping every unique IP address found in the conversations to its corresponding Machine object.

IP Address → Machine()

For organization, I created a Machine class that stores the data and rendering information associated with each endpoint.

This allows packets to instantly locate their source and destination machines without searching through a list.

1. Loading the Gun

I’ll use a gun as an analogy for the remaining stages.

Instead of iterating through every packet in every conversation every frame, packets waiting to be animated are moved into an activePackets list.

This separates packets that are currently “in flight” from packets that are simply stored in the conversation data.

Each conversation contains three important pieces of information:

index — Tracks the next packet to be animated.

state — Indicates whether the conversation is idle or running.

info — Stores the actual packet data.

A CheckState() function examines each conversation.

If a conversation is idle, it jumps directly to the packet indicated by the current index (avoiding iteration through previous packets), creates a Packet object, places it into activePackets, and marks the conversation as running.

1. Pulling the Trigger

This stage is intentionally simple.

The update function only iterates over the packets currently stored in activePackets.

Each packet updates its position by interpolating (lerping) toward the destination machine’s coordinates.
No packets outside of the active list are processed during this stage.

1. The Bullet

Once fired, the packet enters the running state.
As it travels toward the destination,
it continuously checks the remaining distance to its target.

When that distance falls below a predefined threshold, the packet marks itself as done.

Finally, a cleanup function removes all completed packets from activePackets.

If the conversation still has packets remaining, its state returns to idle, allowing the next packet to be loaded and fired.

Here is the code and a demo of version 0.1