“You joined for ROM Hacking, didn’t  you, [player]?”

I’m sure that most people here at PokéCommunity have, through playing Pokémon games, wanted to contribute to a Pokémon game in some way, shape, or form. Be it sprites, music, or actually creating our own game through ROM hacking, we all desired a platform to showcase our creativity. However, none of these tasks were easy from the start.

For spriting, we needed to learn about shading, colour choice, poses, and such. For music composition, we needed to know about basic musical concepts, chords and chord progressions, and such. As for ROM hacking, we had to discover mapping, scripting, insertion of various different graphics, and eventually the implementation of next-gen features through the use of assembly. People with polished skills in these areas then put their abilities to good use by creating tutorials and tools for the rest of us.

Yet even with the vast number of tutorials, we ROM hackers still make mistakes. Why? Well the easy answer is that we’re human, and that humans are prone to making mistakes.

What I want to address are the mistakes that are hard to spot or never even discovered by the casual player, but are actually noticed by seasoned ROM hackers and players. It is possible that none of the hacks currently in the Hacks Spotlight or Progressing Hacks section have any of these mistakes, in which case they should just ignore this article. But if you’re an aspiring ROM hacker or are new to the scene, please take note!

This time I’ll be discussing the syntax of the in-game dialogue.

Introduction

What is dialogue?

First of all, I want to introduce what dialogue is to those who don’t know. Dialogue, in this context, is simply what another character says. For the purposes of disambiguation, let’s consider text from signs, etc. as dialogue as well, since my focus is on syntax rather than content.

What is syntax?

Syntax is a set of rules that governs your text structure. There are many more structural rules that we have to take into account in the case of Pokémon ROM hacking dialogue. These are rules that should be in place in addition to the existing laws of language, which include spelling and grammar.

Let’s get started.

The Syntactical Rules

Again, these so called “rules” don’t matter too much to the general population, so you don’t have to adhere to them. However, if you want your game to look professional, neat, and presentable, you should make the small adjustments needed to follow the syntax of ROM hacking dialogue.

The Character Limit

First up we have the character limit. Perhaps it would be a good idea to define what a character is. A character in this context is not a person or a being. The character I am referring to is any letter, number, space, or punctuation. The real set of characters is much larger than the set of characters that I have just described, but a lot of those characters are not needed. We only need letters, numbers, spaces, and punctuation for ROM hacking dialogue.

As one might expect, the character limit is the number of characters that are allowed in one line of dialogue. In Pokémon ROM hacking, the limit is thirty-four characters. It is pretty obvious that the textbox will look bad if the character limit is exceeded, which will be shown later.

I wanted to mention the character limit because it is something that I was not aware of when I first started scripting.

At first I thought that the limit was thirty-six because it is possible fit thirty-six characters on the first line:

But some characters are wider than others, so let’s replace all of the characters with “A”:

It doesn’t seem to work. In fact, there are only thirty-four full “A”s in that textbox. Since “A” is the widest character (tied with many others), we can conclude that the character limit is indeed thirty-four.

XSE actually has a built-in tool to rewrite text so that it fits the character limit, the Text Adjuster. It was actually through this tool that I discovered the actual value of the character limit. To access this tool, simply type “Ctrl” plus “T”, or click Tools->Text Adjuster at the top of the window.

Personally, I don’t use the Text Adjuster to check if my lines exceed the character limit. There are a few reasons, but basically it’s too much of a hassle for me to open up the Text Adjuster and type my dialogue every time. Here’s the method that I use for checking the number of characters per line:

I highlight the line with my cursor, and the number of selected characters will appear at the bottom tab. It is a very quick and easy method, so use it!

(Note: Do not highlight any \n or any kind of line break, as they will not take up space in the actual in-game textbox)

One other thing to watch out for are variable length names. These names are the player’s name, the rival’s name, and also the name of any Pokémon. The names of the player and rival are seven characters long, and the names of Pokémon are ten characters long. The max possible length of these variable names should be assumed with any dialogue that would include the player’s name, the rival’s name, or the calling of a Pokémon’s name as a buffer.

Take this example below:

At first glance, this line should not be acceptable because it is thirty-five characters long. However, “[player]” is eight characters and will be replaced by the player’s name, which is at most seven characters. Thus, we can assume that this line is at most thirty-four characters, which is at the limit.

It should be also noted that this line would not be acceptable if my selection was thirty-six characters long. The line would work for player names of length up to and including six, but would exceed the character limit if the player’s name length is seven.

Line Breaks

Now we move onto line breaks. The line breaks are \n, \l, and \p. I’m sure that most people reading knows what these are, but I’ll briefly go over each of them once more.

• \n moves to the next line but does not scroll the textbox down (or up, depending on how you look at it).
• \l moves to the next line and scrolls the textbox down (again, or up), and should only be used after \n.
• \p opens a new textbox and moves to the first line in the new textbox.

Knowing what each of these line breaks do, it seems that \n and \l suffice for all of the scripting that we need to do. It makes sense to use \n after the first line and \l after each successive line, and to disregard \p. In fact, this is how I wrote all my dialogue.

However, I later learned that using only \n and \l was incorrect. Even without any tutorial, it can be seen in the base game’s dialogue that \p is indeed used. As a matter of fact, \p is used more than \l is.

But why is this so? Why can’t we just use \l indefinitely? The answer is, simply put, that \l makes text very exhausting to read. However with \p, it is very easy to separate different ideas from each other.

For an analogy, think of each textbox as a sentence. With many \l, it is as if the sentence just goes on and on, sometimes having commas to separate ideas. In contrast, with \p the different ideas are separated into different sentences.

Still don’t believe me? Here is \l:

And here is \p:

Okay, sure, the two aren’t synced very well. But if you pay attention to one and then the other, it will become very apparent that the second one is better.

Keep in mind that \p creates a new box. Because of this, the first line break after a \p should be a \n.

Other Conventions

Of course, there are some other conventions that are used in Pokémon dialogue that need to be taken into consideration when ROM hacking. Here is a brief list:

• Use Pokémon instead of Pokemon.
• For any Pokémon name and even Pokémon as a whole, the plural form is the same as the singular form (e.g. Feraligatr over Feraligatrs and Pokémon over Pokémons).
• Be sure to capitalize (in some way) any proper noun – where proper nouns include Moves, Items, Abilities, Pokémon, NPC names, NPC titles, Area names, etc. (e.g. Use Pikachu or PIKACHU instead of pikachu).
• For Fire Red/Leaf Green, use blue for male text and red for female text, as well as black for text that fits neither category. Though the text will change to the right colour automatically for Person Events, be sure to put the correct colour tags in when writing dialogue in Scripts!

These are some of the basic conventions exclusive to ROM hacking dialogue.

Consistency

The most important aspect of ROM hacking dialogue is having consistency. Having consistency in this case means that your dialogue syntax is more or less the same for all of the dialogue in your game.

For example, sometimes the NPC’s name precedes what they say. In the base games, the colour of their name is the same as the colour of their dialogue. However, some people may not agree with that, as the NPC doesn’t really “say” their own name when they talk. Thus, these people have the NPC’s name in black, and the rest of their text in the appropriate colour. Although I use the former, I believe that both are okay as long as this kind of dialogue is handled the same way for the rest of the game.

So don’t go using “pokemons” in one person’s dialogue and then use “Pokémon” for another person’s dialogue. Even if you use “pokemons” (please don’t), using it for all of your game’s text is still better than being inconsistent.

Closing Remarks

So hopefully this article was of help to some people. I know that the tips here would have helped me a lot when I first started hacking. It could have helped me save many hours of going back and fixing my scripts.

Next time I will be back to address some of the newbie mistakes regarding mapping, so stay tuned!

Edited by adrift and Jake.

Cover image by Sylphiel.