Advice for ROM Hackers


#1

1. It takes time to learn ROM hacking, and even more time to refine those abilities.

My first “project” was an FE8 reskin called Secrets of Darkness. It made it to about Chapter 5x, and included an eerily cany descendant of FE4’s Alec (named…wait for it…Alex), because he was my favorite character from the first generation. I couldn’t figure out battle palettes, and somebody else helped me with the mugshot insertion (this was before the advent of the Event Assembler and FEditor).
 
Make no mistake, ROM hacking is a hobby that requires a willingness to learn. It won’t just come to you. No matter how fantastic your ideas may seem, there’s no such thing as a “make game” button. At the end of the day, it comes down to your commitment to development. Not just to game development, but to the personal development of your own skills.
 
2. Nothing comes out perfect on the first draft.



 
The screenshot on the top is the first public screenshot I showed of the project (complete with a tile change error), on the bottom is the same chapter’s final draft. The map was completely redone, and the entire plot was reworked. Dream of Five’s first few chapters went through some pretty substantial changes in response to outcry over the difficulty.
 
Stubbornly clinging to your first draft only inhibits your ability to refine the product.
 
3. Listening to criticism only helps you in the long run.

This harks back to the previous point. I’d like to preface this one with an important distinction: “listening” doesn’t mean “do everything you’re told.” Rather, it means being open to constructive commentary and understanding that, as a designer, you aren’t infallible.
 
Alfred Kamon’s Midnight Sun project offers a sterling example. In the first post, he offers special thanks to “those harsh but lovely fellas that killed me psychologically offered their critiques back in 2012 when this project was first announced.” Alfred admitted that the original project felt rushed and didn’t meet his personal expectations, and so he decided to scrap it entirely and begin anew. Such things happen; it’s a healthy part of the development process. He took those criticisms, soldiered on, and ultimately wound up with a far more impressive product.
 
Take what is useful to you, leave the rest.
 
However, it’s also important to understand the difference between constructive criticism and simple negativity. This is one area where the community-at-large could stand to improve. Offering constructive criticism fosters an environment that promotes development, rather than tearing down newcomers who are “below” our collective standards.
 
4. Nobody builds a full-length hack by themselves.

It’s important to understand the demands of developing a ROM hack. You need graphics (mugshots, animations, title screens, etc.), maps, events, and a script–at the bare minimum. It’s a monumental task for any one person to undertake. My projects would’ve gone absolutely nowhere without all of the assistance I’ve been given over the years. Teamwork is absolutely essential for success.
 
The best way to get help is by asking for it. However, you also have to be able to back up that request with some actual substance. Putting together a rough draft, a proof of concept will get you much further than a topic with an idea and a plea for others to do the dirty work for you.
 
5. Planning is the most important part.

Projects are a massive undertaking, and shouldn’t be started on a whim. The more effort you devote to thorough planning, the better off you’ll be in the long run. Obviously, planning shouldn’t be static. Elibian Nights started with around seven planned tales, and eventually expanded to thirteen. Change is a natural part of the development cycle. What’s important is building a solid, organized, and thought-out foundation to base your project upon.
 
Spreadsheets are your friends. Nowadays, all of my project concepts start on a Google Doc (it’s great for collaborative work). Here’s a sample doc, outlining vanilla FE5.

6. Don’t be constrained by the traditional structure.

As long as I’ve been developing Elibian Nights, there have been a number of relative unknowns who’ve tried to make their names by copying that concept and porting it to another continent. None of them got very far, obviously. They say that imitation is the sincerest form of flattery. Personally, I’d rather be outdone than be flattered–I’d rather have two quality, unique games than one game and a shallow imitation. If a newcomer looks at my project and thinks “I want to make that,” and answers that inspiration with “Elibian Nights in Magvel,” then they’ve missed the point entirely. This means understanding the difference between “inspiration” and “imitation.”
 
Part of what I feel makes Elibian Nights so note-worthy is that it abandons the traditional Fire Emblem structure in favor of a segregated party with no level progression, putting the emphasis on focused storytelling rather than a grand 30-chapter narrative. That’s the point. Don’t confine yourself to the standard notion of what a Fire Emblem game ought to be, or to anybody else’s notion for that matter. Dare to be different, and be bold with your ideas. At the same time, develop a project that you’ll be capable of completing. Not every hack has to be a 30-chapter masterpiece. A quality 10-chapter hack would be much more well-received than a mediocre 30-chapter game whose length is decided not because it’s what works best for the project itself, but out of resignation to the “normal” way of doing things. By freeing yourself from these conceptions, it only serves to increase creative freedom.
 
 
If, of course, you think there’s anything I’ve missed, feel free to add to this with your own personal advice. Hopefully this can be a valuable resource for newcomers and veterans alike.