Chapter 62: Proper Betatesting

There’s a proper way to do most things in life, and that includes beta testing. You might think it’s not a big deal—just play the game and look for glitches—but if you want a professional hack, you need it professionally tested, or the next closest thing, which is what I’m going to detail in this chapter.

To start, a beta patch may or may not come with a README and other files. If the betatest is one that is practically meant to be released to the public (has patching instructions, readme, etc., along with the patch, of course) you’re going to want to make sure that all the files are clear and it is not confusing as to what is what and how one should go about playing the game.

Once you actually start playing the game, it’s time to analyze everything you can while playing the game. For example, if there are different modes (normal, hard) you’re going to want to play both (or at least test it out, maybe use cheats to expedite the betatesting process if you don’t have time). You want to check out the balance of the game, the graphics, and of course TRY and cause glitches, because it’s better that a betatester encounters it when they are testing than when an ordinary person is playing the game.

This chapter is/is going to be (I just know as I’m writing this that it’s going to be) text heavy. But to make it easier (wall of texts get boring quickly) I’m just going to write 50 things you should know about betatesting a game, and call it a day.

50 Things to Know About Betatesting

1. Make sure that the download isn’t confusing, nor is extracting files or patching the game.

2. Watch all the scenes in a game. Don’t even skip the opening, even if the creator of the patch hasn’t altered it—it might have been accidentally edited.

3. Check for spelling everywhere. If you’re not a good speller, have a spell-checker nearby for words that you think might be spelled wrong.

4. Check for grammar everywhere. I guess in part to be qualified as a good betatester, you kind of need good grammar. Simple stuff like “your” and “you’re” is given, but also run-on sentences and stuff. Of course, if the author intends to use bad grammar in dialog as a means of one’s personal type of speech, or if the game leans toward bad grammar for humorous purposes (or some other obscure purpose), you might want to just ignore the grammar part. But in general, good grammar = good game.

5. Press buttons. Just try pressing random buttons, and see if something odd happens.

6. Check all modes of the game in the main menu to see that they are working properly.

7. In games like Fire Emblem, you may need to check help menus. In Fire Emblem, this is done by pressing “R”, and may also give character or class descriptions, which hackers often forget to change.

8. Listen to all the songs in the sound room (if there is one).

9. If you hear a song play in game, make sure it also appears in the sound room (applicable only to some games).

10. When you hear a song in game and it’s custom, have it loop at least once if possible, not only to make sure it loops, but to make sure that the whole song plays without any problems. Songs from the original game are less likely to be glitchy (and if they are, they’ll probably be obvious).

11. On games with maps (like Fire Emblem, of course) check all the tiles on the map. Sometimes tiles may act funny (you may move onto non-existant tiles, or tiles may appear crossable but not be, or something else weird).

12. In dialog, make sure that there are pauses in between to let the player read the text. This may mean having to press a button to continue, or just having text go slowly.

13. Always look for weird pixels or graphics that might show up somewhere.

14. If you do encounter a problem, take screenshots and videos to show where it is.

15. If a problem occurs, it is very helpful to take a savestate (shift+F1-F10, then press the ‘F#’ button to reload a savestate slot) and then give that savestate to the author of the hack so s/he can access the glitch without having to play through the game.

16. Use all characters in the game at least once.

17. Keep animations on to ensure that you see that battle sprite are working and are colored properly, amongst other things.

18. Look at stats to make sure that they aren’t working weird either (crazy high stats, stats that change on their own, “--“ stats, etc…).

19. Also test animations off to make sure map sprites are working right.

20. Listen to sounds—make sure the right sound effects are being played at the right time.

21. Look for balance in enemy numbers and your numbers. In a game like Fire Emblem, you typically don’t want 20 allied units and only 10 enemy units.

22. Look for balance in unit strength. One of your units shouldn’t be so broken that they can solo an entire chapter (barring the first few chapters, where there are usually only a few units on the entire map…). Similarly, the enemies shouldn’t be so hard that they’re better than your own units, or so weak that they have a 30% chance of doing only 2 damage, or something as ridiculous as that.

23. Analyze the map. Boring maps with a simple path to the area one is trying to go to are boring and should be edited. The terrain should be as diverse as possible while still adhering to the plot (if the characters are in a desert region, there’s typically not going to be a lot of grass or trees or civilization, of course…).

24. Pay attention to consistency in the plot. This includes names, characteristics, and plot details in general.

25. Visit all villages and other places on a map you can possibly go to. This includes looking for secret shops.

26. Analyze the plot to see which characters can be recruited or perhaps check for character relations. Also check for gaiden/secret chapters and how they might be reached.

27. Think to yourself “if I weren’t a very smart person”, and question how confusing the plot may or may not be? Is there something that doesn’t make sense, or perhaps a character doesn’t get enough time to develop themselves?

28. Check for repetitiveness. If every enemy has the same inventory, or only 1 or 2 classes are used for all the enemies on a map, or the same reinforcements constantly come, players won’t feel very excited to play on the map. These things may detract from the enjoyability of the game.

29. Always try both paths. Try killing off units to check their death quotes, or losing to get game overs. It’s possible someone forgot to code in a game over event!

30. Look for suspicious areas on the map. Sometimes there may be hidden secrets on tiles you don’t expect.

31. Check enemy inventories to see if there are any weapons that they have, but can’t be used, as well as droppable items. It’s possible a hacker meant to make an item droppable but didn’t, so question it, even if it’s meant to be stolen by a thief.

32. Question things that might be right, because they might be wrong. If some unit has lethality as a skill, it might have just been a test. A weapon might accidentally have 100 critical because the player was testing a critical!

33. If there are custom animations, test all different aspects of the animation. This includes dodge, magic swords (if applicable), close and far range, etc.; and the same thing applies to custom spell animations.

34. Check to see if something is missing in a game. If one of the characters mentions that “the enemy has ballista” but you don’t see ballista on the map, the hacker likely forgot it, and it’s your job as a betatester to let them know.

35. Expanding on the “multiple path” idea, use savestates to test out possible split choices. A chapter may have two ways to beat it—try both. You may be given a choice to do X or X. Use a savestate, try one, go back , and try the other. Do this every chance you get to make sure things turn out right.

36. Custom cutscenes are often full of problems. For instance, the camera may not follow a person, or may jump around if multiple people are loaded. It might even glitch up sometimes while not glitch other times. One thing is that cutscenes sometimes glitch up if you watch the scene, get to the battle preparations, save, and then restart the chapter, so try it out to see if there’s some major problem.

37. If a certain weapon is broken, suggest to the author that they tone it down.

38. Make sure PRF weapons are actually limited to a certain character (or maybe class) and aren’t apocryphal.

39. Check to see that custom classes behave as they should—for example, a class on horse will need the “move again” ability, and will need the “knight” icon. A custom flying unit will need the movement ability to flow over mountains.

40. Always look for unedited text and other aspects of the game that should probably be edited. This is tricky because it’s not a glitch or a bug as much as it is something the author simply didn’t do. Sometimes character/class/item descriptions, death quotes, battle quotes, or even certain dialog may have been forgotten to be edited. Someone may have left a support of two characters who aren’t supposed to support anymore, or have left an enemy with a weapon that has been edited to be a customized weapon enemies aren’t supposed to have.

41. Try all the different menus in the game. For example, a hacker may have edited a background somewhere, and that same background may be shared in the ‘Options’ menu, but they may have forgotten to edit the palette (coloring) of the background, and so it may look weird. If you don’t check that menu, you won’t know!

42. The game shouldn’t be too difficult or too easy in most cases (unless that is the purpose of the hack). Take into thought that you may be a better player at a game than most other people, and so the game might be too difficult for the average person.

43. Actually test a little bit of hard mode to make sure that it’s working right not just in theory, but in actuality and that hard mode itself isn’t harder or easier than the hacker may have intended. In this case it’s best to just comment on the difficulty level in general rather than say whether it is too high or low.

44. Check for weird occurrences when you suspend and resume the game. For instance, there was this one glitch where certain stats would increase if the game was suspended and resumed (I won’t get into it, but the point is, check).

45. Check for portrait colors (consistency and general appearance). Portraits shouldn’t be a mixture of FE7 and FE8 colors if it can be avoided. Also, really bright colors can hurt the eyes, so make sure the hacker doesn’t give reason for anyone to be blinded.

46. Don’t forget to promote all the units you can too! Savestates are quite useful here. One promotion item can be used to promote units of all classes. You may need to abuse arenas to level units up to level 10, play the game multiple times, or hack the game to help with this, but it’s necessary, because it’s possible the author forgot to do every single promoted battle palette.

47. When you are actually betatesting, write down everything nice and neat, in bullet or numbered form, in a word or notepad file or something. Do it WHILE you are playing the game, not after—because you’ll probably miss something if you just keep it in your head.

48. While writing your report, be detailed and include specifications as to where things are and when they might occur. As said before, use screenshots, videos, and savestates as necessary. It might be helpful to organize your comments into different categories, like “Text”, “Forgotten Things”, and “Glitches”, because it helps them tackle down all the problems in one category at a time. It also helps because “glitches” are usually a priority of beta-fixing.

49. Don’t be too harsh or bias with your betatesting. You don’t want to anger the hacker and make them not want to fix something, or give your opinion on something they don’t care about, like “this portrait looks really ugly, whoever made it sucks at spriting”, or “the plot is really bland, it needs a complete overhaul…”.

50. Enjoy your time betatesting, because if you don’t play normally, it’ll be more of a job than it is a special privilege!