Page 1 of 2 12 Last
  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 13:16. Reason: Formatting and spelling correction

  3. #3
    damned's Avatar
    Join Date
    Mar 2011
    Location
    Australia
    Posts
    19,056
    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

  4. #4
    Thanks for the tip damned, I have been using it extensively,
    Im well aware, ive currently got a near 30+ actor combat coming up for my campaign session on friday night and its a nightmare going through the list of actors, Im intending on using NPC's in a similar way to how fantasy grounds handles retainers for 5e and assigning the individual pokemon as npc's that the players can access via shared npc's, this way, each player only has access to their own pokemon and can be added and removed from the tracker with DM help.

    having dug around for a few days trying to wrap my head around the way the files reference each other I believe im slowly starting to understand some of what im doing, currently im stumped trying to understand how the NPC main sheet is organising the individual fields, Im currently trying to add in another label_column and corresponding number column, however i cant seem to find how it is anchoring each of the fields so trying to insert the new field in above the ac_label or any of the labels really is giving me a little grief, the only point i can find predating the ac_label is the summary label being anchored relative to the top, would you have any idea on which direction I should look towards?

  5. #5
    damned's Avatar
    Join Date
    Mar 2011
    Location
    Australia
    Posts
    19,056
    Blog Entries
    1

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

  6. #6
    I looked into that post however in this case it doesnt quite match my issue, Im not getting another field at all, irrespective of the anchoring, even duplicating the existing fields in the code doesnt yield a result, for example copying (from line57 of the record_npc.xml file)

    Code:
    			<label_column name="summary_label">
    				<anchored>
    					<top relation="relative" />
    				</anchored>
    				<font>reference-b-large</font>
    			</label_column>
    			
    			<line_column />
    			
    			<label_column name="ac_label">
    				<static textres="armorclass" />
    			</label_column>
    			<number_column name="ac" />
    			<string_column_npc_remainder name="actext">
    				<anchored to="ac" />
    			</string_column_npc_remainder>
    
    			<label_column name="ac_label">
    				<static textres="armorclass" />
    			</label_column>
    			<number_column name="ac" />
    			<string_column_npc_remainder name="actext">
    				<anchored to="ac" />
    			</string_column_npc_remainder>
    
    			<label_column name="hp_label">
    				<static textres="hitpoints" />
    			</label_column>
    			<number_column name="hp" />
    			<string_column_npc_remainder name="hd">
    				<anchored to="hp" />
    			</string_column_npc_remainder>
    I would have understood that it would duplicate the NPC's Armor class fields, however even with merge="join"/"delete" or no merge at all, the sheet remains with only the one iteration of the AC field, I tried with a few other data sets, and my own with the strings added and the NPC sheet remains standard (aside from the one wording change which worked as intended), which makes me think im missing something else somewhere else, having spent about 5 hours working on trying to figure out where im going wrong is what brought me back here haha.

  7. #7
    damned's Avatar
    Join Date
    Mar 2011
    Location
    Australia
    Posts
    19,056
    Blog Entries
    1
    "there can be only one!"

    you cant have two objects with teh same name.
    names are unique, they have power!

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

  8. #8
    great to know, I will have another crack on thursday with the strings and what not ive already done haha im sure i will get it eventually but atleast i know that i cant trouble shoot using existing stuff.

  9. #9
    I finally figured it out...... rookie error
    Code:
    <includefile Source="campaign/record_npc.xml"/>
    does not equal
    Code:
    <includefile source="campaign/record_npc.xml"/>
    A bad habit im going to have to break haha got there in the end...

    The more I was looking at the way I had modified "Challenge" to "Species Rating" the more I realised that I had done a bit of bad practice by modifying the existing string to give the definition I wanted instead of creating the appropriate strings for the job. that started me looking into that one a little more and because I knew that the output was able to be affected by the dirty string mod, I had a bit more of an idea on where to look once I determined that the the problems I was having with the modification of the record_npc.xml file not appearing was being replicated with the problems in trying to correctly use new strings. that ment that the file had to have been failing to be either read or included, and thats when I noticed the capital "S" so with that in mind back to the grind stone. Sorry it was such an easy problem to fix but thanks for the time none the less.

  10. #10
    Due to the way that Pokemon are used in this rules varient it made significantly more sense to rework the way the NPC skills function, the easiest way I figured I could accomplish this was to copy the PC Skills Tab and add it to the NPC sheet, after going through the process I can easily see that its a fairly straightforward process, however due to me having negligable coding experience, it took me far longer than it should but atleast I got it done. Here is a screenshot of the current NPC sheet.

    NPC skills page.jpg

    Because Pokemon function more like PC's and the fact that they can be used for utility not just combat, I felt it would be easiest for both players and GM's to have the skills page completely populated, this means that the Skills section on the NPC main page is completely obsolete for this rules varient and as such it will be removed to neaten up the main page in the future as will the Languages section.

    The next task to tackle will be getting the new creature types added and functioning which will lay the ground work for the STAB mechanic to be implemented.
    Attached Images Attached Images

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