GAME DESIGN TIP #1: TESTING YOUR GAME MORE EFFICIENTLY

You are in control of your game; your game is not in control of you.

What's up, guys? This has been my very first article I ever posted, so let me start it all off by talking about how to test your games more efficiently.


Those Blasted Event-Driven Cutscenes!
I know everyone has encountered problems with having to repeat the same cutscene over and over again. I bet you've experienced this dilemma at least once, if not many times while you're making your grand story-packed RPG. Maybe you want to just skip a dialogue so that you can get to the boss fight? You find yourself spamming the ENTER key just to go to the part of the cutscene you actually want to test out. Then, when you actually get there, you found one bug, but you probably missed out on another bug in that specific cutscene, and you just realized that you have to restart your game to the last save point and so, you impatiently wait for that same part to come again.


Skimming an RPG
When you write an essay and you realized that you made a typo, you usually erase the typo and then keep going from where you last left off, right? It's the same thing with RPG Maker. If you want to move forward to a specific part of a cutscene or dialogue without having to go through the tiresome burden of having to replay that same cutscene over and over again, you can. Remember, with RPG Maker, you could set conditional branches and assign switches to those conditional branches. What I tend to do is to create a switch called Skip Mode and create a conditional branch with no handling set when conditions don't apply. That conditional branch will then check for whether the switch, Skip Mode is OFF. All you will have to do from that point is to insert the text that you want to skip over inside that conditional branch. When you go test your game out, you could just press the F9 key to look at the debugging menu and set the switch Skip Mode to ON. That way, any texts and dialogue boxes that you want skipped over will be skipped, and you can turn it back off if you want to see your text and dialogue again. This would be considered a fairly efficient way to make testing your game a lot easier, and seeing as to how you're the only one with the power to turn the switch, Skip Mode ON, it will show up normally when a regular player plays your game. You could probably come up with other methods too; if you have experience with scripting, you could assign a certain key to skip a message box automatically.


Why Skip?
I have played a good handful of modern-day RPGs made by professionals and they all seem to grant you the ability to skip over cutscenes if you choose. All their introduction cutscenes and their dialogues can be skipped over by pressing a certain button. This does serve a pretty important purpose, not just for the player, but specifically for the game designer. Imagine working on a professional RPG that contains cutscenes, video clips, and dialogue that can take up minutes to hours of your precious time. You need to find a way to prioritize and get to those certain portions of your game that you want to access. On some occasions, if your cutscene takes place over a series of maps, you could find yourself changing the player's starting position like I do in my RPG sometimes. However, what if you want to look over a certain text, or say you have been working on a 12 minute cutscene driven completely by events and dialogues in your RPG and it's all in the same map. You can't really use your save points at all, and changing the starting position won't help. This is where adding cutscene skipping functionality into your game will really help, even if the feature is just for you. You could move straight to the important battle, or you could just pay attention to the dialogue and skip any battles you have to face. It all depends on what parts you want to look over in your RPG.




Order from Chaos
If you're not necessarily faced with a cutscene or dialogue issue, you might come across other problems. Tiny flaws in the game's design could cause major bugs and glitches to occur. You could find yourself having to manage the animations and spells of multiple enemies at a time. You might also be trying to ensure that a group of NPCs wander through a village with intelligent minds of their own. Many of these things can go wrong and when they do, chaos will run rampant. How does one fight chaos? Through order, of course. You need to remember that this is YOUR game and you decide how to tame it. YOU are in control of your game; your game is not in control of you. Eventually, you will figure out techniques on how to influence your game in ways that a commander influences armies. That's what we'll be talking about next.


Make Yourself A Deity
If you have a good amount of knowledge to develop an RPG, you probably have enough knowledge to figure out which event commands can be used for you to take control of your game during playtesting. You remember that if you test your game through your game engine, pressing the Ctrl key can let you walk through walls, but if you play the game on an EXE file, you cannot? Well, you need to start finding ways to utilize your unique and temporary wall-passing gift while making your game! What I tend to do is create special events that trigger through Player Touch. First off, make sure your Player Touch event's priority is set to Below Characters. That way, you can easily pass over the event when you need to, and make sure that it is placed inside an impassable tile like a wall or a cliff. You could create hidden portals in your game that only you can access, so you can teleport to different parts in your game that would otherwise be impossible to reach if you're a player since the player can't walk through walls. With this technique, you could also create hidden areas that can take you straight to a boss fight if you want to skip the dialogue that badly. I even made a feature in my game that lets me turn into a sort of camera view when I'm pressing a key, where the player is invisible and you can pass through all walls while being able to move to specific parts of my maps at great speed. Whatever powers you want, you can get. Do you want to reverse time? You can with the right event commands and the right switches and variables used. Maybe you want to get access to any item and equipment in your game without needing to go to a shopkeeper? You can, with a friendly interface that feels comfortable to you. Don't feel so burdened and overwhelmed when making a game. It pays off to have little fun! Make yourself feel like a deity. The game is your playground to experiment with the new magical powers you have! Your tasks can only get easier from that point forward.


My Powers are Broken!? No!!
Making powers for yourself requires a pretty good knowledge on the manipulation of events and event commands on the map. Scripting would also be a huge plus on these cases. If you are having trouble trying to make powers for yourself that you can utilize during playtesting or if you are encountering major glitches with the features themselves, it's up to you to decide if those powers are really worth it in the long run. Sure, you may have come up with a couple new ways to make your game design job a bit easier, but if it gets to the point where you are only adding more to your troubles, then you might want to reconsider other options. I will be talking about other ways on how to handle bugs and glitches in a later article so stay tuned!




Conclusion
In conclusion, there are many ways to make your game designing life easier. You can create different systems that you can use to test and debug your game extremely efficiently. The key here is to try and utilize your convenience as much as possible. Think about it like this. Say, you have two groups; one group makes automobiles manually from scratch, and the other group sacrifices much more time, money, and resources to try and make a factory that can build automobiles automatically. Assuming that both groups have to stick with that same method and they compete for who makes the most cars, it's safe to conclude that a year from now, the first group would be on their way to manually making their fifth car, whereas the second group is still halfway through building the factory and haven't many any cars at all. You might say at first that the first group will win, and that could be true, but only in the short run. In the long run, like 10 years from now, the second group would have been able to manufacture hundreds or thousands of vehicles through their completed factory whereas the first group would only have made fifty cars. It all depends upon your priorities. Spend your time and resources wisely, and you will reap the benefits later on. Thanks for reading my article, and I hope you have some new idea or inspiration that you took away from it that can really help you out with your game design troubles.

Posts

Pages: 1
Good advice. This is why a lot of games have a debug menu in place for certain situations like this.
Thanks, Addit. I agree. Although the debug menu and the wall-passing features built-in are useful tools, they can be utilized to other possible areas of potential. Experienced programmers can figure out how to redesign the debug menu and its features altogether, but for designers more experienced with making events, they also have a good amount of control over how their game environment can be suited to fit their needs.
Marrend
Guardian of the Description Thread
21781
I've sometimes had thoughts of making a "Skip Mode" for playtesting purposes, but getting my head around how it would be implemented escaped me. Though, there have been moments when I find things to edit about the dialog during playtesting, but that's another thing entirely.
It's not a bad article, but there's not much actual advice here. If you don't mind, I'll share my experience.

One of the biggest things, imo, for efficient testing is to have a text file open where you write down bugs as you see them and continue testing the game. So rather than quitting right away to fix one thing, then going through it all again. You can fix multiple things after a single play through. It also helps prevent you from forgetting something that you saw during that play through. I have a bug list that is like 5 screens long, ranging from major bugs to minor visual glitches that will take time to draw up and fix.

The biggest part of testing is finding bugs. So what should people do when they find a bug? How do they know where in the code the bug is occuring? Opening the debug menu and looking at the state of the switches and varibles invovled should be done. Also, you can insert bits of code as markers. So let's say you have a series of events that are supposed to trigger in order. You can put in a message that says "1" at the start. At the next part you put in a "2" message, and so on. Then when you test the game you will see exactly what order everything is being triggered and you might find that "2" didn't show up, so you know exactly where in the code the problem is. You can also insert sound effects or other types of event code to find bugs.

This article doesn't address testing for ABS type games. One of the things I've learned is that you need to think of every combination of actions. I'll use my Zelda game for example. The ladder: you put it down, and it sits there waiting for you to climb on. While it's sitting there the player shouldn't be able to do anything but swing the sword, step on the ladder, or pick up the ladder. So I need to try pressing the menu key, try getting hit, try opening the save menu. I need to test every action the player might encounter at that point. When I'm in the menu, I know that certain keys are disabled, but I need to try pressing each one on every screen of the menu to ensure it's disabled properly.

Also, when actually trying to find the cause of a strange bug that you found and fix it, it's important to test it again after each single correction. If you do 5 things and it fixed the bug, you won't know which thing actually fixed it. So you don't really learn anything from it.

What I tend to do is create special events that trigger through Player Touch. You could create hidden portals in your game that only you can access, so you can teleport to different parts in your game that would normally be hard to reach if you're a player.

You forgot to mention that these events would have to be set to same layer as hero, or placed inside/beyond walls, in order to be inaccessible by players.

I've sometimes had thoughts of making a "Skip Mode" for playtesting purposes, but getting my head around how it would be implemented escaped me. Though, there have been moments when I find things to edit about the dialog during playtesting, but that's another thing entirely.

If you put every dialogue sequence inside a branch that checks if SW:"Skip: is OFF, there will be no change. The player will still be able to see all dialogue.

What you would also do is put a switch operation turning SW:"Skip" OFF at the very end of every dialogue sequence, outside of that branch. Again, the player will see no change.

Then as Gamer said, you can turn on the SW:"Skip" with the debug or a special temporary key input process before initiating that dialogue. It will skip everything inside the branch, and turn off the switch. Returning back to a normal state.

The only problem is that any other switches or variables(or other events like item get) that were in that sequence will not run. So you can add a branch that checks if SW:"Skip" is ON. Put it between the OFF branch and the switch OFF operation at the end. Put in any required event code.

It will skip the normal scene, trigger the necessary code, then turn off the switch so that the next event you talk to will run normally.

If it seems worthwhile to do, that's the simplest way I can think of doing it.
I think I see where you're getting at, Link. When my game has many bugs, I tend to use that same tactic you described; writing the glitches down on a text file and checking off those that I have fixed. I have a bad habit of forgetting what to test for in my game so you're right; that technique can be really helpful for dealing with multiple bugs at a time. :P

Marrend, it helps to start out with what problem you want to solve for. Next, using what knowledge or experience you have, make a utility or even just a new method of doing things that will help solve the problem or make it easier for you to solve.

(P.S. I updated my article to acknowledge the missing information you pointed out when I explained those special Player Touch events, Link. Thanks for putting my attention on it.)
I guess another piece of advice when it comes to testing your games is to use a video capturing software, like FRAPS or Camstudio, and have it record throughout on what your trying to test while you’re playing your game. Then if there are any bugs, errors, or just anything out of the ordinary that you’ve managed to find, the video will record it and you can just watch it repeatedly until your heart’s content and just fix it or adjust it manually from what you saw in the video. I often use this method to test my games, and I’m probably not the only one that does this too. :)
Interesting technique, Addit. I didn't even consider that method before. Heh, there's so many different ways that people handle their game. Use a text program to list down all the bugs, use a game recording software to fix all the glitches you see, etc. Whenever I find a typo in my game, I find it difficult to describe it in my text program so I tend to take a screenshot of it and highlight it using Paint. :]
When I test someone else's game, I take print-screens and describe the bugs in a text file so I can send it to the developer.

When I test my game,
* If the bug remains visible because the game waits for player input, I open the game source code side by side to the game window and fix the bug. Depending on the bug impact, I keep playing or quit the game, recompile and restart the game.
* If the bug doesn't remain visible (for example in a sequence of AI actions), I insert commands in the code to open a text file and write debug information in it. Those commands get executed if a certain variable was defined. The text file gets information as long as the game runs, so if it crashes the last line informs me about the last task it managed to complete.

Here is an example.

At the beginning of the code:
#define DEBUG_txtFile 1

Where I suspect the bug to be located:
   #ifdef DEBUG_txtFile
FILE *pFileDebug;
pFileDebug=fopen("debug.txt","a");
fprintf(pFileDebug,"overwriteUnitActionPoint(%d,%d,%d,%d)\n",Row,Column,ActionPoint,Selected);
fclose(pFileDebug);
#endif

By commenting the #define instruction, I can disable writing of debug information. So when the bug is fixed, I comment the #define and recompile the game. Then a player will not get a file that fills up with debug information each play session.
Pages: 1