How My Brief Flirtation with FE Builder Gave Me a Greater Appreciation for Game Development

My mission was simple. I wanted a guard on my tutorial map to be defending a locked door. Defeating him would cause him to drop the key, teaching the player about the mechanics for dropping items as well as using keys to open doors. I had already programmed the door to open when interacting with it using the key and had already placed the guard at the entrance. So all I had to do was give the key to the guard and check a box that made the item droppable. It’s as easy as a couple of clicks: click an empty item slot, select the key, press a checkbox on the guard’s sheet, and then “write to ROM.” But when I boot up the emulator to test my tutorial, something goes wrong – instead of guarding the door, the guard opens it for the player. His AI says if he has a door key, then he wants to use it.

“Dammit,” I mutter to myself, “so close.” I close the ROM and go back into the menu where I can adjust the guard’s AI. There are settings for primary behavior, secondary behavior, how to behave when retreating, how to behave during recovery…I want the guard to attack the player if he seems them but otherwise to stand guard at the door, not opening it. I change the primary behavior to tell the guard to stand still instead of pursuing the player. “Maybe he’s opening the door to try to reach another unit,” I reason. No dice, guard still opens the door. I tell the guard not to take any action at all, but that creates another problem – other than counterattacking on the player’s turn, he just stands there until someone kills him. I move the guard away from the door where he’ll be closer to the player than the door – he still goes and opens the door instead.

At this point I have a choice – do I keep trying to figure out this miniature puzzle or do I brute force a half-solution so I can keep going and finish the part of the project I want to get done tonight? I decide on the latter, moving the guard to a position that’s far enough away from the door that he can’t reach it, but he will be able to reach the player when they enter the hall. It is only effective insofar as this assumes the player is navigating the tutorial at optimum speed; failing to reach the guards’s hall fast enough will cause him to still move towards the door and eventually reach and open it. But I’m ready to move past this so I chalk this one up to a “known shippable” – a bug or glitch that I know about but choose to leave in the game due to the lack of time or capacity to address it.

This story is just one of many of my adventures with a program called FE Builder, a tool designed to simplify and make accessible the process of hacking a ROM of the GameBoy Advance title Fire Emblem Sacred Stones. Created by FE Universe user 7743, FE Builder is one of a few different programs that fans of the Fire Emblem series use to make their own games. I found the tool myself through one such fan game, Fire Emblem: Vision Quest. While I originally went to FE Universe looking for Vision Quest, once I learned about FE Builder I pivoted immediately into experimenting with what it would be like to create my own game. The adventure that ensued led me to learning about all sorts of new programs and websites, taught me the bare basics of some new skills, and showed me firsthand the challenges that game developers face on a regular basis – granted at a much smaller scale.

The first problem that manifested itself was one I’m familiar with in thanks to my professional life: scope creep. For those who may not be familiar with the term, scope creep is when the intended scale of a project grows beyond its original boundaries as new needs or opportunities are identified. It’s when you start with “I’m going to write a blog post about which character is the best” and end up at “I’ve now recruited a dozen other bloggers to take on the roles of repping characters and serving as judges, all of whom I will guide in the creation of a three month long community project.” As I began using FE Builder, my goal was simple. I wanted to take the existing assets in Sacred Stones and simply rearrange them Majora’s Mask or Deltarune style into an alternate reality with different names and personalities. By the time I “stopped” (and who knows if or when I will pick this hobby up again) I had learned the basics of splicing character sprites using a new digital art program I’d never heard of, made an account on GitHub to download folders of custom battle animations to recolor for my characters, all on top of familiarizing myself with multiple sub-features within FE Builder itself.

The amount of weird trivia I learned during the process reflects all the information that designers have to keep in their mind when working on their games. For example, did you know that the character models in GBA games can only have 16 colors, one of which is the background color to be made transparent during play? Did you know that the blackest black used in the vanilla Sacred Stones game is 40-40-40 on the RGB color scale? Trying to design characters within these limitations adds an extra layer of challenge to something that’s already challenging in and of itself – making a character design that is visually compelling, distinct from the rest of the cast, and internally consistent in the setting of the game.

The way I tried to accomplish this during my time with FE Builder was through splicing, the process of taking existing sprites from Sacred Stones or even the previous GBA Fire Emblem title and cutting them together with a digital art program. As an example, my first character used features from four different characters across these two games: armor from Franz, hair from L’Arachel, eyes and face shape from Eirika, but with Lyn’s mouth (I wanted a feminine mouth that didn’t default to a smile). Of course you can’t just yank these different parts with a cut and paste tool and expect it all to work together smoothly. For one, the parts aren’t designed to go together and so nothing fits perfectly – you end up with lines in weird places, certain parts of the characters overlapping in ways that don’t make sense, and a smattering of inconsistent skin tones. These lines all have to be cleaned up, and in pixel art just the wrong placement of a pixel can make all the difference in whether or not a character’s design looks good at the proper size. When I made my second character, I missed some lines in the outline of his hair that made the top of his head look hazy and undefined when the ROM was running, forcing me to go back and clean up the lines some more.

Even when you have a good-looking splice, there’s still the little issue of making the character’s facial features move. In Sacred Stones, characters on screen blink as time passes and when they are talking, their mouths move. You achieve this effect by placing each frame of the motion into what I have seen referred to on FE Universe as a “hackbox” – essentially a template that shows where you need to put stuff for it to look right on the GBA emulator. The slight misplacement of a frame can make a world of difference – when I made the hackbox for my first character, I failed to realize that there was a one pixel height difference in one of her speaking frames which in-game caused the whole box around her mouth to unhinge and jump forward like a snake’s jaw when she was speaking. Oh, and is this a good time to mention the mini versions of the character portrait that show on the map screen, which look bad if you just shrink the full size character portrait so you essentially have to splice the mini-portraits of your inspiration characters for it to work effectively?

After building the hackbox successfully there’s still the coloring. I used a digital art program called Usenti to handle that. Usenti shows the number of colors in an image by default and has a “requantize” feature that allows you to reduce the number of colors to a specified value. If your picture has 30-something colors and you condense that to sixteen, you get a lot of overlap which can lead to pixels in weird places getting recolored when you don’t want them to. In the case of my second character, I wanted to give him violet eyes, but the requantizing process by default had made his eyes match the color of his hair. So changing the color in his eyes to violet made some of his hair violet too, which then made his hair not match unless I changed ALL of his hair violet too. Similar to my bandit story in the beginning, I had to make a judgment call – how badly do I care about his hair and eyes sharing a color? Is it important enough to keep experimenting with recoloring until I get an effect that I am satisfied with, or do I move on? The process I’ve described here took me six-to-eight hours and that was all just to make two characters in a game that usually has a cast of thirty-something.

Had all of my FE Builder experiences involved more frustration than progress, I probably would have stopped sooner than I did. But learning the program satisfied the part of my brain that likes to solve puzzles, and the rush of serotonin that came with finally getting to a workable solution kept me coming back even when particularly persistent problems stood in my way. Remember the door I described with the guard and the key? As part of opening that door, I wanted an effect where the room was revealed to the player, leading to the realization that there was an archer poised and ready to shoot them on the other side. This required two main changes to what I had already built: a tile change that activated when the door was open to change a room “hidden” by the ceiling into a room that was fully visible, and a scripted event that caused reinforcements to appear when the door opens (because the enemy units would be visible if they were already spawned on the map while the door was closed).

The tile change was tricky because I had already set up the tiles backwards. The map tiles look a certain way by default and the act of opening the door can change them to a different configuration. The one I was working with was actually what I wanted them to change to, which meant I needed to recreate that exact shape in my tile change and then set the default tile to a different pattern that looked like the roof of a building. There was a lot of fiddling involved with that because the door was located vertically in the center row of a large box of tiles that would be changing – when I tried to resize the range of the tile change, it moved the tile where the door key would register into a wall inaccessible to the player. This led me to have to experiment with the sizing so that the trigger for the tile change landed in the right spot while also making sure that only the tiles that needed to be impacted were covered in the range of the box.

Then I had to figure out how to add reinforcements. This was tricky because it required me to mess with a feature I had no practice with at the time: the event builder. Events are a broad mechanical construct in Sacred Stones that can cover everything from new units spawning and conversations starting to tile changes and chapter progression. My tile change was technically an event that I had just built using a different tool, but for those events which don’t have a more convenient resource I would need to look through the available codes to find one that worked. I found the code for spawning in units but the problem was that the units I needed to spawn in were already part of a different group: the ones who spawned when the chapter started. That meant deleting the units from that group and creating a new group dedicated to these “reinforcements” who would spawn when the door opened, and making sure that the spawn occurred after the tile change – otherwise the characters would appear on the ceiling and then the ceiling would go away. When I finally navigated past all of these little considerations and ended up with exactly the scenario I was envisioning in my head, that felt like a huge achievement.

This whole experience has done a lot to enhance my appreciation of the challenges faced by game developers. I spent easily a dozen hours just working in the tool, not counting time I spent reading tutorials, downloading programs, and watching instructional videos. All of that time and effort got me exactly one (1) tutorial chapter with two player characters, five bad guys, and a couple of tile changes. Had I taken the next step and started creating event scripts for dialogue between the characters, text prompts for tutorial activities, and the intro and outro for the chapter, that would likely be multiple hours of effort once again being poured into one single gameplay segment, theoretically a segment which would be accompanied by 25 or so more of a larger size and scale. Then theoretically as part of a team, that chapter would need to be reviewed and refined, playtested and adjusted – it’s easy to see how concepts that seem simple as a consumer of games are actually significantly more complicated than they appear at first glance.

I’ve often read a sentiment from game developers that it is essentially a miracle anytime a video game is shipped. My experience helped me to have a deeper understanding of how true that is. But it also showed me how satisfying it can be to work on a game – to have a vision in your mind of how the elements should come together to make a specific experience and to successfully execute on that vision. During the time I was working with FE Builder it was frequently all I could think about. How did I envision my characters? What mechanical role did I want each one to play? How would the map design and enemy placement teach the player what each character was meant to excel at? Each misplaced frame, wonky color palette, or buggy tile change was frustrating but the moment I managed to successfully push past those problems in order to make something that actually ran without crashing made the whole struggle worthwhile.

I’m not a guy who makes games and chances are I’m not going to be. But as a consumer and a critic, my appreciation for how amazing games are grows alongside my understanding of the process that makes them work. For that reason alone I am glad for FE Builder and what it taught me, and the time I spent with it doesn’t feel wasted. While I may never open up Usenti to requantize the colors in more pixel art or find any use for my understanding of how to make a tile change work, knowing the effort that those things take and the number of visions that have to align in order to make them possible will lead me to be more impressed with games I play down the line. And the next time I play Fire Emblem and a guard doesn’t use his door key to open the path for me, I’ll remember how sometimes the biggest challenges of all can sometimes come from the details you’ll never notice.