Devlog #4: Bot Architecture Cleanup, Persistence & Statistical Charts

Hey everyone! Here’s an update on what I’ve been working on for my project over the past few days.

---

1. Weekly Activity Charts & Statistics

The biggest new feature is visual weekly statistics! Now users can see a chart/graph of their activity over the course of the week.

• The Challenge: Storing data per user, per specific activity, and across each day of the week.
• The Solution: Kept it clean and simple using user_data.
• Persistence: Added persistent storage so data isn’t lost on restart. Honestly, I was mind-blown by how powerful Python persistence is—enabling this took literally just a couple of lines of code!

---

2. Refactoring & Modularizing Code

I decided it was time to break up my codebase into multiple modules/files:

• Separation of Concerns: Initially, my architecture felt a bit messy—files knew too much about each other’s internal logic and were tightly coupled. I refactored the project so that each file and module is more autonomous and encapsulated.
• Troubleshooting: Splitting the code broke a few things at first, but after a bit of debugging, everything is working smoothly now.

---

3. User Experience & Input Validation

I made several quality-of-life improvements to make the bot feel much more robust:

• Daily Log Reminders: Added a daily reminder prompting users to log their data for the day. (Note: Users just need to run /start once to initialize reminders and resets).
• Strict Input Validation: Added input filters. If a step requires a number, invalid text is rejected; if it asks to pick an activity, custom inputs are blocked.
• Python vs C++ appreciation: Coming from a C++ background, it constantly amazes me how complex user interactions and data handling can be written in just a few lines of Python!

---

What’s Next?

• Writing a solid README.md
• Submitting the project!

Devlog #3:

Changes

In this update, I focused on refining the user metrics and implementing the automated weekly reset mechanism.

• Metric Adjustments: Removed water intake tracking from the list of monitored metrics. Simply put, I personally don’t track my daily water intake, so I decided to streamline the bot’s focus.
• Automated Weekly Reset: Spent most of my development time implementing a scheduled automated reset system that triggers every Saturday at 12:00 PM.
  • While the underlying logic isn’t overly complex, working through it while learning Python took more time than expected.
• As shown in the screenshot, where test data entered before 11:31 AM was automatically cleared upon trigger.

---

Learnings

• Logging (logger.info): Discovered how extremely valuable logger.info is for debugging scheduled jobs and tracking state transitions. Without proper logging, diagnosing automated execution bugs would have been significantly harder.

---

Next Steps

1. End-of-Week Summary Reporting: Implement logic to show results right before the automated reset occurs.
2. Weekly Analytics & Graphs: Add visual statistics showing daily progress over the past week

DevLog #2:

---

Switching Libraries

Initially, I started building this bot using another library. However, I decided to rewrite the codebase using python-telegram-bot

Why? python-telegram-bot is much more practical and scalable for complex, multi-step projects. Since I plan to build bigger features in the future, I figured it was best to learn and adopt a solid framework right now. I spent about an hour migrating my previous logic to PTB, and it was definitely worth it!

---

New Features

I added core bot commands and integrated custom reply keyboards:

• /help: Shows available commands.
• /log: Prompts you to pick an activity via a custom reply keyboard and log your stats.
• /analytic: Allows you to select an activity and view your current recorded progress.

The trickiest part:

was figuring out how to handle sequential user inputs :

1. First function: Catches the initial command (e.g., /log).
2. Second function: Receives the chosen activity (e.g., Sport), asks a follow-up question (e.g., “How long have you been doing this?”)
3. Third function: Takes the entered number/value and saves it to the selected activity state.

---

fix-it list:

1. Custom Prompts per Activity: Currently, selecting “Water” asks “How long have you been doing this?” instead of “How much water did you drink?”. I need to customize questions based on the activity type.
2. Data Accumulation: Right now, logging a value overwrites context.user_data[activity] instead of adding to it. I will fix this so values accumulate properly over time.
3. Weekly Reset: I need to implement an automated mechanism to reset tracking data every Saturday.

---

Since fixing these remaining issues won’t take too much time, I’ll soon be ready to add new features.

So let me know if you got any ideas in the comments below

DevLog #1: Learning Python Through Practice

This is my first Python project. Instead of just memorizing syntax from tutorials, I decided to learn the language through hands-on practice.

To test this approach, I’m building a simple Telegram Bot designed to track daily health habits.

---

The Core Concept

The bot will allow users to quickly log their daily metrics:

• Sleep duration
• Water intake
• Physical activity / workouts

It stores this data and, upon clicking a button, generates a weekly summary analysis to track progress.

---

Current Progress

So far, I have:

• Created and structured the GitHub repository.
• Added essential initial files (.gitignore, dependencies, configuration).
• Developed a basic, functional Telegram bot prototype.

---

The Experiment

This project isn’t meant to be a full-scale commercial application; it’s a personal challenge:
Can I effectively master Python by building functional, real-world projects from scratch?

DevLog №10
prepared everything for shiping. added wiring.png and AI usage declaration in my README file.

DevLog №9

###What’s New

• Walls & Pipes Mechanics: Added moving wall obstacles.
• Score Counter: Integrated a score tracking system.

---

###How It Works

• Score Logic: To keep things simple and efficient, the score increases automatically whenever a wall reaches the left edge of the screen.
• Illusion of Movement: The bird stays in place while the walls continuously cycle and reset from the right edge back to the left. This creates a smooth side-scrolling illusion!

---

It was a fairly straightforward feature to implement, but it instantly made the project feel much more like a complete game!

Devlog №8

Bird Physics & Rendering

• Flicker-Free Rendering

  To prevent screen flickering caused by redrawing the entire screen, I optimized the loop by clearing only the bird’s exact position before rendering its new frame.

• Physics Implementation

  Movement relies on both velocity and acceleration:

  • Acceleration continuously increases the downward velocity (gravity).
  • Jump mechanic resets the downward velocity to initial on every input.

---

Next Steps: Wall Generation

• Obstacle Setup

  I need to create an array of one dynamic wall.

• Recycling Logic

  • As soon as a wall reaches the left edge of the screen, it will wrap around to the right.
  • The height/position will randomize each time it reappears to form a continuous level.

Devlog №7

implemted PMW to control sound volume

Devlog №6

Today I quickly set up the startup text so it scrolls smoothly, and that’s pretty much it. Nothing complicated, really—took me literally half an hour.
Next up: finish tuning the PWM to quiet down the audio, and then I’ll probably work on making a more interesting splash screen.

Devlog №5

I added sound effects for every button press on my mini-console! Sounds like a super quick and easy task, right? Well, it should have been. But a few architectural bumps in the road ended up eating way more time than expected.

---

What went wrong (and how I fixed it)

1. Hardware Pin Conflict:

   My buzzer was originally soldered to a pin used by SPI. As soon as the display initialized, things went sideways.

2. Game Loop vs. Main Loop Architecture:

   My game logic was running inside an infinite loop within a standalone function, while the sound playback logic lived in the main loop calling that function.

Solution: soldered the buzzer to another pin and quick architecture refactor solved both problems pretty easily — I spent about an hour on each issue.

---

The Biggest Problem: A very loud buzzer remains the biggest and unsolved issue.

I tried to tame it in software using PWM (Pulse Width Modulation) to decrease the volume. But PWM control is tricky on its own, and since the buzzer relies on a fixed frequency to generate tone, layering custom PWM over it completely broke the audio pitch.

---

Next Up:

• Implement smooth scrolling text for the console startup screen.
• Conquer this cursed PWM/volume issue once and for all.
• Start writing a Flappy Bird clone

DevLog №4

 
What’s New
Pause Menu Implemented: Players can now pause the game at any time with two options:
-> Continue: Return to the game with all current progress intact.
-> Exit to Menu: Quit to the main menu (resets all game progress).
 
Technical Challenges
The main challenge was handling this within my current architecture, which relies on a main loop with a nested switch statement for state management. I needed a reliable way for these states to communicate and handle game object lifecycles properly:
-> Persisting Objects: Retaining game objects in memory when resuming from pause.
-> Cleaning Up: Safely destroying objects and resetting state when returning to the main menu (either voluntarily or on Game Over).
 
Next Goals
-> Add sound effects using the built-in piezo buzzer.
-> Implement a new mini-game: Flappy Bird.

DevLog №3 :
What I worked on: Started implementing the Pause state during gameplay. To make this work properly, the game needs to preserve the current state of both the Snake and Food objects when transitioning into pause and back. Slightly refactored the main loop architecture and updated the SnakeGameHandle function.

The Struggle: decided to write a helper function to update values inside my StateMachine (handling states like Game, Menu, Pause, Snake, FlappyBird).Blaming it on late-night fatigue, I wrote the function in the most overcomplicated way possible… and called it even worse.

The result? Every time I exited the Snake game, I was greeted by a blank black screen because the Menu state was never getting assigned correctly.
I spent over an hour staring at the code, completely stumped as to why it was breaking.

I think it happened because of self-assignment

The Fix: Decided to get some sleep. Woke up the next morning with a fresh head and fixed the black screen issue in 20 minutes.

Next Goal: Finish up the Pause feature completely

devlog #2:
added StateHandle file to handle all the actions(menu, games) in my main loop in main.cpp. Now my main loop is shorter and more understandable

Devlog #1:
I uploaded all the files I had written before I found out about Hack Club. After that, I spent most of my time figuring out how to detect collisions between the snake and the food. Since I originally built everything pixel-by-pixel instead of using a grid system, comparing screen positions directly required too many pixel checks. To optimize this and avoid checking every single pixel pair, I had to tweak the logic. Even though it was tricky to adjust without a strict grid, the collision detection is working now and the game is totally playable