DEV Community: Dean (딘)

Devlog #01: Making Fish Swim

Dean (딘) — Tue, 13 Jan 2026 16:31:42 +0000

The last couple of months I've been fiddling around with Godot and did all sorts of random experiments, from educating myself and getting more comfortable with the engine, to building small prototypes, where I would challenge myself to build one specific thing first.

This journey taught me a lot about the engine and how I can utilize it in the future to build my first fully-fledged game.

Finding the game idea

I had a few ideas in mind what I wanted to create. Started with a heavy logical game with a lot of math and variables, as I wanted my first game to be a simulation game. I must admit, this was not the smartest idea for my first game but one, I'll definitely look into more in the future - not now.

In the end it came down to a game, where the player owns a fish tank, which they have to manage. It's more of a cozy idling management game, where the player feed fish, get more fish, get some upgrades to make life easier (autofeeder, cleaner, etc.), and maybe some challenges to keep the player actually engaged. The game plan is simple and a good starting point for my first game.

Iteration 1: Getting fish moving

From my previous experiments I knew how to move a character around on a 2D scene. So I started by searching for a placeholder fish sprite, placed it in my scene and added a simple movement script to it, which moved the fish around at random directions every few seconds. I used a timer that counts down using the delta value passed to Godot's _physics_process function.

The fish extends the CharacterBody2D node, which gives us built-in physics and collision handling. I used a simple state machine (enum State) to manage different behaviors, though for now we're only implementing the WANDER state.

class_name Fish
extends CharacterBody2D

enum State {WANDER, HUNGRY, EATING, FLEEING}

@onready var pathing: Line2D = $Pathing

@export var speed: float = 100.0
@export var prediction_length: float = 200.0
@export var prediction_steps: int = 20

var current_state: State = State.WANDER
var wander_direction: Vector2 = Vector2.ZERO
var wander_timer: float = 0.0

func _ready() -> void:
  _choose_new_wander_direction()

  if pathing != null:
    pathing.visible = OS.is_debug_build()

func _physics_process(delta: float) -> void:
  match current_state:
    State.WANDER:
      _handle_wander(delta)

  _update_visuals()

  if OS.is_debug_build():
    _update_path_prediction()

  move_and_slide()

func _handle_wander(delta: float) -> void:
  velocity = wander_direction * speed

  wander_timer -= delta
  if wander_timer <= 0.0:
    _choose_new_wander_direction()

  _keep_in_bounds()

func _choose_new_wander_direction() -> void:
  wander_direction = Vector2(randf_range(-1, 1), randf_range(-1, 1)).normalized()
  wander_timer = randf_range(2.0, 5.0)

func _keep_in_bounds() -> void:
  var viewport_size: Vector2 = get_viewport().get_visible_rect().size
  var margin := 100.0
  var turn_force := 2.0

  if global_position.x < margin:
    wander_direction.x += turn_force * get_physics_process_delta_time()
  elif global_position.x > viewport_size.x - margin:
    wander_direction.x -= turn_force * get_physics_process_delta_time()

  if global_position.y < margin:
    wander_direction.y += turn_force * get_physics_process_delta_time()
  elif global_position.y > viewport_size.y - margin:
    wander_direction.y -= turn_force * get_physics_process_delta_time()

  wander_direction = wander_direction.normalized()

func _update_path_prediction() -> void:
  if not OS.is_debug_build() or not pathing:
    return

  if current_state != State.WANDER:
    pathing.clear_points()
    return

  pathing.clear_points()

  var sim_pos := Vector2.ZERO
  var sim_direction := wander_direction
  var step_distance := prediction_length / prediction_steps

  for i in prediction_steps:
    pathing.add_point(sim_pos)
    sim_pos += sim_direction * step_distance
    _simulate_boundary_steering(sim_pos, sim_direction)

func _simulate_boundary_steering(sim_pos: Vector2, sim_direction: Vector2) -> void:
  var viewport_size := get_viewport_rect().size
  var margin := 100.0
  var turn_force := 0.5

  var world_pos := global_position + sim_pos

  if world_pos.x < margin:
    sim_direction.x += turn_force
  elif world_pos.x > viewport_size.x - margin:
    sim_direction.x -= turn_force

  if world_pos.y < margin:
    sim_direction.y += turn_force
  elif world_pos.y > viewport_size.y - margin:
    sim_direction.y -= turn_force

  sim_direction = sim_direction.normalized()

func _update_visuals() -> void:
  if velocity.x != 0:
    $Sprite.flip_h = velocity.x < 0

_keep_in_bounds() applies a gentle steering force, when fish approach the edges. This prevents them from leaving the viewport. The _update_path_prediction() function is used to visualize the fish's predicted path, which helps debug the movement.

This looked good at first and fish actually moved around the scene, but Fish would just get stuck and bump into each other not respecting the boundaries of the scene nor each other.

I then decided to add some sort of avoidance behavior and had to tinker around on the script to actually get something "working". I added seperation behavior - when the fish get too close, they calculate a "push away" vector inversely proportional to their distance.

class_name Fish
extends CharacterBody2D

enum State {WANDER, HUNGRY, EATING, FLEEING}

@onready var pathing: Line2D = $Pathing

@export var speed: float = 100.0
@export var prediction_length: float = 200.0
@export var prediction_steps: int = 20
@export var avoidance_radius: float = 60.0
@export var avoidance_strength: float = 3
@export var steering_speed: float = 2.0

var current_state: State = State.WANDER
var wander_direction: Vector2 = Vector2.ZERO
var wander_timer: float = 0.0
var current_direction: Vector2 = Vector2.ZERO

func _ready() -> void:
  add_to_group("Fish")
  _choose_new_wander_direction()
  current_direction = wander_direction

  if pathing:
    pathing.visible = OS.is_debug_build()

func _physics_process(delta: float) -> void:
  match current_state:
    State.WANDER:
      _handle_wander(delta)

  _update_visuals()

  if OS.is_debug_build():
    _update_path_prediction()

  move_and_slide()

func _handle_wander(delta: float) -> void:
  var avoidance_direction := _avoid_other_fish()
  var direction: Vector2

  if avoidance_direction.length() > 0.1:
    direction = avoidance_direction
  else:
    direction = wander_direction

  current_direction = current_direction.lerp(direction, steering_speed * delta).normalized()

  if current_direction.length_squared() > 0.01:
    current_direction = current_direction.normalized()

  velocity = current_direction * speed

  wander_timer -= delta
  if wander_timer <= 0.0:
    _choose_new_wander_direction()

  _keep_in_bounds()

func _choose_new_wander_direction() -> void:
  wander_direction = Vector2(randf_range(-1, 1), randf_range(-1, 1)).normalized()
  wander_timer = randf_range(2.0, 5.0)

func _avoid_other_fish() -> Vector2:
  var seperation := Vector2.ZERO
  var nearby_fish := 0

  var all_fish := get_tree().get_nodes_in_group("Fish")

  for fish in all_fish:
    if fish == self:
      continue

    var distance := global_position.distance_to(fish.global_position)

    if distance < avoidance_radius and distance > 0:
      Log.info("Avoiding fish at distance: %s" % distance)
      var push_away := global_position.direction_to(fish.global_position) * -1
      var strength := 1.0 - (distance / avoidance_radius)
      seperation += push_away * strength
      nearby_fish += 1

  if nearby_fish > 0:
    seperation = seperation / nearby_fish
    seperation = seperation.normalized() * avoidance_strength

  return seperation

func _keep_in_bounds() -> void:
  var viewport_size: Vector2 = get_viewport().get_visible_rect().size
  var margin := 100.0
  var turn_force := 2.0

  if global_position.x < margin:
    wander_direction.x += turn_force * get_physics_process_delta_time()
  elif global_position.x > viewport_size.x - margin:
    wander_direction.x -= turn_force * get_physics_process_delta_time()

  if global_position.y < margin:
    wander_direction.y += turn_force * get_physics_process_delta_time()
  elif global_position.y > viewport_size.y - margin:
    wander_direction.y -= turn_force * get_physics_process_delta_time()

  wander_direction = wander_direction.normalized()

func _update_path_prediction() -> void:
  if not OS.is_debug_build() or not pathing:
    return

  if current_state != State.WANDER:
    pathing.clear_points()
    return

  pathing.clear_points()

  var sim_pos := Vector2.ZERO
  var sim_direction := wander_direction
  var step_distance := prediction_length / prediction_steps

  for i in prediction_steps:
    pathing.add_point(sim_pos)
    sim_pos += sim_direction * step_distance
    _simulate_boundary_steering(sim_pos, sim_direction)

func _simulate_boundary_steering(sim_pos: Vector2, sim_direction: Vector2) -> void:
  var viewport_size := get_viewport_rect().size
  var margin := 100.0
  var turn_force := 0.5

  var world_pos := global_position + sim_pos

  if world_pos.x < margin:
    sim_direction.x += turn_force
  elif world_pos.x > viewport_size.x - margin:
    sim_direction.x -= turn_force

  if world_pos.y < margin:
    sim_direction.y += turn_force
  elif world_pos.y > viewport_size.y - margin:
    sim_direction.y -= turn_force

  sim_direction = sim_direction.normalized()

func _update_visuals() -> void:
  if current_direction.x != 0:
    $Sprite.flip_h = current_direction.x < 0

This was a good improvement as the fish now tried avoiding each other. However, another issue occurred: Fish would get stuck in the turning "animation" when bumping into each other or were about to bump into each other. This made it look very funny at first - but it was a bug I certainly have to fix as this will get very frustrating to look at especially when a couple of fish don't know what to do anymore and are stuck in an infinite turning loop while they still get new coordinates to move to.

Iteration 2: Fixing the turning loop

To fix this issue, I had to rethink how the fish were avoiding each other. The problem was that the avoidance behavior was too strong and would override the wander direction completely, causing fish to get stuck in a loop when multiple fish were trying to avoid each other at the same time.

I decided to implement a smoother steering system that would blend the avoidance direction with the wander direction, rather than replacing it entirely. I also added an alignment behavior that would help fish move in similar directions when they're near each other, which would reduce the chances of them getting stuck in a turning loop.

Here I switched the CharacterBody2D to Area2D because I no longer needed physics-based collision resolution as I'm now handling movement manually and using the area's signals to detect nearby fish more efficiently than iterating through all fish every frame.

class_name Fish
extends Area2D

enum State {WANDER, HUNGRY, EATING, FLEEING}

@onready var pathing: Line2D = $Pathing

@export var speed: float = 100.0
@export var prediction_length: float = 200.0
@export var prediction_steps: int = 20
@export var avoidance_radius: float = 60.0
@export var avoidance_strength: float = 5.0
@export var steering_speed: float = 2.0
@export var alignment_strength: float = 0.5

var velocity: Vector2 = Vector2.ZERO
var current_state: State = State.WANDER
var wander_direction: Vector2 = Vector2.ZERO
var wander_timer: float = 0.0
var current_direction: Vector2 = Vector2.ZERO

var nearby_fish: Array[Fish] = []

func _ready() -> void:
  add_to_group("Fish")
  _choose_new_wander_direction()
  current_direction = wander_direction

  area_entered.connect(_on_nearby_fish_entered)
  area_exited.connect(_on_nearby_fish_exited)

  if pathing:
    pathing.visible = OS.is_debug_build()

func _physics_process(delta: float) -> void:
  match current_state:
    State.WANDER:
      _handle_wander(delta)

  _update_visuals()

  if OS.is_debug_build():
    _update_path_prediction()

  global_position += velocity * delta

func _handle_wander(delta: float) -> void:
  var avoidance := _avoid_other_fish()
  var alignment := _align_with_other_fish()

  var avoidance_magnitude := avoidance.length()
  var wander_weight: float = clamp(1.0 - avoidance_magnitude / avoidance_strength, 0.2, 1.0)
  var desired_direction := ((wander_direction * wander_weight) + avoidance + alignment).normalized()
  var steer_speed := steering_speed * (1.0 + avoidance_magnitude)
  current_direction = current_direction.lerp(desired_direction.normalized(), steer_speed * delta).normalized()

  velocity = current_direction * speed

  wander_timer -= delta
  if wander_timer <= 0.0:
    _choose_new_wander_direction()

  _keep_in_bounds()

func _choose_new_wander_direction() -> void:
  wander_direction = Vector2(randf_range(-1, 1), randf_range(-1, 1)).normalized()
  wander_timer = randf_range(2.0, 5.0)

func _avoid_other_fish() -> Vector2:
  if nearby_fish.is_empty():
    return Vector2.ZERO

  var seperation := Vector2.ZERO

  for fish in nearby_fish:
    if not is_instance_valid(fish):
      continue

    var to_fish := fish.global_position - global_position
    var distance := to_fish.length()

    if distance < avoidance_radius and distance > 1.0:
      var push_away := -to_fish.normalized()
      var strength := 1.0 - (distance / avoidance_radius)
      seperation += push_away * strength

  Log.info("Fish %s avoidance vector: %s" % [name, seperation])
  return seperation.normalized() * avoidance_strength if seperation.length() > 0.1 else Vector2.ZERO

func _align_with_other_fish() -> Vector2:
  if nearby_fish.is_empty():
    return Vector2.ZERO

  var average_direction := Vector2.ZERO

  for fish in nearby_fish:
    if not is_instance_valid(fish):
      continue

    average_direction += fish.current_direction

  return average_direction.normalized() * alignment_strength if average_direction.length() > 0.01 else Vector2.ZERO

func _keep_in_bounds() -> void:
  var viewport_size: Vector2 = get_viewport().get_visible_rect().size
  var margin := 100.0
  var turn_force := 2.0

  if global_position.x < margin:
    wander_direction.x += turn_force * get_physics_process_delta_time()
  elif global_position.x > viewport_size.x - margin:
    wander_direction.x -= turn_force * get_physics_process_delta_time()

  if global_position.y < margin:
    wander_direction.y += turn_force * get_physics_process_delta_time()
  elif global_position.y > viewport_size.y - margin:
    wander_direction.y -= turn_force * get_physics_process_delta_time()

  wander_direction = wander_direction.normalized()

func _update_path_prediction() -> void:
  if not OS.is_debug_build() or not pathing:
    return

  if current_state != State.WANDER:
    pathing.clear_points()
    return

  pathing.clear_points()

  var sim_pos := Vector2.ZERO
  var sim_direction := wander_direction
  var step_distance := prediction_length / prediction_steps

  for i in prediction_steps:
    pathing.add_point(sim_pos)
    sim_pos += sim_direction * step_distance
    _simulate_boundary_steering(sim_pos, sim_direction)

func _simulate_boundary_steering(sim_pos: Vector2, sim_direction: Vector2) -> void:
  var viewport_size := get_viewport_rect().size
  var margin := 100.0
  var turn_force := 0.5

  var world_pos := global_position + sim_pos

  if world_pos.x < margin:
    sim_direction.x += turn_force
  elif world_pos.x > viewport_size.x - margin:
    sim_direction.x -= turn_force

  if world_pos.y < margin:
    sim_direction.y += turn_force
  elif world_pos.y > viewport_size.y - margin:
    sim_direction.y -= turn_force

  sim_direction = sim_direction.normalized()

func _update_visuals() -> void:
  if current_direction.x != 0:
    $Sprite.flip_h = current_direction.x < 0

func _on_nearby_fish_entered(area: Area2D) -> void:
  if area is Fish and area != self:
    nearby_fish.append(area)

func _on_nearby_fish_exited(area: Area2D) -> void:
  if area is Fish:
    nearby_fish.erase(area)

Iteration 3: Reading about Navigation Agents

I was still not happy with the movement of the fish. Some issues would still occur, like fish getting stuck in corners or not being able to move around the scene properly. I then watched a video on YouTube about someone implementing navigation agents in his game but for player movement avoidance. This got me thinking: if navigation agents could also work for fish movement.

I had to read through the docs about the NavigationAgent2D node and how to actually use it. Navigation agents are actually quite neat as they come with a lot of built-in functionality for pathfinding and avoidance of obstacles. The decision was made to try it out and see, whether it would work for the fish movement.

Adding the NavigationAgent2D node to the fish and setting up the navigation map was quite easy. All I had to do was to create a navigation mesh on the game scene and set it up as the navigation map for the fish. Then I had to actually rewrite 80% of my fish.gd script to make use of the navigation agent.

class_name Fish
extends CharacterBody2D

@onready var nav_agent: NavigationAgent2D = $NavigationAgent2D
@onready var energy_bar: ProgressBar = $EnergyBar

## Minimum speed of fish
@export var speed_min: float = 10.0
## Maximum speed of fish
@export var speed_max: float = 80.0

# Timer for when fish will pick a new wander target
var wander_timer: float = 0.0
# Current speed of fish
var current_speed: float = 0.0
# Current fish energy
var current_energy: float = 100.0:
  set(value):
    current_energy = clamp(value, 0, 100)
    if energy_bar:
      energy_bar.value = current_energy
      energy_bar.visible = current_energy < 50
# Timer for how long fish will conserve energy
var conserving_energy_timer: float = 0.0

func _ready() -> void:
  add_to_group("fish")
  current_speed = randf_range(speed_min, speed_max)
  current_energy = randf_range(50, 100)

  if energy_bar:
    energy_bar.value = current_energy

  await get_tree().physics_frame
  await get_tree().physics_frame

  nav_agent.set_velocity_forced(Vector2.ZERO)

func _on_nav_agent_velocity_computed(suggested_velocity: Vector2) -> void:
  velocity = suggested_velocity
  move_and_slide()

  if velocity.x != 0:
    $Sprite.flip_h = velocity.x < 0

To my surprise, the code got simpler - well mostly because I moved most of the code to my state machine. I also decided there, to tinker around with energy management and added a simple energy bar to the fish (for debugging purposes), which would decrease over time and when it reaches 0, the fish would sort of stop getting new coordinates and just sort of "rest" for some time until its energy is restored.

The wandering state now looks like this:

extends FishState

func enter(previous_state_path: String, data := {}) -> void:
  _new_wander_location()

func physics_update(_delta: float) -> void:
  fish.wander_timer -= _delta

  # Consume energy when moving, gain energy when not moving
  fish.current_energy -= _delta * 0.1 if fish.velocity.length() > 10 else 0.05

  if fish.current_energy < 10:
    transitioned.emit(CONSERVING_ENERGY)
    return

  if fish.wander_timer <= 0.0 or fish.nav_agent.is_navigation_finished():
    _new_wander_location()

  if not fish.nav_agent.is_navigation_finished():
    var next_pos = fish.nav_agent.get_next_path_position()
    var dir = (next_pos - fish.global_position).normalized()
    fish.nav_agent.set_velocity(dir * fish.current_speed)

func _new_wander_location() -> void:
  var vp_size: Vector2 = get_viewport().get_visible_rect().size
  var target_position: Vector2 = Vector2(
    randf_range(100, vp_size.x - 100),
    randf_range(100, vp_size.y - 100)
  )

  fish.nav_agent.target_position = target_position
  fish.wander_timer = randf_range(3.0, 6.0)
  fish.current_speed = randf_range(fish.speed_min, fish.speed_max)

I'm happy with the result and the fish movement as it is now much more natural and looks a lot better in general. My state machine also simplified a lot of things and made the code a lot more maintainable.

The approach for the state machine I followed was the Finite State Machine pattern by Nathan Lovato, which also covered a node based implementation - where I'm at right now.

Node based state machine implementation is quite neat and makes the code a lot more readable as each state is a separate node in the scene tree (for me the Fish scene) and a separate script. This makes it easier to understand and maintain the code for me. I also know it might be a bit overkill for a simple game like this, but I thought it's a good learning experience and I would definitely benefit from it in my future games.

My learnings from this

The project is still far from being finished but I'm happy with the overall progress I've made so far. I'm not working 24/7 on it but when I do, I feel like making progress, even though I'm somewhat slow at it. What I've learned in November was quite valuable and I'm looking forward to continue the journey on the game.

Some key takeaways from this journey:

Navigation agents handle avoidance better than manual steering
State machines make complex behaviors manageable
Starting simple and iterating is more effective than over-engineering upfront

What I plan to do next

With the movement of the fish sorted out, I'm actually now trying to tinker around with some UI elements and the game mechanics like the feeding and the cleaning of the tank and the entire buying update system - which would require to tinker around with a minimal economy system.

The project is open source and can be found on my GitHub profile. You can find the repository here. I'm also happy to receive any feedback or suggestions you might have, as I'm looking to actually improve my understanding of how to make games.

Okay, I think this is enough yapping for now. I'll definitely write more devlogs like these in the future. 👋

My AI Journey

Dean (딘) — Fri, 05 Sep 2025 08:00:00 +0000

Over the past couple of years, AI has quietly become one of the most valuable tools in my development toolkit. What started with simple autocomplete suggestions has evolved into something I use daily for learning, problem-solving, and getting more done.

This isn't a story about AI replacing developers or some revolutionary breakthrough moment. It's just my honest experience of how these tools have changed the way I work, and why I think they're worth considering if you haven't tried them yet.

AI as My Coding Sparring Partner

The most valuable way I use AI (and this might resonate with you) is as a sparring partner when I'm stuck. Instead of immediately bothering a colleague who might be deep in their own work, I can bounce ideas off AI first. I can pitch half-formed thoughts, ask "what if" questions, and iterate through solutions without feeling like I'm wasting someone's time.

God, I remember those StackOverflow days. You know the ones... spending hours scrolling through threads, only to find answers that were either outdated or didn't quite fit your specific situation. The frustration was real. Now with AI, I get quick responses that I can actually have a conversation with. The answers aren't always perfect (neither were StackOverflow answers, let's be real), but here's the key difference: I can iterate. I can ask follow-up questions, provide more context, even link current documentation. It's like having a patient colleague who never gets tired of my questions.

This approach recently saved my sanity when I was wrestling with a particularly nasty bug. Instead of getting stuck in analysis paralysis, I could talk through the problem with AI, explore different angles, and actually make progress. That's gold for someone like me.

AI as My Learning Accelerator

The other game-changer? Using AI as a learning tool. As you might remember from my last post, I've been diving into game development with Godot. While I'm comfortable with web development, game dev is relatively new territory for me, and Godot's ecosystem felt overwhelming at first.

My initial plan was to work through the documentation methodically. But to be honest, it felt like drinking from a fire hose... too much information, not enough practical application. So I tried a different approach: I asked AI for a simple character movement script in GDScript. Within seconds, I had working code that I could actually run, tinker with, and understand through experimentation.

This is how I've always learned best, even before AI existed. I'm much more effective when I can start with working code and figure out what makes it tick, rather than trying to absorb theoretical concepts first. I'm not the type who needs to understand every underlying mechanism. I just need to know enough to build things and solve problems. And sometimes I still fail, which is perfectly okay. AI helps me fail faster and learn from those failures more efficiently.

My AI Tooling

I've tried a lot of AI tools, and my preferences have evolved quite a bit.

ChatGPT started feeling too much like a "yes man" for my taste. It would agree with everything I said rather than challenging my thinking, which isn't what I needed from a sparring partner.

Then I discovered Cursor, which I still use as my main code editor. The integration is seamless... great code completion, useful AI agents, and access to multiple models right in my coding environment. It's become an essential part of my daily workflow.

But for deeper conversations and research, I've settled on Claude. What won me over was the ability to define context for our chats and its research mode that can pull in current web information. Plus, Claude can read links directly, which is incredibly useful when I want to reference specific documentation or articles. When I'm working through complex problems or need to understand new concepts, this is where I turn.

(And no, this isn't a sponsored post, just sharing what's actually working for me.)

Where I Draw the Line

Before you ask, I don't use AI for image/video generation. I have mixed feelings about the copyright and intellectual property implications, especially knowing that many models were trained on artists' work without explicit consent. That's a line I'm not comfortable crossing right now.

About AI Bashing

Okay, I need to get something off my chest. If you've been on LinkedIn or social platform lately, you've probably seen the AI bashing going on. Software engineers calling out other engineers for using AI, saying shit like "you're not a real developer if you use AI" or "I tried it once and it made me less productive because I had to fix everything."

Look, I get being skeptical. But this defensive BS is getting old.

Here's the thing: if AI isn't making you more productive, you're probably prompting it wrong. It's like saying "I tried using Google and it sucked" when you were searching for "red thing that goes fast" instead of "Ferrari 488 GTB specifications." The tool isn't the problem... how you're using it is.

But hey, maybe you gave it an honest shot and it still doesn't click for you. That's totally fine! Different tools work for different people. What's not fine is looking down on others and dismissing their success just because your experience was different. Just because something doesn't work for you doesn't mean other people are lying when they say it transformed their workflow.

AI isn't going to replace software engineers. That's not what this is about. But dismissing it entirely because you're afraid of looking less competent? That's just shooting yourself in the foot. The developers who figure out how to work with AI effectively are going to be more productive, learn faster, and frankly, have more fun coding.

And for those who get all defensive when someone suggests trying AI... maybe ask yourself why that suggestion bothers you so much. Because I promise you, the people effectively using AI aren't trying to replace you. We're just trying to get more shit done in less time so we can focus on the interesting problems.

AI is Here to Stay

Here's what I've realized: AI hasn't replaced my need to think or learn... it's amplified both. I'm asking better questions, exploring ideas I might have been too intimidated to pursue, and iterating through solutions faster than ever before. It's like having a patient mentor who's available 24/7 and never judges my "stupid" questions.

The technology is moving incredibly fast, and honestly, that used to stress me out. But now I see it as an opportunity to stay curious, keep experimenting, and continue growing. In a field that changes as rapidly as frontend development, having AI as a learning partner feels like a superpower.

Look, if you're skeptical about AI, I get it. I was there too. But here's the thing: you don't have to dive in head-first or change your entire workflow overnight. Next time you're genuinely stuck on something, instead of opening another StackOverflow tab, try asking an AI tool one simple question. See what happens. The worst case? You waste five minutes. The best case? You might just rediscover why you fell in love with coding in the first place.

What has your experience been so far? Have you tried out AI in your workflow recently?

What I've Been Up To These Last Few Months

Dean (딘) — Mon, 11 Aug 2025 09:54:23 +0000

This isn't going to be a polished update post — it's more like thinking out loud. It's been quite some time since I've written anything on my site. To be honest, I wanted to write, but I hit a massive creative block and completely lost direction on what to do next.

I know I'm just getting started with this post, but I've been feeling burned out from both work and personal life. I found myself spending most days just lounging around and gaming, which only made things worse. I'm slowly regaining my energy and figuring out my next steps. During my RV trip this month, I had several breakthrough moments about where I want to go professionally. I realized I haven't really developed myself in the last couple of years—I've just been stuck doing what I had to do rather than what I love to do. I hope that resonates with some of you.

My plan for this year is to dedicate serious time to my side projects: Cardia and another unnamed project I'm excited about.

Cardia: A Personal Health Project

Originally, I wanted Cardia finished by January—that didn't happen. I kept getting stuck on the design, feeling like it wasn't quite right. In February and March, I completely redesigned Cardia, giving it its own unique style instead of just relying on Shadcn styling. The results have been much better.

(Note: I've got an interactive before/after comparison slider on my original blog post that shows the design evolution better than static images can - definitely worth checking out if you're curious about the UI transformation.)

Cardia is planned as a self-hosted blood pressure tracker that I started building after being diagnosed with high blood pressure. Most existing apps I found were either expensive, had poor UI/UX, or were bloated with features I couldn't turn off.

Cardia will support multiple users so entire families can track their blood pressure together. The self-hosted approach means you truly own your data—no wondering what some company might do with your health information.

I think once it's complete, I'll write a more detailed post and create a proper marketing website. The concept is solid on paper, the core system works, and I just have a few more features to integrate before releasing the upgraded version.

Exploring Game Development: A Tool Comparison

I'm also working on a game right now. Over the past two months, I've experimented with several programming languages and game engines: LÖVE2D, Unity, and Godot.

I started by creating basic character movement in each engine to see how they felt. Here's my honest take on each:

LÖVE2D was quickly eliminated—the lack of built-in GUI tools gave me headaches, especially when trying to set up nine-patch scaling for UI assets. If you're comfortable building everything from scratch, it's powerful, but I wanted to focus on game logic, not reinventing UI wheels.

Unity's coding approach was completely foreign to me. Coming from web development, the component system and C# felt like learning a completely different paradigm. I felt lost from the start and couldn't find a natural workflow.

Godot with GDScript has been the winner. GDScript feels like Python and TypeScript had a baby—it's intuitive to write. The node-based architecture is a lifesaver for creating clean, well-structured games. Plus, the fact that it's open source and has a rapidly growing community sealed the deal.

I plan to write more technical details about the specific Godot features that won me over, but the short version is: if you're coming from web dev and want to try game development, Godot is incredibly approachable.

What I can say now is that it's going to be a management game, which aligns perfectly with my personal gaming preferences.

What's your experience with these engines? I'd love to hear in the comments if you've tried any of them or have other recommendations.

Moving Forward

So that's where I am: still alive, still creating (or trying to), and committed to being more active with my writing.

I'll be posting detailed development updates for both Cardia and the game project on my blog, including screenshots of the current Cardia interface, deeper dives into Godot workflows, and probably some honest takes on the challenges of building health tech that people actually want to use. The blog posts there include interactive elements and additional visuals that make the full experience worth checking out.

Thanks for sticking with me through the radio silence.

Originally posted on my blog with interactive elements and additional screenshots.

Lessons Learned: Overusing useMemo in React

Dean (딘) — Mon, 09 Dec 2024 19:00:00 +0000

Recently, while working on a React Native app for SWK, a local service provider, I came across the useMemo Hook for the first time. It seemed like a magical tool for optimizing performance by caching expensive computations. Excited about the possibilities, I started using it almost everywhere. However, I quickly realized that overusing useMemo can lead to unnecessary complexity without tangible benefits. Here's what I learned and how you can avoid the same mistakes.

What Is `useMemo`?

useMemo is a React Hook designed to optimize performance by caching the result of a computation. React recalculates this value only when its dependencies change. It's most useful for expensive calculations that might otherwise slow down your app. For instance:

const sortedItems = useMemo(() => {
  return items.sort((a, b) => a.value - b.value)
}, [items])

Here, the sortedItems variable is recalculated only when the items array changes, saving time during re-renders.

For a deeper dive into how useMemo works, check out the React official documentation.

Performance Analysis with `useMemo`

Before adding useMemo to your code, ask yourself: Is the computation expensive enough to warrant optimization? To find out, you can use tools like the React Profiler. Here's how:

Profile Without useMemo: Use the Profiler in React DevTools to measure rendering times.
Identify Bottlenecks: Look for components that take a long time to render or frequently re-render.
Add useMemo: Apply it to optimize specific expensive calculations.
Compare Performance: Profile again to confirm improvements.

Example:

const expensiveComputation = useMemo(() => {
  return performComplexCalculation(data)
}, [data])

By testing before and after adding useMemo, you can verify whether it has a meaningful impact.

When to Use `useMemo` vs. Other Tools

useMemo works well for caching derived values, but it's not the only optimization tool in React:

React.memo: Use this to memoize entire components, preventing unnecessary re-renders when props haven't changed. Learn more about React.memo.
State Management with Zustand: Zustand offers a lightweight and intuitive approach to managing shared state, reducing the need for derived state or excessive memoization. It simplifies managing and updating global state without extra boilerplate.

Quick Tip: Reserve useMemo for expensive computations, while React.memo shines for optimizing component rendering. Combine these judiciously with efficient state management for the best results.

Avoiding Common Pitfalls

Here are some common mistakes to watch out for:

Memoizing Simple Calculations: Avoid using useMemo for lightweight tasks like:

  const hasData = useMemo(() => data.length > 0, [data])

This doesn't save much processing power and adds complexity.

Unstable Dependencies: Ensure your dependency array contains stable references; otherwise, React recalculates unnecessarily.

  const result = useMemo(() => compute(items), [items])

For more on how dependency arrays work, see this React guide on Hooks.

Edge Cases and Code Examples

When useMemo Helps:

Memoization shines when working with computationally expensive operations, like filtering or sorting large datasets:

const filteredData = useMemo(
  () => data.filter((item) => item.active).sort((a, b) => a.value - b.value),
  [data]
)

In this case, memoizing avoids recalculating the result on every render unless data changes. This can lead to noticeable performance improvements, especially with large arrays or complex operations.

When useMemo Hurts:

For trivial computations, like this:

const isLoading = useMemo(() => !data.length, [data])

useMemo adds unnecessary overhead. Simple logic or derived values, like !data.length, can be directly defined without memoization.

Better approach:

const isLoading = !data.length

Using useMemo in such cases complicates your code without measurable benefits.

For more in-depth examples and scenarios, check out this Telerik guide on useMemo.

Final Thoughts

useMemo is a precision tool, not a catch-all solution. Always start by profiling your app, and remember that clarity and maintainability should come first. When used correctly, useMemo can significantly enhance performance, but misuse can just as easily detract from it.