Search the Community

I am Vectra. The Master Eventor. I've gotten a request from a friend to do this. I did this for someone else a a week ago so i figured I'll make a tutorial for all who wants to know how. Here's what you need: 4 Variables 2 Conditional Branches What are the 4 variables?: X-Coord1 Y-Coord1 X-Coord2 Y-Coord2 Let's say you want to detect the distance between the player and a rock: 1 is Player and 2 is the rock. X-Coord = X coordinate Y-Coord = Y coordinate The multiplying by -1 is so that the number will be positive. In mathematics, distance cannot be a negative number. Due to you X-Coord and Y-Coord check needing to be 1, the system checks for diagonals too. You minus the rock's coordinates with the player's coordinates. If the answer is 1 or 0 then they're touching. If you want it like have it where if the rock is 5 steps away then you simply make the condition branches 5 or less instead of 1 or less. It'll look like this: This checks if it's 5 steps away horizontally and then checks vertically. Wait, but what if I want distance between two events? Then you replace player with whatever. For example, If i wanted the distance between 2 rocks then I simply replace X and Y Coord1 with another event's X and Y Coord instead. If you want to know the distance of more than 2 events then every event added needs 2 variables(X & Y Coord). SUB-TUTORIAL: DISTANCE Only difference is you scrap the Y-Coord PL check and add X-Coord and Y-Coord right before the proximity (which is now distance) check. SUB-TUTORIAL: Projectiles Description: I have left numerous comments (using the "comment" event command) to show you how to create projectiles. You will need extra switches and extra commands which will be shown and explained in the demo. You need to know the above first before proceeding to this. https://drive.google.com/open?id=0B6YgxySqsh57UnNVMHBSLUhybTQ Partial Credit goes to Retnuh If you have ANY questions plz ask.

This is a neat little idea that can make your typical boulder-pushing puzzle a little more interesting. It took me a while to figure out how to do this through events (although I'd like to learn, I currently have no ability to script), but I have it sorted now and hope it might help someone else. Hard mode: Multiple boulders and gaps. (<if this anchor doesn't work, just scroll down) Pushing a rock into a gap. First thing's first - create an event that will be the boulder, or whatever your character will be pushing. You also need an area of water or a hole or something of the sort, which the boulder can be pushed into. The gap must be one tile across, the the boulder can act a bridge when in the water. In this case, the player is pushing a boulder into the river in order to get to the island. I added a chest that can only be reached this way, for added incentive. The boulder event will eventually have several pages, but initially, just set up the first event page. The settings should look like this: 'Event Touch' means that the boulder will move when the player stands beside it and pushes a directional button. Other people may prefer setting the trigger to 'Action Button' so that the player must press the 'A' button to activate the movement. You will need to use a terrain tag to label the water tiles. Doesn't matter what number you use, but tag the water tiles you want the player to be able to push the block into. You need several variables for this. Two will store the boulder's current X and Y location on the map, two will store the X and Y location of the position the player is trying to push it to (when they walk up to it, or press 'A'), one will store the terrain tag of the new position. So, let's do some eventing! As soon as the event is triggered, we want the boulder to store its current position in the variables. We can then use conditional branches on which direction the player is facing to determine which direction the boulder is being pushed towards. With this information, we can store in variables the new position. We then get the terrain tag of the new position. If the player is just pushing the boulder over land, the boulder should just move normally as these tiles are passable. We check if the terrain tag is equal to the one you set up for the water. If so, the boulders move route includes setting it as 'Through' which means it can pass into impassable tiles (like water). Self Switch A is then turned on if the boulder has fallen into water. It's not mandatory, but I added an extra bit of eventing here so that the boulder wouldn't reset back to its original position if the player left the map. This only activates if the boulder is in the 'goal' position and the puzzle is solved. Use two conditional branches to check if the boulder's new position is equal to a designated goal location, and if so, turn on a switch. This isn't a self switch, as we need it to link to another event. More on this later - first, let's finish setting up the other event pages on this boulder. Here's what the first page looks like: Page 2 is relatively simple. Once the rock is in place, this page sees when the player is trying to cross over it. It takes note of which side the player is on. Because switch A turns on if the boulder falls into ANY water, we need to check if it is in a goal location first. Page 3 is triggered if the player touches the rock and is facing left. This page must be set to 'Autorun' and the priority 'Below Player'. This is important, because the 'Below Player' priority means that the player will walk on top of the rock, rather than appearing to walk behind or underneath it. The event autoruns and moves the player over the rock to the other side. The switch then turns off, so that if the player touches the rock again, Page 2 runs, which looks at which side the player is on and redirects to the corresponding event page. Page 4 looks exactly the same as this, but is for if the player approaches from the other side. The only difference is that the move route contains 'Move Right' and it's a different self switch. Of course, you can also make boulder bridges which are north-south. So that's it - for the most part. What about Page 5 though? Well, it's completely empty! Remember that part at the end of Page 1 where I said something about getting the boulder to stay put after it's solved? If you want to add this feature, create a second event using the same boulder graphic. Put it in the place where the boulder is 'supposed' to be when the puzzle is solved. The second event contains a copy of pages 2 to 4 of the first event, with an additional condition that the 'Solved' switch must be 'on'. This switch also removes the first event from view. Hopefully this was useful to somebody - it's the first tutorial I've written and I'm not particularly confident in my ability to explain things, hence the use of pictures. Here's a short demo of how this looks in-game. *** Hard Mode: Multiple boulders and gaps! (Uses more switches and variables, but the basic idea is the same). It's here that I must stress the importance of keeping your switches, variables and event names organised. Otherwise, you're gonna have a bad time. Depending on just how complex you want to go, here's the switches and variables you need to use: The good thing is though, that you can re-use some of these for other boulder puzzles you might wanna make in your game and it won't make any difference. Namely, you can re-use the variables in any number of puzzles. The switches must be set up individually for each puzzle though, as they recognise which puzzles have been solved and which rocks have been used, and allow the player to leave the map and the puzzle still be solved. I used 3 boulders when I was figuring this out. You can easily use more than that without it becoming more complex to set up, but you'll need the extra switches and variables. Variables Rock_X_Location - Stores X location of the boulder that the player is about to push. Rock_Y_Location - Stores Y location of the boulder that the player is about to push. Pushing_Towards_X - Stores X location that the boulder is currently being pushed to by the player. Pushing_Towards_Y - Stores Y location that the boulder is currently being pushed to by the player. Terrain_Tag - Stores terrain tag of the location it is being pushed to. Goal_X_Location - X location of first possible solution. Goal_Y_Location - Y location of first possible solution. Goal_2X_Location - - X location of second possible solution. Goal_2Y_Location - Y location of second possible solution. Goal_3X_Location- X location of third possible solution. Goal_3Y_Location - Y location of third possible solution. Switches Boulder1_Solved - Switches on if any boulder has been pushed into goal location 1. Boulder2_Solved - Switches on if any boulder has been pushed into goal location 2. Boulder3_Solved - Switches on if any boulder has been pushed into goal location 3. Boulder1_Used - Switches on if boulder 1 has been pushed into any goal location Boulder2_Used - Switches on if boulder 2 has been pushed into any goal location Boulder3_Used - Switches on if boulder 3 has been pushed into any goal location To give this a sense of meaning, here's the cave where I'm setting up this puzzle: You can see the three boulders. I've named them 'Boulder1', 'Boulder2', 'Boulder3' for convenience. The three 'empty' events are locations where the boulders can be pushed into to enable our hero to cross the water. These events are named 'Solved1', 'Solved2', 'Solved3'. You might notice that it's possible for either of the two boulders near where the hero is standing to be used for either of two goal locations. I have considered this. Let's look at the event pages. This is the first page of Boulder1. If you read the basic part of my tutorial first, you'll notice that the general structure is pretty similar. We check the rock's current position, which way the player is pushing it, it's new position, and the terrain tag of the new position. If the terrain tag is the one for water, it makes a 'splash' and falls in. Then comes the extra bit.... It gets the data for the variables 'Goal_X_Location', 'Goal_Y_Location' etc. from the positions of the events which are at the goal locations. We then need conditional branches to check whether the rock has been pushed into ANY of the possible goals in the area. This is done by using branches of the form: Conditional branch: Pushing_Towards_X = Goal_X_Location Pushing_Towards_Y = Goal_Y_Location Branch End Branch End Repeat this for each goal location. Within these conditional branches, we need to flick on the switches that indicate which boulder we have pushed into the water, and at which goal location. This is why I numbered my boulder events and goal events. If it's pushed into water (as recognised by the terrain tag), self switch A turns on, which is just a blank page. This is just so that the boulder is not able to move if it's in the water (eg. if the player stood at the waters edge and pushed). The reason I didn't use the A switch to allow the player to cross the boulder is because depending on where the boulder is placed, it might form either an East-West bridge or a North-South bridge. As such, this movement is tied to the 'goal' events which appear when the rock is moved into place. ((I used 'empty' comments for the sole purpose of spacing this out into sections so it looks neater and was easier for me to work on)) This event above is Boulder1. The other boulders look exactly the same, except that the switch turned on when they fall into place is 'Boulder2_Used' or 'Boulder3_Used', etc. etc. for however many boulders you have. ((My switches for this include the area name, in case I later want to use a similar puzzle on a different dungeon)) Okay, this has probably been slightly confusing. I'm trying hard to keep it as organised as I can and sometimes I have to look back and think things through again. Hopefully looking at the other pages of the events will help all these switches and variables make more sense. This is pages 2 and 3 of the boulder events: Page 2 is empty and is triggered whenever the boulder falls into water. It's just there so that it stays put and acts as an unmovable object. Page 3 is triggered when this particular boulder has been pushed into a goal location. It makes the original boulder event invisible. Now let's finally get to these 'goal' events... Page 1 is blank and has no image. Because having a crossing before a boulder has been pushed here would defeat the purpose. So, page 2... Looks rather familiar, huh? It's the same eventing as you may remember from the basic tutorial here, which triggers a self-switch when the player touches it and allows them to cross in a certain direction. This activates if the switch 'Boulder1_Solved' is on. Not to be confused with 'Boulder1_Used'. The 'solved' switches correspond to the goal or solution locations, and can be triggered by any boulder if it is pushed into the goal location. Then as you may guess, the B and C self-switch pages are exactly the same as before. .... done. Finally. Let's see it in action!(unfortunately without the pretty mapping this time)

So yeah, Maki here! How's your day? I hope it's great! If it isn't, then I wish for a better day, and I hope this writing can help lift up your mood! Somehow. Anyway... "Trapper Classes" have been a niche element in quite a number of games, from traditional RPGs, tactical RPGs, RTSs, MMOs, and even MOBAs. Some are more practical than the others, Trappers and their annoying arsenal of traps are usually associated with a more traditional RPG Class, the Ranger class. Ranger is one of those class that have much difference between its iterations in many RPGs. In Final Fantasy Tactics A2, Rangers can wield daggers and bows, has the ability to set traps and can "mirror" items to use against the enemies (Phoenix Dawn that kills, Remedy that inflicts status effect, etc.); on the other hand, Rangers in Phantasy Star Online 2 can wield Rifles and Grenade Launchers, has the ability to set traps and can load special bullets to their Rifles (Weak Bullet to cripple enemies, Bind Bullet to Stun enemies, etc.). Back to Trapper! This tutorial aims to help RPG Maker users who wants to emulate Traps in their RPGs. And while the title mainly says "VX Ace" and this tutorial would use that engine, I believe this can be done in "close neighbor" RPG Makers such as VX and MV. Well, so we're gonna make traps, right? But first, we need to think what kind of trap we're gonna make, and how the "trap" mechanic is handled in our games... In this tutorial, we're gonna make this trap: Mine Trap >Explodes upon contact, dealing damage to all enemies. >If more Mine Traps are laid, the damage would be greater when they are triggered. >Once the trap(s) are triggered, all of them would explode. >The player would have a skill that could force-donate the Mine Traps. The Trap Mechanic: >Traps are treated as Items. >The player has the ability to see the amount of Traps they have laid. >The traps trigger depending on the enemy troop's "intelligence"; the smarter the enemies are, the harder it is for the traps to trigger. Yosh, let's begin the main part! For this, we're gonna need these stuff: 1. Variable to count the amount of traps you have laid, let's call it "Mine Traps". 2. Variable to count the enemies' intelligence, let's name, let's call it "Troop Stupidity". 3. Variables to do the trigger calculations, let's call them "Trigger RNG" and "Trigger Modifier". 4. The Trap Item, properly call it "Mine Trap". 5. The "execution skill" for the Item, let's call it "Mine Trap Skill". 6. A Common Event for the Trap, name it "Mine Trap". That's all for the preparation to establish our Trap System, the "counting" and "force-donate" skills are to be prepared later. Let's focus on the core stuff now. First, edit the Trap Item. Make it a consumable and should only be usable during battle. Set target to none, and decide the price if you're planning for it to be trade-able. Finally, link it to the Mine Trap Common Event. Now, we're gonna make the execution Skill. Let's make it so that our skill deal exact damage, that gets multiplied by the amount of "Mine Traps" variable. Next, edit the Common Event. Make it so that it increases the Variable "Mine Traps" by 1. You can also add a piece of text dialogue as to mark the event. Finally, link the Item and the Common Event with the Effects options in the item setting. Now, we are about halfway done with the system! What's left is making in function in battles, so let's create some enemies! In this tutorial, we're gonna make 2 kinds of enemies: Zombie (dumb) and Mage (smart). The enemy settings are up to you. After that, make separate troops for each two. Now for the Troop Event. We're gonna do the Zombies first. In the Troop Event page, have it set at Turn 0, Span: Battle. This event would setup the stupidity of the Troop. Make it by setting the Variable "Enemy Stupidity" to a desired amount. Since we're gonna do a percentage-based system, make sure that the "Stupidity" value stands between 0 (Smartest) and 100 (Dumbest). For the Zombies *2 Troop, let's do a 75 Stupidity. Oh, and remember that this is Troop stupidity, not Individual. It's pretty flexible. You can decide various values depending on the troop members. Also, it is recommended to put in "character comment" in this event, to ease the player in knowing how intelligent the things they are about to fight. Next, create a new Event Page in the Zombie troop. This is where the rather difficult part starts, so let me show a picture for clarity. Using the picture above, I'll explain how the event works. The event takes place during each turn's end. First, the event would "refresh" the RNG and Modifier from the previous turn's. Next, the event would check if there's already a Mine Trap(s) laid on the field. If true, the event would proceed to calculate the trigger priority, with the Trigger Modifier as its central. Here's how it counts: [Amount of Mines + Enemy Stupidity = Trigger Modifier] For example, you are fighting a Zombie troop with 75 Stupidity and have laid 3 Mines. The calculation would become: 3 + 75 = 78% trigger chance. Fascinating, isn't it? Then, the RNG comes into action. It would take a number between 0 to 100 at random. If the number is lower than the Modifier, then the trap triggers. This means the more mines lying around, and the stupider the enemies are, the easier the traps would trigger. The trap triggers by-- Of course, having our Ranger use the Skill. After that, clear the "Mine Traps" variable because they all explode! (Remember that we set the skill to deal damage equal to the amount of mines?) That's all for the battle event. Move on to the next troop, the Mage. Set their intelligence to be higher, and copy the second event page of the Zombies troop to theirs. The system can actually work fine this way, but it would be easier to manage if you use scripts that enables the user to center all battle-related events in a single troop. Now, it's time for the second half of the tutorial! This parts would be about creating "trap counter" and "force-detonate" skills. First, we're gonna make the Trap Counting Skill. Make a Skill and Common Event, and call them "Trap Count". Yes, link the Skill to the Common Event the same way we link the Mine Item to its Common Event. Don't forget to set-it into battle-only, with no target. As for the Common Event, make it show a dialog box that contain something along the line of "Mines set: \V[n]" Notice the coding. The \V[n] stands for Variable n, with n being whatever the Mine Traps variable is. So if you make it variable 6 for example, the code would be \V[6]. Additionally, you can use Instant Cast script to make it so that checking the amount of Traps don't consume turns. Next, the forced-detonation. Make two skills, name one "Detonate" and the other "Detonate Execution". Also make the usual Common Event and link it to Detonate. Give Detonate a 50 MP cost. Detonate Execution deals damage equal to the amount of mines +100 to all enemies. Both skills are, again, battle-exclusive. The Common Event should check with Conditional Branch, the amount of Mine Traps laid. If there are 1 or more, the player would use the Execution skill to the enemies. Otherwise, the Skill would fail. Finally, make a Parallel Process event in the overworld that clears all used variables during battles. This is done as a fail-safe event just in case. That should be everything to make the evented Trap system this tutorial aims to guide. However, there are still many things that can be done with this system other than making Mine traps. That's why I've included a Demo to show some things that might become inspiration or base for those who are interested in this. The Demo is also good for those who likes practice more than theory, has difficulty in understanding the written version, or lacks internet connection to read the guide for reference. NPCs in the Demo: >Lime heals you for free. >Pennywipe sells Traps. >Skeleton, Orc and Wizard for different intelligence level during battles. >GIRL gives tips about the Trap system. She also gives a special Trap once you befriend her. The Demo uses custom scripts, but mostly only for making things neater or debugging, and in no way required for the system to work. These scripts are: 1. Include Battle Events from another Troop by Fomar0153. 2. Instant Cast by Yanfly. 3. Debug Extension by Yanfly. 4. Core Engine by LiTTleDRAgo. 5. Show Event Name by LiTTleDRAgo. Grab the Demo here: http://mega.nz/#!4pAhxbjZ!L4pPUHaxnDO0PVG-sMYOAPe5qpP66huofa6Pu7S6A8Q And finally, credits and thanks: 3. SEGA's Phantasy Star Online 2, for the inspiration. 2. Fomar0153, Yanfly and LiTTleDRAgo, for their helpful scripts used in the Demo. 1. You, for reading this! Well, I guess that's all for now! I hope this tutorial helps you and you enjoyed it! Happy designing! -Maki13

Hello, this is Vectra, the Master Eventer. Recently, I've been asked about this from a friend and I thought: "Why not show everyone else once I'm done with the demo." Description This allows you to absorb HP from enemy for x turns. It's not damage HP which is negative HP Regen. This can be don Just so you know, this can also be done for Mp Drain, Atk Drain, Defense Drain, etc. All but TP since there is no way to pinpoint how much TP someone has by events. . Things to look at: Common Events Skills Noteboxes "EXTRA NOTE" common events Troop Page of Vectra Here's the demo, it explains everything very thoroughly Demo: Link Note: It is not encrypted so you wanna go in and battle-test against Vectra. Vectra, how do you make a variable equal to an enemy's (or actor's) stats? Go to Control Variable Go to Game Data On the right, click on the 3 dots Go to actor (or enemy) On the right, you'll see level Click on it and choose a stat In this case, you would use MAXHP I will answer any questions/concerns.

Welcome to Maki's Boss Battle Design Tutorial! Intro: Boss Battles have been pretty much a staple in almost every RPG out there. What make Boss Battles (and Bosses themselves) stand out is that they're usually pretty different and unique in design and executions than the usual battles. However, designing a nice Boss Battle is a challenge in and of itself. Yes, you can probably just take the graphic, make its stats triple than the party, make it immune to all status effects, insert it in its lonesome into a Troop, and call it a Boss... But doing so would make the battle bland and boring; and it also took away the fun in designing! Always remember that designing... is art! Well, that's why I write this guide. I want to share some advice, ideas, guidelines, etc. in creating more interesting Bosses, especially to the newer users of RMVXA. I'm not saying that you cannot create generic, "plain" boss. It's just... Wouldn't it be fun to spice up your boss battles with unique seasonings? Oh, and you can help to if you'd like! Just leave your feedback and, suggestions in the comments, or even additions you think would make the guide better! I'll see if that could be added later into the guide~ So without further adieu, let's begin! Chapter 1: ~What is a Boss?~ "Salazar went Berserk!" Yep, let's start and reflect from the very basic: What is a "Boss"? or What makes enemy a "Boss"? Answers may vary a lot, but I personally think that Bosses are special and usually stronger enemies that are there to either advance the plot or serve as "checkpoint" for the player in learning to play the game- It's not unusual to get a certain ability only to find it crucial in the next boss battle; the Zelda games are particularly fond of this. Some are locked into thinking that Bosses needs to be bombastic, one-of-a-kind enemy with 4xxxxx HP, scary stats, specials attacks and hours to beat. But in actuality, you don't need to fill all those criteria to make good boss fights. Looking at the beginnings though, these "cliches" are actually justified; it's just that they're just so overused they became tedious and sometimes annoying to go through. Boss Battles are usually set-up differently than usual enemy battles. There's a cutscene, the dialogue and stuff, and even a random winged lion in the forest usually have a short cutscene just about the monster appearing to the player. RMVXA itself has its own settings to determine if an enemy is a "Boss" by enabling the user to choose different collapse effect, SE, and the RTP is bundled with more than one "Battle Start" SE just in case the user wanted a different one to use in Boss Battles. Chapter 2: ~Boss Types~ There are a lot of Boss Types, it'll be quite difficult to explain them all here. I'm just going to highlight some of the more simpler ones, and you can expand from there. Be creative! "The Damage Sponge" As its name implies, the Damage Sponge can take a lot of punishment before going down. It also has a lot of stats, and usually the best strategy is just beating it to death with every offensive move you got. Sounds familiar? Well, it's the "basic" template for a Boss, and usually, when people think about Boss, they think about this type. Unless they play too many SMT games, probably. This boss type can be commonly found in older, retro games. The Final Fantasy series are also particularly fond of these. Example: Too many to count and give. Just grab your nearest RPG and play it, nine out of ten you'll encounter one. "The Puzzle Battler" The polar opposite of the Damage Sponge, the Puzzle Battler requires certain strategy to be taken down. This usually involve out-of the box tactics, but once the player figures out the way, they're usually pretty easy to take down. More prominent in platformer or side-scroller, but can be found in RPGs too. Examples: Wallman from Castlevania: Order of Ecclesia. House of the Red Rose (Second Battle) from Yggdra Union. (Gotta love that game's difficulty...) "The Elemental Changer" This Boss mess with Elemental RPS. They constantly change affinities, and can be pretty annoying in games that use the "Accumulate actions, then execute turn" mechanic as the player usually can't help but seeing their Whirlwind gets absorbed by the Boss' new WIND -150% affinity. They usually stand in the border between Damage Sponge and Puzzle Battler, depending on the Boss. Examples: A certain "Hipster Angel" from Persona 4. Seiryuu from Final Fantasy V. "Undefeatable" Undefeatables are... Well... Undefeatable. You can't beat them because the plot said so. However, they're usually not Game Over-inducing, and some even give Game Overs if the player actually manages to beat them. Additionally, a Boss might be Undefeatable and/or certain point. The player could do something to make it defeatable. Examples: Beauty Queen Etna from Disgaea 2. The Black Knights from Final Fantasy II. "Multi-Limbs Boss" One of the favorite classics, Multi-Limbs Bosses are those who needs to be taken bits by bits, until ultimately brought down. They may be a giant octopus, a multi-headed dragon, or even a mob of angry people! Usually, there's a "core" part that serves as the hub/main part of the boss. More often than not, destroying the "core" instantly wins the battle. May overlap with Multi-Stage Boss if the limb-tearing takes multiple stages. Examples: Polaris from Shin Megami Tensei: Devil Survivor 2. Menace from Castlevania: Dawn of Sorrow. "Multi-Stage Boss: Another classic favorite, these are Bosses that transcend a stage to continue the fight. They usually do so by transforming into their "stronger" or "true" forms. Most of them takes really long time to beat, and they usually gets all their stats fresh like a jar o' skippy during the transition while your party have to cling on those Mega Potions or Greater Heals. May overlap with Multi-Limbs Boss if the battle involves battling various part of the boss. Examples: Kefka from Final Fantasy VI. Death from... Almost every Castlevania game he's in. Chapter 3: ~Tips and Tricks!~ Here are some of my tips, tricks and ideas in designing Boss Battles. You don't need to take them fully, these are just suggestions and advices for you. I'll be happy if they could help you out~ 1. Sense of Progress How convenient. Make sure that the Boss Battle is meaningful to the player. Or at least, not just a button-mashing galore (Except if your game is a hack-and-slash, probably.). I don't mean you can't pop a Chimeric Steed out of the mountains. You can. What needs a meaning is not the Boss, it's the Battle. Unneeded Boss Battles can be a hassle to some players, so take account into that. Of course, you can just ignore this advice completely for Bonus Bosses or Secret Bosses, as they're purely optional. Just make sure that the players don't feel like they're just wasting their play time by fighting the boss. 2. No "Attack Spam", Please... Just sleep, just dream. It's only a battle... One of the most glaring thing I saw when playing some RPGs is some of the Boss Battles consist of nothing but Attack-spamming. (Although it's inevitable if you chose 4 Warriors in Final Fantasy XD) The battle becomes pretty tedious by that, and the Boss Battle would just turn into a glorified random battle. Don't misunderstand- I'm not against it, everything can be cool if properly executed, it's just that I advise to be against Attack Spam design just for the sake of it. 3. Let's Party! (Author's note: It kinda looks like Oscar is dodging the rubbles ._.") How about making the Boss do something to the Party? It doesn't have to be the Boss joining after battle like pictured. You can use other options such as: a. The Boss being a bertraying party member all along! The reverse from the above situation happens, and the boss is removed from the party member. a. The Boss is actually a nice guy, and one of your party member's a traitor. The Boss joins in the middle of the battle, and a new battle starts against the betraying party member. A mix of the example picture and example a. 4. Utilize Those Status Effects! Aah... Succubus! You make Enchanter-chan sad Nine out of ten, you know that feeling. When you play a game where there are like 15 "Ailment" States present... But none of them worked on the Bosses. What's the purpose, then? The Warrior and Mage can just slash and burn through the small fries, so it's usually moot to Ailment them. So how useful would the Enchanter be? So my next suggestion is, make States more meaningful to the mechanic. Although, you'll need to manage which are affected with what. It probably wouldn't be a good idea to make Firespirit affected by Burn or Toxic Wyrm affected by Poison. Although I also suggest that the "Death"/"Knockout" State should not be able to be used on Bosses, since it could break the game's challenge. Or alternatively, don't add insta-death Skills. 5. Make a Duel Boss! Natalie would actually look pretty sweet as a cheerleader... Duel Boss is a kind of Boss where only a certain number of your Party may join the fight (Usually only one). You can specify whether only the Chosen Twins may fight the Twilight Ruler, or that only the Star Princess can soften the Solar Dragon's anger. Executed well, Duel Boss can make a Boss Battle challenging and/or fresh without looking too cheap. 6. Make "Irregular" Battle A Hero Arrives! (Spoiler: It's Noah) Alternatively, you can make a Boss Battle that ended in an unusual fashion. Be it a mysterious hero rescuing your Party and defeating the Demon once its HP reaches 40% or below, a Greater Demon that kills the Lesser Demon and replaces it during battle... The plot potential is strong! 7. Alternate Win/Lose Condition! You take care too, Isabelle. We need your Spells but your MHP seems to be against that. Usually, the main goal of a Boss Battle is to take down the Boss by making its HP reach 0. However, you don't have to always stick upon that. You can make alternate goals such as surviving for 30 Turns, protecting a friend who's channeling a Barrier, or walking the usual beat-to-death route, but with a mix such as making the Grave Squirmer only killable by casting Holy Spark! 8. Linked Enemies! SLASHTHEM You can make Multi-Parted bosses too in RMVXA! There are scripts for that I'm sure, but you can also make simpler ones with eventing. Multi-Part Bosses are essentially multiple Enemies set up in the same Troop. Once the "Core" dies, an event triggers that places Death state into the others. 9. Reverse Multi-Limb! Of course, talking is easier than executing. ... ...That pun. How about making a twist to the usual Multi-Limb fight, and make that you're easier/possible to win the less you bother with the "Core" enemy? If that sounds too easy, then remember that you could "Invoke" (Guess the hint?) the player to attack the forbidden. Be careful with balancing, though... There are many possibilities with this one: A Chaotic Spirit that is unaffected by all Magic but has Magic Seeker skill to turn all Elemental Magic toward him? Your hero's hostage girlfriend forced into an armor that redirects all Sword Skills toward her? Up to you! 10. Outside Battle Tweak (Suggested by AlliedG) MY EYES!!! (I luckily captured this state though SS ) Who says you cannot tweak the battle externally? You can apply circumstances that makes the a Boss Battle different depending on your doing outside it. You can make a Boss gets a weakness to Fire by completing a sidequest involving sabotaging the Boss' magical capability, or makes an NPC that will strengthen the Boss if you failed his request! XX. Hair-Pulling Edition: Yuu Narukami Myriad Truth SWAG (Requested by Casta) This basically emulates the final phase of the final boss fight in Persona 4, where you manually cast a certain skill on the boss in a scripted fight, which finally leads to winning. It's quite tricky (and long), and requires multiple Database setup, so please read and proceed very carefully. 12. The Persona Reaper Encounters! (Requested by Casta) This one is more into map eventing than battle eventing, but still cool for me, nonetheless! The Reaper encounter style from the Persona series 3, 4 and 4 Golden. The Reaper itself is a really tough special enemy that appears in Persona 3 and 4/G that is well-known for its extreme difficulty and special encounter method. And now we're going to mimic those encounter systems! This request would be separated into 3 parts, divided by the game the Reaper appears in, because the encounter method is different in each game. This is another one that's a bit more into the intermediate-to-advanced skill level, so please read thoroughly. Especially the P3 one. I spent the whole night figuring that one out, while the others don't even take 10 minutes. 12. 1. The Reaper Encounter (Persona 3) 12.2. The Reaper Encounter (Persona 4) 12.3. The Reaper Encounter (Persona 4 Golden) I hope you find these useful~ Useful Links: "Boss Battle" on TV Tropes. Basically a witty exposition about Bosses and Boss Battles, complete with a huge list in Tropenese. Are you One of Us, too? http://tvtropes.org/pmwiki/pmwiki.php/Main/BossBattle "Battle Systems 101: Creating Bosses" by Lowell Richards. A neat guide found in this very forum. Has a well-written pointers and insights, including some small details not found in here. Despite seeming a bit incomplete, it's definitely worth reading! http://www.rpgmakervxace.net/topic/1098-battle-systems-101-creating-bosses/ Outro: Well, I think that's all for now! I'll update the guide once I got more, so stay tuned for that! Don't forget to give feedback and leave comments if you have any! I hope this guide would help you in designing cooler, more interesting Bosses and Boss Battles. Happy designing! -Maki

Hello, hello! Maki here, and today we'll be creating something that some of you might not expect... Yep! We're gonna create the Auto-Skill feature from the Devil Survivor series with events! "What is an Auto-Skill!? Not everyone can survive plays Shin Megami Tensei!" Of course I know that not everyone does, so I'll explain what the Auto-Skill is. If you haven't guessed it already, Auto-Skill is a kind of Skill that activates itself without manual command. In the Devil Survivor series, an Auto-Skill is automatically activated at the start of a team's skirmish, if that team's leader has the Auto-Skill equipped. Auto-Skills would always be activated at the very beginning of the team's skirmish regardless of turn order, as long as the leader has the resources required to cast the Skill. Auto-Skills are the Human equivalent of Racial Skills, which are exclusive to certain demon races, and not all of those Racial Skills are automatic. In this tutorial, we're going to create one of those skills. Of course, it would be adapted into the mainstream turn-based battle system that most RPG Maker user uses. Rage Soul People who plays Devil Survivor 2 might remember this Skill courtesy of a certain bipolar kid. In this tutorial, we'll be creating this infamous buff skill, Rage Soul. Originally, it doubles physical damage at the cost of disabling manual Skill usage, but since RMVXA doesn't have that feature implemented, we're going to alter it a bit into doubling ATK at the cost of disabling manual Skills. Skill Data: Name: Rage Soul Type: Auto Cost: 7 MP Doubles party's ATK for the remainder of the battle, but disables Skills. We're gonna need... 1. An Actor to use the Skill, let's call him Kao. 2. The Skill itself, set everything to None so it can't be used from the main menu nor battle menu. 3. The State for the Skill, let's also call it Rage Soul for convenience and have it change ATK to 200% and seal your Skills in its Trait. 4. A Variable to store the caster's MP, let's call it Kao's MP. Let's Event! At every single Troop you want an Auto-Skill to be able to activate, place this battle event: So, how does it work actually? What does it do? Let's skim through the event step-by-step... 1. A Conditional Branch checks if Kao has the Rage Soul skill. If true, then proceed. 2. The Variable is set to take data from Kao's current MP, to determine of he fulfills the cost needed. 3. This one part is actually non-existent in the original DeSu games, I just put it so the player can have more control over the skill, effectively turning it into a Semi-Auto-Skill. You can omit this part and just proceed with the MP Conditional Branch if you want pure Auto-Skill. 4. A Conditional Branch checks if Kao has sufficient MP to pay for the Skill. If he has enough, proceed. Otherwise, a message appears to inform that Kao has insufficient MP, and thus aborting the Auto-Skill activation. 5. If Kao has enough MP, the event will then reduce Kao's MP by 7 (Rage Soul's "cost"), and a message would appear to inform that the Skill has been activated. You can also optionally add a battle animation as Rage Soul's "animation" while executed. 6. And finally, add the corresponding Rage Soul stat to the entire party. (NOTE: I misnamed the State as "Berserker Soul", pardon me uwu) Omake So I accidentally found out the method written in this guide while I was messing up with the RM and the internet in despair to find alternate Elemental Affinity system because the default one isn't really good to me. I wanted to create "Break Elec" or "Fire Amp" kind of Skills, but the default way they system treats elemental affinities isn't suited without some tweaks. I can use the advice to alter it via Troop Event, but it would bring problem if I use, say, Bestiary scripts that show the enemies' true Stats. Then one thing led to another, and somehow I accidentally thought of a way to make DS-styled Auto-Skills! XD "So, this 'Omake' is just you telling your life story?" No, of course! This is one of the things that I had been messing with in the RM, and I think I'm just gonna share it XD Die For Me! (Devil Survivor 2-Style) Alice's signature attack takes one of its most macabre iteration in Devil Survivor 2, where it kills its target instantly with perfect accuracy, unless said target happens to resist the Almighty element (Needs to Crack Anti-Almighty from a certain spoiler character), in which the Skill's effect becomes... Halve target's HP. Yep, still nuts. Oh, and it also happens to target an entire party, too... Skill Data: Name : Die For Me! Type : Command Cost : 40 MP Element: Almighty Instantly kill all enemies that don't resist Almighty. Else, cuts target's HP by half. There's no fancy event we need to make, I'm just gonna show the damage formula we can use with this Skill. Always know that the damage formula box is one of the fanciest feature of RMVXA, which makes it very powerful and versatile. b.element_rate(9)<=0.50 ? b.hp : 9999 So let's see what we have here... The pattern of this formula is a simplified If-Else statement. It basically reads: Condition ? True : False First, it checks the Almighty (ID 9 in my Database) elemental affinity of the target. If it's 50% or below, it gives damage equal to target's HP. Else, it hits for 9999 damage. You may ask a question though, why b.hp instead of b.hp/2 if we're gonna halve target's HP? Well, it's because the target already has 50% affinity to Almighty. Since it's already halved per Trait, adding a "/2" would make the damage 25% instead. Another one could be, why 50% or lower affinity? Why not exactly 50%? Yup, it might look very confusing, since it would make it a bit awkward for enemies with, say, 40% or 20% Almighty affinity. However, DeSu only have Normal (100%), Weak (200%), Strong (50%) and Null (0%) affinity, not counting Reflect and Absorb. And since 0% affinity would practically receive 0 damage from the Skill anyway, I decided to keep it at 50% or lower. You can adjust it to "==0.50" for your project if you wish. Well, so I guess that's it for now! Thanks for reading this guide guys, I'll see ya later! Questions? Comments? Feedback? Just leave them below! Happy designing~ -Maki13

Auto-walk This is my first attempt at a tutorial, have a few more planned but please tell me how I could improve it or where I can clarify. Please find attached a basic demo of the Auto-walk demonstrating the features and showing the eventing in detail. autowalk demo (dropbox link) Basic premise - Using eventing a some knowledge of script calls (no scripts needed) you can have a common event that allows for the player characters to follow a road or a path 1 tile wide in any shape or path that you have drawn it - at the press of a button. This was inspired by the Witcher 3 where, if you hold down a button when riding your horse it will automatically follow the road. I have been making big maps - really big, and on these maps I've been drawing in roads, but it gets a little tiresome to explore these maps by moving around holding a direction. I'd been looking for a script that could do something like this but with no luck. Luckily, with a bit of rooting around and thinking me and my bro managed to figure out something that works for us, and might work for you. Example of a map with road drawn on - How it works - At the press of a button your character will follow a path, stopping when you press a directional button or at the end of the road or at a crossroads. you can draw any kind of road 1 tile wide on a map of any size and it should work. The only script I've used is yanfly's button to common event, but it is not necessary to get auto walk working, only for convince. you do not need the script but it does make auto-walk simpler. link to script What you'll need - 1. You will need to create 3 blank events per map, and they will all need to have the same id - the simplest way is to have them be event 1, event 2, and event 3. They should be blank and have the through box ticked. 2. You will need 1 common event slot - everything will be handled here. 3. For the terrain that you want the player to autowalk on you will need to go to the Database, Tilesets, Terrain Tags and modify the number of the terrain to something that you aren't using for any other terrain. I've set roads to terrain tag 5 and am not using it for any other terrain other then roads. Important to note I've discovered that at a normal move speed the auto-walk does not seem to work all that well - I've found that the max move speed that it works at is about 3.6. you can use a simple script call to alter the move speed - $game_player.instance_eval("@move_speed = 3.6") I've made it so the common event in the demo changes the players move speed while auto-walking, but this is not pictured in my screen shot below. Auto-walk Common Event In the spoiler you can see the whole common event that I'm using - there are a few bits that may be redundant but it more or less works (lol) The initial conditional branch is to make sure that the event does not proceed if the player is not on a road - this prevents interference on maps that you do not want the autowalk to function on. you can similarly use a switch or variable or map id for the condition. Below that starts the loop. in the demo I've included a script call to change the players speed to 3.6 - the max speed I've found that the auto walk works at properly - any faster and is doesn't seem to turn correctly. you might be able to figure out how to get it working better than me xD At the start of the loop you'll see a conditional branch by player direction - this then uses a script call to place events 1,2,3 respectively in front, and to either side of the player. this needs to be repeated for each event and for each possible direction the player can face. Just below there is a nested conditional branch that reads the terrain tags of events 2 and 3 and calls a move route for the player to wait for one frame. this makes the player come to a halt at crossroads or where multiple roads intersect. Below that is the conditional branch reading the terrain tags of event 1 - the event in front of the player. this simply reads that if the terrain tag is 5 (a road terrain) the player preforms 1 step forward, skipping if unable to move. In the conditional branch, as well as in the conditional branches that follow you'll see I've included nested conditional branches that in the case of any direction being pressed the loop will break - this is so at any point during the auto-walk you can resume control of the player character. In this conditional branch there is a jump to label: loop, taking you back to the label at the top of the common event at the start of the loop - this is necessary so that during the auto-walk the player movement prefers going forward to turning at junctions. The next two conditional branches are identical, reading the terrain tags of events 2 and 3 - in the case of event 2 it would turn the player character right by 90 degrees and step forward, in the case of event 3 left by 90 degrees and a step. You can see that I've included a wait for 5 frames after each - that is so the move has time to execute / be registered before the event loops. Nested in the conditional branches all the way to the bottom are repeated the conditional branch to break the loop by direction pressed - I'm not sure if all of them are entirely necessary, but I've included them because it was working for me xD. At the bottom, after the look (not pictured) is a script call to return movement to normal speed. Finally - The common event in the demo attached differs slightly from whats pictured, and includes the yanfly button to common event script. you should be able to see it working. Well, thats about it I reckon. This is the first tutorial I've tried my hand out, not sure how helpful it might be - I was just excited at having figured out how to do something like this and thought to share it with youse all. I hope you can find something to use in whatever project you're working on here, and in the future I might try my hand at a couple of other tuts to do with mapping or variable terrain speed. Thanks for reading! autowalk demo (dropbox link)

Hello, friends, and welcome to the next Tutorial Town! In the first series (Click Here) we made a game using the default editor and had loads of fun doing it. In this new series, we're starting totally from scratch. Deleting the database, importing as many new resources as we can make use of and integrating loads of scripts to try to make a truly awesome player experience! Join us for a new journey into game making. https://youtu.be/mqWAuFyNnYM

A video on how to make dynamic digging so you can dig holes where ever the player sprite is! You will need: 1 common event 2 terrain tags 7 variables 1 digging implement, preferably a shovel.

I have seen a lot of posts around the internet with people having issues with projectile collision in this ABS. The issue begins when setting "Tool Through" to false on a projectile weapon. The projectile no longer passes through objects that are at the same level as the character, such as walls, but won't hit enemies anymore. Proposed fixes include changing the tools size, which has the side issue of hitting a two wide area instead of one. After a lot of messing around I was able to cobble together a fix with a proximity script and a simple script call. This may only work with single character games since this is all I tested it with. The reason being it changes priority (height) of enemies. I may edit this post later with pictures but for now we will start simple. Needed Scripts: Vlue's Proximity Events Script - Link Falcao Pearl ABS Liquid V3 - Link This tutorial starts after you've already installed Falcao's ABS. You should also understand how to set up items and set "Tool Through" to false. As well as also setting up enemies. Step One: Install Vlue's Proximity Event Script. There isn't much setup here. All you have to do to make this work is set the PROXYRANGE to 1 in the script. Step Two: Set enemies second page (the page where they sense you, self-switch "B") priority to "Below Characters". Step Three: Create an event that runs on a "Parallel Process" trigger. You will use a condition branch script check. The check will call the proximity event script. Proxy.inprox?(ID) will be used for the branch check. ID will be the ID of your enemy event. If you have multiple enemies you will have to set up multiple branches with their respective ID numbers in this event. $game_map.events[iD].instance_eval("@priority_type = 1") will be used to move enemies up to your level once you are within one space of them, this way you can't step on them and they will attack you in melee. This ID is the same as above. $game_map.events[iD].instance_eval("@priority_type = 0") is your else case. This moves them back below you so you can shoot them again. ID same as above again. You will need the event on each map where there are enemies you want to check. Also don't forget to make sure your "Tool Through" is set to false. Otherwise this tutorial would be pointless! Bugs / Issues: You can't shoot enemies at point blank range with this, but you can use a melee attack. You may still pass over / step on enemies sometimes. Thanks: Vlue for the useful Proximity Events Script Falcao for the powerful Pearl ABS liquid V3 Script There you have it. A fairly simple fix. I spent hours looking all over the internet for a fix. I finally got the idea to use the priority and proximity to make a quick fix. I hope that anyone with this problem finds this fix and is happy with it!

Enemy Reinforcements This tutorial will teach you how to create an enemy skill that allows enemies to summon reinforcements. After searching the internet and spending a good couple of hours trying to work out how to do this I thought I'd share what I came up with. Special thanks to Galv and Gawaine whose posts on another topic helped me figure it out. What You will Need 1 Skill 1 Common Event 1 Enemy (Minimum) 1 Switch 1 Variable 1 Troop with a minimum of 2 enemies. Step 1: The Common Event First of all, we need to set up a very simple common event. All we have to do is create a switch called Reinforcements to be turned on when the common event is run, like so: @>Control Switches: [0001:Reinforcements] = ON This common event can then be used for any Enemy Reinforcement skills you have. Step 2: The Skill Now we'll set up a skill to call the reinforcements. I've called mine 'Cry'. You can leave everything but the name blank. What you need is inside the Effects box. Double click inside Effects, go to page 4 (Other), and select the Common Event Reinforcements. Step 3: Setting up the Enemy Next we'll set up the enemy's skills. Find or create the enemy you want to use the skill. For this tutorial I'm using slimes. Go down to Action Patterns and add the Reinforcement Skill to the enemy's skill set. You can set whatever conditions you like. For this example I've set the skill to be used once the enemy's health drops below 70%, but you can also set it to call for reinforcements if the party is at a certain level. Step 4: Setting up the Troop Now that we've done the easy bit it's time to move on to the meat of the skill. First add the number of enemies you want in the battle. For this tutorial I'm sticking with 3 to make things easier. Right click on two of those enemies and set them to Appear Halfway. This means they won't initially appear when the battle starts. Now go down to the Battle Events. Set the Condition to Switch[001: Reinforcements] is ON and the Span to Moment. This is very important as leaving the span set to battle will not allow dead enemies to be resummoned. Now onto the actual event. We need a variable called Enemy Reinforcements and we need to set it to a random number between 1 and however many enemies you want to summon in the troop. We'll be setting it between 1 and 3. Next we need a conditional branch set up to check if our reinforcement variable is equal to 1. Uncheck 'Set handling when conditions do not apply'. If the variable is equal to 1 we'll summon Enemy 2. To do this, make another conditional branch to check whether or not Enemy 3 is dead. If Enemy 2 is dead we must remove the Dead state and increase the Enemy's health by whatever it's Max HP is. If Enemy 2 is not dead we go to tab 4 and click Enemy Appear. Overall, the Event should look like this: Don't forget to Turn the Reinforcement Switch Off after the summon is done. Repeat the Conditional Branches for as many enemies as you want to summon. For Use With Holder's Animated Battlers

CREATING OBJECT SHADOWS USING PHOTOSHOP by Nestat REQUIREMENTS: You need to know your way around Photoshop; (this guide made with the use of version CS4 but you can use any version, i think) A game map as a template. LET'S GO! 1. Go ahead and load your map in Photoshop. 2. Separate the floor from the objects/furniture into two different layers as shown in the picture below. (This step will not be covered in this tutorial) 3. Right-click on the furniture layer and select "Blending Options..." 4. Choose "Drop Shadow" and click on it for more options. Drag the "Distance" slider to the right, 5-20 px (depends on how close/far your light source is.) Adjust the "Angle" to match the direction of light of your map. 5. Select Layer -> Layer Style -> Create Layer. Notice that your 'Shadow Effect' is now isolated in its own layer, separate from the furniture layer! Select the shadow layer. Give it a 15-35 % transparency. 6. Make the changes accordingly to your map needs. (erase shadows not needed, change shadow color etc.) That's it! Happy Shadowing!

This is a request made by Captor Medicine in this thread. The first thing you want to do is create your maps. Now, you want to make an event and it might help to make sure it is the same event number on all maps. To make it easier, I am just using Event 1 and I am naming it Dog. Now, in the conditions tab, click the switch button and label a switch. I called mine Dog and placed a dog graphic in the event. Next you add a choice box and label it the interactions you want to have. I picked: Pet, Follow Me, Cancel. Copy and paste this event in all the maps you want your dog. And that is it for that event! You can place it on all the maps you want your dog and the system. Here is how it should look: Now you want to create a common event and have it set to a parallel process, then make a switch and call it Hunting. First, create a conditional branch set to when your dog is in the party. In the else statement set the Dog switch on. Now we will focus on what happens if your dog is in your party. For me, I like to use buttons as a way to call the event, and since this is a smaller system, I plan on just using the choice menu. In the common event you just made, create a conditional branch and set it to what button you want to press to call the event. For me, I am going to use the A button, so I will call the X button in the conditional branch. Inside that conditional branch, set up the choice menu and place the interactions you want. For me, I picked: Hunt, Stop Following Me, Cancel. In the Hunt choice, we are going to remove the dog from our party. Next, create a variable called Randomizer and set the random variable to how you'd like it. For me, I choice 0 - 3. Then, create a wait command to how long you want your dog to hunt for. In my case, I set it to 400 frames. Now, place your dog back in your party. Next, create a conditional branch to when the randomizer is equal to 1. In mine, I have it so the dog found a potion. In the else statement, set another conditional branch and have it equal to 2. In there, I put that the dog found magic water. This is how mine looks: And that is all to making a hunting system where your dog fetches the items for you.

This is the video version to Game creations original tut HERE You will need: 3 variables 1 switch 1 common event terrain tags a sound effect of your choice

Skill Level: Medium Technical (knowledge of layers), Basic/Low Artistic (knowledge on how to place pixels) (to skip to the tutorial, click HERE) You have a fantastic game idea, a clever set of characters, and a storyline all written up. Now it's time to take a visual approach – to decide on what your characters are going to look like in game. For artists both pixel and otherwise, this is a relatively easy task. But for those who feel like they don't have a creative bone in their body (or simply have a tough time working with tiny pixels), they get stuck with default characters and character generators.* *Now, this isn't to say that default characters and character generators are bad things! They all have their uses, and can be a great starting point. They also offer alternative genre parts if you're creating a game that doesn't fall under the Fantasy tag. Here is a comparison between 2 generated sprites, 2 RTP sprites, and 1 custom sprite. I want you to note the differences – not the really superficial stuff like the clothing and colors – but the way the eyes look slightly different, the ways the hair (or lack thereof) is shaded differently, how the clothing is handled. This really shows the limitations of the default generator – the right three sprites have eyebrows, facial hair, expressions. You can tell that there's a middle aged guy and that one guy possibly is a fairly angry individual. You cannot get this effect using a generator – they have one face, and one face only. So if you want to create a unique character that isn't aged 16-25 with minimal facial hair, you're stuck with the defaults. Here's where I teach you that isn't quite true. You see, that custom sprite I pointed out, the rightmost one in the comparison? He's not really custom. He's a frankenstein* of 2 different RTP sprites. *Keep in mind that people who create true custom charsets may not be happy with you using their parts to make your own character. If it isn't RTP, ask the creator before you go messing with their stuff! Sure, he's been recolored, given a v-neck shirt and grew a goatee, but the parts are still there. So that's what you need to start doing when you're hunting for that perfect character – not see them for what they are, but for the parts they're made out of. Here's an example of taking 3 different sources and making them their own unique character. Do you have a mine section in your game? Of course you do, mine dungeons are the best! Obviously you need the main character in a mine cart, but where would you get such a thing... [anchor=tutorial][/anchor] Now if you've made it this far (or clicked the link at the beginning, I guess) you may be interested in learning exactly how do do this. What I'll be using for the actual tutorial section is GIMP 2.8, mostly for one incredibly useful feature – the Select by Color tool. This fantastic little tool allows me to do exactly what the name says it does, and select all of a single color. This comes in incredibly useful when trying to separate hair from a head or change the color of any object. Photoshop has no equivalent, which is why I'm using GIMP.* *I am unsure if any other common programs have this feature. If you're using Photoshop or a program that doesn't have a real 'select by color' feature, you'll have to settle for careful use of the lasso or magic wand tool. I have yet to test this using Photoshop's region select tool. I start with a character concept – this is a lady that's a down-to-earth hunter, the sort of person who would rather spend a lifetime in the forest than a single day in the city. I find the hair I want in Actor 5-1 – which, yes, is a guy, but he has the perfect hair for a hunter character and the RTP faces (not bodies) are interchangeable between genders. Another great one is Actor 4-7, whose curly ponytail does not look out of place on any female character. After looking through the outfits, I settle on Actor 3-4's.* *I may be using resources out of the Actor set, but don't feel limited to that. There are some great character designs in the People set and even in the generator. Imporant Note: If you're not working on a fresh canvas and instead editing the charsets on their native canvas, make sure that you set the image mode to RGB. By default, the Actor sets are Indexed, limiting their color depth. This limits color-changing possibilities and can cause some ill effects when bringing in other charsets to edit in this space. We're going to start by selecting the hair, fur, and head accessories from Actor 5-1. You'll want to make sure your selection threshold is set to 0. Since we're dealing with incredibly small images and working with exact color, this will make sure we'll only select the colors we want to select. Be sure to press SHIFT to add to your selection – if you accidentally select something you don't want to, use CTRL and click on the part you want to get rid of to do so. As we start to select the pieces we want to transplant onto Actor 3-4's body, we discover that the whites and grays used in the feather are the same that are used in the gloves. This presents a problem. There are two ways to go about this – go with this selection and delete the gloves in the next step, or deselect the white and the manually select the white part of the feather. Since the gloves have more pixels than the feather, I opt for the second approach, deselecting the whites and grays and then use the rectangular marquee/select to grab the white feather portion on every facing position. In addition, select the blacks. It'll require some clean-up afterward, but will keep the defining shape of the hair. Now copy this selection using CTRL+C, and then paste using CTRL+V and press the new layer button in the layers palette. This automatically makes the pasted selection into its own layer. Make the old layer invisible. There are a lot of lines left over from selecting the blacks. Time to clean them up! Take the eraser tool, select 'Hard Edge' in the Tool Options and make sure the size of the brush is 1px. Then go and erase any black lines that aren't a part of the hair or fur. DO NOT erase the irises from the eyes. They will come in useful in a few steps. When in doubt, leave the black. We can always fix any errors at the end. Now that this half is largely cleaned up, we move over to Actor 3-7, who gets to lose her hair. I do like her angry face, however, so we'll be keeping that. If you're working with identical faces, or if you prefer the face that came with the hair, or if you're using a face from something else altogether you can simply delete the head altogether by using the rectangular marquee/select. Make sure to deselect her eyebrows before getting rid of the hair! Don't worry too much about cleaning it up right now, because we're going to move the hair from Actor 5-1 over to this body. Simply move the hair layer over and line it up until it looks correctly. This is where leaving the irises comes in useful – simply line it up with the existing ones and you'll get a pretty good placement. However, I can see we still have some cleaning up to do with the leftovers from actor 3-4's hair. Hide the hair layer and move back down to the body layer. Erase the ribbons and the floating blacks, leaving the body and the face. Now we need to clean up her face, get rid of the transparent bits around the warpaint and the ears. On the body layer, I color pick the skin tone and follow the shading patterns until it's all filled up. Basically, I start with the lightest one until the surrounding area gets a bit darker, then switch to the darker tone, and so on. I'll also reference a hairless head to see how the shading is done around the cheek there. You can also simply copy and paste from that area on Actor 5-1, which is what I opt to do here. Now in all honesty we could move onto recoloring and be fairly fine, but I want to make a few adjustments. Because we took the fur scarf from a male character, the shoulders are a bit off on the female frame, so I'm going to color pick and just even it out in some of the blockier areas. I'm also going to lengthen her shirt so it covers her midriff. Now that we've finished that, and are pretty happy with how the image turned out, we're going to merge the layers so we can begin editing colors. This is where some artistic or fashion knowledge comes in handy, but it's not necessary as long as you remember a few things. Keep all metallics the same unless your character is meant to look eclectic – all golds or all silvers or all iron or whatever. Our character has gold necklace and bracelet and a silver buckle – something that looks a little odd. Pick a color and then play with neutrals on the opposite side of the color wheel. If you want the primary color to be blue, use warm browns for any neutrals. If you want the primary color to be red, go with cooler/bluer neutrals. Remember tone contrast. When you have colors you're pretty happy with, duplicate the layer and desaturate it. Can you still see where the shirt ends and the pants begin? If not, you need to either brighten or darken one of them to increase contrast. Since our character is a hunter, her colors are going to be green, gold, and brown. Her hair is going to go to a coppery shade, her eyes are going to be brown instead of blue. We begin by selecting objects by color – we'll start with the hair. We're going to be using the Colors → Colorize tool to recolor, primarily. Hair can be a little tricky because the highlights can get washed out after a colorize. You can fix this by selecting the highlights only after it's recolored, and using the hue/saturation tool to raise the saturation to acceptable levels. Remember to zoom out to 100% to see what it'll look like in game! Repeat this for the rest of the clothing and accessories. At the end, I had this character. You may have come up with something completely different if you followed along, and that's fine. All you have to do is ask "Does this character look like one that wouldn't look out of place alongside the other main characters?" If yes, then fantastic! If no... you may want to make the character stand out a little bit more. Congratulations! You've completed a custom-looking sprite with minimal artistic intervention. You can apply this sort of technique to a lot of things that may be difficult to find otherwise, from downed sprites to special animations. Now, go forth and create beautiful custom characters! And show me any you make using this tutorial, I'd love to see!* *If you need any help or if any part of the tutorial is unclear, feel free to send me a PM or leave a note here. I'll do my best to respond promptly!

This system of events work to get make it possible for you to have the same type of character switcher in GTA5. This means you will be able to switch you character when ever you want, and you can meet the other characters and interact with them and so on.

This tutorial will teach you how to create a "quick travel" or "teleport" scene purely using events. The locations the player is able to quick travel to only become available once they discover them, and are listed in the order they are discovered. This tutorial was created as part of the RMDev Challenge #1. A demo can be downloaded here (RTP not included). The final result should look something like this: (note that the layout is completely customisable! Import your own pictures to give it a personalised appearance!) Pressing Q and W scrolls through discovered towns, and selecting the highlighted town teleports the player to that location. This tutorial is split into multiple sections which all work together. An event is required in each town, as well as one at the teleporter, and three common events are required. Also, you will require a basic understanding of switches and variables to understand this tutorial. So, without further ado, let's get into it! Town Events: This event will run as soon as the player enters a town and will record that the player has entered the town (note that town events in the demo are located in the upper-left hand corner of each town). For example, let's say the player enters town A; the event should look like this: Now, straight away, we see some switches and variables that need to be defined. X (variable) is used to keep track of how many towns the player has discovered. Each time the player discovers a new location, it should be increased by one. Town A (variable) is used to show in what order Town A was discovered. Every town requires a variable such as this. By setting this value to X the game can determine how many locations the player had visited before visiting Town A (Hence, it is important to increase X by 1, only after setting the town's variable to X. Discovered A (switch) records that Town A has been discovered. Every town requires a switch such as this. This first page should be set to Autorun, with a second, blank, page activating after switch Discovered A is on. Teleporter Event This is the event that activated the location selection. It may look daunting at first, but is actually quite simple: The first thing the event does is check to see if any towns have been discovered. As X is the number of towns that have been discovered, if X equals 0, then no towns have been discovered. A simple message is displayed to signify this. The Map Selection variable will be discussed later. However, if a town is discovered, the event sets up for some common events (which will be explained later). However, the biggest task this event carries out is setting up the names of the towns that have been discovered. See in the first screenshot how there are town names on the left hand side? This event is what displays them. Each town's name is a picture which is displayed. The X coordinate for each picture is 5, and the Y coordinate is calculated based on the order they are discovered. This allows the names to be listed in the order they are discovered. The exact Y and X coordinates are completely optional. To calculate the Y coordinate, I incorporated the town's variable in the calculation. If a town is discovered second, it's variable would equal 1, if it was discovered fifth, it would equal 4, etc. hence, by multiplying the town's name's picture's Y coordinate by its respective variable, it will be displayed further down the screen than subsequent towns. The final thing this event does is activate the common event: Select Map Location. Select Map Location Common Event This is event determines which location is currently highlighted: The first thing this event does is disable the player's access to the menu. As this is kind of creating a new menu, it would be weird for the player to be able to access the pause menu as well. Also, it makes the B button available (which is the default "exit menu" button). At the end of the event, it can be seen that the player can escape the location selection scene by pressing the B button, and the button's normal function is then restored. I believe my comments explain the rest event in adequate detail. Basically, the event gives the function to the Q and W buttons to scroll through available locations. The MapBackground picture is the black and brown circle in the first screenshot (excluding the map on it, that is a separate picture). Map Selection (variable) was mentioned earlier on.This variable is used by the common event: Show Map Location. It is initially at 0 (as shown in the Teleporter event). It increases by 1 every time W is pressed and decreases by 1 each time Q is pressed. Show Map Location Common Event This common event is called at the beginning of the Select Map Location common event. This event simple shows a picture based on Map Selection is currently equal to: Now, this event may look large, but is actually just the exact same process repeated each time (once for each town). What the event does is, firstly, checks to see if a town has been discovered yet. If not, it moves on. If it has, then it checks to see if the town is currently highlighted by the Select Map Location common event. As mentioned before, each town is given a number when it is discovered. If this number is equal to the Map Selection variable, then it will be highlighted, otherwise it is un-highlighted. Go To Map Location Common Event This common event activates if the player presses Z or Spacebar in the Map Selection scene and is the final step in the process. This event begins by stopping the Select Map Location common event and erases all of the pictures associated with the map selection: Then once everything is "put away", it transfers the player to the location that is currently highlighted. Finally, normal use of the B button is restored so the player can once again access the pause menu. And so concludes this tutorial! You are now one step closer to eventing your own, sleek, quick travel system! Good Luck! A demo can be downloaded here (RTP not included).

Since working on the other tut based on Destrik Gamer's tutorial I figured I should keep the ao oni train rolling with another Ao oni based Tut! This time for the hiding mechanics. Hopefully I explained everything well enough since I got a little ramblomatic xwx;

Hey guys, this is the second part of my tutorial on how to create an addictive RPG. If you missed it, you can catch part one http://www.rpgmakervxace.net/topic/26193-rpg-addictiveness-part-1/. Go read that. Stop reading this, go read that. Have you read it? No? Go read it. Okay, you good? Let's go. So, my first tutorial went over the general format that I use personally when making games. I call it the Story and Rewards method, and relies on the high levels of dopamine. It generally goes like this: have a simple dungeon where the player is unstoppable, then a small bit of story, to set the scene. Repeat that once or twice. Then your dungeons should go up in difficulty. The first time they should feel a bit of a bump, where they can tell it's more difficult, then it should go up smoothly to the point that at the last dungeon, they're spending a lot of time in there and they really have to work for their big ending. So now, I'm going to go over exactly what happens in the story. First off, is character creation. There's lots of character generators out there to use if you'd like, but something I like to do is I put my music on shuffle and pick the first couple of songs. Each song will be the personality of each character. This only works if you have a variety of music, and the character generators will work too, in this case. That's when you start creating the actual character. The reason I use songs is so that I can listen to the song over and over while making the character. Each good song will have an overall feel and message in it, and that's what you have to listen to. There's many different information sheets out there to fill out, and it really depends how in depth your game is. My game, for example, is all about how every person has their own story, so most, if not all of my characters need in depth backgrounds. This website does a much better job of explaining this all around than I ever could: http://rpg.ashami.com/. Anyways, don't be afraid to have contrasting characters. These characters can't be exact opposites, because you need to make them have some sort common attribute that will bring them together. For example, a tough street thug and a rich cowardly man could be a good match if someone is threatening to steal the rich guys money so he offers some to the street thug to help him. That makes a common goal. Don't have the common goal be too stretched. The player will feel this and not be quite as interested. You'd be amazed as to what you can get away with, but you'd also be amazed as to what you can't. Now, let's talk about how the story relates to the Story and Rewards plan. When I'm planning my story out, this is the general path I follow. This is something that you can find in a lot of films to make the viewers sympathize with the characters. You'd be hard pressed to find a film that doesn't follow this to some degree. 0% - 10% - The first 10% of the film should draw the viewer into the initial setting of the film. What was life like beforehand? It should show the everyday life of the hero before the events of the film, show some flaws, what they're good at, etc. 10% - 10% of the way in they should be presented an opportunity. which will create a new, visible desire, and will start the character on her journey. The opportunity doesn't have to be quite what the main story is about, but it has to move them into a new situation. 10% - 25% - The next 15% of the story should show the character adapting to their new environment. They form plans on how to approach their new situation. Most of the time, they enter with excitement. 25% - About a quarter of the way through, something must happen to change their original, general goal into a visible, focused goal. The thing that the audience is rooting for the hero to do in the end is revealed.This is arguably the most important structural principle. If the hero's visible goal is defined too early, the story will run out of steam long before the climax. If it isn't defined until the halfway point, the viewer will have lost interest and moved on. 25% - 50% - This next quarter is simply the hero moving towards their goal. They could suffer minor setbacks, but they make a lot of progress here. 50% - At the midpoint, they must fully commit to the goal. Before, they could kinda get out of it and get around it, but now they need to burn their bridge back and go forward. 50% - 75% - For the next quarter, the obstacles become bigger and more frequent, achieving the visible goal becomes far more difficult, and the hero has much more to lose if he fails. The conflict begins to build until, just as it seems that success is within your hero's grasp... 75% - They suffer a major setback. This is a MAJOR setback. The audience should feel like EVERYTHING is lost. The hero's lies are revealed, the lovers break up, whatever it is. All hope must be completely lost. This just leaves the hero with one option. They can't go back to the life they lived before, since they burnt their bridge back already. Now they can only go out and launch one final, all out assault. 75% - 90-99% - Now they are beaten and battered, the fights are harder, the challenges are more difficult, and the pace has accelerated. They need to give everything they have. 90-99% - Several things must occur at the climax of the film. The hero must face the biggest obstacle of the entire story, they must determine their own fate (often overlooked) and the goal must be resolved, once and for all, for good or for bad. 90-99% - 100% - No movie ends with exactly what they were hoping for. The audience needs to feel something related to the excitement, emotion, sadness, romance, etc. in the end. Answer any unanswered question and show the hero after the battle. Now, that's quite a bit of information, but that's exactly what you should do with your game. Maybe make a few changes, specifically for the introduction. But there are two types of setbacks. Major and Minor. Now here's the information you're really looking for. When you're planning a game out with the Story and Rewards strategy, you need to plan out how many dungeons you have. Split it up into thirds. For example, twelve dungeons becomes 3 groups of 4. It doesn't have to be exact. Now, at the end of each group of dungeons (so, in the example of twelve dungeons, at the end of every fourth dungeon), you should have a Major setback. At the end of ones that don't have a Major setback, you put a Minor setback. The final major setback comes during the final dungeon, just before the final boss. This brings up the excitement, and the dopamine levels I went on about so much last part. The final part, at the 90-99% - 100% part of the story, this will generally be the final cutscene. I find the Final Fantasy series does that really well, where they tend to wrap up EVERY SINGLE @#$%ING CHARACTER. And I love it! It's brilliant. Anyways, your final cutscene should aim to do just that, unless you're going for a sequel or something like that. Again, don't forget, this is just one strategy. There are countless strategies. See if you like it. Anyways, here it is put in plain text for you, with the example of 12 dungeons once again. Introduction -> Simple Dungeon -> Bit of story -> Simple Dungeon -> Bit of story -> Simple Dungeon -> Bit of story -> bit more challenging dungeon -> Goal Change/Focus -> Dungeon -> Minor Setback/Progress -> Dungeon -> Minor Setback/Progress -> Dungeon -> Minor Setback/Progress -> Dungeon -> Point of No Return -> Dungeon -> Minor Setback/Progress -> Dungeon -> Minor Setback/Progress -> Dungeon -> Minor Setback/Progress -> Final Dungeon (Inside the Final Dungeon, there should be the Major Setback with all hope lost and the final battle). Hope this helped you guys! Feel free to comment if you had any questions about it

Hello there VX Ace community.Today i'm going to be showing my method Parallaxing Dynamic trees that are simultaneously on the ground layer and the parallax layer.Essentially the purpose of this guide is to show how to create trees that have their roots under the player, the trunk in front of the player and have their leaves over the player. Scripts needed Tsukihime Map Screenshot Yamis overlay Script Ok now lets get inot this step by step. 1.Start a new project with defualt map size 2.Fill with any green grass 3.Install Tsukihimes map Screenshot script,start the game via playtest and take a screenshot of the map(see instructions inside the script). 4.Drag and drop your map into an image editor (i'll be using GIMP for this tutorial). 5.Setup your grid (32 x 32 pixels,any color that suits you). 6.Add some parallax trees into your project as a new layer (i'll put the ones i'm using in the spoiler tag with the screenshot) 7.Draw a selection around the biggest tree,copy and paste it as a new layer.Name this layer "par Layer". 8.Hide every other layer beside and single tree 9.Now,install Yamis overlay script and create a folder in the graphics folder of your project named "Overlay".Go back into your editor and export just the tree and name it "par1-1" and place it in the new "Overlay" folder you just made. 10.Now,start your game up in the test and you should see your tree on map 1 and as expected the tree is completely above the player .You can walk completely under it,and if you know how layers work you know that the only other layer below par is ground but if we set it up as a ground then we would be able to walk over it as if it were grass so normally your only option is to set up the passability on the roots so the player cannot interact with any part of the tree except the leaves but not only does this not feel right to keep the player that far away from the tree,it also limits how it interacts with the player and its place on the map.Now! lets do something cool to fix this and make the tree more dynamic. 11.Go back into your image editor project and make the mapshot visible (so its just the mapshot and the single tree with visibility). Zoom in and Select the whole shadow in front of the tree and as much as the tree stump as possible without selecting any of the leaves! Also,notice how the front roots are place on the grid.Its done in a way that anticipates what the player will be touching when they walk towards it.They will be standing on the roots while in front of the stump without their head touching any part of the leaves. 12.Once you have your selection like the picture above. 1.Copy it 2.Cut it 3.Paste it as a new layer and name that layer "ground layer". move the new layer under the "par" layer (the tree).Now what we have is two images that make one image,two parts of the tree that make the whole tree. 13.Now hide everything except the "par" layer (which should now have its trunk cut off) and export it and name it "par1-1" and place it in your projects overlay folder (replace the one that was in their),then,go back into the image editor and hide everything except the "ground" layer (which should be just the tree trunk and the shadow) and export it and name it "ground1-1" and place it in your projects overlay folder. 14.Now start your game via test and Viola! What you now have is a tree with roots you can walk on,a tree trunk you can face and leaves you can walk under! NOTE: You will need to place invisible impassibility tiles above the characters head in the two screenshots above and you will have a perfect tree that actually behaves like a tree. In the above pic he is standing on a root while the leaves are over his head.

Hi, this idea again came up in another thread. The basis for it are two games joined together. 1) Pexeso, trying to find two of same kind in many other pieces. You uncover one and then try to find the other, if you find it, they both stay uncovered. If you don't find it, both are turned over again and you guess again. Maybe it is called another way in English. 2) Follow the line has simple premise, you have a maze and try to navigate through it and if you collide with wall you start over again. Or are penalized in some other way. So let's start with the overview. The map for this one test was rather small. I think it s 17 by 14. Here is the image. The green tiles are just ordinary green rug from A tileset from Indoor, I liked the effect it did on edges. (I am sure something magnificent could be done with proper tileset or parallax mapping). The black circles are events placed on beige rug. The orange tiles are all events, more on that later. The 1-1, 1-2 untill 3-1 and 3-2 are the pexeso "tiles" that are matched together. The circle is displayed when you don't see the face of the tile. I created simple "character" for that and replaced the player with an image of soldering pen tip. Any events or your own pictures can be used of course For the purpose of this minigame I used several switches. I guess variables could be used in similar way, maybe to better extent, but in this case, switches. The switch 1 will be used to show if a pexeco piece is flipped over. Switches 2 to 7 are used to mark which piece exactly is flipped. (and here is probably the thing where single variable could be most likely used) Switches 8 to 10 are used to mark when pair of same pexeso pieces are flipped. That's for the pexesoy thing. For the maze I used the region id feature in connection with 3 variables. One for saving the terrain tag, and two for the player's X and Y position. The map then looks like this with the regions. As you can see the tagged region surrounds the maze where player is supposed to move. As for the pexeso pieces I used three pages per event. The first page deals with the pexeso piece when it is not revealed (in my case they are in shape of circle). The logic is that it checks if there is another piece revealed (the switch no. 1) and if so it checks if the revealed piece is the one that goes in pair with the one activated right now. So if you activate 1-2 piece it checks if 1-1 piece is revealed too. If you have match, the switch no. 8 (both matching pieces 1-1 and 1-2 revealed) is turned on and switch no. 1 is turned off, signaling you are to turn another single one. If you turn over a piece and its twin is not revealed, but not matching one is, this one is shortly revealed. This is done viea Set Move Route that makes the piece turn (in this case down, the top row in !$pexeso.png) and then back to circle, hiding it again and turns of all switches used for the pieces (batch switch flip, 1 to 7, because we turn off the flipped pieces indicator and that there is none revealed currently). If you turn a piece and no other piece is revealed yet (both conditions fail) this piece and its corresponding switch is flipped (in this case 1-1) and switch no. 1 is turned on to mark that a piece is revealed. The next two pages of the event deal with revealing the piece under conditions of it being the active piece you look the twin for and the condition that you found both pieces of the pair. The Graphics are hard to see, since they are simple and only black, sorry. But it is, in this case, an electronic schematic for resistor. The other events are set in same way, just with properly changed switches, turning and graphics. These are the pictures for the 1-2, 2-1, 2-2, 3-1 and 3-2 pexeso piece events. Also note that each of the pexeso piece event is set to be BELOW character and to be triggered by PLAYER TOUCH. So for now the pieces are set. You probably noticed the common event in each of them, I will get to that later. For now, I will show how I set the path (it is not needed, really, it just adds another flair to it and a bit more difficulty.) Each square of the path is in fact an event of two pages. This makes it so that if you step on the tile (defaultly orange - had to adjust a tile in B, C, D or E) it checks if there is an active pexeso piece (switch no. 1) and if so, it flips self switch. This activates the second event page that uses red tile and if activated it resets the pexeso switches 1 through 7 and turns itself off. The second page is triggered when BOTH self switch AND switch no 1. (a pexeso piece is active) are turned on. Both pages are set below character and activate on player touch. This means that when you flip a pexeso piece and start looking the twin, you cant step on same tile twice or the pexeso piece you are looking for resets. (Now that I think about it the self switch turn off is probably redundant, as the common event in the pexeso pieces takes care of that hmm) Anyway, for the common event that is called. As shown this common event calls a script code that goes for array from 7 to 44 over the array of self switches. The key which self switch to use is following, map ID where the event is ($game_map.map_id makes it the ID of current map) the number of the event (in this case the events for the floor route have IDs of 7 to 43 => the 44 is not included because ot goes from 7 to 43, it is <7,44) interval) and which self switch to flip ("A" in this case). All those self switches are turned OFF by setting them false. That is all. As said this common event is called when you activate a pexeso piece, turning off the self switches on all the tile floor, turning them back from red to orange in both cases of finding the match or missing. NOTE: This is why the path of the maze was filled with events almost as last, to make their IDs go one after another, so the cycle can be used. Now for the last piece of the minigame. The part where you must not step out of the maze. For that purpose there is the control event that runs as parallel process. This event constantly checks the player position and saves it into two variables (X and Y position), then checks the Region ID on the map for those coordinates. If the Region ID there is 1, it means the player stepped off from the maze. In that case all the pexeso switches are turned off, even the ones that say a pair was found so be carefull, if you miss the route, you start all over, completely. The condition is hard to see, because I did not want to use three conditions, but used script in one condition, it checks for the three switches (8, 9 and 10) for pexeso pairs if all three pairs were found. $game_switches[8]==true && $game_switches[9]==true && $game_switches[10]==true If so, the game puts out a message that player won and the controll event turns itself off via self switch B (B used just to be sure :-) ) The second page of the control event is empty and the only condition is the B switch turned on. I think that is all so, to sum it up. Player has to move through the maze to find matching pairs, if the pair is mismatching, you look again, though any revealed matching pair stays revealed. The looking for pair is also interrupted if player tries to backtrace. If player steps out of the path any and all pexeso pieces are hidden again and the player starts anew. A picture how it looks in middle of play... I am sure it can be enhanced, both code and graphical wise, especially graphical wise. Like making the player image, the pen, sparkle when active and use parallax maping and such.

Hi, there was a thread about minigames and I was thinking about some I played or an "ordinary" ones in life. I was also working on rather simple "jump" over thing and decided to develop it a bit. So in the first part, the number guessing game. 1. Guess the number The premise is simple. You get a range of numbers and you have to guess one from that range. The whole thing can be subject to a counting of number of tries you already used to give it a true meaning. The rule goes that if you don't guess the number the range from which you guess is adjusted. For example if the number to guess is 26, from range 1 to 100 and you try to guess 78, the range is adjusted to 1 to 78 and you guess again. If you then try 6, the range gets adjusted to 6 to 78 and so on. As I said, it can be subject to a certain number of tries. I used 4 variables for this. 1st is for the random number, 2nd is for the lower number of the range, 3rd is the upper number of the range and 4th variable is for the guess. To test it out I used a single event. of two pages which was set up followingly: Now, when you first activate the event, it initializes (picks random number and sets the range) and flips a self switch. The event then switches to the second page, where the core of the minigame is, asking you to guess the number, offers the number input and then checks if you guessed right. If not the range is adjusted and you are informed to try again, which you do by activating the event again. If you guess right the event switches the self switch and upon next activation initializes itself anew. As I said before, it can be adjusted, either to run in loop untill you guess right or run out of tries, etc. 2. Jumping platforms 2.1. The first jumping platforms are rather primitive and easy with each platform being an event of below character priority and action button trigger. The platforms are placed horizontally and there is one square empty between them. Each platform event then has check to which direction the player looks (in this case left or right as I placed them horizontally) and then makes the move route on player, jumping by 2 squares. The starting jumping platform is just the same except the direction you don't need is removed. The map looks like this. This is example of the middle platform (event no4 as I created the side starting and ending platforms as first and second). Each of them (3,4,5) are the same, the start and end have just jumping in one needed direction 2.2 To make it more challenging, I made the platforms move on their own, up and down with "Autonomous Movement" set to Custom and the movement looking like this This makes the platforms move up and down in a way that when the two side platforms (event 3 and 5) go down, the middle platform (event 4) goes up. They are also permantly set as Through, so they can move in impassable tiles. Next the starting and ending spots were adjusted (event 1 and 2) to look like this You can notice the variable 5 (5, because it is same project as the number guessing where I used variables 1 to 4). That is to indicate on which moving platform the player is. It will be used later. Now as the platforms move, we want the player to be able to jump on the other platforms only sometimes, so the code on those platforms is adjusted. The adjustment is so before jump, the code checks both the player facing direction and if the player is alighned with the other platform. You may noticed that there is a turning walking and through fix tampering when the player jumps from the most sideway platforms, that is to ensure the player will be moving properly again after s/he gets down from platforms. It is because we are switching those because we move with the player in another event, to make illusion the player moves with the platforms. That last event is a paraller running event with three event pages, each one taking care of the player movent on each of those three platforms (and I am sure it could be adjusted with the variable telling me on which platform the player is, but this is more basic-y). The controll event is set like this: (I used the pictures just to see it changing acordingly) This event is always running in parallel and checks whether or not the player Y position is the same as the Y position of the platform the player is standing on (as stated before, it could possibly be done on one page while referencing the platform via variable, but not quite sure what would happen if the pattern of the platform moves varied differently, then again that is not so in this example and this way is sufficient). If difference is detected, the player is moved to the same position as platform. Since the platforms move relatively slowly, the lag of player moving with them is small (though noticeable, maybe slower moving platforms would lessen the optical lag). Various properties are tampered with, namely the walkign animation, to make the player appear standing on the platform, the through flag, to make the player be able to move with the platform and the direction fix, so the player is facing the same direction when the platform moves. Then those flags are turned off again for a while so when the platform stands still, player can turn around. With setup like this, there is one problem though, since the jumping from platform to platform is taken care off by the platform events, if you try to jump and there is no platform to jump to, the platform you are standing on doesn't move for a short while (similar to when you activate a walking NPC, it stops the walking during the event execution). So the player can cheat by repeatedly activating the event and thus wating on the same spot untill the other platform aligns itself. For that a more unforgiving jumping platforms can be created. 2.3 Deadly platforms allow you to jump in any direction, but if there is no other platform, further proccessing is made, eg telling the player of the fail and doing more of desired stuff. For this we can leave the setup as we had in before, but adjust the code of the platforms themselves to following: These changes ensure that if there is platform to jump at, nothing else happens, but if there is not neighboring platform ready, the player is told about his/her death, and the player is transported to another map. This is because if the player was transported back on the same map, the platforms would not reset their position and the text, because it is displayed by the platform event stop the platform's movement makes the platforms not aligned properly. But with RE-Entering the map, all the events are reset, thus the platform align again. (Practically you could transfer the player during a fade out screen to another map and from that map transfer him to the platform map again.) This partially eliminates the player cheating by activating the platform event and making it wait in spot, as the player jumps into depths. I am sure many variations can be made of these. If you make the platforms move one square, then turn off their THROUGH flag, the player can step on them, without jumping, by walking. Then you need to turn their THROUGH flag on again, though, to make them able to move again.

The tutorials posted here range from beginner to lower range intermediate. They are video tutorials so that anyone can easily follow along. They will cover the basics of: Making your own pixelated tileset Making an animated sprite from a behavior sprite Making a base from formentioned sprite Making add ons for the generator in ace Taking/Making XP sprites and using them in ace TUTORIALS Tileset basic Dancin Sprite Behavior Along with base creation Making Addons XP to VX/VX Ace Ripping sprite hair to make our own add on Recoloring an existing sprite Making a tileset to match the rtp Continuation of the last tutorial, this time making a chair. Making more furniture in rtp oh yeah! Making an animated water tile following World of Noels tutorial from Deviantart NEW! NO more blurry lines with free transform If you have any questions feel free to ask. ^^

Here's my 3-part series on creating autotiles! Each video has chapter links in the youtube description so you can skip around. Part 1 covers how autotiles work (see diagram below), the differences between A1-A5, borderlines, counters, etc. Part 2 shows how to create a standard seamless tile -- skip this if you already know how. Part 3 shows how to make an autotile! Follow my order and it's dead simple, and you really don't have to worry about whether things will line up! I show some advanced Photoshop tricks to speed up the process, but you can also use simple tools like the eraser. Part 2 - Seamless tile (skip if you want)

(This is an intermediate tutorial -- I do assume you know how to create conditional branches and things. Beginners can probably follow along but may need to pause/rewind. You can check out my beginner videos in my signature that will explain ALL the basics if you have any trouble.) Here are multiple methods for random loot (stats are not random, only which items you get are). This can be used for items, weapons, armor, etc., and you don't need to only use treasure chests -- maybe an NPC will give you some loot? This tutorial was a request! Let me know what else you'd like to see, in the comments. Malagar updated Galv's script to add some new functions! You can get both here: http://www.rpgmakervxace.net/topic/25462-galvs-random-loot-drops-v-11/ Visit http://crackedrabbitgaming.com/guides/rpg-maker-vx-ace-tutorials/ for a list of scripts I use in these videos.