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)
[RMVX ACE] VARIABLE RNG SYSTEM PROTOTYPE?
Posts
Pages:
1
bulldozerman185
107
bulldozerman185
View playlists
CloseI've been doing some experiments with Common Events while trying to perfect a true "RNG" generator for in-game events, and I wanted your guys' thoughts on this.
What's supposed to happen is when the player selects an option during one of the many in-game events, the game uses a variable that's constantly adding up from 0 to 100 to determine what happens ( either something good or bad ). And being 0 to 100, I can set up as many as 100 different outcomes for that event through very clever use of Conditional Branches that are checking for where the RNG counter is sitting.
Here's one example:
[IF "RNG" IS 25 OR LESS:
Do outcome A
ELSE:
[IF "RNG" IS 50 OR LESS:
Do outcome B
ELSE:
[IF "RNG" IS 75 OR LESS:
Do outcome C
ELSE:
[IF "RNG" IS 100 OR LESS:
Do outcome D
It works because the "RNG" count is never supposed to go over 100, when it hits 101, it resets back to 0, and begins it's climb to 100 again. This makes it nearly impossible to guess what's going to happen when you press that confirm button.
I tried using a constantly active Common Event that's set to parallel process to do this, and at first it worked okay, after setting it up so it resets to 0 everytime it went over 100 using a second common event, but then I realized that when a text bubble is on the screen, the game forgets the other active common event that's supposed to reset the RNG counter back to 0!
I then moved the trigger for resetting the RNG counter to 0 into the main common event ( the one that's making the counter go up ), and set it to automatically reset the counter to 0 if it exceeds 99. It's working pretty well now, although I'm going to continue to beta test this system to ensure it works like I need it too ( resetting the RNG counter back to 0 despite what's on screen ).
No complicated scripting required, just a simple common event that's set to "Parallel Process" and does it's thing when a switch is activated. This also means that it's possible to turn this switch off and stop the RNG counter altogether, making it much easier to beta test every event and outcome before the game is released. The way I have it set up, the RNG counter begins ticking after the player starts a new game and has entered their name, which triggers a switch to turn on. After that, the RNG counter is constantly running in the background 24/7 like a hamster in a hamster wheel. Except it NEVER, EVER stops in-game unless I program something in to turn the switch off.
As you can see in the example image I have here (My apologies if it doesn't show up, the link to it is directly below it if it doesn't):
(https://ibb.co/LRnHqzZ)
It's set up so that a label tells the game to keep looping this event, thus keeping the number moving. If it didn't do this, the counter would get to "1" and freeze. It's also set up so that there's a 5 frame delay between looping the event to stop the number from moving too fast ( which might cause lag on weaker systems ).
Would you guys say this is a reliable way to design different outcomes to in-game events based on random chance? Is there an easy to use script that can do the job better? Let me know how this system turns out for you.
What's supposed to happen is when the player selects an option during one of the many in-game events, the game uses a variable that's constantly adding up from 0 to 100 to determine what happens ( either something good or bad ). And being 0 to 100, I can set up as many as 100 different outcomes for that event through very clever use of Conditional Branches that are checking for where the RNG counter is sitting.
Here's one example:
[IF "RNG" IS 25 OR LESS:
Do outcome A
ELSE:
[IF "RNG" IS 50 OR LESS:
Do outcome B
ELSE:
[IF "RNG" IS 75 OR LESS:
Do outcome C
ELSE:
[IF "RNG" IS 100 OR LESS:
Do outcome D
It works because the "RNG" count is never supposed to go over 100, when it hits 101, it resets back to 0, and begins it's climb to 100 again. This makes it nearly impossible to guess what's going to happen when you press that confirm button.
I tried using a constantly active Common Event that's set to parallel process to do this, and at first it worked okay, after setting it up so it resets to 0 everytime it went over 100 using a second common event, but then I realized that when a text bubble is on the screen, the game forgets the other active common event that's supposed to reset the RNG counter back to 0!
I then moved the trigger for resetting the RNG counter to 0 into the main common event ( the one that's making the counter go up ), and set it to automatically reset the counter to 0 if it exceeds 99. It's working pretty well now, although I'm going to continue to beta test this system to ensure it works like I need it too ( resetting the RNG counter back to 0 despite what's on screen ).
No complicated scripting required, just a simple common event that's set to "Parallel Process" and does it's thing when a switch is activated. This also means that it's possible to turn this switch off and stop the RNG counter altogether, making it much easier to beta test every event and outcome before the game is released. The way I have it set up, the RNG counter begins ticking after the player starts a new game and has entered their name, which triggers a switch to turn on. After that, the RNG counter is constantly running in the background 24/7 like a hamster in a hamster wheel. Except it NEVER, EVER stops in-game unless I program something in to turn the switch off.
As you can see in the example image I have here (My apologies if it doesn't show up, the link to it is directly below it if it doesn't):
(https://ibb.co/LRnHqzZ)
It's set up so that a label tells the game to keep looping this event, thus keeping the number moving. If it didn't do this, the counter would get to "1" and freeze. It's also set up so that there's a 5 frame delay between looping the event to stop the number from moving too fast ( which might cause lag on weaker systems ).
Would you guys say this is a reliable way to design different outcomes to in-game events based on random chance? Is there an easy to use script that can do the job better? Let me know how this system turns out for you.
You seem to be grabbing the page in it's entirely, rather than just the image. The correct reference would bring up...
...this.
Not that I 100% understand what the advantage of doing it this way than using the built-in RNG of Control Variables, as Darken is pointing out. Like, would it not be more appropriate to set the "RNG Factor" to a number between 0 and 100 each time the common event is called, rather than what you're doing? Like, there is absolutely no reason why this should be a Parallel Process, and be called only when it needs to be.
...this.
Not that I 100% understand what the advantage of doing it this way than using the built-in RNG of Control Variables, as Darken is pointing out. Like, would it not be more appropriate to set the "RNG Factor" to a number between 0 and 100 each time the common event is called, rather than what you're doing? Like, there is absolutely no reason why this should be a Parallel Process, and be called only when it needs to be.
bulldozerman185
107
author=Marrend
You seem to be grabbing the page in it's entirely, rather than just the image. The correct reference would bring up...
...this.
Not that I 100% understand what the advantage of doing it this way than using the built-in RNG of Control Variables, as Darken is pointing out. Like, would it not be more appropriate to set the "RNG Factor" to a number between 0 and 100 each time the common event is called, rather than what you're doing? Like, there is absolutely no reason why this should be a Parallel Process, and be called only when it needs to be.
Funny thing, I actually tried to do that first, and it kind of... backfired. HARSHLY. Plus if I do it this way, I won't have to CONSTANTLY keep putting in the trigger to set the number for the RNG counter EVERY SINGLE TIME something that uses it comes up. And there's a lot of stuff that uses that variable. Like, 3, 4, maybe 5 things going at once. Having to keep all that organized is annoying enough without having to constantly keep putting in the trigger for the RNG counter EVERY SINGLE TIME something that uses it comes up! Letting a parallel process do it for me in the background makes my job a lot easier.
Also, unless I misunderstood something, doing it the way that Darken mentioned means there's no way for me to stop the counter from bouncing around WITHOUT setting a switch to turn it off at EVERY SINGLE INSTANCE WHERE IT'S CALLED UP, which can make it almost impossible to test the specific event I want to test. Bear in mind: There's going to be about 100 different events that can occur here, and almost all of them have differing outcomes depending on where the RNG count is sitting. Being unable to stop it from changing to a different number after I manually set it to the number I need it to be for the event to trigger will make it very difficult to test each event, and each outcome, as they're added. With the parallel process going, all I need to do it hit F9 and turn the very first switch "off" to stop the counter. I can then manually set it to whatever number I need.
I will definitely keep the method you guys mentioned in mind, but sadly, that method just doesn't work for the kind of game I'm going for here, and even if it did, it's just going to cause beta testing to be more of a pain in the neck than it already is. As the old saying goes: "IF IT AIN'T BROKE, DON'T FIX IT."
Strictly speaking, if you don't want a variable over 100, and want to keep incrementing the variable, I think you might be able do something like...
..this, and skip the check for being over 100. The modulus operator will divide the contents of $game_variables[38] by 101, and return the remainder of that division. Which should (unless I'm totally of-base, here) be a number between 0 and 100.
As for the parallel process method versus calling every time an event needs an RNG, let me think out loud for a second.
So, there can be multiple events running, possibly running simultaneously, that need to know the value of a certain variable for whatever reason. Is it simpler to define the value of that number per event, or through a parallel process?
The main thing, it seems, is for the variable these events are checking against to be the same across all checks that care for that variable at the moment. Funnily enough, both methods seem to be using a game-switch to turn on/off the RNG process. In the case of the parallel process, it stops the counter from incrementing. In the case of the non-parallel process, it would probably be to re-randomize the value contained in the variable! Like, I'm specifically thinking about there being a switch would activate/deactivate on entering a location, or something similar like that? The extra-funny thing is that if it triggers on entering a location, or whatever, it... might be better off being a Common Event!?
$game_variables[38] += 1 $game_variables[38] = $game_variables[38] % 101
..this, and skip the check for being over 100. The modulus operator will divide the contents of $game_variables[38] by 101, and return the remainder of that division. Which should (unless I'm totally of-base, here) be a number between 0 and 100.
As for the parallel process method versus calling every time an event needs an RNG, let me think out loud for a second.
So, there can be multiple events running, possibly running simultaneously, that need to know the value of a certain variable for whatever reason. Is it simpler to define the value of that number per event, or through a parallel process?
The main thing, it seems, is for the variable these events are checking against to be the same across all checks that care for that variable at the moment. Funnily enough, both methods seem to be using a game-switch to turn on/off the RNG process. In the case of the parallel process, it stops the counter from incrementing. In the case of the non-parallel process, it would probably be to re-randomize the value contained in the variable! Like, I'm specifically thinking about there being a switch would activate/deactivate on entering a location, or something similar like that? The extra-funny thing is that if it triggers on entering a location, or whatever, it... might be better off being a Common Event!?
Darken
3952
@bulldozerman185: I don't know what you're trying to accomplish other than you want a number between 1-100. The topic sounded like it was a general RNG thing and not a specific scenario which you seem to be describing which I don't really understand because there's a lot of details missing.
bulldozerman185
107
Well, nevermind me. A friend of mine managed to fix a problem I was having with the other method Darken mentioned and get everything working. I guess I can switch over to that system now.
However... I will keep this one I developed in the back of my mind. Might come in handy later down the road for another project I'm working on.
Anywho, thanks for your thoughts, everybody.
However... I will keep this one I developed in the back of my mind. Might come in handy later down the road for another project I'm working on.
Anywho, thanks for your thoughts, everybody.
Pages:
1
