Developer Diary #2 - April 1, 2026

I'm MicalPixel, the solo developer of May and the Amazing Bouquet ("MATAB")!

Happy April Fools' Day! What a perfect time for an actually-serious update on the game. 😁

Gosh, it's been a while, hasn't it? The last news update for May and the Amazing Bouquet was 3 months ago!! Nonetheless, progress on this game has moving along, and there's a lot to talk about!

Menus

The game now has a consistent visual style for its menus. They will all feature a tan parchment-like background and border, with contents that are more colorful. For important menus, they will be divided into large buttons, each of which features a small animation of May when hovered over. For options menus, they will have all options listed vertically, with the ability to change them by pressing left/right.

Other than the items menu, all of them are fully functional. I like the achievements menu in particular.

Another big hurdle was how to handle the three most important menus: the system menu, the map, and the items menu. I wanted them to all be easily accessible, but also somehow allow the game to be played with just four non-directional buttons. Two for actions, and two for menus. Just like the Game Boy hardware this game is heavily inspired by. But...we have 3 menus, and only 2 buttons for menus...?

The solution was a tabbed interface. Each menu can be accessed via its own button OR accessed from its siblings via the tabs at the top. So you technically can play it with just 2 menus buttons - you'd just need to use tabs to reach the third - whichever one you choose to not map buttons to. I'm very happy with this setup.

Music

I've been nervous about the music and sfx for my game, since I have almost no experience in them.

I wanted the game's audio to be based, again, on the limitations of the Game Boy. For a few reasons:

• Consistent aesthetic style. Pixel art and controls mimic those limitations, so music should too.

• Avoid scope creep. Modern DAW programs have a near-infinite amount of flexibility, which also takes time to learn. But limiting my options to those of a 30-year-old device makes it easier to narrow my focus and not get overwhelmed.

I tried nearly a dozen different chip music tracker programs, but none of them clicked for me.

I wanted *FULL CONTROL* of the audio. The Game Boy was already limited, but limiting it even further based on what aspects of the hardware the DAW gave me access to, was more than I wanted. While also providing lots of customization via effects and such, which the original hardware *COULD NOT* do, rubbed me the wrong way.

These tools simultaneously provided too much, and too little. I also liked the piano layouts used by so many non-chip DAWs, and the visualizations of the music scores, which so many chip trackers did not have.

So, like any sane person, I opted to write my own music tracker (lol).

And after 46 days of work on it (which is the main reason for my lack of "official" updates here), it is now capable of reproducing some of the longest and most complex tracks in commercially successful Game Boy games.

Link to the Video

And I now think it's ready to use for making my own music. I even bought a midi piano to make entering notes easier.

And sound effects. Will probably make some adjustments so it can do sfx more easily for me, but overall the tool is in a great spot.

Version 0.4

During the last two months of focusing on music, I've had time to think about other aspects of the game. Taking a step back for a bit can be very eye-opening, yeah?

And there's things I'd like to change.

Every time I've made a significant change which impacts the map size, or game loop, I've flagged it as a new internal version number.

And with the following changes, we're now at version 0.4:

Map Size

MATAB is a small-ish game. But I also want exploration to be a big part of it. Unfortunately, looking at the map, it feels too linear. There ARE branching paths that lead to the various main quest areas, but once you're on a path, there's not much to do other than continue along the path. I want to provide opportunities to "go off the beaten path." Find optional NPCs, other goodies, ... But...the world map is so small that there's not much room for optional-paths.

So, I'll be increasing the world map size. It's currently 8x8. Not entirely sure how big to make it. 16x16 seems a big much though. So, somewhere in-between. 12x12 perhaps?

Map Verticality

The existing map is...flat. Too flat. There's almost no cliffs, hills, impressions, stairs, etc. Every cave is a staircase in the ground, rather than a cave doorway. The flatness makes the world feel less interesting than it could be, and at worst, feel more repetitive. Verticality can also serve as useful landmarks to make it harder to get lost. So I want to add more verticality as part of increasing the map size.

Item Upgrades

Until now, the game had no item upgrades. On the plus side, this means you can get to basically anywhere. Nothing is gated by item abilities.

But I think this makes the world feel too small and simple. It removes a sense of mystery of seeing something that's out of reach. Even games famous for giving you "all the tools at the start," like Breath of the Wild, still had many things gated by upgrades you'd obtain later. Clothes for handling certain kinds of weather. Improvements to stamina to climb higher areas. Upgrades are fun to obtain, and having certain areas be off-limits adds a sense of mystery which I feel the game was lacking. So, I'd like to add in some item upgrades to obtain.

I am adamant that this game will NOT have equippable items or a HUD. That extra tile's worth of space for a HUD bar is too previous to give up. But that doesn't mean the game can't have upgrades to enhance May's existing abilities or provide other effects.

The game's main quests are meant to be done in any order. I'd like the upgrades to be such that there's no obvious "must-have" item which compels players to get it first. Each one should be useful in its own right. One of the upgrades I have in mind is actually based on a debugging "ability" I created to make traversal and testing easier.

I'm also considering life/defensive upgrades as well.

Destructible Terrain

May has 2 abilities: jump and whistle. Which aren't really destructive abilities, and to the idea of destructible terrain I hadn't considered. But it can add a lot to make the world feel more dynamic and interactable. I have a few ideas for destructible terrain which I'd like to include in the map overhaul.

Shaders

There have been a few neat (to-be-optional) visual effects I've wanted to add to the game. And which I got working...

But only in a separate program. It breaks when I copy it into the actual game's code. And I'm quite sure it has to do with the game using a flat scaled viewport which does not allow for effects that are less than one scaled pixel in size. Like the thin lines in this dot matrix shader. I'd like version 0.4 to make it easier to include things like this dot-matrix shader:

Other

The above changes will also have some impacts on the game's story and world. As one example, I'd like to add a tutorial cave. There are also a few plot beats which I think could use tweaking.

Refactoring

Finally, there's the codebase itself. There's two big things I'm not too happy about with it:

• Adding new content (maps, NPCs, cutscenes) is more time-consuming than it needs to be.

• There's a lot of hack-y stuff in the codebase which....works...but is a pain to deal with.

For example, right now, I have to edit each individual screen-sized "map," one at a time. Each one is stored separately. And each one contains all the cutscene and script data for that map.

This makes it harder to play around with different layouts for areas that are larger than one map size. I can only look at each one one-at-a-time. It also means having to juggle a large number of tabs. And keep track of individual names for each map. Which is just...unnecessary. I could code things much more efficiently to make prototyping and development much faster.

This is my first professional game, after all. And my first time making one with Godot. And overall I'm actually quite happy with the code quality. But I want to be able to experiment and prototype things faster than it currently allows.

For example, a way to view and store the entire overworld, and all its NPCs and enemies, on a single screen in my editor. And let the game dynamically load individual, bite-sized pieces of it. Which I tried out, and so far I'm extremely happy with:

Now, I can move an NPC to another map just by dragging it. And I can split apart the existing maps to insert new maps in-between them, again, just by dragging its tiles out of the way. WAY more convenient than what I had before.

Most other games do not divide their maps into a single large grid with equally-sized rooms. That allows them more flexibility with resizing things, which I don't have. So I need to devise my own tooling if I want to make such maps efficiently.

TL;DR The less time I have to spend scrolling through script file names, juggling tabs, and scrolling through very long files, the more time I can actually spend making the game.

In the last few days I've gone through the entire codebase and made notes of everything I consider sub-optimal. The current plan is to brainstorm ways to improve it all, and experiment a bit. And come up with a plan to tackle it all. Then, and only then, will I rebuild the game from the ground-up, this time, without all those issues.

I suspect I'll be able to copy and paste a LOT of code from version 0.3. For example, all the game's menus are fine. No reason to touch them. But many of these other systems, like maps and scripting, impact so many things in the game, that I think it would be easier to just rebuild the game than swap it out in-place.

I'll also be able to include all the other version 0.4 changes mentioned while rebuilding the game. This may sound like a lot, but honestly, I don't think it will take that long.

Closing

With the music tool largely finished, I'm hoping to get back to weekly updates on my social media accounts. The tool required a lot of time and focus. And I wanted to focus entirely on it without trying to spruce it up for social media.

Thank you for reading! And thank you for your interest and support in May and the Amazing Bouquet!!