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)
HOW DOES DEBUGGING ACTUALLY WORK?
Posts
Snodgrass
View playlists
CloseOk, for those who don't know me: total newb, no knowledge of scripting, haven't figured out how to make a game yet.
Right now I'm just lurking and scouring info about game making while creating the maps for my first game using the default tiles and I saw this thread:
http://rpg-palace.com/categories/game-maker-s-guild/game-making-support/tutorialxpvx-debug-mode
...and it reminded me how I don't know how to debug so...um... how exactly do you debug?
Obviously I have to remove the bugs and I have to actually have bugs but how does a debugging mode help in detecting those bugs other than making a cheat mode that makes it faster to play through the game...or is that the point? You're still bug checking but the mode just makes it faster to reach a problem point?
I know the thread elaborated on it but having no actual idea about elements like variables, I really have zero idea with regards to why seeing those variables would be important while playing the game.
Playing/enabling the debug mode in other games, my impression is that they sometimes vomit out codes that read like jargon to my eyes at a rapid rate.
Right now I'm just lurking and scouring info about game making while creating the maps for my first game using the default tiles and I saw this thread:
http://rpg-palace.com/categories/game-maker-s-guild/game-making-support/tutorialxpvx-debug-mode
...and it reminded me how I don't know how to debug so...um... how exactly do you debug?
Obviously I have to remove the bugs and I have to actually have bugs but how does a debugging mode help in detecting those bugs other than making a cheat mode that makes it faster to play through the game...or is that the point? You're still bug checking but the mode just makes it faster to reach a problem point?
I know the thread elaborated on it but having no actual idea about elements like variables, I really have zero idea with regards to why seeing those variables would be important while playing the game.
Playing/enabling the debug mode in other games, my impression is that they sometimes vomit out codes that read like jargon to my eyes at a rapid rate.
debugging:: you run through your scenario and see if you get the result you expected. If not, make changes, repeat test.
In 1947, Grace Murray Hopper was working on the Harvard University Mark II Aiken Relay Calculator (a primitive computer). On the 9th of September, 1947, when the machine was experiencing problems, an investigation showed that there was a moth trapped between the points of Relay #70, in Panel F. The operators removed the moth and affixed it to the log. The entry reads: "First actual case of bug being found." The word went out that they had "debugged" the machine and the term "debugging a computer program" was born.
Although Grace Hopper was always careful to admit that she was not there when it actually happened, it was one of her favorite stories.
The exhibit
One of the most common stories about the moth, and a story I often repeated, was that the moth was on display at the Smithsonian. A correspondent for the Online Hacker Jargon File decided to check on it and guess what . . . it wasn't there. In 1990, the editor of the Online Hacker Jargon File did some investigating. Turns out that the log, with the moth still taped by the entry, was in the Naval Surface Warfare Center Computer Museum at Dahlgren, Virginia. They had tried to donate it to the Smithsonian, but that the Smithsonian wouldn't accept it.
The 1990 curator of the History of American Technology Museum (part of the Smithsonian) didn't know all of this, agreed to accept it, and took it in 1991. It took years to be actually exhibited due to space and money constraints.
As the Online Hacker Jargon File notes
Thus, the process of investigating the original-computer-bug bug fixed it in an entirely unexpected way, by making the myth true!
The Term
So, where did the term "bug" come from? Well, the entry ("First actual case of bug being found.") shows that the term was already in use before the moth was discovered. Grace Hopper also reported that the term "bug" was used to describe problems in radar electronics during WWII. The term was use during Thomas edison's life to mean an industrial defect. And in Hawkin's New Catechism of electricity, an 1896 electrical handbook from Theo. Audel & Co.) included the entry:
The term "bug" is used to a limited extent to designate any fault or trouble in the connections or working of electric apparatus.
In discussing the origin of the term, the book notes that the term is said to have originated in quadruplex telegraphy and have been transferred to all electric apparatus. Common folk etymology says that the phrase "bugs in a telephone cable" was used to account for noisy lines. There is no support for this derivation. However, the term "bug" was used in the early days of telegraphy. There were the older "manual" keyers that required the operator to code the dots and dashes. And there were the newer, semi-automatic keyers that would send a string of dots automatically. These semi-automatic keyers were called "bugs". One of the most common brands of these keyers, the Vibroplex, used (and still does use) a graphic of a beetle. These semi-automatic "bugs" were very useful, but required both skill and experience to use. If you were not experienced, using such a "bug" would mean garbled Morse Code.
Radio technicians also used the term "bug" to describe a roach-shaped device consisting of a coil of wire with the two ends of wire sticking out and bent back to nearly touch each other. This device was used to look for radio emissions. This term "bug" was probably a predecessor to the modern use of "bug" to mean a covert monitoring or listening device.
But, lets go way, way back to Shakespeare. In Henry VI, part III, Act V, Scene II, King edward says "So, lie thout there. Die though; and die our fear; For Warwick was a bug that fear'd us all."
Samuel Johnson's first dictionary includes a definition of "bug" to mean
a fightful object; a walking spectre
In 1947, Grace Murray Hopper was working on the Harvard University Mark II Aiken Relay Calculator (a primitive computer). On the 9th of September, 1947, when the machine was experiencing problems, an investigation showed that there was a moth trapped between the points of Relay #70, in Panel F. The operators removed the moth and affixed it to the log. The entry reads: "First actual case of bug being found." The word went out that they had "debugged" the machine and the term "debugging a computer program" was born.
Although Grace Hopper was always careful to admit that she was not there when it actually happened, it was one of her favorite stories.
The exhibit
One of the most common stories about the moth, and a story I often repeated, was that the moth was on display at the Smithsonian. A correspondent for the Online Hacker Jargon File decided to check on it and guess what . . . it wasn't there. In 1990, the editor of the Online Hacker Jargon File did some investigating. Turns out that the log, with the moth still taped by the entry, was in the Naval Surface Warfare Center Computer Museum at Dahlgren, Virginia. They had tried to donate it to the Smithsonian, but that the Smithsonian wouldn't accept it.
The 1990 curator of the History of American Technology Museum (part of the Smithsonian) didn't know all of this, agreed to accept it, and took it in 1991. It took years to be actually exhibited due to space and money constraints.
As the Online Hacker Jargon File notes
Thus, the process of investigating the original-computer-bug bug fixed it in an entirely unexpected way, by making the myth true!
The Term
So, where did the term "bug" come from? Well, the entry ("First actual case of bug being found.") shows that the term was already in use before the moth was discovered. Grace Hopper also reported that the term "bug" was used to describe problems in radar electronics during WWII. The term was use during Thomas edison's life to mean an industrial defect. And in Hawkin's New Catechism of electricity, an 1896 electrical handbook from Theo. Audel & Co.) included the entry:
The term "bug" is used to a limited extent to designate any fault or trouble in the connections or working of electric apparatus.
In discussing the origin of the term, the book notes that the term is said to have originated in quadruplex telegraphy and have been transferred to all electric apparatus. Common folk etymology says that the phrase "bugs in a telephone cable" was used to account for noisy lines. There is no support for this derivation. However, the term "bug" was used in the early days of telegraphy. There were the older "manual" keyers that required the operator to code the dots and dashes. And there were the newer, semi-automatic keyers that would send a string of dots automatically. These semi-automatic keyers were called "bugs". One of the most common brands of these keyers, the Vibroplex, used (and still does use) a graphic of a beetle. These semi-automatic "bugs" were very useful, but required both skill and experience to use. If you were not experienced, using such a "bug" would mean garbled Morse Code.
Radio technicians also used the term "bug" to describe a roach-shaped device consisting of a coil of wire with the two ends of wire sticking out and bent back to nearly touch each other. This device was used to look for radio emissions. This term "bug" was probably a predecessor to the modern use of "bug" to mean a covert monitoring or listening device.
But, lets go way, way back to Shakespeare. In Henry VI, part III, Act V, Scene II, King edward says "So, lie thout there. Die though; and die our fear; For Warwick was a bug that fear'd us all."
Samuel Johnson's first dictionary includes a definition of "bug" to mean
a fightful object; a walking spectre
As far as I know...
In RM terms at least.. A variable is a function that determines the behavior of something in the game based on the value it holds.
In debug mode you can manually choose to assign the value held in the variable while the game is running rather than having to execute the in-game actions that would usually be responsible for altering the value held in the variable.
Same goes for switches, but they're either "on" or "off" rather than value-based. In "debug mode" you can turn switches on and off without having to perform the in-game actions that would usually be responsible for making a switch turn on or off.
Does that help at all?
In RM terms at least.. A variable is a function that determines the behavior of something in the game based on the value it holds.
In debug mode you can manually choose to assign the value held in the variable while the game is running rather than having to execute the in-game actions that would usually be responsible for altering the value held in the variable.
Same goes for switches, but they're either "on" or "off" rather than value-based. In "debug mode" you can turn switches on and off without having to perform the in-game actions that would usually be responsible for making a switch turn on or off.
Does that help at all?
author=NewBlack
As far as I know...
In RM terms at least.. A variable is a function that determines the behavior of something in the game based on the value it holds.
In debug mode you can manually choose to assign the value held in the variable while the game is running rather than having to execute the in-game actions that would usually be responsible for altering the value held in the variable.
Same goes for switches, but they're either "on" or "off" rather than value-based. In "debug mode" you can turn switches on and off without having to perform the in-game actions that would usually be responsible for making a switch turn on or off.
Does that help at all?
Yep. That actually makes sense but from the sound of it, it seems like it would demand some manual in itself to debug the code and some knowledge of how turning an on or off switch would actually matter. (i.e. narrowing down a particular event as being the one causing the bug in real time)
Since I don't have a full made game yet, I can't even tell what I would get from RM's debug mode.
Any thread that has this list of commonly used commands as well as common bug fixes for RM's debug mode? (I haven't done a web search yet. I'm also worried that from the way the help file phrases it, it sounds like I have to learn almost everything about Ruby before I would even get somewhere but I haven't read anything about RGSS yet either.)
Edit: Maybe turning switches on and off isn't the best example either. From the way variables sound, it sounds like I have to have some idea why changing the range in the variables would actually matter and what common ranges to replace a current variable with.
Debugging is useful and it works by allowing the developer to check if the program is behaving the way it was intended. So any unexpected output would be handled accordingly as the developer wishes.
The purpose of debugging is to check if the actual output from the program is correct. It's similar to testing except it can be done before any functional prototype is made. Debugging can be used on methods and functions as well as a whole program. Difference between debugging and testing is that debugging is done during development, while testing is done by testers during testing.
The purpose of debugging is to check if the actual output from the program is correct. It's similar to testing except it can be done before any functional prototype is made. Debugging can be used on methods and functions as well as a whole program. Difference between debugging and testing is that debugging is done during development, while testing is done by testers during testing.
Yeah that definition doesn't really help. It sounds like the antithesis of using a RPG Maker.
How can someone who doesn't know how to script know how the game's code is supposed to be intended?
...or is debugging mode purely from someone who knows how to look at Rpg Maker's code as code and isn't meant to be used by users who just copy paste scripts?
How can someone who doesn't know how to script know how the game's code is supposed to be intended?
...or is debugging mode purely from someone who knows how to look at Rpg Maker's code as code and isn't meant to be used by users who just copy paste scripts?
author=Snodgrass
...or is debugging mode purely from someone who knows how to look at Rpg Maker's code as code and isn't meant to be used by users who just copy paste scripts?
It's meant to be used by people who know what they are doing. You shouldn't expect someone who doesn't know how to code to understand it.
progression in the game, and things like how many special items you have, how far you have actually gotten, how many x you have left to x, etc. are things variables can be used for. If a player were to debug, I'm sure they aren't doing it to test outcomes and find bugs.
Well that creates a dilemma then.
How would one who doesn't know what they are doing go about fixing a bug in a game they make in Rpg Maker?
Make bug fix request threads? I find it hard to imagine that many coders would offer to help. From the few instances where I encountered the term debugging, it's often represented as one of the most tedious process in coding. (Well bug fixing in general)
It also begs the question, how stable is a RM Maker game? Both using the default sets as well as when copy pasting the scripts. Seems like a catch 22. A game maker is supposed to allow people who don't know how to code to make a game but you don't know if the actual game maker has any lingering bugs or which common settings have a tendency to induce bugs except for the most stated issues like lags.
I know if the engine was really this buggy, of course no one would use it but I also don't know how many of the newbie rpg maker game devs have support especially in the beginning and how many of those people made the type of rpgs that needed that type of support.
How would one who doesn't know what they are doing go about fixing a bug in a game they make in Rpg Maker?
Make bug fix request threads? I find it hard to imagine that many coders would offer to help. From the few instances where I encountered the term debugging, it's often represented as one of the most tedious process in coding. (Well bug fixing in general)
It also begs the question, how stable is a RM Maker game? Both using the default sets as well as when copy pasting the scripts. Seems like a catch 22. A game maker is supposed to allow people who don't know how to code to make a game but you don't know if the actual game maker has any lingering bugs or which common settings have a tendency to induce bugs except for the most stated issues like lags.
I know if the engine was really this buggy, of course no one would use it but I also don't know how many of the newbie rpg maker game devs have support especially in the beginning and how many of those people made the type of rpgs that needed that type of support.
author=Snodgrass
Yep. That actually makes sense but from the sound of it, it seems like it would demand some manual in itself to debug the code and some knowledge of how turning an on or off switch would actually matter. (i.e. narrowing down a particular event as being the one causing the bug in real time)
Since I don't have a full made game yet, I can't even tell what I would get from RM's debug mode.
Any thread that has this list of commonly used commands as well as common bug fixes for RM's debug mode? (I haven't done a web search yet. I'm also worried that from the way the help file phrases it, it sounds like I have to learn almost everything about Ruby before I would even get somewhere but I haven't read anything about RGSS yet either.)
Edit: Maybe turning switches on and off isn't the best example either. From the way variables sound, it sounds like I have to have some idea why changing the range in the variables would actually matter and what common ranges to replace a current variable with.
Well debug mode, in Rm terms, is for the person who made the game. Not really for anyone else (although as you linked, there exist ways of making the final .exe of the game playable in debug mode, for whatever reason - possibly to hand out to beta testers so they can avoid getting stuck if they encounter a gamebreaker and can be given instructions on how to get around the broken parts by using debug-mode-only functions so they don't have to wait for a fix to be made in order to keep testing). If somebody makes a variable or switch in their project to handle "x thing" then of course they're going to know what that variable does or what effect changing the values will have, because they purpose-made it.
Yes but under that scenario I'd assume there would be no major need to change a variable or switch if it's working currently. That and you can also do it the long way via the actual project file.
Edit: ...or am I missing something here?
I would assume the phrasing debug involves either finding or removing/fixing/disabling bugs.
I don't see how I could understand much less fix a bug simply because I know which event/switch/variable toggles it. I could disable it but then that would be no different from deleting an event. Especially if it's a bug that comes not from something advanced but just basic event gui creation.
Edit: ...or am I missing something here?
I would assume the phrasing debug involves either finding or removing/fixing/disabling bugs.
I don't see how I could understand much less fix a bug simply because I know which event/switch/variable toggles it. I could disable it but then that would be no different from deleting an event. Especially if it's a bug that comes not from something advanced but just basic event gui creation.
author=Snodgrass
Yes but under that scenario I'd assume there would be no major need to change a variable or switch if it's working currently. That and you can also do it the long way via the actual project file.
Changing the value held in a variable =/= changing the variable.
Say I have a door that only opens when I have 3 keys.
I set variable "door" to 0
Then I tell RM to +1 to variable "door" every time the player picks up a key.
In debug mode I could just go to "variables" set "door" to "3" and the door would open without me needing to waste my time going around picking up keys and now I know the door works as it's meant to.
Crappy example but... whatever.
Just mentally rename "debug mode" to "test play mode" and this will all probably make a lot more sense.
So...just to make sure I understand you correctly, debug mode = test play mode and test play mode here would be something like game dev speed running towards each event to verify they all work correctly without actually playing the game. Would that be correct?
That is to say you're only technically considered as finding bugs not because you are searching for them but you just want to make a quick scan that every event is doing a process that you intended it to.
Mind you I'm making this definition of test play longer than it needs to be because I don't really understand how tweaking the requirements would mean knowing what the door is meant to do. My idea of actually quickly scanning for bugs is to play the game and I was hoping I would eventually stumble on a tutorial that explains how to skip to an event but as of this writing, I had assumed you need to play the game exactly as it was made as to even verify the stability of the game (and you had to play over and over from the beginning). I have even encountered some other games where it's generally not advised to enable debug mode because it might be the one causing the actual bugs.
Edit: I nearly forgot: if this is actually the case then what term/process/keyword represents actual bug finding/bug fixing if not for debugging? Especially in an easier interface that would help a newbie like some form of "mode"? Nothing?
That is to say you're only technically considered as finding bugs not because you are searching for them but you just want to make a quick scan that every event is doing a process that you intended it to.
Mind you I'm making this definition of test play longer than it needs to be because I don't really understand how tweaking the requirements would mean knowing what the door is meant to do. My idea of actually quickly scanning for bugs is to play the game and I was hoping I would eventually stumble on a tutorial that explains how to skip to an event but as of this writing, I had assumed you need to play the game exactly as it was made as to even verify the stability of the game (and you had to play over and over from the beginning). I have even encountered some other games where it's generally not advised to enable debug mode because it might be the one causing the actual bugs.
Edit: I nearly forgot: if this is actually the case then what term/process/keyword represents actual bug finding/bug fixing if not for debugging? Especially in an easier interface that would help a newbie like some form of "mode"? Nothing?
