1. #1

    Pokemon 5e- adapting ruleset.

    First and foremost, I am beginning work on this (while also trying to learn the basics of how Coding works big thanks to Damned for his Youtube videos, great resource).

    This project is based on the great work done @JOEtheDM on twitter, having adapted pokemon mechanics into the 5e ruleset as well as create statblocks for Pokemon Generations 1-4, if you are interested in checking out his work this is the link to his PDF:
    https://homebrewery.naturalcrit.com/share/r1TpuSfiz

    My mate and I started work on building the modules needed to run the game in the 5e Ruleset when I noticed a few somewhat significant snags which ultimately halted the module creation process while we worked out our options. We seemed to have settled on taking the 5e Ruleset and re-tweaking it to fit to the specific needs of the pokemon variant 5e rules. Below in no particular order are some of the issues we found and ultimately have decided to try and resolve to keep some semblance of automation (especially around pokemon types and elemental damages as calculated in the varient ruleset):

  2. #2
    1) Changing race types from the D&D specifics (like fey, dragon, humanoid and the like) to the specific Pokemon types needed (like Fairy, grass, fire, poison, fighting and the like). This step becomes important when calculating resistances and vulnerabilities and also has an effect on the way some moves are calculated.

    2) Integrating a new mechanic for Same Type Attack Bonus (STAB from here on out), this mechanic is critical for establishing the damage output of the pokemon, it is similar to having a proficiency bonus however it is not tied to the proficiency bonus at all which does add a little more complexity to the integration. The way that STAB works is that a fire based move as used by a fire type pokemon will be more powerful than a fire based move being used by a non fire type pokemon, and of course that also figures into resistances and vulnerabilities after the fact.

    3) Establishing the difference between Pokemon and Characters (the way the rules work is that you play as a pokemon trainer that levels up, gains abilities, stat bumps, and perks. As the trainer you capture Pokemon which have their own levels, abilities, stat bumps and perks.) The first idea I had for making this work is to use the NPC sheets as a base for building the pokemon, especially when adding in over 300 of the things and forming a bestiary. The one drawback to doing this is that because the pokemon level up, new mechanics and integration have to be incorporated into the NPC sheets to allow for easy calculation of the above mentioned STAB bonus as well as adding a Level Mechanic, another addition is effectively adding the skill page from the character sheet to the NPC sheet to allow for an easier interface for pokemon skill checks. the final element is adding Proficiency bonus to many of the pokemon moves which for calculation will have to be added to the sheet. Actually the easiest way might be to make every pokemon into a character then just add the STAB bonus in as an ability that gets calculated, however when our group plays (5 players) and has each player controlling up to 7 characters, the UI is going to get completely overwhelmed with character icons, not to mention that having over 300 individual character sheets is completely impossible to manage without an effective grouping mechanism. I am open to ideas on how to tweak or make a less intense modification that still brings in the needed mechanics

    4) If making each of the pokemon entries as a modified NPC sheet is the direction that makes the most sense (I believe it is but im open to alternatives) then a super easy one to change (which i already have done) is the change from CR to SR (Challenge Rating to Species Rating) In the most updated version of the PDF files the pokemon are ranked by SR, a players ability to catch a pokemon is based on a few things and SR being one of them, as far as automation goes its not a problem to run that calculation manually, I dont think its something that is super necessary to automate, However a couple of our players get easily confused so as a quality of life thing I renamed CR to SR, easy and done.

    5) The Pokemon Moves are another element that needs a bit of consideration, not just because of the addition of NPC proficiency bonus being something that isnt static but rather changes with level, but also because of the new STAB mechanic that needs to be incorporated. As it stands, I believe it makes the most sense to create the Pokemon Moves as spells, for a few reasons really, firstly an overwhelming majority of them have spell like effects which makes it easier to deal with by simply making them spells, it also makes sense for automation and ease of adding spells to NPC sheets. Where this as a concept begins to need a bit of work is the change from spell levels/spell slots to spell uses or PP for those familiar with the Pokemon games. My very first thought as far as incorporating this into the existing 5e rule set was simply to use the spell slot mechanic and assign one move to each of 4 (or 5 as some pokemon under some conditions can have 5 moves based on this adaptation) spell slot then adjust the spell slot uses to match the PP of the move in question. That quickly unravels when you have multiple pokemon using the same move from different slots, it means every time a move is gained or removed the move has to have the associated spell level changed to suit the slot of the move on the sheet, which will quickly become a nightmare for the GM when it comes to the actual running of the game, as spell entries being duplicated and or changed constantly will make a mess of preplanned encounters. Another variant I had considered was to make every move a different weapon and assign it as a ranged weapon and add ammo tracking to keep track of the total amount of uses of each move, again this falls into a problem by not being able to drag and drop weapons into NPC sheets, meaning having to resort to the pokemon being made into characters which adds all those character icons making the UI hard to deal with and the overwhelming amount of character sheets making the life of the GM unbearable.

    6) The Pokemon Trainers in this rules variant also adds an additional couple of considerations, namely the case of there being effectively only one class but having 11 class paths and 18 specialisations, neither of which are reliant on each other. If im being honest it almost feels as though there are two different forms of specialisations which makes it a little tricky to implement, My first thought was to make the specialisations function like races (they give proficiency to one or a choice of two skills and most of them also give you a +1 bonus to all skill checks by associated Pokemon) However that doesnt work 100% either as there are a couple of levels where you get to add another the effect again OR pick a different effect, for instance, you could pick Bug Maniac and get Proficiency in Nature checks and a +1 to all skill checks made by any of your bug Pokemon, now at Level 7 you can take that again to get a +2 to all skill checks made by your bug Pokemon or you could specialise in something else like say Bird Keeper which gives you Proficiency in Perception and adds +1 to your flying type pokemon. Now obviously races dont normally have a leveling based mechanic to them (excluding a hand full of damaging based racial abilities) and there isnt a way to add and keep track of multiple races in the one character sheet. At the moment I was toying with the easy way out of adding the Specialisations and the class paths into the same mix though I am completely open to any other ideas as the Specialisation section of the class section is a complete mess of entries.

    7) Tables had to be made for calculating Pokemon natures (has an effect on their base stats like +2 Wis, -2 Strength or +1 AC, -2 Dex) but that's nothing and can be manually added in when building encounters, though it would be really nice if there was a way to automate that process when adding Pokemon to the combat tracker, just a quality of life thing for the GM more than anything but not strictly needed.

    8) There is a Loyalty mechanic in the rules variant, pretty much depending on the Loyalty of the Pokemon it adds a modifier to the saving throws and also depending on the loyalty level, have a dice roll needed to be made giving the possibility of a failure for the Pokemon to make the move, or a Pokemon might have additional hit points if the Pokemon is loyal. This mechanic is easily added via the effects so im not worried about that at all, that can be added in without having to touch the code.

    9)
    There are a few big tweaks to some of the status effects, and with the addition of other status effects and considering how common moves with status effects are, it doesn't make sense to not tweak those status effects to be more in keeping with the Pokemon style, also makes entering the move's significantly easier, being able to directly link the adjusted effects and have them apply correctly will vastly improve the user experience.

    10) With the changes to the Status Effects, its also worth noting that there is a common Mechanic in play for Weather Effects, I had already made a table for randomising the weather effects which is a nice little thing for the GM to have access to, however being such a common thing and often Pokemon/moves do more damage or have more effects dependant on those Weather Conditions, it makes perfect sense for creating those commonly used Weather Conditions as a single hit button so that everyone can have their rolls automatically adjusted for the weather.

    Im sure there are more considerations that i have missed in the adaptation of the variant into the 5e system. I did have a bit of a look at Morecore but weirdly enough I dont know where to start there to adapting it to Morecore to the point where im more looking at the modification of the 5e Ruleset, though if everyone believes that we can accomplish these adaptations easier in Morecore, I will happily dive in there. Any ideas and directions I could be looking towards to make effective changes would be greatly appreciated.

    Much thanks
    -Elyh
    Last edited by G3Gaming; August 17th, 2019 at 12:16. Reason: Formatting and spelling correction

  3. #3
    damned's Avatar
    Join Date
    Mar 2011
    Location
    Australia
    Posts
    18,757
    Blog Entries
    1
    Im neck deep in a bunch of programming myself right now so Ill just throw out a few comments here and there...

    1. Use find-in-files and search (without case checking) to find each of the current races to understand what additional coding has been added for them and how its been done. Some is scalable and some is very specific.
    2. If the BAB works in principle maybe add a checkbox. Look at how/where BAB is used, add some logic to it that looks to see if the checkbox is ticked and then add the additional bonus and untick the checkbox. Probably a lot of ways to handle - but this was the third one that I thought of.
    3. Find a way to use NPCs... only add actors when they are being used. The CT really doesnt make things easy to navigate if you have 20+ actors so work out a way (play style) to limit when you add them.

    MoreCore - Generic Ruleset
    --- Projects ---
    Extensions | Tutorials | MoreCore | MoreCore Themes | Call of Cthulhu | Maelstrom | FG Con

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

Log in

Log in