Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Ninjamida last won the day on January 4 2018

Ninjamida had the most liked content!

Community Reputation


About Ninjamida

  • Rank
    Advanced Member
  • Birthday 07/16/1991

Contact Methods

  • Website URL

Profile Information

  • Gender
    Not Telling
  • Location
    New Zealand

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Sorry about the slow response - I don't check this site often these days. I'll explain in brief how my game's counterattack code works. You will need to either learn a bit of scripting, or get help from someone who does, in order to follow along. This is all fairly basic stuff, but not basic enough that it'll make sense to someone who isn't familiar with scripting - if anyone else would like to further simplify this to that level, go ahead. Firstly, enemies need to have some kind of property to indicate their counterattack routine. In my case, I used a numeric value called "counter AI". You can either use notetags, or values coded in the script, to assign these to the enemies - there's plenty of information out there on how to do either of these, so I won't go into detail on that. If your counterattack system is very simple - ie: the only thing you want to change is which attack they use - then you could even directly store the attack ID in this property. Next, you'll need to find the code responsible for calling a counterattack. By default, it's hardcoded to return the first attack in the database, which will generally in turn correspond to the Attack command. Instead, it needs to call a separate function that handles counterattack decisions - or if you're using the "store attack ID directly in the property", it simply needs to return the attack that corresponds to that property. It's tidier to override the function altogether, but if you prefer, you can modify it in-place. If we're going the function route, then the main function should then divert to separate functions based on the value of the enemy's counter AI property. For example, in my game: def counterskill(target, attacker, item) counteraiscript = target.caiscript case counteraiscript when 1 # No action but memorises attacker. return counter_ai_001(attacker) when 2 # Memories attacker if they are lowest HP, also uses Radar. return counter_ai_002(attacker) when 3 # Counters with random element, changes to alignment to it. return counter_ai_003(attacker) when 4 # Yu Pagoda style full-HP revival but instant. Cuts off once # max HP excees AIVAR#1. return counter_ai_004(target) when 5 # Physical with Blind, Magical with Silence. If neither, or # target already under status, picks a random status to try # out of Darkness, Silence, Sleep, Poison, Slow. If under # all, will not counter. return counter_ai_005(attacker, item) when 6 # Counts up damage in @aivars[1] return counter_ai_006(attacker) when 7 # Just messes with a few switches. return counter_ai_007(item) # etc else return [1, attacker.index] end end The "else" is a fallback to the default. Note that my functions return an array with two values - an attack and a target. Simpler systems may not need to do this. It's probably possible to do this in a tidier way, in particular, instead of hardcoding for each possible value of "counter ai", do some kind of call that appends the number to some prefix in order to determine which function to call - I was pretty new to Ruby when I threw this together, so it doesn't make use of that kind of option. In turn, the "counter_ai_xxx" functions determine, using normal scripting, what attack to use as a counter, and who to use it on (because in my game, I don't always want the counter to be used against the attacker - in some cases, I might want to target a random or specific-but-not-the-attacker ally, or I might want the enemy to counter by casting a healing spell on themself, etc). It's also possible for the functions to return nil, which indicates that no counterattack should be used. Such a scenario might be that you have an enemy that attacks whichever actor last attacked them - so the counter AI would remember who attacked, but would do nothing instead of launching any kind of counterattack. (Obviously, this requires a similar setup for on-turn attack selection, because the built-in attack selection features don't allow for selecting specific targets.) Here's an example of one of the counterattack function's code: def counter_ai_005(attacker, item) if hp == 0 $game_switches[57] = true return nil end return nil if result.hp_damage < 1 possstat = [2, 3, 4, 5, 20] possstat.delete_if {|x| attacker.state?(x)} return nil if possstat.empty? if item.physical? && possstat.include?(3) return [184, attacker.index] end if item.magical? && possstat.include?(4) return [185, attacker.index] end nposs = possstat.size try = possstat[rand(nposs)] return [183, attacker.index] if try == 2 return [184, attacker.index] if try == 3 return [185, attacker.index] if try == 4 return [186, attacker.index] if try == 5 return [190, attacker.index] if try == 20 return nil end
  2. Ninjamida

    Creating a one shot spell

    If you want to avoid scripting, IIRC there is a condition that requires the switch to be on. So you could set the switch to on in a battle event at the start of the battle, then switch it off when the attack is used.
  3. I don't know of any pre-made scripts to do this, but there might be one. I custom-rolled something for my own game that achieves this, but it's pretty complicated and messy. (And extremely buggy if you want the counterattack to be a hit-all attack - had to workaround by activating a switch then using events to actually perform the attack.) I recall doing this by looking for the code that triggers the normal counter attack, then diverting it to a certain custom function (a specific one for each enemy it's relevant to) that returns which attack and who to target - the latter part matters too, because some enemies counter by casting healing spells on themself, or aren't guaranteed to attack the character who attacked them, etc.
  4. Ninjamida

    Target selection in battle

    Sorry - I think you misunderstood. I'm not asking "how do I make it work with script X". More like, "what kind of formulas should I be using to determine the new target"? This is in an entirely custom engine, so "what script I'm using" isn't even a valid question.
  5. Yeah, that's gonna fall foul of the EULA for sure. Better off not distributing that. A bit disappointing that there's no EULA-friendly way to make a game with a resolution that high, but not much that can be done about it. Does MV support full HD (I'd imagine it would with custom scripts, given that it has no reliance on custom DLLs and there's no hidden code)? If not, your best bet might be to look outside the RPG Maker franchise - or even consider writing your own custom engine.
  6. So - here's a point that came up on another website, regarding the battle system in my new project. To give some background info - it is absolutely critical that with most attacks, you can choose whether to target enemies or allies. The battle system is side-view, enemies on the left, allies on the right. So, initially, my thought was - have a dedicated button for changing target party, while the arrow keys (or dpad, on a gamepad) select a target within that party. But someone pointed out that they feel it'd be more natural to have left/right switch party, and up/down to select a target within the party. The issue I see here - what if we have, say, a formation of two enemies, one behind the other (but at the same Y coordinate). To me, it would feel weird to be using up and down. If it's a matter of "if you're already on the furthest right enemy, pressing right again will target allies, but otherwise it targets an enemy further to the right than the currently-selected one", that could work. The other question is how exactly to implement it. Yes, for a human, it's easy to see "I have this enemy selected and pushed this button, so now I should have this enemy selected instead". Implementing an algorithm for it... not so simple. This actually pushes me towards actually using the up/down thing, perhaps combined with just not creating formations that have enemies in a straight line horizontally so the oddity of using up/down to (visually) move left/right between targets never comes up. What's everyone else's thoughts on this?
  7. Not quite the same as doing it in RPG Maker, but I'm currently working on a new project (coding it from scratch using C# and MonoGame), and I've probably spent upwards of 10 hours on the battle system already - and all it does so far is display party / enemies (including current HP / MP for the party), calculate and display the turn order (it's using a FFX-like CTB system), and let you select attacks (but the attacks don't actually do anything, aside from display their name, yet). EDIT: I've done a bit more since I posted this message (although not much), and currently, the source file for the battle scene alone stands at 1126 lines, 39KB. And I'd say it's at best maybe 25% complete now. (Yes, feature-wise it doesn't sound so close, but there's also a fair bit of behind-the-scenes stuff in place to support the rest of the front-end features it needs.) Now, of course, that 10 hours includes things like "adding stuff to actors / enemies that the battle system needs" and in a couple of cases creating graphics (very basic MS-Paint style ones though) that I can use for testing, but still - that's a considerable amount of time already and I'm only just getting started. True, Ruby is a little bit more flexible and easy-to-use than C#, and even more so if you already know Ruby (I literally didn't know a thing about C# when I started this project). But still - the point is, if you're doing it from scratch, a custom battle system will take a long time to create. Now if you can re-use parts of the default system or an existing script, that will definitely save you a lot of time - at the cost of that you're sacrificing some degree of control over how it works. This was something that greatly frustrated me with my RPG Maker game - as amazing as Yanfly's CTB script is, I never really properly figured out the internal workings and thus wouldn't be able to tell you how turn order is determined in my game beyond "certain moves mean your next turn comes sooner or later, and higher agility = you get more turns and get your first turn sooner".
  8. Ninjamida

    Legends of an Otherworld [V026b update 01/01/2018]

    Download link broke about a month ago (due to me migrating from Dropbox to Onedrive), I've fixed it now. No new update or anything, just a fix for the broken link.
  9. Ninjamida

    RPG with no levelling / stat growth?

    My thought is that you won't ever get permanent stat gains. However, your abilities would also be non-permanent, but rather, you equip them - think of it as something along the lines of FF7's materia system, just without all the linked materia stuff. You'd have limited slots, and you'd also only be allowed to equip abilities that match the character's class (though later in the game they could get a second class). There'd also be neutral abilities that, rather than giving a new in-battle ability, might increase a stat. Likewise, your actual weapon and armor could have traits like "10% extra damage" or "reduce damage taken by 10%". Strategy would come from a greater focus on things like status effects and buffs, as well as selecting the ideal equipment with only a limited number of slots available. With that being said, I'm now leaning a bit more in favor of having levelling, but making it have relatively little impact. If you have 5000 HP and the boss's attack averages 5100 damage, you can probably grind a bit. If you have 5000 HP and the boss's attack averages 5500 damage, grinding to survive it will probably take too long and you might want to think about whether you can use buffs (or perhaps negative statuses on the boss) to reduce that damage instead. Or something along those lines.
  10. So, this is an idea I've been considering for the remake of Legends of an Otherworld. For those of you who aren't familiar with my game - in brief, it's a turn-based RPG with a CTB battle system (like in Final Fantasy X). As such, the focus is primarily on in-battle strategy, with pre-battle setup being a fairly close second; levels are actually relatively unimportant. (The final bosses can easily take down a level 99 party if your strategy isn't good, but are very comfortably beatable at level 50-60 with good preparation and strategy.) A huge inspiration was FFX challenge runs, where you generally don't gain stats at all throughout the entire game. As such, I'm considering - why not take levelling out of the equation altogether? This way, the player never thinks "Maybe I'm just underlevelled and should go grind", they know they need to improve their battle strategy and/or better tailor their equipment to the battle. New abilities and items would still become available as the player progresses, and small stat boosts through equipment would remain possible - just no permanent increases. While I definitely see why this wouldn't work for the average RPG, I get the feeling that for one like mine, it might be a very good approach. What are your thoughts on such a concept? (PS: I'd be willing to guess there's probably already at least a couple of games out there that do this - if you know of any, how were they?)
  11. Ninjamida

    Legends of an Otherworld [V026b update 01/01/2018]

    Put another battle video up. This one shows off the battle system really well; the downside being it spoils how to beat the first (of many) "That One Boss" in the game - although the video ultimately ends in a game over, it shows a lot about how to approach the battle in general. See first post for the video, it's the second one.
  12. Ninjamida

    Legends of an Otherworld [V026b update 01/01/2018]

    Put some better preview images up now. Go check 'em out in the first post. (Of course, if you've played the game, you'd have already seen it anyway...)
  13. Ninjamida

    Legends of an Otherworld [V026b update 01/01/2018]

    Transient is the first one with the "hard boss" music (Battle3 of the RTP). The one that uses Pulse and Trauma, and is immune to physical damage unless Weaken is inflicted on him.
  14. Ninjamida

    Legends of an Otherworld [V026b update 01/01/2018]

    For sure, not everyone gets stuck on it - but many people have reported it as their first roadblock. (For those who don't get stuck here, Transient is usually the first roadblock - and for those who do get stuck here, Transient is usually the second.) A lot of it comes down to how quickly you get here; since this battle is very challenging if you're low level, but fairly easy if you're even slightly high level. By comparsion, you have to be very far overlevelled before Transient becomes a pushover.
  15. Ninjamida

    Legends of an Otherworld [V026b update 01/01/2018]

    Finally got around to making an up-to-date video of battle footage. It's a better choice of battle too, in my opinion, as the one previously shown was a boss from fairly far into the game, that was also to at least some extent spoilery to know the existance of. Not to mention, it's literally considered the game's best (and hardest) battle, so it was neither representative, nor a great idea to show how to beat it in a demonstration video. On top of that, I also got the feeling that choosing such a battle revealed too much of the available options in the game, rather than leaving plenty for the player to discover on their own. By comparison, this one is a battle that's considered to be a highlight when first encountered and for a while beyond, but relatively unspecial by the time the player gets towards the later stages of the game. It's from a fairly early point in the game, and has little plot relevance, so doesn't really spoil anything. Of course, it still shows how you can beat this battle (which is one people tend to get stuck on), but I feel for this battle it's okay. It also shows off the concept of "you need to be strategic" without showing too much complexity. Of course, the biggest problem was simply that the old video was based on an extremely out-of-date version of the game. Here's the new one, which I've also added to the first post.
Top ArrowTop Arrow Highlighted