Scrogdog

Well, the story is more or less that my screen name became an 'in joke' among friends. When I was much younger, I had a group of friends at work that was rather large and very close. Especially with two who happened to be women. We hung out a lot. That was it though, no romance or anything physical. But, of course, soon enough the rumor mill began with all sorts of false stories and pretty tall tales. lol Greatly concerned about the honor of my two dear friends, I went to them and let them know what was happening. Well, they practically fell over themselves laughing. In fact, they thought is was so riotous that the actually played it up because they knew it embarrassed me! So, of course, this only added to the false 'legend'. So, one night we were all out at some bar, and I happened to start talking to this girl who wasn't part of the group. She gets up to go the the rest room and another friend, Al, came over to start with his usual prankster stuff. He says, how can you hit on this girl when Sandi and Kathy are SITTING RIGHT THERE! You are just a regular Scrogdog! Practically the whole bar broke out in laughter, and the rest is history!

I usually go top down. So, the world and background come first. Races, political structures, history and lore. Most of these things will never make it in to the game directly, but it helps me achieve consistency and also helps a great deal with reasons for things like side quests. Once the backdrop is created, then I start on character bios. To me, that's the best way to sort of get to know the folks you are writing about. It also gives the player an anchor and an understanding of why a particular flaw or foil may make the character act in a certain way. Frankly, I don't know my own characters as well as I do my favorite villains and heroes in my favorite stories. It is only a beginning though, so part of that might also describe how the character changes and evolves through the story and the impetus for that development. It also helps you write so that not all of your characters seem the same. You always know that so-and-so has a racial hatred so he is going to react differently towards that group than your other characters do. Also, various traits are important to help define your character. Is he or she always dressed to the nines, or slovenly? How about social status? Did the character struggle and grow up poor, or is he or she nobility? Are they locals or travellers from afar? For me, the more the world has been 'set up' the more ideas you get for interesting plot twists that are actually meaningful and have a reason to occur.

The only thing that I raised an eyebrow about was direction fix. Why is that on? Not sure how that might affect things, but perhaps the front of the event must do the touching or something like that?

Yes. The way I did this was to create an item that is actually a weapon in the database. For example, in my Star Trekky game you can only use the scanning skill if you have the scanner equipped, but the scanner is not an item, it is a weapon, even though it doesn't do damage. Then you just go to the skill in your database and at the bottom make the item/weapon a 'required weapon'. However, this means that the character must equip the weapon to use the skill, not just have it in inventory. The other way to do it is to have the item call a common event in the 'effects' box. However, the item would still need to be 'used' and not just be in inventory. As for the item then 'decreasing' you mean that you want it to disappear on use? If you really don't want the item to be used, just be in inventory, then have the skill itself call a common event that checks for the item in inventory, then proceeds with the effect if the item is found and after that it is removed. If not found, show text "You don't have item X".

I presume you mean that the monster splits upon first hit by the player? Not as simple as it seems because battle processing can't be interrupted by eventing as far as I know. This might require a script to get done unless someone else has an idea. You could split it before or after, but not during battle processing. As far as I know.

The flashlight is also an event? If so, I can't think of a way to stick it to another event using eventing. Might need a script.

Use Move Route. In the top left of the Move Route box is a drop down that defaults to player. If you select the drop down, you'll also see 'this event' and then a list of event numbers in the local area. So, presumably you would be writing the event out using 'this event', unless you are controlling a cut scene with multiple elements from it's trigger point. The other event numbers are other characters and such around you. To move them, you would select their specific event number instead of 'player'. There is a lot you can do with move route. You can design a specific path like "turn left", "1 step forward", and so on. You could also have the event move randomly, or towards the player, or away from the player. You can mix and match these items in an event. Move randomly, then towards the player, for example. You can also use wait to have the event hold position, then start back up again. So, you could have a dog in your town that moves randomly, waits a few seconds, then barks by playing a SE, then moves randomly again.

Heh, no you are not bewildered, you are getting it! Though, the original demo seems a bit ham-fisted now. If anything we are both over thinking this. This is so elegantly simple that we almost can't believe it! In fact, now that I think of it there is really no need for common events since our conditional simply asks a question that we already know the answer to. What region is the player in? Well, if we know that barrel 2 is surrounded by region 2 tiles, then there is really no need to test if the player is in region 3 or 1 when creating the event for barrel 2. So, this simple; if barrel 1 is in region 1 (surrounded by region 1 tiles in this case), create a single conditional for barrel 1 that tests if the player is in region 1. If yes, write the move route for barrel 1 right under it. If no, nothing. I was overthinking it a bit too based on my thinking of the original event. Common events are good so you don't need to write out the same thing over and over, but since there is only one answer to the question, that is not needed.

I can't see your examples too well, but I was hoping that you'd realize that we don't need the previous event structure at all now that we are using regions. So scrap the previous events and start from scratch. The only tiles that should have regions are the 8 tiles that surround each barrel. Same as characters and player touch just like before. Now, when the player touches the barrel, right off use conditional branches to detect which region the player is on. For example, if the player is on region 1, then call the common event that moves barrel one.

I didn't get a chance to look at the bridge again, but we can worry about that later. So, let's get you started on regions and move routes! First, have a look at this excellent tutorial about the many uses for regions; http://forums.rpgmakerweb.com/index.php?/blogs/entry/464-player-on-region-demo/ Now here's the strategy as I see it. Each barrel will be surrounded by a unique region. We'll need to modify the barrel events so that instead of them disappearing as in the demo that the movement of the barrel and the player is initiated. We'll do that with a conditional branch exactly as shown in the tutorial where it looks at a small line of script to determine what region the player is standing on. That way we know exactly which barrel to move. It would be a little messy to write out all three move routes under the conditionals. I think it would be better that the 'true' condition of the branch would call a one of three common events; each one being a specific move route for one of the three barrels and the player pushing them. For the most part, after you play with it a bit, I think that most of the buttons in move route should be fairly self explanatory. The thing to keep in mind here is that you want both the barrel and the player to move together, so that means that you don't want either event to 'wait for completion'. Simply stack one move route on top of the other. You'll notice that there is a drop down box in the top left of the move route screen that defaults to player. That means that the player will be affected by the move route you design. To move some other event, chose the event number from the drop down, in this case the event number of one of the barrels. You could also re-name the barrel events to, say, barrel1, barrel2 and barrel3 and then they will appear that way in the drop down. So, you'll be designing two move routes for each common event; one for the barrel and one for the player. Since you don't wait for completion, they will both move together. Just keep the player in the proper pushing position if you know what I mean. Again, at start consider this a learning experience so allow it to be that. Undoubtedly things will look a bit wonky at start, like if the player initiates the event from the left side of the barrel and the event has the player begin to move the barrel from the right. Don't worry about little details and perfection just yet. Just get the concept working in general we'll work out the details later. Good luck!

You're welcome! But we still have a little issue here. Did you try actually walking across the bridge? lol Doesn't work as I discovered last night (I was using the same map to test the followers issue). The first thing I did was to check the passability on the graphic and sure enough it was incorrectly set to X instead of O. Fixed that and then checked off the 'through' box on page two of the event. Still didn't work. So I laid down a normal bridge directly without events and it worked. Hmmm. I'm a bit puzzled by this. It's almost like the impassible water is overriding the through option of the event. I'll look at it again tonight as it's probably something obvious I'm missing. We'll see.

Well, I guess you could try to remove, then wait, then add in the same event. A bit awkward I'd say. Probably each jump would need a different wait time. But a script to have the followers follow the jump sounds like it would be better for your game. Unless someone else has an idea.

Ok, the only way I can see is to forget remove and gather followers. Use change party member to both add and remove because that actually removes the actors from the map. Of course, that would require an event in the landing position. How were you triggering the re-appearance of followers?

I'll look in to it tonight when I get home. My project is single avatar so I haven't done a lot with parties as yet.

Yes, it looked to me like the description of what the writer was doing was fairly complete in concept anyway. Might help to figure it out. Yeah, I'm thinking that we might have three common events each with a move route for one of the barrels and then we just call it when the barrel is identified. Something like that. Hmmm, perhaps we could use regions to detect the proper barrel along with a small snippet of code. @SECOND POST Posted 41 minutes later Here's a link to the demo. http://www.mediafire.com/download/wnml5drkw0xhub9/Test.exe