SNODGRASS'S PROFILE

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?

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.

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.

I should have clarified.

I referenced the ultimate items because those are the most common designs I've encountered but trademark items can be just as bad. (Plot-wise not gameplay-wise)

For example in your scenario, you explained the justification of gaining the item but you didn't explain the justification of switching from that item.

Let's say a player does get that exclusive item but then later in the game, the item's power just loses out against a generic item (this is why people tend to make ultimate weapons as the rewards) then the question for someone who's immersion is just as important as gameplay is whether they can make the bard keep using this item or they will be forced to grind like crazy just to maintain some semblance that the soothing memory is still valuable to that bard.

This isn't always logical or rational either. Sometimes players may even want a modified ending for keeping those items and, design-wise, now you have a lot of extra conditional events to add on top of the time travel.

Again this is only if you really want to deliver the design. Not many players would demand or overthink these things through. It's just as far as ideas and narratives, that's one of the pitfalls that lead to a poorer story. Doesn't mean bad, just poorer or executed greatly...the more apt term would be less memorable. You really have to have experienced comparable great scenes though to even get to this type of criticism and many players simply don't have that expectation or standard but still, it is a notable enough warning methinks.

I think the first paragraph is definitely interesting. I haven't encountered anything exactly like it. Would definitely be curious how you pull it off especially with time travel.

I think for the second paragraph, it's still rare but not as original, so for the 2nd paragraph I think my idea would be to just be careful into turning the side quests into necessities.

Sometimes sidequests harbor too powerful of items (like the most powerful item a class can get) that it destroys the logic of things especially time travel where instead of players taking that optional route for 1 or 2 characters, they totally forego the plot just so they can complete the scenes. You may even have to shift the path from the plot into those items if you really want them to be seriously treated as sidequests like if you want them to gain an item in the end, instead of choosing a branch, the item is the branch and upon gaining the item...only then do they need to complete the quest to keep the item. That way the player has a more plot justified reason from breaking off on the path.

This isn't to say you can't do it in a more traditional side quest - reward manner (it certainly hasn't stopped time travel concepts from being ranked lower in popularity) but many time travel plots tend to destroy/devalue the actual time travel because of delays mainly because the hook is that, even without an actual timer, time travel rely on the suspense that you have to keep doing the next thing so if a flashback is too long or if a time travel is delayed simply because a powerful character chooses to get his favorite items...many of the immersion gets broken.

I do emphasize that this is only important if you actually insist on valuing the time travel aspect. This is one of those designs that many gamers especially JRPG gamers tend to excuse even praise because it means lengthier games. At the same time, this is also why many JRPG flashbacks can't execute the smoothness of flashbacks like those done in Kensai: Ronin of Kyoto and Max Payne or the suspense found in shows like the early seasons of Sliders (alternate dimension show but it did include a time travel/alternate dimension episode).