Full Games List
Featured Games
New Games
Reviews
Media
Images
Blogs
Game Updates
Images Feedback Summary
Game Design Highlights
Tutorials
Articles
Scripts
Utilities / Plugins
Resources
Engines
Engine Bulletins
What is Makerscore?
Past Events
Achievements
Misaos
Forums
Post History
Chat
New to RMN?
Full Store List
RMN Music Pack (free)
RUNNING A SUCCESSFUL PLAYTEST
Posts
Pages:
1
Red_Nova
Sir Redd of Novus: He who made Prayer of the Faithless that one time, and that was pretty dang rad! :D
9192
Red_Nova
View playlists
CloseTesting games is everyone's favorite thing to do, right? It's such a simple and easy task that you can do without sacrificing much of your time and vitality trying to fix and tweak every single little detail, right?
...
Okay, testing sucks. You have so much to look out for when running through your game that it's next to impossible to keep an eye out for every little detail through a single run. What can we do to make it suck less? Obviously, you're gonna be running through your game time and time again while you fix and polish as much as you can, but what are ways you've found that make testing easier on yourself?
While this can include getting others to test your game, I'm primarily talking about self testing in this topic. Coordinating testing efforts with others is a whole different can of worms that could probably go in its own topic.
Personally, I have different testing sessions where I focus on one aspect of the game and ignore everything else. Functional testing, writing testing, balance testing, bug testing, etc. are all done separately in order to keep from overloading my brain by looking at every possible issue that could potentially occur.
I keep a running tab of every bug/issue I find classed in one of four ways:
CRITICAL
These are the showstopper bugs that impede progress of the game. If your game is impossible to complete due to this bug, then it is a critical class bug and requires addressing before any other class of bug. Key items not appearing, required bosses missing a resource, faulty event logic on a required event, etc. are all critical bugs that prevent the game from being completed.
MAJOR
Bugs that disrupt a core function of the game. Examples include: a party member's skills don't work as intended, the menu system doesn't display when pressing a key, a save system doesn't correctly save data, etc.
MINOR
Bugs that don't directly impede progress like Major bugs do, but affect more core functionality than Trivial bugs. Examples include displaying incorrect messages to the situation like a Show Choice function that accidentally holds "Yes" logic under the "No" choice and vice versa, or having a skill description not accurately describe the skill.
TRIVIAL
Tiny little details that don't affect anything other than polish. These can be typos, dialogue overflow, misaligned pictures, etc.
Do you do something similar? Different? Let's talk about how we can get the most out of playtesting our games.
...
Okay, testing sucks. You have so much to look out for when running through your game that it's next to impossible to keep an eye out for every little detail through a single run. What can we do to make it suck less? Obviously, you're gonna be running through your game time and time again while you fix and polish as much as you can, but what are ways you've found that make testing easier on yourself?
While this can include getting others to test your game, I'm primarily talking about self testing in this topic. Coordinating testing efforts with others is a whole different can of worms that could probably go in its own topic.
Personally, I have different testing sessions where I focus on one aspect of the game and ignore everything else. Functional testing, writing testing, balance testing, bug testing, etc. are all done separately in order to keep from overloading my brain by looking at every possible issue that could potentially occur.
I keep a running tab of every bug/issue I find classed in one of four ways:
CRITICAL
These are the showstopper bugs that impede progress of the game. If your game is impossible to complete due to this bug, then it is a critical class bug and requires addressing before any other class of bug. Key items not appearing, required bosses missing a resource, faulty event logic on a required event, etc. are all critical bugs that prevent the game from being completed.
MAJOR
Bugs that disrupt a core function of the game. Examples include: a party member's skills don't work as intended, the menu system doesn't display when pressing a key, a save system doesn't correctly save data, etc.
MINOR
Bugs that don't directly impede progress like Major bugs do, but affect more core functionality than Trivial bugs. Examples include displaying incorrect messages to the situation like a Show Choice function that accidentally holds "Yes" logic under the "No" choice and vice versa, or having a skill description not accurately describe the skill.
TRIVIAL
Tiny little details that don't affect anything other than polish. These can be typos, dialogue overflow, misaligned pictures, etc.
Do you do something similar? Different? Let's talk about how we can get the most out of playtesting our games.
I... treat all bugs as if they have the same importance, regardless of their actual impact to gameplay. So a mis-coded method that causes crashes will be as pressing to fix as a window that is 3-pixels off-centre.
Tend to break the game down into parts when testing, and rarely ever perform a full playthrough myself. If at all. Which... would explain how my game can feel both rough and polished at the same time.
Tend to break the game down into parts when testing, and rarely ever perform a full playthrough myself. If at all. Which... would explain how my game can feel both rough and polished at the same time.
I test corporate betas differently than I test indie games.
Indie games get better treatment. If a corporate beta wants my full attention, they can pay me. I treat all bugs, big and small, the same. Next up is how much faith I have in the developer. If I'm really interested in the project I'll go the full 9 yards by checking every tile from each direction, etc. If the game involves stats I'll even cheat to simulate and make sure the maximums don't cause problems (like what happens when you beat that unbeatable boss since a player could technically spend weeks killing slims to level up enough to do it).
I cry inside every time I find event bugs and bad typos in mandatory places and the dev says "none of my other testers reported that."
Testing is very much an act of faith. I wouldn't half-ass a test because I wouldn't test for a half-assed developer.
inb4 my own game is full of bugs:(
Indie games get better treatment. If a corporate beta wants my full attention, they can pay me. I treat all bugs, big and small, the same. Next up is how much faith I have in the developer. If I'm really interested in the project I'll go the full 9 yards by checking every tile from each direction, etc. If the game involves stats I'll even cheat to simulate and make sure the maximums don't cause problems (like what happens when you beat that unbeatable boss since a player could technically spend weeks killing slims to level up enough to do it).
I cry inside every time I find event bugs and bad typos in mandatory places and the dev says "none of my other testers reported that."
Testing is very much an act of faith. I wouldn't half-ass a test because I wouldn't test for a half-assed developer.
inb4 my own game is full of bugs:(
90% if the time, when I do a self-playtest, it's to see if a sequence of events I just wrote, or section of code I just wrote, works. So, I tend to want to skip right to the section of the game where it's happening, but do an up-to-that-point playthrough regardless. I sometimes find minor bugs to tweak on the way, and, of course, I will want to fix those bugs before continuing.
author=Marrend
90% if the time, when I do a self-playtest, it's to see if a sequence of events I just wrote, or section of code I just wrote, works. So, I tend to want to skip right to the section of the game where it's happening, but do an up-to-that-point playthrough regardless. I sometimes find minor bugs to tweak on the way, and, of course, I will want to fix those bugs before continuing.
Yeah, for my own stuff I pretty much do this. It's also great for finding those dialogue lines that sounded cool when I wrote them but check em now and I wonder if I weas drunk.
Red_Nova
Sir Redd of Novus: He who made Prayer of the Faithless that one time, and that was pretty dang rad! :D
9192
I'm not sure treating trivial bugs with the same importance as progress-breaking bugs is the best idea. We all tout the line of "no game is perfect" and I think that translates to fixing trivial bugs. I don't think I'm exaggerating too much when I say that taking the time to fix every single trivial bug would mean the game would take about ten extra years to complete. There are only 24 hours in the day, and eventually a time has to come when you think the game is as good as it's gonna get, and your time is better spent addressing the weaker aspects of a game.
Trivial bugs I typically leave to the last round of polishing. Once I can play through the entire section of the game, then I go back and tweak and adjust line overflows, typos, graphical hiccups, etc. as needed. During the actual development, too much can change that could invalidate the tweaks and waste all that time anyway, like rewriting dialogue or tweaking a map's layout.
Trivial bugs I typically leave to the last round of polishing. Once I can play through the entire section of the game, then I go back and tweak and adjust line overflows, typos, graphical hiccups, etc. as needed. During the actual development, too much can change that could invalidate the tweaks and waste all that time anyway, like rewriting dialogue or tweaking a map's layout.
Jakoo56
91
I just make the game and fix everything that is either Critical or Major while i'm making it, i leave the rest of the small bugs for the end but note them on a paper or txt file. Everything that doesn't affect gameplay directly is something minor to me.
Pages:
1
