This isn’t the place for me to tell you why, but I am excited to talk about all the stuff I plan to work on in 2026.

scorebug.sh

Live mlb scores in the terminal

Late last year, I was looking for an excuse to use Charmbracelet’s popular ecosystem for building TUI’s, and found my excuse while watching the lead up to the 2025 MLB post season.

I had recently been getting really annoyed with the MLB apps, the various hoops to jump through, and insane fees to pay just to be able to track and watch the sport. I started poking around at the MLB stats api and… damn this is all just kinda out there for free huh?

I started piecing together a way to display live game scores in the terminal that update automatically. Even with just this feature alone, I could see the potential.

Last month I just finished up a refactor that will allow me to iterate on this alot faster. I have a lot of fun ideas planned, including player stats, play-by-play, and possibly even visualizing the plays with the help of some of charm’s more experimental libraries.

You can check out scorebug.sh here

Radix

Retro fps godot project

This is a project that I started ~2 years ago, initially just to test out some Godot pluins (GoldGdt & func_godot), to see if I could quickly whip up something that “felt” like half-life in the Godot engine. I quickly realized that the GoldGdt plugin, which provides a half-life-esque character controller, was not really the most extensible for my needs. I put the project down for about a year.

Fast forward after several quake & source engine history lessons, source code deep-dives, obsessing over source engine modding / map making, and creating an automated set of shell scripts and docker-compose for running cs 1.6 servers later… I return to Radix with my new goals!

Radix goals

I have so many thoughts I want to share on this endeavor, but for now my most important goals for this project are to…

- Create an FPS game that feels good to ME. This may just be me chasing the "source engine feel" but hey... why discount perfection ;)

- Build a set of tools to create cool FPS experiences with, for years to come.

I gave some serious thought to commiting to such a large project, with such an open ended goal. I ended up coming back to it becuase it’s both an obsession, and just satisfying to slowly chip away at these large undertakings. I don’t expect it to be done fast, and that’s fine. I can always take breaks for game jams and stuff anyways :)

If you are still reading- thanks, stranger! Not much to show for now, so feel free to poke around the Radix codebase.

Along with the main theme, the 3 option “wild card” themes were “white out/ freezing out”, “blood is fuel”, and “trash everywhere”.

Design Process

I originally planned on a completely different game. Aside from many of the ideas I had during my brainstorming session, which included a souls-like style game about climbing a freezing mountain, a game that involved writing medieval illuminated manuscripts, and even a game about lighting dumpsters on fire…

What I eventually landed on was a colony sim game, where you manage a community living through a post apocalyptic eternal winter. At the center, a garbage fire keeps their village warm. Your job would be keep their fire burning bright by sending colonists out to scavenge for trash to burn, hunt to keep the colony satiated, and eventually accrue enough weapons and numbers to take back the junk yard. I sketched up some rough concept art and called it a day.

The next day I woke up to get to work. I sat down with my design doc open, fired up Godot, and started to slap some basic components together. However it was during this process that I had the realization that there would be no way I could finish this in time with a proper game loop. I tried to strip it down to the most basic game loop possible, and considered building the same idea out into an idle game format. But even after reworking the doc in various ways, I was losing sight of one of my main goal for the week: whatever I make, just make sure its fun. If you can’t find the fun, move on and try something else.

I put this initial concept aside and started to think of something else to make that was more realistic for my skill level. By this point the day was half over, so I decided to do something unconventional for me, which was to just start by drawing something fun. This is how I ended up with the character design seen in the final version. What I ended up with was this little man right here.

At this point there was no design doc aside from a couple bullet points I had written down.

CANDLE RUNNER
- You play as a lit candle guy
- As you run, the candle burns out
- You cannot burn out fully
- You can pick up wax by standing under big melting candles
- You illuminate checkpoints by standing under a wick that lights a flame
- The check point forms you into a fresh tall candle
- Some areas require you to be shorter

It was pretty minimal, but it was enough to improvise off of. This moment kind of set the tone for my development process over the rest of the week as well, since it became more of a rapid prototyping session, which allowed me to become more comfortable throwing away ideas that didn’t work quite right.

Rapid and Reactive Prototyping

So, it was settled then. A puzzle game where the “wind” caused by the candle running around would make the flame burn brighter and the wax run out faster. I got to work on creating the mechanics necessary, and had it worked out by the end of Tuesday.

Over the next couple days I had made all of the other components necessary to build some puzzles out. I built the wax candle spawner that allows you to grow the candle size, the lanterns you need to light, and I even added a bonus spider web obstacle, that you could get past by lighting it on fire with your flame!

There was one small problem that I had realized on Wednesday night though… while the mechanics were coming together to form some semblance of a game… it still didn’t feel fun. I didn’t want to lose sight of this core goal I gave myself, so I decided to just sit and play around with game feel for the rest of the night. The first thing I realized was, the movement just didn’t feel smooth or natural enough. So that would be the first thing to fix. The other key takeaway was, I really didn’t like the wax running out based on the player movement. It almost felt like the game was de-incentivizing the player… playing the game? “Don’t move around too much, or you just die!” It sounds so obvious now but when I was designing the mechanic on paper, it just simply didn’t occur to me.

It was because of this short late night play test that I decided to instead give the player the choice of what size the candle should be, and base the puzzle on this aspect. Need to fit into a tight area? Shrink down! Need to reach a lantern up high? Find a wax spawner to grow! This was the moment the game went from puzzle game, to puzzle platformer. I decided to focus on the movement aspect more, and make it feel more like a platformer, which is now fully realized the in the final release.

Polishing it up

For the movement changes, I really wanted the animations and physics to work with each other, to make the player feel like the movement felt natural and believable, all while being somewhat whimsical. I added a slight skewing effect based on the direction and speed of the player, which kind of gives the effect that the candle is a little bit top heavy.

I also wanted to add some momentum to the movement, so it was here that I was starting to tweak the jump physics, and the amount the player would slide around when changing directions. It was now Thursday night, and I was getting a little concerned that I would not have enough time to create enough levels for the game.

You see, I had held off making levels entirely up until this point. Not out of procrastination, but because I was afraid of wasting time making levels, and then having to either fix them or throw them away if I made any movement tweaks that ended up breaking the levels. I was able to finish the movement tweaks by the end of Thursday, and now I had all of Friday, Saturday, and whatever would be left of Sunday to design levels.

Designing the levels was a massive learning process. I had gone into it thinking “Ah finally, this will be easy! I’ve been working towards this moment and now all I have to do is the most fun part!”….no it was not easy. 3 Days resulted in 6 levels. Not terrible but I was hoping to reach an even 10 levels.

I knew I wanted to have some easy levels dedicated to introducing new mechanics. They hard part was filling in the gaps between those introductions, and combining the mechanics learned in creative ways. Puzzles are hard to make! And because of this, I am glad that I ended up dedicating more time to making the movement feel good, because it allowed me to lean on more skill based levels than thinking based levels.

After making all 6 levels, I ended up having an hour left, and that’s where I added a basic pause function, sound effects, and some graphics for the itch page.

Results

My game ended up taking 13th place overall out of 120 submissions! What was even more exiting to me, I placed 5th in the fun category! I couldn’t believe that my goal I had set for myself for the week actually paid off.

My take aways from this experience were:

• Don’t spend the time creating a design doc, until you’ve prototyped enough to determine that the design will actually be fun
• Always be testing your game, always make sure it feels right, don’t let an un-fun game become such a big undertaking that you don’t even know why you are making it anymore. Figure out how to make it fun as early as possible.

Things I would change based off of user feedback:

• Make the controls a little tighter. I went a little hard on the slidey-ness of the momentum and made the game a little too slippery.
• Levels are going to be harder than you think, because you designed them

Diagonal movement bug

Had to change the movement vector code to fix a bug that would allow the player to move in diagonals… which kind of breaks the whole rule set of Snake now doesn’t it. This is because the Input.get_vector() func will create a vector based on all inputs it recieves. Good for some games like top down 2d or 3d games, not good for snake.

 1# Snake.gd
 2
 3...
 4func _process(_delta):
 5	if Input.get_vector("left", "right", "up", "down") != Vector2.ZERO:
 6		if manager.current_state == GlobalVars.State.PAUSE :
 7			manager.set_state(GlobalVars.State.PLAY)
 8	if Input.is_action_just_pressed("left"):
 9		input_buffer = Vector2(-1, 0)
10	elif Input.is_action_just_pressed("right"):
11		input_buffer = Vector2(1, 0)
12	elif Input.is_action_just_pressed("up"):
13		input_buffer = Vector2(0, -1)
14	elif Input.is_action_just_pressed("down"):
15		input_buffer = Vector2(0, 1)
16...

So I unfortunately had to break up my nice neatly coded movement code into a sequence of if statements, while still keeping the get_vector for detecting an input to start the game. I’m sure theres a hip way to consolidate this but for now this’ll do.

Dead snake

To detect if the snake’s head has made contact with the snake’s tail, I just added a CollisionArea2d to the SnakeTail.tscn, and add the following code to connect the body_entered signal.

 1# SnakeTail.gd
 2extends StaticBody2D
 3
 4@onready var col_area = $CollisionArea
 5@onready var manager = get_parent()
 6
 7func _ready():
 8	col_area.body_entered.connect(_on_area_2d_body_entered)
 9
10func _on_area_2d_body_entered(body):
11	if body.is_in_group("SnakeHead"):
12		manager.set_state(GlobalVars.State.DEAD)

I added the SnakeHead node to a group “SnakeHead” as a lazy check, I’ll admit. This may change later if I find it stupid but it works well enough for now.

Play area changes

As you can see from the header image, its pretty minimal. I added a new TileMap layer for the “frame”, so the playarea does not end up being massive and take forever to traverse, and I can also decorate it later if I want / when I choose a final visual style. Overall a simple but pleasing enhancement from the janky floating window with dimensions that were slightly off from the TileMap :D

Detecting wall collision

Ideally, in Godot 4 I could simply add a physics collision layer to the TileMap. However, because I’ve chosen not to use any physics based movement, I don’t think this is possible.

The good news is, since I’m already storing the coordinates for all the cells that make up the playarea, all I need to do is check to see if the cell that the snake’s head is about to move into is going to have an x or y value greater or less than the maximum x or y values used for the playarea.

 1# GameManager.gd
 2
 3...
 4func _ready():
 5	bg_layer_coords = grid.get_used_cells(1)
 6	min_nav_x_y = bg_layer_coords[0]
 7	max_nav_x_y = bg_layer_coords[bg_layer_coords.size() - 1]
 8	
 9...
10
11func is_in_boundaries(grid_coord):
12	if (min_nav_x_y.x < grid_coord.x) and (max_nav_x_y.x > grid_coord.x):
13		if (min_nav_x_y.y < grid_coord.y) and (max_nav_x_y.y > grid_coord.y):
14			return true
15	return false
16...

This function gets called in the _timer_timeout() func.

 1# GameManager.gd
 2
 3...
 4func _timer_timeout():
 5...
 6	if snake.grid_coords.size() > snake.body_segments.size() :
 7		update_snake()
 8	for s in range(snake.grid_coords.size()):
 9		if s == 0:
10			if !is_in_boundaries(snake.grid_coords[s]):
11				set_state(GlobalVars.State.DEAD)
12...

So close I can almost smell the polishing phase.

Managing state

This is pretty much as simple as you can get, which I think fits for the tiny scope of this project. For now this is what that looks like

 1# GameManager.gd
 2
 3...
 4var current_state := GlobalVars.State.PAUSE
 5
 6func set_state(new_state: GlobalVars.State):
 7	current_state = new_state
 8	match current_state:
 9		GlobalVars.State.PLAY:
10			timer.start()
11			timer.paused = false
12		GlobalVars.State.PAUSE:
13			timer.paused = true
14		GlobalVars.State.DEAD:
15			timer.stop()
16...

As you can see, it really only needs to manage the timer for now.

GlobalVars.gd is an autoloaded file that simply has an enum called State.

1# GlobalVars.gd
2
3extends Node
4
5enum State {
6	PAUSE,
7	PLAY,
8	DEAD
9}

Now, any child nodes of the GameManager.tscn can set the state of the game by creating a reference to the GameManager node, and calling the set_state func.

1# Snake.gd
2
3...
4@onready var manager = get_parent()
5...
6
7...
8manager.set_state(GlobalVars.State.PLAY)
9...

Time to eat

Setting up the apple scene is simple. A StaticBody2d for the root node, attatch a Sprite node which for now I will lazily drop the snake tail’s sprite into as a placehodler, and a CollisionShape2d. For the snake to be able to eat this thing, we’ll need a Area2d with a CollisionShape2d as its child node, which I have named PickUpBoundary.

My inital plan was to use the Area2d’s body_entered signal to trigger the function to make the snake grow. However for whatever reason, that signal is not working when the Snake body enters it. Everything is on the same collision layer and mask layer too, so it should be detectable. Might investigate this later and see if its a Godot 4 beta bug.

So for a backup plan, I gave the snake.tscn an Area2d node called PickUpArea, and I instead connected the area_entered signal.

 1# Apple.gd
 2
 3extends Node2D
 4
 5@onready var pickUpArea = $PickUpBoundary
 6
 7signal spawn
 8
 9func _ready():
10	pickUpArea.area_entered.connect(_area_pickup)
11
12func _area_pickup(area):
13	if area.get_parent().has_method("grow"):
14		area.get_parent().grow()
15		emit_signal("spawn")

The callback function simply checks if the parent of the Area2d that entered the PickUpBoundary has a grow method, and calls it if it does. Which looks like this

1# Snake.gd
2
3...
4
5func grow():
6	var new_seg = grid_coords[grid_coords.size() - 1]
7	grid_coords.append(new_seg)
8
9...

The reason I am able to simply set the Vector2 position for the new segment, rather than doing some vector math to calculate the next position, is thanks to my logic for moving the snake in my _timer_timeout func in the GameManager.gd.

 1#GameManager.gd
 2
 3...
 4func _timer_timeout():
 5	var segment_next
 6	var segment_previous
 7...
 8	for s in range(snake.grid_coords.size()):
 9...
10		else:
11			grid.erase_cell(1, snake.grid_coords[s])
12			segment_previous = snake.grid_coords[s]
13			snake.grid_coords[s] = segment_next
14			snake.body_segments[s].position = grid.map_to_local(snake.grid_coords[s])
15			segment_next = segment_previous
16	if current_state == GlobalVars.State.PLAY : 
17		timer.start()

Because I’m just scooting the Vector2’s by keeping the previous segment in memory, it just kinda works. It might feel a little lazy to have the last 2 Vector2’s in the array be the same value for a moment, but in reality this means that when that last line segment_next = segment_previous is executed for the new snake tail segment, it’s making the previous snake’s last tail segment the new one, which is exactly what we want. It ends up having effect of “growing forward” as the snake moves, since the end of the tail does not move for one of the timer timeouts.

More apple

As you can see in the gif above, we get a new apple when we eat one! I created a spawn signal in Apple.gd that is emitted when the apple’s area_entered callback is triggered by the snake eating the apple.

In the GameManager.gd, I set up a _new_apple() func that will spawn the new instance in a random location in the playarea.

 1# GameManager.gd
 2
 3...
 4
 5func _new_apple():
 6	if get_node_or_null("Apple") == null :
 7		apple = apple.instantiate()
 8		add_child(apple)
 9		apple.spawn.connect(_new_apple)
10	var temp_coords = bg_layer_coords 
11	var new_apple_pos : Vector2 = temp_coords[randi() % temp_coords.size()]
12	while snake.grid_coords.has(new_apple_pos):
13		new_apple_pos = temp_coords.pick_random()
14	apple.position = grid.map_to_local(new_apple_pos)
15	
16...

Here, we check to see if there is an Apple node in the scene tree. If there isn’t we create an instance of one, and connect the spawn signal, the same signal that it emits on pickup. This is to make sure there is only one Apple.tscn instance, but this could change in the future.jh}

Oh, and thanks to the newest Godot 4 beta, which is Beta 4, I get to use a new built in array method, pick_random!

Previously to get a random array element you would have to do something like this

1new_apple_pos = temp_coords[randi() % temp_coords.size()]

Not the most riveting new feature to test but hey I’m down. After that I have a while loop that will garuntee that the random value for the new Apple position is not occupied by the snake body.

Other improvements

I moved the code that is used to update the snake when there are new segments available at the moment of a timer timeout to an update_snake() function. This way it can be used by the ready(), _timer_timeout(), and whatever other function may need it.

1# GameManager.gd
2
3...
4func update_snake(grid_coords_pos = snake.grid_coords.size() - 1): 
5	var current_segment = snake_segment.instantiate()
6	add_child(current_segment)
7	current_segment.position = grid.map_to_local(snake.grid_coords[grid_coords_pos])
8	snake.body_segments.append(current_segment)
9...

I also had to define a default value for the grid_coords_pos argument, since the _timer_timeout() func specifically needs the last segment of the snake to be updated, but the ready() func actually needs to call this for every snake body segment after the head, so the ready() func now looks like this

 1# GameManager.gd
 2
 3...
 4func _ready():
 5	bg_layer_coords = grid.get_used_cells(0)
 6	timer.timeout.connect(_timer_timeout)
 7	snake = snake_head.instantiate()
 8	for s in range(snake.grid_coords.size()):
 9		if s == 0:
10			add_child(snake)
11			snake.position = grid.map_to_local(snake.grid_coords[s])
12			snake.body_segments.push_front(snake)
13		else:
14			update_snake(s)
15	_new_apple()
16...

Next update will most likely be triggering the death state, and some bug fixes

One new feature I am looking forward to using in Godot 4 2d is the new TileMap node updates. To get myself farmiliar with the new TileMap api, I wanted a project that would let me dip my toes into this node, but I also wanted a project that had a small scope and ideally I wouldn’t have to think up rules or functionality from scratch. So, I chose to remake Snake, using a TileMap as my main playarea!

Concept

While this isn’t really going to be using many of the new features of TileMap, most of it is new to me anyway as a Godot noob. The idea is to use the TileMap as a grid for the play space. The snake the player controls is made up of a series of grid squares, and every x seconds, the snake moves one grid square in the direction the snake is pointing, which is determined by input that is buffered between the movement timer’s timeout duration.

On the grid

The main scene contains a TileMap and a Timer node, underneath the parent Node2d, which has a script attached called GameManager.gd. The TileMap being the play area, and the Timer being the amount of time between each movement of the snake, which I currently have set to .5 seconds.

Using the TileMap node’s Layer system, I am able to split the background layer from the snake. This way, when I’m modifying grid squares of the TileMap to show the snake move, I don’t need to worry about redrawing the background.

I created a Snake scene and added a Snake.gd script to the root StaticBody2d node, as well as adding a Sprite2d and CollisionShape2d of course.

Here’s what that script looks like at the moment for just covering the movement.

 1# Snake.gd
 2
 3extends StaticBody2D
 4
 5@onready var manager = get_parent()
 6
 7var input_buffer := Vector2.ZERO
 8
 9var grid_coords := [Vector2(21, 22), Vector2(22,22), Vector2(23,22), Vector2(24,22)]
10var body_segments: Array
11
12func _process(_delta):
13	if Input.get_vector("left", "right", "up", "down") != Vector2.ZERO:
14		input_buffer = Input.get_vector("left", "right", "up", "down")

It’s a little different from a basic 2d game set up, since I’m not moving the player kinematically, hence the StaticBody2d node. I’m just storing the vector from Input.get_vector, and using that to influce the direction the snake will move on the timer’s timeout duration. The grid_coords is an array that will be storing the position of each snake segment position on the TileMap. Which leads me to the SnakeTail scene…. which is actually pretty much identical to the Snake scene at the moment, just without a script and a different sprite. For now it is just serving the purpose of being an instanced scene.

Now to tie it all together in the GameManager.gd script.

 1# GameManager.gd
 2
 3extends Node2D
 4
 5@onready var grid = $TileMap;
 6@onready var timer = $Timer;
 7@onready var snake_head = preload("res://Snake/Snake.tscn");
 8@onready var snake_segment = preload("res://Snake/SnakeTail.tscn");
 9
10var snake
11
12func _ready():
13	timer.timeout.connect(_timer_timeout)
14	snake = snake_head.instantiate()
15	for s in range(snake.grid_coords.size()):
16		if s == 0:
17			add_child(snake)
18			snake.position = grid.map_to_local(snake.grid_coords[s])
19			snake.body_segments.push_front(snake)
20		else:
21			var current_segment = snake_segment.instantiate()
22			add_child(current_segment)
23			current_segment.position = grid.map_to_local(snake.grid_coords[s])
24			snake.body_segments.append(current_segment)
25	timer.start()
26
27func _timer_timeout():
28	var segment_next
29	var segment_previous
30	for s in range(snake.grid_coords.size()):
31		if s == 0:
32			segment_next = snake.grid_coords[s]
33			snake.grid_coords[s] = snake.grid_coords[s] + snake.input_buffer
34			snake.position = grid.map_to_local(snake.grid_coords[s])
35		else:
36			grid.erase_cell(1, snake.grid_coords[s])
37			segment_previous = snake.grid_coords[s]
38			snake.grid_coords[s] = segment_next
39			snake.body_segments[s].position = grid.map_to_local(snake.grid_coords[s])
40			segment_next = segment_previous
41		timer.start()

Basically, in the _ready func we set up the snake by instancing all of the body parts from the Vector2’s that are stored in the Snake scene’s grid_coords array. To make things easy, the snake’s head is always position 0 of the array, and the rest of the snake tail segments are added in sequential order. For both the snake head and body segments, instances of each scene are created for each of the Vector2’s in grid_coords, and pushed to the Snake scene’s body_segments array. Since they are in sequential order, we know that grid_coords[2] is the position of the instanced scene stored in body_segments[2]. Ain’t that fun.

Here you can see some of the TileMap api coming into play, utilizing the map_to_local(Vector2i) func, which takes a Vector2 and returns the cenetered position of the cell in the TileMap’s local coordinate space. We do this to prvent the snake’s sprites being off center on the grid, which would make things confusing when we start moving things around and adding pick up items to the TileMap.

Then, to actually move this bad boy, we connect the timer’s timeout signal. When the Timer times out, the signal will call the _timer_timeout() func, and start to shift the position of the snake’s head stored in grid_coord by adding the input_vector to it’s current position Vector2. Then we just use the previous position of the snake’s head as the position of the next object in grid_coords, and do the same for each body segment.

And that’s it for basic movement! Next up is adding some basic state management, and adding the apple pickup item so you can grow up to be a nice big snake.