The Coolest Thing I've Ever Made on RPG Maker

[Wavelength]

It took me most of the month to create, and honestly came as the result of far too many all-nighters, but I'm proud to say I've finally created a demo-able Action Batlle System on VX Ace.



The current version has three (placeholder-ish) characters, a few fully functional enemy types, about a dozen cool spells to sling at your foes, and a couple of surprises to look out for. Most of the setup is completely scalable (I can copy it to new maps, create new instances of an enemy in seconds, etc.), so I'm hoping to utilize this system in a full game in the future.

Credit where it's due: I used Nelderson's Text Pop Over Events script for the damage/healing numbers and Tsukihime's Large Script Call script to make my "Script..." event commands more flexible. Besides that, everything you see in the demo is completely original.

Want to try the ABS out for yourself? The demo's available here. Please note that you need the VX Ace RTP to play the demo, which you can download here if you don't already have it. Normally I'd upload a second version that includes the RTP, but given how poor my upload ability is lately (the above 400MB video literally took six hours to upload to YouTube), that will have to wait.

Whether you tried the demo or watched the video, I would love to hear your thoughts on this Action Battle System. Does it feel right, is it fun, is it relatively balanced? Would you prefer a more developed form of this ABS in a full game, as opposed to a good implementation of the standard RPG Maker battle system?

[Jamos]

Re: The Coolest Thing I've Ever Made on RPG Maker

I would kill to have half the understanding to do that. Then I might actually be able to complete a game... or get halfway through... the beginning.

[TheHonorableRyu]

Re: The Coolest Thing I've Ever Made on RPG Maker

Okay so I spent a good 40 minutes with the demo thus far. There's a lot of cool, inventive touches! I especially like the dropping stone feet, the player-controlled kinetic ball, the knight enemy's straight dash, and the use of boulders to create walls for crowd control. Good work with the programming, too. The main issue with a system like this is that the hit detection can be a bit sluggish and spotty, which is mostly an RPG Maker thing. For this reason I'd choose Gamemaker before RPGM for an ATB, which is not to say that this project isn't worthwhile.

A few suggestions to enhance what you have:

• I'd create an enemy that dies with one or two normal attacks (perhaps one hit from the brawny cat girl and two hits from the others, making there a strategic reason to use that character in such situations) and throw them into the mix. I'd also give it or perhaps other enemies a more predictable movement path.
  
  Right now the lowest level slime--representing the lowest threshold of combat--eats up several hits, and between the spotty hit detection, the sluggish 4-way movement scheme, the small range of normal attacks, and the erratic movements of these enemies, it's kind of a chore to have to deal with these guys (especially when there's just like 1 or 2 of them around and you can't get a high return for your mana from hitting a bunch with one spell) and I'd rather just avoid them. But you have to fight get EXP and treasure chests, so it feels like an obligation.
  
  
• I'd place text indicating the corresponding w a s d keys over the four elemental bars at the bottom left. Between all the different spells spread across the three characters, the timing and aim required for them to connect, and the pauses before you can try again, the control scheme feels aloof rather than tight at first and some text indicating what key is mapped to what elemental spell would help. I found myself having to stop to think what spell is going to come out when I press what key. The name of the currently equipped spell would help as well. Also, currently the keys are mapped to the reverse of expected (Fire is listed first on the GUI and in the set up menu but it's mapped to the d key rather than w) and some of the spells are different colors than the element (e.g, the kinetic ball is purple rather than a warm red), adding some counter-intuitiveness. In my opinion it's best to help the player become one with the controls as soon as possible.
  
  
• I'd make it so that defeat enemies drop or display color-coded gems or numbers when killed that indicate what kind/how much elemental mana the player is getting for defeating it. Right now it's a bit awkward to have to carefully watch numbers.

***EDIT***
Played some more, got my characters to level 11. Liking the rewards you get from boss clears.

As I was raising levels there was a window in there where I was having the most fun, when the slime enemies were dying in one or two hits but the wizard and knight enemies were still taking several. But it ended pretty quickly because killing enemies that quickly at the levels of EXP they grant caused me to rapidly gain a few levels. Then it became too easy to kill enemies and restore my elemental mana. Things are just at the tech demo/proof of concept stage but if you start using the system for a full game I'd look at fine-tuning the range and kinds of enemies that appear in a given area as well as the EXP and mana restoration they grant.

There's a couple glitches with the Ride the Lightning spell. You can use it and end up inside walls, or escape the monster traps. Another quirk: with some spells (like the kinetic ball) it's easy to kill all the enemies in a monster trap without even entering it, but if you step into the region afterward the monster trap text will still activate and then immediately disappear.

[Wavelength]

Re: The Coolest Thing I've Ever Made on RPG Maker

Thanks for the compliment, Jamos! And thanks so much for all that wonderful advice, Ryu! I appreciate that you liked a lot of the player and enemy skills; they are at the core of what I am trying to make into a strategic action system. Hopefully you had some fun poking around with it and I love some of this feedback. To respond and follow up on some of your comments:

• I'll just get it out of the way up-front: I'm honored that you played the "tech demo" for over an hour, but I didn't think anyone would stick with it that long! It's no wonder that by Level 11 you were able to slice through enemies with ease. My biggest priority for the demo was making sure players wouldn't succumb to health/mana attrition, so all balancing was done around that. As the real game is built, monster health, damage, item gains, EXP, and mana restoration will be changed dramatically.

• Hit detection, from the very start, proved challenging. If a character is moving from one tile to another, projectiles that seem like they should hit often pass through them. To improve it, I've given most skills "timing windows" where it will loop through every few frames for maybe a quarter-second and keep checking to see if an enemy is in the hit area. It's definitely still not in a place where I'd be happy releasing it in a game, so I need to keep playing with the timing windows and animation timing as I work on it.

• On the same lines, you mentioned Game Maker (I worked with this many years ago and started an Arkanoid-like game, so I definitely see how it runs action mechanics better). But I want to integrate this ABS into a game with some more standard RPG mechanics, where you have items to manage and you're often talking to NPCs and you can roam freely around large maps. (I'm even considering porting my development progress on Nights in Blue over to this project, since I feel a lot of the puzzles play really well with this action system and the ability to create objects/projectiles.) Have you worked with Game Maker and do you know whether it can handle this kind of "normally RPG" stuff well? I'd love to hear your thoughts on the feasibility.

• Different weapon types will have different attack patterns as I build the system, and I'll definitely work on the currently-unwieldy hit timing for basic attacks. To be honest, I found it more rewarding to work on the spells, so they took priority during the first month.

• I really like your suggestion for more predictable move routes; in general I was using the default "Approach" settings (except for stuff like the toy soldier's Dash attack), and as enemies closed in on me, they were dodging more of my projectiles than I care to admit. This is one area that will receive a lot of work in the near future.

• Great suggestion on the GUI/HUD interface; this is exactly the kind of feedback I was hoping to hear when I posted it. I'll add that information to the HUD. I normally think of Fire and Ice/Water as the first two elements, but I think of Air as "Up" (where the W key is) and Earth as "Down", so that's why I mapped it that way - but now that you brought it to my attention, I see how this dissonance just makes it harder for the player. Thanks for the nice catch. In the long run, I'd love to allow the player to map their own buttons.

• Color-coded gems would be tough (though perhaps doable) because each event can only show one animation at a time. If I can think of a good way to make it work, it would be a great touch. If not, I could probably flash "+X" numbers on the HUD's mana bars when you gain mana.

• What you call a glitch, I call a feature! My Microsoft tendencies aside, using "Ride the Lightning" to get on top of walls was intended behavior; I thought it was way too cool to leave out of the demo. I could use Region IDs to prevent this. But I feel like these "creative" uses of the spells are pretty fun, personally, and I only foresee removing them if they prove so good that they crowd out other potential battle tactics.

• The Monster Traps, inspired by Sword Art Online, were one of my favorite elements to make. I did think through different ways to handle sniping enemies (or vice versa) before you activate the trap, or escaping the trap with flash spells (the prime reason for trap deactivation after 90 seconds) - and the behavior you described is exactly what I came up with. If you were creating this mechanic, how would you design it?

Once again, thanks a ton for the time you spent with the demo and for sharing your thoughts in such detail. It's great to have another perspective, especially one that knows design so well, as I'm working on stuff.

[TheHonorableRyu]

Re: The Coolest Thing I've Ever Made on RPG Maker

I'll just get it out of the way up-front: I'm honored that you played the "tech demo" for over an hour, but I didn't think anyone would stick with it that long!

That's what friendly neighborhood play testers are for!

But yeah, I realized that you weren't trying to balance for that many levels. Just thought I'd mention that somewhere between levels 1 and 11 there was a brief sweet spot where I was having the most fun.

Hit detection, from the very start, proved challenging. If a character is moving from one tile to another, projectiles that seem like they should hit often pass through them. To improve it, I've given most skills "timing windows" where it will loop through every few frames for maybe a quarter-second and keep checking to see if an enemy is in the hit area. It's definitely still not in a place where I'd be happy releasing it in a game, so I need to keep playing with the timing windows and animation timing as I work on it.

What happens if you drastically increase the collision check frequency? The game doesn't bog down from all the calculations does it? A quarter-second may not sound like a lot, but it's plenty of time for projectiles to appear as if they're passing through objects without hitting them. About a quarter-second is about a 4 frame per second frame rate, whereas VX Ace runs at 60 fps and cycles animation frames at 15 fps by default.

On the same lines, you mentioned Game Maker (I worked with this many years ago and started an Arkanoid-like game, so I definitely see how it runs action mechanics better). But I want to integrate this ABS into a game with some more standard RPG mechanics, where you have items to manage and you're often talking to NPCs and you can roam freely around large maps. (I'm even considering porting my development progress on Nights in Blue over to this project, since I feel a lot of the puzzles play really well with this action system and the ability to create objects/projectiles.) Have you worked with Game Maker and do you know whether it can handle this kind of "normally RPG" stuff well? I'd love to hear your thoughts on the feasibility.

Yeah that's the rub: there's things that take a month in RPG Maker but take two days in Game Maker, but other things that take two days in RPG Maker take a month in Game Maker. I have worked with Game Maker before, primarily for little shmup, action RPG, and tower defense type stuff with light RPG elements. With Game Maker you'd probably be stuck building a lot of the "normal RPG" stuff from scratch. It's difficult to learn, though definitely doable, and there are scripts and tutorials available online. Barkley's Shut Up and Jam: Gaiden, ostensibly a joke game but actually one of the best indie RPGs ever made, with battle and other play mechanics better than many professional games, was actually made in Game Maker, and it has all the "normal RPG" stuff you'd expect from a traditional JRPG. Turn-based menu command battle system, NPCS and themed message system, item/equip/status/shop menus and inventories, etc. So much so that many people mistakenly think it was made in RPG Maker. It actually was started in RPG Maker 2003 but then switched over and completed/published in Game Maker 6.1. Ultimately I think it comes down to what elements do you want to be the most robust in your game and then choosing the engine best suited for it.

I really like your suggestion for more predictable move routes; in general I was using the default "Approach" settings (except for stuff like the toy soldier's Dash attack), and as enemies closed in on me, they were dodging more of my projectiles than I care to admit. This is one area that will receive a lot of work in the near future.

Cool. There's a lot of inspiration to be had here from 2d action rpgs and sidescrollers, like Zelda or Castlevania. Some enemies "puppyguard," walking back and forth or bobbing up and down to guard a passageway (right now in the demo it's too easy to just bypass enemies and get to the boss without fighting if you wanted). Some enemies "hug" the walls, traversing their perimeters. Some regular enemies just bob up and down and just fire projectiles in straight lines regardless of how close you are. Etc.

Depending on how creative you eventually wanted to go with your environments, I could also definitely see some enemies traveling on "rail" paths (literal or otherwise). Like in your present map you could have an enemy riding on the mining cart and taking potshots at you as it passes by. Or you could be in a toy factory with toy soldier enemies on a conveyor belt, or in an amusement park with slimes on a carousel.

Color-coded gems would be tough (though perhaps doable) because each event can only show one animation at a time. If I can think of a good way to make it work, it would be a great touch. If not, I could probably flash "+X" numbers on the HUD's mana bars when you gain mana.

You wouldn't necessarily need an explosion of little gems graphics flying everywhere. Just one might do, either as one gem that represents the total amount of elemental mana you're getting, or as one graphic with multiple gems depicted in the same graphic file. You could also have the enemy event, after the enemy dies, change to a new page with the graphic set to the gem(s), which then the player could collect by walking into it (rupees in Zelda-style) or which displays momentarily then disappears and adds to your mana automatically.

What you call a glitch, I call a feature! My Microsoft tendencies aside, using "Ride the Lightning" to get on top of walls was intended behavior; I thought it was way too cool to leave out of the demo. I could use Region IDs to prevent this. But I feel like these "creative" uses of the spells are pretty fun, personally, and I only foresee removing them if they prove so good that they crowd out other potential battle tactics.

I can definitely see that; I guess I had a "was this supposed to happen?" kind of reaction because it seemed too good. Like it seems that the enemies won't hit you at all if you're on top of the walls and don't step onto any of the tiles that are adjacent to the floor.

But yeah, there's a lot of creative potential for the Ride the Lightning skill as you design more maps. Like maybe in some areas you could use the skill to cross otherwise uncrossable chasms or bypass locked doors to progress in the game or to find secrets.

The Monster Traps, inspired by Sword Art Online, were one of my favorite elements to make. I did think through different ways to handle sniping enemies (or vice versa) before you activate the trap, or escaping the trap with flash spells (the prime reason for trap deactivation after 90 seconds) - and the behavior you described is exactly what I came up with. If you were creating this mechanic, how would you design it?

Assuming you wanted to keep it possible to snipe all the enemies in a monster trap before entering it: I'd simply make it so that if you did kill all the enemies first the treasure chest would appear with a sound effect (and maybe a "monster trap destroyed" kind of message) and the regular enter-monster-trap event would be deactivated. As it stands, the enter-monster-trap warning starting and then ending as suddenly is a bit odd, and I could see some players seeing this before they saw a monster trap activate normally.

However I'd actually want to add a play mechanic that prevents easy sniping for monster traps or for certain enemies in general. Like there could be a forcefield that blocks projectiles surrounding monster trap rooms, which is deactivated when all the monsters (or perhaps the monster or tower generating the forcefield) in the room are destroyed. And some enemies themselves could have magic shields or attacks that block or cancel projectiles. There's a lot of variants to how this could be handled. For example:

1) Some enemies might have a magic shield or attack that cancels or (perhaps reflects) projectiles, but (like your toy soldier's charge) it takes some time to charge before it comes out, making it so that the enemy will have enough time to cancel a projectile fired from long-range but not one fired from mid-range.
2) Spell projectiles could "degrade" over time, meaning that if they travel a certain distance they'll be cancellable by enemy shields or attacks.
3) Some enemies might resist or block spells of a particular element, making it a more likely situation that you won't have enough elemental mana available to hit it with a projectile from a particular element it doesn't block.
4) Some enemies might fire their own projectiles at long range, and if their projectile and your projectile come into contact they'll both cancel out, but the enemy switches to close range attacks once you get close to them.
5) Different player and enemy projectiles could have different "priorities," meaning a higher priority projectile will eat up projectiles of a lower priority and keep on going. This could also have an elemental aspect, i.e., certain elements have higher or lower priority to others in a paper-rock-scissors fashion.

Right now it seems that long-range sniping is the best way to deal damage while avoiding it for all the enemy types. I found myself relying on the kinetic ball for all the regular enemies and the boss as well. At least part of this is due to the fact that the ball stays on the screen for so long without disappearing, so hit detection is less of a problem for it than other spells, but I'd still want to make it so that at least some enemies are more dangerous or invulnerable from afar so that you'll need to bring the battle closer to them.

[Wavelength]

Re: The Coolest Thing I've Ever Made on RPG Maker

What happens if you drastically increase the collision check frequency? The game doesn't bog down from all the calculations does it? A quarter-second may not sound like a lot, but it's plenty of time for projectiles to appear as if they're passing through objects without hitting them. About a quarter-second is about a 4 frame per second frame rate, whereas VX Ace runs at 60 fps and cycles animation frames at 15 fps by default.

I was unclear because I was talking about two different types of skills at once. Tile-targetted skills (like Water Bomb, Rockfall and Blast) are checked every few frames, for about a quarter-second (depending on the skill) - so in that quarter second, it's usually checking five or six times. This seems to work pretty well; I haven't noticed any hit detection problems on these spells. If you did, please let me know and I'll check into it (one oddity I am aware of - Rockfall's collision detection triggers a little earlier than you'd expect from the graphic and it's because of the way I evented it, but otherwise its hit detection is working properly).

On the other hand is Projectiles, where there are some noticeable hit-detection issues (mostly when characters are walking from one tile to another). I checked into my Projectile Handler parallel-processing event and it only has a 1 frame wait at the end. I don't know how many frames' worth of time it actually takes to run through the event (which loops several hundred times to check each projectile and each event), but my instinct is that, at least on my relatively-fast computer, it's under one frame's worth of time. So I don't know why the hit detection is spotty on these, but it's something I will play with (maybe add additional projectile handlers or something to run concurrently) to see whether I can improve it.

The only time I've gotten lag was when I originally created the HUD. It lagged to an unplayable level. I changed it to only update every several frames. It still lagged somewhat. I then got smart and had it check whether your player or stats have changed before it refreshes anything graphically, and that removed all traces of lag.

Yeah that's the rub: there's things that take a month in RPG Maker but take two days in Game Maker, but other things that take two days in RPG Maker take a month in Game Maker. I have worked with Game Maker before, primarily for little shmup, action RPG, and tower defense type stuff with light RPG elements. With Game Maker you'd probably be stuck building a lot of the "normal RPG" stuff from scratch. It's difficult to learn, though definitely doable, and there are scripts and tutorials available online. Barkley's Shut Up and Jam: Gaiden, ostensibly a joke game but actually one of the best indie RPGs ever made, with battle and other play mechanics better than many professional games, was actually made in Game Maker, and it has all the "normal RPG" stuff you'd expect from a traditional JRPG.

Thanks for this!! I downloaded Barkley (ha! that sounds weird to say), and will give it a try this week; I'll also look around and see if I can find how successful other efforts have been to make real RPGs on Game Maker.

Cool. There's a lot of inspiration to be had here from 2d action rpgs and sidescrollers, like Zelda or Castlevania. Some enemies "puppyguard," walking back and forth or bobbing up and down to guard a passageway (right now in the demo it's too easy to just bypass enemies and get to the boss without fighting if you wanted). Some enemies "hug" the walls, traversing their perimeters. Some regular enemies just bob up and down and just fire projectiles in straight lines regardless of how close you are. Etc.

Depending on how creative you eventually wanted to go with your environments, I could also definitely see some enemies traveling on "rail" paths (literal or otherwise). Like in your present map you could have an enemy riding on the mining cart and taking potshots at you as it passes by. Or you could be in a toy factory with toy soldier enemies on a conveyor belt, or in an amusement park with slimes on a carousel.

I'm envisioning the system much more in the conceptial framework of adventure (like Banjo-Kazooie) than action (like Castlevania), and as such, any areas that are narrow enough to properly utilize enemies that do things like simply pace back and forth are going to be bits of a much bigger, more-open map.

That being said, while the demo enemies have extra behaviors (like the Specter's fireball or the Soldier's dash), I totally understand your point about them having such similar movement. I'll make sure to make enemies more diverse in this regard as I build out the game.

I think one of the main reasons that enemies are (maybe too) easy to avoid right now is that there's no movement setting between 3 (half the speed of the player) and 4 (same speed as the player). One of those places I bet Game Maker could do much better. Setting them to 4 seemed too uncomfortable for the demo, so I left them at 3. What I might do as I adjust move routes is to allow enemies to "notice" the player, not only adjusting their route but also their speed.

Oh, and I LOVE the idea of a projectile-using enemy riding the minecart past and trying to nail you

You wouldn't necessarily need an explosion of little gems graphics flying everywhere. Just one might do, either as one gem that represents the total amount of elemental mana you're getting, or as one graphic with multiple gems depicted in the same graphic file. You could also have the enemy event, after the enemy dies, change to a new page with the graphic set to the gem(s), which then the player could collect by walking into it (rupees in Zelda-style) or which displays momentarily then disappears and adds to your mana automatically.

The amount of mana received by each party member when you defeating an enemy is random, based upon parameters specific to that enemy. So having lots of gems flying in a single animation, that will be cool (and I probably will do it), but I don't think there's a good visual way to show the actualy amount of mana recovered, short of literally printing the number somewhere onscreen (like the HUD).

I can definitely see that; I guess I had a "was this supposed to happen?" kind of reaction because it seemed too good. Like it seems that the enemies won't hit you at all if you're on top of the walls and don't step onto any of the tiles that are adjacent to the floor.

But yeah, there's a lot of creative potential for the Ride the Lightning skill as you design more maps. Like maybe in some areas you could use the skill to cross otherwise uncrossable chasms or bypass locked doors to progress in the game or to find secrets.

Yup! It quickly became my favorite skill, and there will eventually be a few other skills with the potential to "flash" to another location - one skill I have in mind is a projectile where if you hit an enemy, you get a few seconds' window where you can re-activate the skill to flash behind them, wherever they've gone. Skills like this are going to be used in puzzles like the chasms you mentioned, or to get to otherwise-unreachable treasures. At some point I have to figure out how to rescue the player if they run out of mana on one of these puzzles.

Conjured objects like Rockfall's boulder are going to have a lot of uses, too, like you probably saw on the buttons "puzzle" in the demo, or creating a path across a raging river if you don't want to wander all around hitting switches that lower the water level. Ways around the standard "railroaded" puzzle solutions is something I've always felt was sorely lacking from JRPGs and I think if I can pull it off well, it will be incredibly rewarding for the player when they solve an obstacle "their way" instead of trying to solve the psychology of the developer.

The ability to this kind of thing with your skills and make it feel right at home alongside exploration and battle is what made me start leaning toward using the system for Nights in Blue, and it's a tough decision because I really liked what I did for it with XP's DBS as well.

Assuming you wanted to keep it possible to snipe all the enemies in a monster trap before entering it: I'd simply make it so that if you did kill all the enemies first the treasure chest would appear with a sound effect (and maybe a "monster trap destroyed" kind of message) and the regular enter-monster-trap event would be deactivated. As it stands, the enter-monster-trap warning starting and then ending as suddenly is a bit odd, and I could see some players seeing this before they saw a monster trap activate normally.

However I'd actually want to add a play mechanic that prevents easy sniping for monster traps or for certain enemies in general. Like there could be a forcefield that blocks projectiles surrounding monster trap rooms, which is deactivated when all the monsters (or perhaps the monster or tower generating the forcefield) in the room are destroyed. And some enemies themselves could have magic shields or attacks that block or cancel projectiles. There's a lot of variants to how this could be handled.

Yeah, I do like the idea of "Monster Trap destroyed" happening without entering the trap if you manage to pick off the entire group from outside. Thanks!

I'm not going to do a force field (for Traps, at least) since I think it would make it far too obvious that you're about to walk into one.

Ever since you mentioned this in the first post, though I've thought a lot about whether it's appropriate to be able to snipe the danger out of monster traps, and I'm on the fence. One thing I might do is have most (though not all) of the trap enemies appear only once the trap is activated. You could pick a few enemies off, you think the area is clear... then BAM! You walk in and find out what was waiting for you.

For example:

1) Some enemies might have a magic shield or attack that cancels or (perhaps reflects) projectiles, but (like your toy soldier's charge) it takes some time to charge before it comes out, making it so that the enemy will have enough time to cancel a projectile fired from long-range but not one fired from mid-range.
2) Spell projectiles could "degrade" over time, meaning that if they travel a certain distance they'll be cancellable by enemy shields or attacks.
3) Some enemies might resist or block spells of a particular element, making it a more likely situation that you won't have enough elemental mana available to hit it with a projectile from a particular element it doesn't block.
4) Some enemies might fire their own projectiles at long range, and if their projectile and your projectile come into contact they'll both cancel out, but the enemy switches to close range attacks once you get close to them.
5) Different player and enemy projectiles could have different "priorities," meaning a higher priority projectile will eat up projectiles of a lower priority and keep on going. This could also have an elemental aspect, i.e., certain elements have higher or lower priority to others in a paper-rock-scissors fashion.

I like these ideas a lot, particularly #s 1 and 4. It will take some scripting to make enemies use these in smart ways, but I think it will be worth it in terms of creating a fun play experience.

For example, the Specter currently shoots a fireball if a certain random number has been chosen and the player is within 4 tiles of the direction the Specter is facing. I could modify it to have it also shoot if a projectile is coming at its frontside (and maybe require that the player would need to be more than two tiles away in order to do so). I think this is kind of what you were describing for #4, and I do think it would really be a "whoa, that's cool" moment for the player the first few times they notice their snipe attempt getting bamboozled.

What I really love about your suggestions is how they use the aspects of time and position to really create the kinds of incomparables that can only be abstracted even in a really good turn-based battle system. In certain situations that long-range projectile will be golden, and in others you'll need to move in close enough that it's impractical.

Tangentially related to #3, enemies will have elemental strengths and weaknesses. I don't foresee creating many that would "no sell" projectiles, but large resistances against elements that use them (specifically Fire in the demo) could achieve the effect you described.

Right now it seems that long-range sniping is the best way to deal damage while avoiding it for all the enemy types. I found myself relying on the kinetic ball for all the regular enemies and the boss as well. At least part of this is due to the fact that the ball stays on the screen for so long without disappearing, so hit detection is less of a problem for it than other spells, but I'd still want to make it so that at least some enemies are more dangerous or invulnerable from afar so that you'll need to bring the battle closer to them.

I nerfed Kinetic Ball's cost/power tradeoff so many times in the three days between completing its function and releasing the demo... and it's clear it still wasn't enough! It's the only long-range (greater than 4 tiles) snipe tool available in the demo, so I think the fact that it seems overpowered suggests that you're right about some enemies needing ways to avoid being picked off from long range, or otherwise increase the amount of inherent risk in using snipey skills.

Once again thanks for all of this feedback. It's been great to have with this ABS, and of course it was really invaluable as I was crunching for the contest version of How Badly. I definitely "owe ya one" and if you ever want some feedback or any other type of help with the very-cool sounding projects that you're developing, don't feel shy about reaching out.

[TheHonorableRyu]

Re: The Coolest Thing I've Ever Made on RPG Maker

I was unclear because I was talking about two different types of skills at once. Tile-targetted skills (like Water Bomb, Rockfall and Blast) are checked every few frames, for about a quarter-second (depending on the skill) - so in that quarter second, it's usually checking five or six times. This seems to work pretty well; I haven't noticed any hit detection problems on these spells. If you did, please let me know and I'll check into it (one oddity I am aware of - Rockfall's collision detection triggers a little earlier than you'd expect from the graphic and it's because of the way I evented it, but otherwise its hit detection is working properly).

Ah, I see. There were times when I felt like Water Bomb passed through enemies. It may have to do with the size of the event's hit detection compared to what it looks like graphically (it expands so it might look like it's covering more area than the hit area event itself). In a lot of professional games, the collision detection hit boxes of an attack or object are often different sizes than the graphic and it takes a lot of fine-tuning to get it to feel right.

With Rockfall I didn't feel like it had hit detection issues as much as felt like the timing and aim required for it to deal damage (versus just blocking an enemy) was pretty exact, and I relied more on other spells for dealing damage. The hit detection for Blast felt about right but it did feel like enemies are unexpectedly able to bump into you before, while, and after you're doing it.

On the other hand is Projectiles, where there are some noticeable hit-detection issues (mostly when characters are walking from one tile to another). I checked into my Projectile Handler parallel-processing event and it only has a 1 frame wait at the end. I don't know how many frames' worth of time it actually takes to run through the event (which loops several hundred times to check each projectile and each event), but my instinct is that, at least on my relatively-fast computer, it's under one frame's worth of time. So I don't know why the hit detection is spotty on these, but it's something I will play with (maybe add additional projectile handlers or something to run concurrently) to see whether I can improve it.

Yes, the hit-detection issues were most noticeable with projectiles, but I'd also say that the hit detection during the "walking from one tile to another" situations you mentioned feels spotty for bumping into enemies as well, and it's one of the biggest reasons I found myself fighting from long range. For example, if you're running from an enemy and then doubleback to attack it, if you're stepping onto the same tile that the enemy is about to step on it feels like the enemy will bump into you and deal damage from a further distance/prematurely.

I'm envisioning the system much more in the conceptial framework of adventure (like Banjo-Kazooie) than action (like Castlevania), and as such, any areas that are narrow enough to properly utilize enemies that do things like simply pace back and forth are going to be bits of a much bigger, more-open map.

Ah, okay. The demo definitely emphasizes fighting more than exploration and collecting things so I didn't realize that this is what you were envisioning! Also, since there's no jump button or feature I think the exploration is more likely to channel a 2d Zelda experience before Banzo-Kazooie.

I think one of the main reasons that enemies are (maybe too) easy to avoid right now is that there's no movement setting between 3 (half the speed of the player) and 4 (same speed as the player). One of those places I bet Game Maker could do much better. Setting them to 4 seemed too uncomfortable for the demo, so I left them at 3. What I might do as I adjust move routes is to allow enemies to "notice" the player, not only adjusting their route but also their speed.

Yeah there's a lot that can be done here, including having some enemy move routes change based on distance to the player (via scripts). One enemy could "notice" the player, speed up until it's within a certain distance and then do a kind of step forward and attack, step backward, step forward and attack, step backward & repeat kind of dance until the player is out of range.

The amount of mana received by each party member when you defeating an enemy is random, based upon parameters specific to that enemy. So having lots of gems flying in a single animation, that will be cool (and I probably will do it), but I don't think there's a good visual way to show the actualy amount of mana recovered, short of literally printing the number somewhere onscreen (like the HUD).

Printing them on the HUD might be the best choice, though is there a particular purpose for making the mana received random?

I'm not going to do a force field (for Traps, at least) since I think it would make it far too obvious that you're about to walk into one.

That's true. You'd really only want to use a forcefield if you wanted to emphasize the obvious prospect of taking up a challenge and collecting a treasure, as opposed to the "surprise" of a monster trap. But I didn't realize that you wanted to maintain the element of suprise because after a player encounters a monster trap once future monster traps become fairly obvious anyway. They're enclosed spaces with a high concentration of monsters, and have "monster trap" written all over them. To keep the element of surprise I would try drawing the traps around more open areas and/or do what you suggested below: "most (though not all) of the trap enemies appear only once the trap is activated." That idea works not just for sniping but for maintaining the element of surprise as well!

For example, the Specter currently shoots a fireball if a certain random number has been chosen and the player is within 4 tiles of the direction the Specter is facing. I could modify it to have it also shoot if a projectile is coming at its frontside (and maybe require that the player would need to be more than two tiles away in order to do so). I think this is kind of what you were describing for #4, and I do think it would really be a "whoa, that's cool" moment for the player the first few times they notice their snipe attempt getting bamboozled.

That sounds like a good way of handling it.

What I really love about your suggestions is how they use the aspects of time and position to really create the kinds of incomparables that can only be abstracted even in a really good turn-based battle system. In certain situations that long-range projectile will be golden, and in others you'll need to move in close enough that it's impractical.

Right, for an ABS I think it's best to stress things that can't really be done in a turn-based menu system, which primarily means a timing and a spatial aspect, player reflexes and hand-to-eye coordination, etc. Otherwise the system you're designing can feel like it's being made to "fit" within the limits of a tool not designed for the genre, and therefore existing in some strange limbo state in between the limits of the tool and the intended genre, rather than transcending the tool.

Another thing I think would help create the incomparables is something like a short-dash and/or dodge maneuver that depletes a stamina meter, which meter slowly refills when it's not being used. When I was working on a 3/4 view action RPG system in Game Maker some ten years ago, I had a dash/dodge system (activated by quickly tapping any direction twice) working as well as a jump button that could be used to leap over enemy projectiles and other attacks if timed correctly (but would result in the player being knocked down to the floor and stunned for a moment if they were hit by an enemy while in the air)--which required a lot of fine-tuning to get the hit detection to feel right. 8-way directional movement as opposed to four feels a lot more fluid.

Anything that stresses when, and at what range, and in what situations an enemy is vulnerable to damage can help, too. For example, perhaps an enemy has a shield up that greatly reduces damage but is completely vulnerable while it's attacking, so the player can develop a strategy to bait the enemy's attack and wait for the right moment to strike.

[Wavelength]

Re: The Coolest Thing I've Ever Made on RPG Maker

Ah, I see. There were times when I felt like Water Bomb passed through enemies. It may have to do with the size of the event's hit detection compared to what it looks like graphically (it expands so it might look like it's covering more area than the hit area event itself). In a lot of professional games, the collision detection hit boxes of an attack or object are often different sizes than the graphic and it takes a lot of fine-tuning to get it to feel right.

Yeah, you're right about this one. I just did a test by coloring tiles different colors, and the graphic is covering an area that looks more like a 3x3 grid than the "single cross" (target tile plus four adjacent tiles) that the spell actually hits. I'm not sure I can make a bubble-popping graphic convincingly cover a cross area, so maybe I should just change the hitbox to 3x3.

With Rockfall I didn't feel like it had hit detection issues as much as felt like the timing and aim required for it to deal damage (versus just blocking an enemy) was pretty exact, and I relied more on other spells for dealing damage.

In my playtesting I noticed the same thing - it just didn't feel as useful as other damage spells. I'll probably buff the damage on it, since I've since made another spell ("Stonewall") that provides more reliable on-demand crowd control.

The hit detection for Blast felt about right but it did feel like enemies are unexpectedly able to bump into you before, while, and after you're doing it.

Thanks. I'll keep an eye out for that. Each spell has a charge time and a recharge time - usually a small fraction of a second, but Blast's is fairly long at 0.4/0.3 seconds. If you're holding down the D key, the enemies will get a small window in which they could get to you before they're blasted away again. I wonder whether that could be it?

Yes, the hit-detection issues were most noticeable with projectiles, but I'd also say that the hit detection during the "walking from one tile to another" situations you mentioned feels spotty for bumping into enemies as well, and it's one of the biggest reasons I found myself fighting from long range. For example, if you're running from an enemy and then doubleback to attack it, if you're stepping onto the same tile that the enemy is about to step on it feels like the enemy will bump into you and deal damage from a further distance/prematurely.

It's probably baggage that comes with the way "Event Touch" event pages are handled. I'm sure smarter Move Routes will help make the short-range attack mechanics feel better to use, but besides that, I'm looking for ideas.

Printing them on the HUD might be the best choice, though is there a particular purpose for making the mana received random?

No particular game-related reason. It just feels right to me to have a slightly unpredictable flow of elemental mana coming in.

That's true. You'd really only want to use a forcefield if you wanted to emphasize the obvious prospect of taking up a challenge and collecting a treasure, as opposed to the "surprise" of a monster trap. But I didn't realize that you wanted to maintain the element of suprise because after a player encounters a monster trap once future monster traps become fairly obvious anyway. They're enclosed spaces with a high concentration of monsters, and have "monster trap" written all over them. To keep the element of surprise I would try drawing the traps around more open areas and/or do what you suggested below: "most (though not all) of the trap enemies appear only once the trap is activated." That idea works not just for sniping but for maintaining the element of surprise as well!

Maybe I should just tape a note to it that says "I'm a Monster Trap"?

But yeah, I do want to maintain the element of surprise and danger. The best thing I can hope for is to have a player wander into one unknowingly, think "Oh crap! Is this gonna finish me?", but have the tools to fight their way out of it.

Right, for an ABS I think it's best to stress things that can't really be done in a turn-based menu system, which primarily means a timing and a spatial aspect, player reflexes and hand-to-eye coordination, etc. Otherwise the system you're designing can feel like it's being made to "fit" within the limits of a tool not designed for the genre, and therefore existing in some strange limbo state in between the limits of the tool and the intended genre, rather than transcending the tool.

I'll do my best!

Anything that stresses when, and at what range, and in what situations an enemy is vulnerable to damage can help, too. For example, perhaps an enemy has a shield up that greatly reduces damage but is completely vulnerable while it's attacking, so the player can develop a strategy to bait the enemy's attack and wait for the right moment to strike.

Yeah, I would love to implement enemy attack patterns like this. Definitely doable... definitely will take a while.

Another thing I think would help create the incomparables is something like a short-dash and/or dodge maneuver that depletes a stamina meter, which meter slowly refills when it's not being used. When I was working on a 3/4 view action RPG system in Game Maker some ten years ago, I had a dash/dodge system (activated by quickly tapping any direction twice) working as well as a jump button that could be used to leap over enemy projectiles and other attacks if timed correctly (but would result in the player being knocked down to the floor and stunned for a moment if they were hit by an enemy while in the air)--which required a lot of fine-tuning to get the hit detection to feel right.

I really like this. It would actually be a much better way to handle attack frequency than re/charge times alone, and the ability to incorporate invincible frames or even speed bursts would be one more way to make the melee game more feasible.

I think I'd have to name it "Adrenaline," partially because I plan to use "stamina" as a completely different mechanic as part of the day/night system, and partially as a nod to my other games where Adrenaline plays the function of the self-refilling resource.

8-way directional movement as opposed to four feels a lot more fluid.

I'm going to check out some of the 8-direction and pixel movement scripts out there and see if they would be compatible with the way I do hit detection (which is to compare the X and Y coordinates of the skill/attack/projectile and the character/enemy). Because I agree, 8-way movement does feel like a smoother ride.

[Jamos]

Re: The Coolest Thing I've Ever Made on RPG Maker

One idea I think would be neat is well actually a skill I intend to have in DotB, but would be pretty useful here. Some setup like spells. For example the user casts Downpour, this attack does no damage, but the water makes them slower (because it is pretty hard to move in soaking wet clothes!) and increases the effectiveness of ice and electric attacks. Not sure how useful that idea would be to you, but thought I'd put it out there.

[Wavelength]

Re: The Coolest Thing I've Ever Made on RPG Maker

Thanks for your idea, J!

I will definitely have some spells like that. The one spell that "sets up" for others in the demo is Blizzard - it's not documented well in the demo, but each time an enemy is hit by Blizzard, they are frozen for one second, not only stopping them from moving/attacking, but also doubling damage from all sources except other ice moves and fire.

The "Soaked" status effect in Nights in Blue actually does almost exactly what you're describing - slower Priority Points generation and increased susceptibility to Electric attacks (which, as Ryu pointed out in the Beta Test thread, made Tielle + Rhyss a REALLY good combination at the game show).

I love combos like this that kind of naturally make different characters into good teammates, and for sure I'll be using it in this ABS. The more the player swithes between characters, the more fun and dynamic the system will feel.

[TheHonorableRyu]

Re: The Coolest Thing I've Ever Made on RPG Maker

I noticed that Blizzard freezes enemies but I didn't notice that against frozen enemies attacks that aren't fire or ice-based dealt double damage!

Something else that would encourage switching characters is to play up some more intrinsic differences between them. Right now there's differences in HP and MP and each character can keep a different spell set equipped, but each of the characters can equip the same spells and the same weapons (raising their Attack or Magic Attack) making them shift closer to three copies of the same blank slate character. It would be interesting if one character had, say, a slightly faster default walking speed, and another longer range on their normal attack, and another higher defenses (either in the form of receiving reduced damage or having a percent chance of "sloughing off" hits from bumping into enemies and taking no damage).

[Wavelength]

Re: The Coolest Thing I've Ever Made on RPG Maker

I noticed that Blizzard freezes enemies but I didn't notice that against frozen enemies attacks that aren't fire or ice-based dealt double damage!

Yep, there's no way to notice this in the demo without simply being told it happens, or paying ridiculously close attention. In the final version I'll probably have the status menu fully describe any status you currently are affected by (as well as general documentation in and outside the game).

Something else that would encourage switching characters is to play up some more intrinsic differences between them. Right now there's differences in HP and MP and each character can keep a different spell set equipped, but each of the characters can equip the same spells and the same weapons (raising their Attack or Magic Attack) making them shift closer to three copies of the same blank slate character. It would be interesting if one character had, say, a slightly faster default walking speed, and another longer range on their normal attack, and another higher defenses.

Totally agree. I did it this way in the demo to give players a taste of the Setup menu (since there were only about a dozen spells to work with), and also to make it easy for me to test stuff.

If I proceed with porting NiB content to this project, which is looking probable, the skill division will be a lot like what you saw in How Badly, where each character has a class of spells (like Energy, Alchemy, Fire, Psychic, or Time) with their own inherent strengths and styles. This would mean getting rid of the Fire/Water/Earth/Air classification; I might reclassify spells within each class as Astral/Spirit/Physical/Elemental (or the like), or just let the player equip any four spells the character has learned in that class.

If I make this into a new project, in which case the game would focus more on action elements and level design, I think I'd probably have one main character who could use a large library of skills (which would allow me to fully use the Fire/Water/Earth/Air classification), and the ability to switch to other "support" characters that have fixed sets of skills. Either way, the "sameness" shouldn't be a problem.

Also, with that cool idea you gave me with the Adrenaline-based actions, that's another good place I can differentiate characters. Different amounts of adrenaline and maybe even different actions (one character could dash with the "action button", another could dodge). I wish I could give each character (and enemy) slightly different speeds, but I don't think that's doable... which is why the dash is such a great idea.

[TheHonorableRyu]

Re: The Coolest Thing I've Ever Made on RPG Maker

I'm going to check out some of the 8-direction and pixel movement scripts out there and see if they would be compatible with the way I do hit detection (which is to compare the X and Y coordinates of the skill/attack/projectile and the character/enemy).

That's basically how Game Maker (and 2d games in general) perform the checks. (The difference is that Game Maker has precise controls for what counts as an object's hit box, so like you can draw your own sprite map and make that the object's hit box, and checks are easily evaluated on a pixel by pixel basis rather than x by y squares). I'd try giving some 8-direction scripts a try and see what happens!

I wish I could give each character (and enemy) slightly different speeds, but I don't think that's doable...

Maybe try looking into this script?

[Wavelength]

Re: The Coolest Thing I've Ever Made on RPG Maker

That's basically how Game Maker (and 2d games in general) perform the checks. (The difference is that Game Maker has precise controls for what counts as an object's hit box, so like you can draw your own sprite map and make that the object's hit box, and checks are easily evaluated on a pixel by pixel basis rather than x by y squares). I'd try giving some 8-direction scripts a try and see what happens!

I was really disappointed to find that even the large sprites used single-tile hitboxes. To get around that for the boss (which has two hitboxes for each statue), I made a script that checks both the front and back tiles' "HP" and subtracts all damage you do from the same HP pool. That works okay, but it's going to be very hard to get a multi-tile boss to actually move around and bring its invisible extra hitboxes with it.

So yeah, definitely gonna try some of the scripts that are out there that include hitbox features, and see whether they're compatible with my hit detection. My instinct is that they won't be, but if they are, that would make my day.

Maybe try looking into this script?

Thanks for that, but just tried it, and what it does is allow database objects (such as armors) to change a player's numerical speed (1-6, or theoretically higher). I already have full control over a player's numerical speed - what I would need to reasonably have character speeds differ would be something that makes the differences between each number far more granular.

3, for instance, is twice as slow as 4, which is twice as show as 5. If I could change the difference between them to 10-20% instead of 100%, and still use the same (or similar) hit detection, that's something I could incorporate into my ABS.

I do love Hime's scripts, though. They're the best out there. One that I'm about to try is the "Event Trigger Labels" to separate Event Touch vs. Player Touch, and see if that can stop players from annoyingly getting hit when they are trying to move onto the same tile that a monster is trying to move onto. And "Large Script Block" has been absolutely invaluable.

[Kefka Jr.]

Re: The Coolest Thing I've Ever Made on RPG Maker

This is real impressive. I could not shake this kind of effort for my brief foray into RPG action so I'm pretty floored and inspired.