Full Games List
Featured Games
New Games
Reviews
Media
Images
Blogs
Game Updates
Images Feedback Summary
Game Design Highlights
Scripts
Utilities / Plugins
Resources
Engines
Engine Bulletins
What is Makerscore?
Past Events
Achievements
Misaos
Forums
Chat
New to RMN?
Full Store List
RMN Music Pack (free)
Profile
Locker
Play ListsTHENECROMANCER'S PROFILE
TheNecromancer
3160
Close
RMN sucks
Search
Filter
All
Game Pages
RPG maker 3 (for PS2) HELP!
I'm not too familiar with that version but an idea of how to get a random number popped into my head. Put invisible/unseen code throughout the dungeon that increases a variable by different amounts, and put them in places that will trigger based on how the player is moving around.
So for example you could have invisible 'on hero touch' events in front of doors, so every time the player enters or leave that room the variable changes. Put some of those events in the middle of rooms, so if by chance the player touches them the variable changes. Add it to existing events, so when the player opens a normal chest it increases that variable. So if they didn't open that chest before the random chest, the variable would be different compared to if they did open that chest first.
Therefore, based on the actions taken by the player, in whatever random order they happen to trigger them, you will end up with a different(random) variable each time the game is played. You probably want to increase that variable by small numbers, or you could take that variable and divide it by something to make it smaller, and use that remainder in branches to give different items. Does it have Modulus? Use that on the variable and the remainder will be different each time.
Or, maybe a simpler idea, have a background process that increases a variable by 1 every X seconds. When it reaches the limit of possible choices in that chest, have the variable set to 0 and it starts over again. So when the player opens that chest, the variable could be anything. Which will be different depending on the timing of opening that chest.
So for example you could have invisible 'on hero touch' events in front of doors, so every time the player enters or leave that room the variable changes. Put some of those events in the middle of rooms, so if by chance the player touches them the variable changes. Add it to existing events, so when the player opens a normal chest it increases that variable. So if they didn't open that chest before the random chest, the variable would be different compared to if they did open that chest first.
Therefore, based on the actions taken by the player, in whatever random order they happen to trigger them, you will end up with a different(random) variable each time the game is played. You probably want to increase that variable by small numbers, or you could take that variable and divide it by something to make it smaller, and use that remainder in branches to give different items. Does it have Modulus? Use that on the variable and the remainder will be different each time.
Or, maybe a simpler idea, have a background process that increases a variable by 1 every X seconds. When it reaches the limit of possible choices in that chest, have the variable set to 0 and it starts over again. So when the player opens that chest, the variable could be anything. Which will be different depending on the timing of opening that chest.
End of the moth log-out?
End of the moth log-out?
Should I retire monthly website stats?
author=pianotm
Well, if you're going to stop compiling stats, then you're going to need to give members a way to see them for themselves. Otherwise, much of the purpose behind makerscore and achievements will be gone. We won't be able to see who has the most reviews, or who has the most articles, or who has the most resources. Being able to see these things is an unconscious motivator to increase those numbers. There are people like Kloe, Gourd, Marrend, and Infection_Files that follow post count. Without that motivation, I'm worried that site participation will drop significantly. There isn't actually a benefit to try and acquire makerscore or to increase reviews or articles or to supply scripts or assets beyond that false confirmation that the stats provide. Without them, a significant chunk of active members may no longer see the point in contributing. If you don't want to compile stats anymore, then you should add a page that automatically tracks them. In fact, it would probably be better for a lot of people.
I don't know about this logic. Many sites don't have stats yet people still frequent them. In the early days of RMN I don't recall constant stats, yet people still did things. Most people create for their own enjoyment or participating in events. The phantom motivation you speak of is unlikely to cause people to start leaving en masse. I would say that the way you describe it only applies to very few people.
MS is an ever present number so the motivation is always there, and has always been there. I'm not sure where you are getting such an idea on the 'purpose' behind it. It doesn't matter how one gets their ms, just that they have it. And if a person is so obsessed with monitoring how many reviews or whatever someone has, that information is available by looking at their profile. I like seeing stats and the leaderboard aspect of it. So I'm not against stats, but it's not like it's required for the site to function or people to produce content. Stats are a privilege, not a right.
It sounds like an excuse to me. Like a person who has no real motivation themselves and relies on external, superficial stats to make things. Perhaps that person should find a better suited hobby. I hear scrimshaw is pretty happening.
Should I retire monthly website stats?
Super Dr. Toadly World
What would be the downside to extending this event until there are enough levels to fulfill your original intent?
Super Dr. Toadly World
How to make a demo
author=CaptainCrimson
God damn, so many people are so passionate about demos...for no good reason.
You don't get to decide what other people are passionate about or decide if their passion is legitimate.
Why are so many people taking this as personal attack?
If you actually read the comments and still don't get it, then there is nothing left to discuss.
Push / Pull objects (no-script method)
Oh, of course. I'm remembering now what I did to solve that problem and it's only slightly different.
Instead of actually moving the events, then checking the results, just simulate it.
So you do all the same stuff, except instead of doing a move route event, just change the variables.
Get hero x,y as normal. In every one of my games I have a set of x,y for the hero that is always updated and never changed. A control or baseline value, because if other systems use hero x,y and we start to mess with them, you'll get bugs(just a side note).
Then use a second set of variables for x,y and set them to be equal to the x,y from above. Then change the second set to match the button pressed.
This would be applied to the second set of x,y:
So now you have a set of coordinates equal to where the hero will be after pressing a direction key.
Hmm, of course you would need to use some method of checking if a tile is passable or not. Terrain ID or Region I guess, but based on your code you know how to do that. So go into the tileset and apply a Terrain ID(or Region) for impassable tiles, for this example we'll use 10.
Then use the command to check for Terrain ID of a location, plug in the second set of x,y vars, and it will check if the space you intend to move is passable(terrain NOT EQUAL to 10). If yes, then proceed with move events because you know the way is clear. If not, end event processing and nothing will move.
This would only work for moving backwards(and sideways I suppose), because when moving forward the hero will always have a passable tile in front. If you can combine this method with what you have now and it works, then great. If not, you would need to apply this same idea to the object being moved. Copy it's coordinates, check in front by adjusting variable, and yadda yadda yadda.
Try that.
Heh, this is what I miss about using RPG Maker. Finding solutions to problems like this and ending up with a functional new gameplay element. Ah, the good old days.
Instead of actually moving the events, then checking the results, just simulate it.
So you do all the same stuff, except instead of doing a move route event, just change the variables.
Get hero x,y as normal. In every one of my games I have a set of x,y for the hero that is always updated and never changed. A control or baseline value, because if other systems use hero x,y and we start to mess with them, you'll get bugs(just a side note).
Then use a second set of variables for x,y and set them to be equal to the x,y from above. Then change the second set to match the button pressed.
This would be applied to the second set of x,y:
if press UP
var Y -1
if press DOWN
var Y +1
if press LEFT
var X -1
if press RIGHT
var X +1
So now you have a set of coordinates equal to where the hero will be after pressing a direction key.
Hmm, of course you would need to use some method of checking if a tile is passable or not. Terrain ID or Region I guess, but based on your code you know how to do that. So go into the tileset and apply a Terrain ID(or Region) for impassable tiles, for this example we'll use 10.
Then use the command to check for Terrain ID of a location, plug in the second set of x,y vars, and it will check if the space you intend to move is passable(terrain NOT EQUAL to 10). If yes, then proceed with move events because you know the way is clear. If not, end event processing and nothing will move.
This would only work for moving backwards(and sideways I suppose), because when moving forward the hero will always have a passable tile in front. If you can combine this method with what you have now and it works, then great. If not, you would need to apply this same idea to the object being moved. Copy it's coordinates, check in front by adjusting variable, and yadda yadda yadda.
Try that.
Heh, this is what I miss about using RPG Maker. Finding solutions to problems like this and ending up with a functional new gameplay element. Ah, the good old days.
Games - Tester
Games - Other
