DEV Community: Luis F. Patrocinio

Diving into Doxygen: Documenting for Devs, Teammates, and AIs

Luis F. Patrocinio — Sat, 14 Mar 2026 16:48:02 +0000

Ah, code documentation. That one thing we all love when we need it, but when it's time to actually write it... it can be a drag, right?

If you've ever worked on a team, you know how crucial good documentation is. It avoids the classic "hey, how do I use this function of yours?" and makes onboarding a new dev a much less painful experience. But what about when it's a solo project? Trust me, your "future self" will be immensely grateful for not having to decipher code that you wrote six months ago.

A quick note before we dive in: I originally drafted this post a few months ago, and in that short time, the world of coding has been completely shaken up by AI assistants. You might think that with tools like Copilot writing code for us, old-school practices like documentation are becoming obsolete. But I've found it's exactly the opposite. These fundamentals are now more important than ever. Think of it this way: good documentation is what trains your AI assistant to be a useful partner, not just a random code generator.

As Harold Abelson once said:

"Programs must be written for people to read, and only incidentally for machines to execute."

It's the absolute truth. But lately, that quote has gotten a modern upgrade. Today, besides your team and your future self, there's a new "reader" for your code: Artificial Intelligence. Tools like Copilot and other generative AIs have become our new, omnipresent interns, and well-documented code is what guides them to provide truly useful suggestions.

The Philosophy: Why Bother? The Classic Benefits (and the New AI Bonus)

When I think about code structure, the K.I.S.S. principle (Keep It Simple, Stupid!), a concept I've recently come to appreciate, always comes to mind. Code that is direct, predictable, and has clearly defined responsibilities isn't just more elegant; it's infinitely easier to maintain and, of course, to document.

In my opinion, this is even more valuable in game development. Imagine a single function that handles collision, applies damage, updates the UI, and plays a sound, all at once. That's a nightmare to maintain. It quickly becomes a house of cards, with everything tangled and dependent on everything else.

Combining simple code with a great documentation tool like Doxygen offers incredible advantages:

📑 It standardizes your documentation: Creates a consistent pattern that the entire team (and AIs) can follow.
🤝 It makes collaboration easier: Reduces the need to ask obvious questions and speeds up development.
🤖 It supercharges your AI: Clear comments and tags (@param, @return) are fuel for AIs. They use these "magic words" to understand the intent of your code and generate much more intelligent and accurate suggestions.
🛠️ It generates professional output: Automatically transforms your comments into a navigable HTML website or a PDF.

And yeah, I also think it's a bit sci-fi to be writing for an AI, but it's our new, and increasingly real, reality.

We let the AI handle the boring and heavy work while we enjoy a little time travel.

Doxygen: The Magic of Turning Comments into Docs

Doxygen generates documentation from comments you write directly in your code. While it's a powerhouse in the C/C++ world, it also supports many other languages.

The "magic" happens with special comment blocks. Check out this C++ example:

/**
 * @brief Calculates the final damage to be applied to a target.
 *
 * It takes the target's defense and the possibility of a critical hit into account.
 *
 * @param baseDamage The base damage of the weapon or skill.
 * @param targetDefense The target's defense value.
 * @param isCritical A boolean indicating if the hit was critical.
 * @return The final calculated damage.
 */
int CalculateDamage(int baseDamage, int targetDefense, bool isCritical);

Commands like @brief, @param, and @return are "tags" that Doxygen understands and uses to structure the documentation.

Getting Your Hands Dirty: Your First Steps

Want to get started? Using Doxygen from the command line is pretty simple:

Generate the config file: In your terminal, navigate to your project's folder and run doxygen -g. This will create a configuration file named Doxyfile, which contains tons of customizable options to define how you want your documentation to look.
Generate the documentation: After tweaking the Doxyfile (at least to point to your source code folder and an output folder), just run doxygen Doxyfile.

And that's it! A folder containing a navigable HTML site of your documentation will be created.

Doxyfile configuration file generated with doxygen -s -g

If you don't like the idea of editing the huge (and intimidating) Doxyfile by hand, there's also DoxyWizard, a graphical user interface that makes the configuration process much easier.

Not Just for C++: Documentation in the Game Dev World

This philosophy of in-code documentation isn't exclusive to Doxygen. Our favorite game engines already have built-in mechanisms for this:

In GameMaker, the community widely uses the JSDoc standard. By using tags like @description and @param, you can create tooltips and other useful info that pops up right in the IDE when you hover over a function. Link to GameMaker Docs

In Godot, it's even more integrated. GDScript comments starting with ## are treated as documentation and are displayed in the editor's help panel. They even support BBCode for formatting, like [b] for bold and [codeblock] for code examples. Link to Godot Docs

This just goes to show that, no matter the tool, the practice is universally powerful.

So, What Now?

Documenting your code doesn't have to be a headache. With the right tools and a bit of discipline, we can turn a tedious task into a valuable investment for the future of our projects—whether it's for our team, our future selves, or even the AI that's helping us code.

I'm currently exploring the best way to integrate Doxygen-generated documentation with GitHub Pages to make it all accessible online automatically. Once I have a solid workflow, I promise I'll be back with a new post to share the details. 😉

Until then, why not take a look at your own projects and see where a little documentation could make a big difference? I'm always looking to improve my workflow, especially with AI, so if you've found a better way to do this, let me know over on [LinkedIn/X]! I'd love to learn from your experience. 🚀

Taming Tedious Tasks with a Tiny Titan: The ESP32 Auto-Controller

Luis F. Patrocinio — Mon, 17 Nov 2025 12:38:18 +0000

Hey, dev community! Patrocinio here. I'm back after a productive few months of focused learning.

I've got a lot of new projects and insights ready to go, and I can't wait to share them. Let's jump right in. As someone who lives and breathes the gamedev universe, and while studying the fascinating world of embedded systems, I've always asked myself: how can I merge these two worlds?

The other day, while playing the incredible Pokémon Red, I stumbled upon a wild challenge: you need 9,999 coins to buy Porygon! And the biggest jackpot in the casino, if you're incredibly lucky, is just 300 coins. I realized that to beat this challenge, the process could be boiled down to a single action: mashing the 'A' button forever. Eventually, the coins would come. My inner engineer immediately screamed, "Why not build a joystick to do that for me?".

(Just a side note: this mindset is mentioned in the book "A Theory of Fun for Game Design", which talks about how players, by nature, tend to optimize the fun out of games, often looking for the easiest path to victory. It's like we're programmed to "cheat", dominating a pattern. Our brain wants to solve the problem!)

And so, the uncontrollable urge to create the PatroAutoController was born. I want to share the key lessons from this quest with you.

The Armory: Our Forging Tools

For this endeavor, our "loadout" was carefully chosen:

🧠 The Brain (ESP32): A powerful microcontroller with built-in Wi-Fi and Bluetooth. It's our brainy, brawny hero.
🕸️ The Nervous System (FreeRTOS): Instead of a giant, confusing loop(), we used a real-time operating system. This lets us have "mini-brains" (tasks) running in parallel.
🛠️ The Workbench (PlatformIO): Using PlatformIO in VS Code is like having a perfectly organized workshop. It manages our libraries, compilation, and uploads.
📜 The Magic Scroll (ESP32-BLE-Gamepad Library): This incredible library does all the heavy lifting to turn our ESP32 into a Human Interface Device (HID).

The Build, Level by Level

Building robust software is like forging a sword: each layer adds strength and functionality. But as challenges grow, you don't just need a sword. You start building an arm cannon, a blaster that can fire powerful shots to take down the toughest bosses.

💠Level 1: The Modular and Scalable Architecture

From the very beginning, the goal was clear: the project had to be modular and scalable. I knew this small idea could grow, so I built a solid foundation that would allow for easy expansion and modification in the future. Instead of one giant main.cpp, we separated the responsibilities:

config.h: Where all the "magic numbers" (pins, delays) live.
HardwareIO.cpp: An abstraction layer for the hardware, with functions like io_read_potentiometer().
JoystickController.cpp: Where all the Bluetooth logic resides.

A good architecture is what separates a prototype from a product. It saves us from the spaghetti code monster! It's worth the effort!

💠Level 2: Mastering the Analog World

This project was also an excuse to explore the potentiometer better. As an analog component, it offers incredibly fine-grained control. All I had to do was adjust the range in the code to set the speed limits. It was a great opportunity to understand how it works in practice: it acts as a variable resistor, controlling the resistance applied to the current. By turning it, we change the voltage that the ESP32's analog pin reads, giving us a continuous spectrum of values to work with.

// Inside our task_read_potentiometer...
void task_read_potentiometer(void *pvParameters) {
  for (;;) {
    int rawValue = io_read_potentiometer_raw();
    // We map the ADC value (0-4095) to our desired delay
    joystick_delay = map(rawValue, 0, 4095, MIN_DELAY, MAX_DELAY);
    vTaskDelay(pdMS_TO_TICKS(100)); // Pause without blocking!
  }
}

A quick note: Ever wonder why the ADC value goes from 0 to 4095 specifically? It's because the ESP32's ADC Resolution is 12-bit. That means the number of distinct values it can produce occupies 12 bits. 2¹² = 4096 possible levels.

💠Level 2.5: The Unexpected (and Happy) Detour

Initially, I planned to build a USB controller. However, I ran into a crucial hardware limitation: the standard ESP32 I was using doesn't have a native USB controller (OTG). Its USB port is only for programming and serial communication. For a USB controller, I'd need an ESP32-S2 or S3.

However, this closed door opened another path. This "obstacle" forced me to look at the ESP32's other great feature: Bluetooth. And what a great call that was! The implementation was surprisingly smooth, and the final result was a wireless controller, which, let's be honest, is infinitely cooler.

It Looks Like Magic, but It's Technology: How the ESP32 Becomes a Joystick

Okay, but how does this "transformation" happen? How does a simple microcontroller convince a computer or phone that it's a joystick? It's not magic. It's a very clever protocol.

When a Bluetooth device connects to a computer, it's not a casual meeting. It's more like a job interview. The device has to introduce itself and state exactly what its skills are.

This is where an incredible feature of Bluetooth (and USB) comes in: the HID Profile (Human Interface Device). Think of profiles as job titles: a headset uses the audio profile, and a controller uses the HID profile. It's a universal language for mice, keyboards, and, of course, joysticks.

What the ESP32-BLE-Gamepad library does behind the scenes is handle this entire "negotiation":

The Advertisement: The ESP32 starts broadcasting via Bluetooth: "Hello! I'm not just any device, I'm an HID Gamepad!" Your phone or PC sees this ad and already knows how to talk to it.
The Contract (Report Descriptor): Once the connection starts, the ESP32 sends a detailed "map" to the computer. This map says, in a standardized format, "I have 16 buttons, 2 analog sticks (X/Y axes), a D-pad, etc". The operating system reads this map and creates the virtual joystick device.

From there, our code just needs to send tiny data packets like "Button 2 was pressed". The crucial point is that all this communication must be assembled bit by bit, following strict protocol specifications. This all needs to be written in low-level, almost machine-level programming. And thankfully, the ESP32-BLE-Gamepad library handles all of this for us.

It does all the complex byte manipulation behind the scenes, giving us clean, simple functions like joystick_press_button(2). In the end, our "magic" as programmers is knowing how to choose and use the right tools that let us focus on our game's logic, not the bureaucracy of protocols.

💠Level 3: Unleashing the Bluetooth Magic

With the decision to use BLE, the next FreeRTOS task became the heart of the project. This is the code for the task responsible for pressing the button "infinitely". It's a loop that will run in parallel.

// Inside our task_joystick_press...
void task_joystick_press(void *pvParameters) {
  for (;;) {
    if (joystick_is_connected()) {
      io_blink_led(); // Visual Feedback
      joystick_press_button(2); // Press Button 2
      joystick_release_button(2); // Release immediately
      vTaskDelay(pdMS_TO_TICKS(joystick_delay)); // Wait for the time set by the potentiometer
    } else {
      vTaskDelay(pdMS_TO_TICKS(1000)); // Waiting for connection
    }
  }
}

The beauty of FreeRTOS shines here: while this task is "sleeping" in vTaskDelay, the potentiometer task is free to run and update the speed. No blocking, maximum responsiveness!

Victory! The Final Result

After defeating a few mini-bosses (like blocked pins and library dependencies), the moment of truth arrived. I powered on the ESP32. On my phone, a new Bluetooth device appeared: "PatroAutoController". I connected. I opened an emulator. And there it was, my character in the Game Corner, automatically racking up coins. I turned the potentiometer, and the speed changed instantly.

The feeling of solving a real in-game problem with hardware you built and programmed yourself... it's simply indescribable. And this freedom is achieved through a lot of study and practice!

You can check out all the code, the structure, and the full documentation in the GitHub repository!

PatroAutoController GitHub Repository

Next Level: What's to Come?

This project is proof that a simple idea can become a delightful learning journey. And now, with this modular foundation, the possibilities are endless. An accelerometer-based controller? A web interface for configuration? Who knows?

What we do know is that the knowledge we've gained will let us move on to bigger and better things. This is purely the Mega Man Method™️! I hope this story has inspired you to cross the borders between your own passions. We can grab a microcontroller, have a crazy idea, and start building!

Until next time, and let's keep leveling up our skills!

Maximizing Memory Management: Object Pooling in Games

Luis F. Patrocinio — Mon, 28 Apr 2025 04:18:27 +0000

As I shared in my first post, I started programming games without much ambition -- I just wanted to have fun with my friends. Back then, I didn't really think about what was happening behind the scenes, especially when it came to memory management or performance. I just wanted to make little games, and that was it!

However, as I dove deeper, studying programming more seriously and working professionally, I learned that creating and destroying objects all the time comes at a cost. And this becomes crucial when porting games to consoles or when we need to ensure a game runs well on more limited systems.

In any case, in real-time applications like games -- and even more so in embedded systems -- efficient memory management is ESSENTIAL. That’s when I discovered the concept of Object Pooling. I remember that some veteran friends had mentioned it before, but I completely ignored it at the time.

What is Object Pooling?

Instead of creating and destroying objects during gameplay (which consumes processing power and constantly allocates/deallocates memory), Object Pooling is a technique where you pre-create a set of objects and reuse them.

When you need an object, you take an available one from the pool.
When you're done using it, you reset it and return it to the pool for future use.

This avoids costly operations like memory allocation and garbage collection, making your game much faster and more stable -- especially in situations with lots of projectiles, enemies, effects, or particles.

Notice in the GIF below that our friend Megaman X can only fire up to three bullets at a time. This is a classic example of object pooling: each projectile is kept "off-screen" in a pool of three, deactivated and waiting for the player to fire.

Why is Object Pooling so important?

Performance Boost: Reduces CPU and memory usage.
Consistency: Prevents random frame drops or micro-freezes.
Control: You know exactly how many objects exist at any moment.
Scalability: Helps your game handle large numbers of simultaneous objects better.

Even with today’s powerful consoles, we can’t go overboard with objects being constantly created and destroyed. And in embedded systems, where resources are extremely limited, techniques like object pooling aren't just good practices -- they’re necessary.

Is it really necessary to implement Object Pooling?

A common question -- especially for those using modern engines like GameMaker, Godot, Unity, or Unreal -- is: "If there’s already automatic Garbage Collection, do I still need to worry about this?"

I’ve asked myself that same question before. The answer is: it depends on your project. 😅

For small games or scenes that don’t frequently instantiate/destroy objects, the engine's garbage collector can handle everything without noticeable issues.

However, in games that involve a high volume of rapid instances (for example: shooters, hack-and-slash, bullet hells, or intense particle systems), constant creation and destruction will cause overhead -- and at that point, even the garbage collector won’t prevent performance drops.

In those cases, implementing Object Pooling manually can make a huge difference in keeping your game smooth and responsive.

Simple Example of Object Pooling

Imagine a simple projectile pool: At the start of the game, you create 100 projectiles and keep them deactivated.

When the player shoots, you activate an available projectile from the pool instead of creating a new one. When the projectile hits something or leaves the screen, you deactivate it and return it to the pool.

Here's a basic pseudocode example. I initially started writing an example in C, but it was getting way too big, so I decided to simplify it with this small block of pseudocode instead:

pool = createProjectilePool(size=100)

function shoot():
    projectile = pool.getAvailableProjectile()
    if projectile != null:
        projectile.activate(position, direction)

function onProjectileDestroyed(projectile):
    projectile.deactivate()
    pool.returnProjectile(projectile)

As you can see, the shooting function fetches a reference to an available projectile (with an inactive status) and activates it, repositioning it accordingly.

When a projectile is destroyed, we simply change its status flag back to deactivated. A deactivated projectile isn't rendered or processed, saving a lot of resources.

Final Thoughts

The truth is, many modern game development tools already have very efficient garbage collection mechanisms, which can often give the impression that object pooling is obscure or unnecessary -- but it's important to note this is only how it seems!

However, when developing games for limited systems -- like a small game running on a microcontroller -- every byte of memory matters, and object pooling becomes absolutely essential.
Not to mention that it’s a way to build faster, more stable, and more optimized games overall.

Of course, if you're just starting your journey in game development, don’t worry if these optimizations seem complex right now. With time and practice, they'll become natural, an effortless habit.

And if you've already mastered the basics, learning and implementing techniques like Object Pooling is an incredible next step to take your projects to the next level!

Thanks for reading, and I hope this little knowledge drop was helpful to you!

Wired with WebSockets: Experiments in Real-Time Multiplayer Communication

Luis F. Patrocinio — Sun, 20 Apr 2025 19:01:25 +0000

One of the coolest things I’ve learned on my journey as a developer was understanding how real-time communication works in games. For a long time, it felt distant, complicated, and really hard to understand.

But that started to change when I joined the Systems Analysis and Development graduation course at IFPI. Throughout the classes and projects, I began to understand how everything works and started seeing WebSockets differently -- as an accessible, powerful, and incredibly fun tool to work with.

In this post, I want to walk you through that journey in a simple and practical way, starting from the basics and showing how we can implement this kind of communication in games or other real-world applications.

WebSockets vs HTTP

One of the main advantages of WebSockets over traditional HTTP is asynchronous and bidirectional communication. It's bidirectional because both the client and the server can "start a conversation," and asynchronous because messages don’t have to follow a strict request-response pattern.

With HTTP, for example, a game would need to keep polling constantly (asking "hey, is there anything new?"), which is pretty inefficient. But with WebSockets, a single persistent connection is enough, and the server can notify when something new happens.

WebSocket connections actually start as regular HTTP requests -- the initial handshake is HTTP, and then the connection is upgraded to a WebSocket. So in a way, it's like an improved version of HTTP, designed to support real-time communication.

In a WebSocket network, all messages go through the server, which can process, validate, and route them as needed. WebSockets also allow either party to close the connection, which is why it's common to have specific methods to handle these events (like reconnections or state cleanup).

Starting with an Echo Server

The first thing I did was implement an Echo Server using Python. This is one of the simplest ways to experiment with WebSockets: the server just sends back to all clients any message it receives.

import asyncio
import websockets

# Set to store active connections
connected_clients = set()

async def echo(websocket, path):
    # Add the connected client to the set
    connected_clients.add(websocket)
    try:
        async for message in websocket:
            # Send the received message to all other connected clients
            for client in connected_clients:
                if client != websocket:  # Avoid sending it back to the sender
                    await client.send(message)
    finally:
        # Remove the disconnected client from the set
        connected_clients.remove(websocket)

async def main():
    # Set up the WebSocket server
    async with websockets.serve(echo, "localhost", 8765):
        await asyncio.Future()  # Keep the server running

asyncio.run(main())

This setup uses two important Python libraries: asyncio and websockets.

Asyncio is a Python little library that helps handle asynchronous tasks, which means running multiple operations at the same time efficiently, without blocking the program.

Websockets is another little library that implements the WebSocket protocol, allowing real-time communication between clients and servers. We use it to create a persistent communication channel without the need to establish new connections each time.

In this code block above, we set up the server to call the echo function whenever a new client connects. This function listens for messages and echoes them to all other connected clients. Pretty useful haha

Creating a WebSocket Game in the Browser

My second experiment was connecting multiple people to the same game through their browsers. Each player would access a page on their phone and could join the game in real time.

At this point, I started using JSON messages, which are very common in the web world. Each message sent had a type and some data. For example, when a new player joined the game:

{
  "type": "playerJoined",
  "data": {"name": "Patrocinio", "iconIndex": 3}
}

This type and data message structure allows you to create a custom protocol -- it's like inventing a mini-language between the client and the server. The server would then handle the message based on its type and send updates to the other players. This kind of structure helped me better organize game logic and understand how to build personalized protocols on top of WebSocket.

It's a powerful approach, because both client and server speak the same "language", based on standardized message formats. Every time a new game feature was added, I just needed to define a new type and its corresponding handler.

In this case, the game was played on a TV, while players used their phones as controllers. Each phone (via browser) would send information through WebSocket to the game running on the TV.

However, notice that in this particular scenario, it wasn’t important for all clients (the players) to know when others joined the game -- that information only mattered to the main game instance (which was also a WebSocket client).

Since I didn’t yet know how to segment messages for different types of clients, the server echoed everything to everyone. That meant all players were receiving unnecessary data, which caused a small waste of bandwidth and processing. Even so, the server worked well for its experimental purpose -- and the learning experience was what truly mattered.

Evolving with WebSockets: Identification, Best Practices, and My Final Project

Over time, I started facing more complex challenges -- like distinguishing between different types of connected devices (phones vs. the game on the TV), identifying clients right after connection, handling disconnections, and avoiding unnecessary broadcasts. I also began adopting some best practices that remain essential in the projects I work on today:

🔹Identify each client as soon as they connect
🔹Handle disconnections by cleaning up inactive connections
🔹Avoid unnecessary broadcasts, sending messages only to those who need them
🔹Standardize the message format, usually using JSON with type and data fields
🔹Create a clear protocol structure, to make maintenance and expansion easier
🔹Separate clients by room/session, especially in larger games (I still need to learn more about this part haha)

It's important to say that in low-resource environments, like embedded systems, I also learned that JSON is often replaced by fixed-size binary buffers -- a more efficient approach that requires well-defined protocols. This topic is super interesting and definitely deserves its own post. (Coming soon! 😄)

Today, I’m putting all this knowledge to work in my final university project: a multiplayer arcade platform where players use their phones to join games via QR Code. Everything communicates in real time using WebSockets -- from login to session control.

It’s a challenging and exciting project, and I’ll definitely be sharing more about it in future posts! Stay tuned!

🔵⚙️ PS: I added Megaman to cover the QR codes as a reminder: keep learning, keep evolving. Just like Megaman gains new powers with each challenge, we level up with every experiment.
Trust the Megaman Method™️!

Trigonometry Tricks: The Math Behind Game Effects

Luis F. Patrocinio — Sun, 13 Apr 2025 15:51:25 +0000

Hey folks! This is one of those posts I was really excited to write: we're finally talking about math! Yes, the one that many people try to run from... but in the world of gamedev, it can become one of our greatest allies.

I’ve always loved this subject, especially because it blends perfectly with game development -- especially when the goal is to add that visual spice that transforms a prototype into something that feels like a game.

Those little effects that make everything look smoother, more dynamic, more alive. That famous magic of game feel (you’ll see me talk a lot more about that in future posts 😄).

🧠 Math Is Everywhere

Math is like the invisible engine behind almost everything that works in a game (in world, actually!). From basic movement to physics and particle systems -- there’s always some formula running under the hood.

And when it comes to bringing systems and movement to life in games, one branch of math really stands out: trigonometry.

🔺 The Unit Circle (Wait, don’t run!)

For many, trigonometry is that horrible topic from high school that caused some sleepless nights. But believe me -- in the right context, it’s actually fun and extremely useful.

It all starts with the unit (or trigonometric) circle: a representation of a circle where each point on the edge can be described by an angle. That angle gives us two magical values: sine (sin) and cosine (cos). These basically tell us the height and width of a point on the circumference.
In the next image, take a look at sin behaviour:

If we try to get the sine of any value -- for example, the game’s running time -- we get the projection of that angle from -1 to 1. This creates a sine wave, an awesome and easy ripple effect.

These functions are cyclical -- they repeat -- and that makes them perfect for simulating smooth, continuous patterns in games.

✨ Trigonometry in Visual Effects

Sure, trig includes tangents, secants, cotangents... but let’s keep it simple. Here, we’ll stick to sine and cosine -- they’re more than enough to create some really cool stuff.

Here some examples:

🔸Circular movement: enemies orbiting the player, or spinning items on the map.

🔸Subtle pulses: like that "breathing" effect on menu buttons.

🔸Oscillations: sprites floating or gently swaying.

🔸Arcing projectiles: like arrows or magical spells.

🔸Rotating lasers: using dynamic angles.

🔸Waves and tremors: screen shake or shader effects.

🔸Wobbly stuff: that jiggly, gooey motion like a slime creature or melting object.

All of this can be done with just a few lines of code using sine, cosine, and time.

🎮 Trigonometry in Game Logic

Modern engines come with tons of features built-in -- from collision detection to movement using vectors. But knowing a bit of math gives you more freedom and flexibility to do things your way.

For instance, instead of using a bunch of ifs to determine which direction sprite to show based on player movement, you can just compare the sine and cosine values of the movement angle. Something like:

That famous quote comes to mind: “It looks like magic, but it’s just math.”

📈 The Learning Curve

It seems complicated at first -- and that’s totally normal. Years ago, I used to avoid anything that involved sine or cosine in my projects. I thought, "That stuff isn’t for me."

But then came our old friend: the Megaman Method™.🔵⚙️

Every challenge we overcome gives us a new weapon, a new skill. At first, we get wrecked. But after repeating a few levels and defeating some bosses, we realize we’ve leveled up. And before we know it... we’re using sin(time) to animate our HUD energy bar 😅

What used to be scary becomes fun. And every new technique is one more power added to our arsenal.

💡 EXTRA: Trig Fun Facts

🔢 atan2(y, x) is a hero: this function calculates the correct angle of a vector on a Cartesian plane, accounting for all quadrants. It’s used to aim enemies toward the player, create auto-aiming systems, or just figure out where something’s heading.

🔫 Bullet Hell games: Games with crazy projectile patterns (like Archvale or Enter the Gungeon) use trig all the time! Patterns follow rules like angle + sin(time) or angle += speed, creating hypnotic and challenging effects.

🎨 Advanced shaders: In shaders, just sine and cosine can go a long way. You can create real-time waves, distort textures, make psychedelic effects... it’s the ultimate playground (for the brave-hearted) of trigonometry.

🚀 To Wrap It Up...

You don’t need to master every bit of math to make amazing games. But the more you explore it, the more doors open -- and the more magical your creations become.

So if you’ve made it this far, why not try sprinkling a little sine and cosine into your next project? Whether it’s for a visual touch or an elegant solution to a complex logic -- math might just become your best sidekick.

Make math your ally -- and I promise: this knowledge will transform your projects.

Trust the Megaman Method™.

Learning and Leveling Up: Beyond the Tutorial

Luis F. Patrocinio — Wed, 09 Apr 2025 12:19:36 +0000

🚀 Learning by Doing -- and Understanding

As a developer, one thing I strongly believe is that there’s no better way to learn than getting hands-on and diving into the official documentation of the technology we’re working with.

Nothing against step-by-step YouTube tutorials or plug-and-play little libraries that come with everything ready to go. They have their place: they help speed up prototyping, save time with tested and reliable solutions, and even teach us the best ways to apply the core concepts. But when it comes to deep learning -- especially in areas where performance and optimization are crucial (like games or embedded systems) -- understanding how things work under the hood makes all the difference.

Yes, it’s more work, and it takes more time. But the knowledge we gain stays with us, and it makes us faster when facing future challenges. It’s like Megaman, the classic game character -- he absorbs the power of the enemies he defeats, making it easier to beat even stronger ones later on. I love this metaphor, and you’ll definitely "hear me talk" a lot about the "Megaman Method". 🔵⚙️

📡 Exploring Wi-Fi Networks on the RP2040

Recently, as part of a hands-on embedded systems residency program I'm currently enrolled in, I worked with the RP2040 microcontroller to scan for Wi-Fi networks using the cyw43 driver from the official Raspberry Pi SDK.

The proposed challenge was simple: print the found networks to the serial monitor. But I saw a great opportunity to go further. Instead of just printing to the terminal (as suggested), I built an interactive network selector directly on the BitDogLab board (an educational board with buttons and a display -- I’ll be talking about it more around here, too).

It was an awesome experience -- beyond learning how the driver and SDK work internally, I ended the day with a fully functional piece of software, ready for my portfolio or as a base for future projects. (I even made my own "little library"!)

⏱️ Understanding Interrupts with a Timer

Another interesting challenge we faced involved using interrupts to build a stopwatch. The goal was to better understand how interrupts work on the microcontroller by using callback functions with repeating timers.

While reviewing a friend's code, I noticed he was manually tracking the elapsed time using a variable. That got me thinking: "Doesn’t the SDK already offer a function to return elapsed or remaining time?" I went digging through the documentation -- and yes, it does: pico_time/time.c -> remaining_alarm_time_ms.

A simple question ended up leading me to a better understanding of the SDK’s built-in features and allowed me to write cleaner, more reliable code -- and with more functionality.

📦 The Art of Building Little Libraries

Creating small libraries during development is a great way to practice concepts like modularity, code reuse, and project organization. Besides making the software or game more scalable and reusable, this kind of practice reinforces solid design and architecture principles.

These are essential skills for tackling larger projects -- not to mention the soft skills involved, like autonomy, curiosity, and initiative, all of which are highly valued in any tech team.

🎮 And in Game Development? The Logic Is the Same.

In the gamedev world -- especially when working with popular engines like Godot or GameMaker -- we have access to an ocean of plugins, add-ons, and ready-to-use libraries. And that’s great -- but it can become a trap if we stop understanding how and why things work.

When we create our own systems (a scene manager, AI logic, camera controller, particle system, etc.), we not only learn much more, but we also build real technical baggage, gain independence, and -- over time -- start making smarter decisions in future projects (after all, we already know the pitfalls to look out for at each stage).

🧠 Final Thoughts:
Learn by exploring. Go beyond what’s necessary. Don’t be afraid -- or lazy -- to understand why things work the way they do. We only grow from it. 💫

Thanks for making it to the end -- See ya! ✌🏼

Patro Powered by Passion: Games, Systems, and Infinite Learning

Luis F. Patrocinio — Mon, 07 Apr 2025 02:45:13 +0000

👋 Hello, world! I'm Patrocinio!

Hi everyone! My name is Luis Felipe, but I'm best known by my last name: Patrocinio (or just Patro!). I've wanted to start an online profile to share my journey, projects, and ideas with the Dev community for a long time --- and I'm so excited to finally begin!

For this first post, I thought it would be cool to share a bit about myself, my background, and some key decisions that led me here --- decisions that changed not just my career, but also the way I view technology and creativity.

🎮 From Hobbyist to Professional Game Developer

My journey started with a passion for making games just for fun. Around 2015, while I was still studying Accounting, I teamed up with a close friend to help with some of the bureaucracy and accounting issues of his game studio. I had no idea that distant first contact would change everything.

That experience made me realize that creating games wasn’t out of reach, so I dove into programming --- making small projects to play with friends, always learning from tutorials and participating in gamedev communities (which opened my eyes to incredible new possibilities!).

Today, many years later, I run my own game studio Black Hole Games and also collaborate with other studios, building projects of all sizes and for all kinds of platforms. Game development is part of my everyday life --- it’s how I learn, how I create, and how I connect with others.

I frequently participate in game jams and have published dozens of games on my itch.io profile --- many built under super tight deadlines, starting from wild ideas that became fun little games. You can check them out! o/

💡 Technology as a Form of Creative Expression

To improve my skills, I joined a degree program in Technology in Systems Analysis and Development. I’m always channeling what I learn into game development --- whether it’s data structures, software engineering, web server creation, or AI.

More recently, I’ve had the chance to dive into a totally new world: Embedded Systems.

I’ve fallen completely in love with low-level hardware programming using C. It’s opening my mind to an entirely different layer of computing. Building everything from absolute scratch is a whole new level of challenge --- and I’m hooked!

It's amazing to think that sitting at a desk, typing sequences of code instructions, allows us to create authentic applications --- from games that deliver fun to systems that control real-world actions. That power to create is what drives me.

🚀 What to Expect Here

I'll be sharing posts about:

🎮 Game development experiences and insights (mainly GameMaker and Godot)
🧠 Programming concepts and challenges
🔧 Embedded systems exploration (yes --- microcontrollers and C!)
📓 Reflections and musings from a tech student and lifelong learner
👾 Game analysis (retro, indie, and modern titles)
💼 Game business and entrepreneurship (from freelancing to running a studio)

🌌 A Little More About Me

Outside of programming, I’m fascinated by things that shape how I see the world (and influence my creative process too):

I love astronomy 🪐, body language 🧘‍♂️, science fiction 🧬, parallel universes 🌌, love stories 💞, sports 🏐, books 📚, good drinks 🍹, and of course, games 🕹️.

✨ Thanks for reading this far! See you in the next post! 🚀