SqueeG/awesomeTome

Base Class Chapter

Tarkisflux opened this issue · 54 comments

We know we're going to have one of these chapters, and we know it's not going to look drastically different than what we had before. So we might as well start determining exactly what base classes are going in so that we can update and errata and start putting them in their place.

Here's my suggestions from the Den thread (slightly updated), because it seems as good a place to start as any:

For sure:

  • Assassin
  • Barbarian
  • Cleric (or replace with Favored Souls or Priest or some sphere variant),
  • Druid (or replace with some elemental sphere variant),
  • Fire Mage, level 15 or 20 version depending on level cap in the book (can do 2 or 3 varieties even)
  • Knight
  • Marshal (10 level version, expected to knight prc)
  • Monk
  • Thief Acrobat
  • Wizard

Possibly:

  • Bard (requires one worth having)
  • Fighter (requires lots of system knowledge, and doesn't provide much new conceptually IMO)
  • Jester (on the fence here admittedly)
  • Paladin (assuming one can be agreed upon)
  • Ranger (assuming one can be agreed upon)
  • Rogue (not sure what it covers that isn't already handled by thief-acrobat or assassin)
  • Sorcerer (again with the system knowledge (reduced if using wiki version), reasonably well covered thematically by <*> mages or sphere classes)
  • Anything sphere based (more subsystem to write, sort of covered by <*> mages conceptually).

I find the inclusion of both the Knight and the Fighter redundant - I know that ability-wise, the Knight is different and all, but I see them as fulfilling the same kind of role thematically, and it seems weird to have both in my opinion.

I agree, which is why I put it down in possibly and put the more focused ones up top.

Also, I missed one I'd like to see in for sure: Samurai

I'd like this to allow people to easily allow people to convert from 3.5

So I'd like to see the iconics have direct replacements ( or suggested replacements ) that won't turn my players into Grognards and mutiny on me.

Even though my group can be open to new things, they give the stink eye to material thay takes them _too_ far out of their comfort zone. Which is, admittedly, why I want to try and have this Tome stay simple with a second edition being more... advanced.

What's everyone's opinions on 'broad' versus 'narrow' classes? To give a simple example, a broad class is 'Wizard' - with that class, you can build a wide range of characters with different, but thematically-similar shticks. An example of a narrow class is Assassin - they do one particular thing, and one thing only.

I'm more in favour of broad classes, for the following reasons:

  • It means we can re-use more of the code. We can write up the chassis of a wizard once, and then give it abilities to make fire mages, ice mages, warmages, your-mum-mages, etc.
  • It solves the 'do we include Samurai, Knight and Fighter, even though they're all just reskins of each other' problem quite neatly. You just have one broad class (the Warlord, say), and give enough options for it to allow everyone to build whichever of those (in whichever form of those) that they want.
  • It means we need fewer classes overall, and expanding them becomes easier.

However, narrow classes are easier to write and probably easier to use, especially for the newer folks out there. So I can understand that as well. However, I don't think a system should mix the two. Thoughts?

squeeG -

So, your group would be ok with Knight/Samurai/Marshal as focused replacements for Fighter and the assorted Fire Mage flavors filling in for Sorcs? But they'd still want an included Bard and Ranger and Paladin (which aren't represented on my for sure include list), so that they could ? That sounds pretty workable.

mrsinister13 -

This question does not seem particularly relevant for the current scope of the project. We're leaning towards doing relatively little design work and reusing as much existing material as possible. So unless you're volunteering to do a bunch of new classes, we're likely to go with what we've got: a bunch of broad casting classes and narrow martial ones.

Well, that's fair enough. I just wasn't sure what this would involve, so I wanted to have that cleared up.

With the way classes have been designed to "Tome standards", I could see developing (at some point) several "broad classes" that have design specifications for creating "narrow classes" out of. Then plop those design specs in the DMG.

For instance... from the Wizard, you'd create the Fire Mage, Warper, Time Mage, etc. The Fighter would have rules/templates that walk you through making Rangers, Paladins, Barbarians, Monks, etc. The broad classes would basically be blank templates. You fill in a power source, create powers to hit certain benchmarks, etc and (hopefully) come out the other end with a Tome-balanced class.

Obviously it's outside of the immediate scope, but if it's not a terribad idea I could see it being useful in the future or for a new edition.

MS - you may want to see this broader issue to get a sense of where we're at with things already. It's much broader than the specific chapter issues (which I'm only making when things in that issue have shaken out a bit).

We need, at minimum, every class in the SRD. Tome versions of classes where possible. Additional classes can be added only after we have all the SRD classes in.

I don't care if there's also a system that lets you make your own variation of Fire Mage out of Wizard or Paladin out of Cleric or Fighter, but there needs to be a default and complete Paladin in the book already. For all the same reasons that 4e got a bad rep classwise. You can't have less classes to start than the last version of things.

Avoiding the 4e problem does not require a complete SRD redo. It requires sufficient classes to cover the SRD thematically. Are you asking for actual name for name replacements Lokathor, or are substitutions (in some cases, multiple substitutions) acceptable?

Also, do you have a paladin / bard / and ranger you want to include off hand? Or should I get a list of them together for review?

There are these classes that were linked in one of the Tome threads: http://tgdmb.com/viewtopic.php?p=346439#346439

None are really helpful in the direct-replacement category.
Maybe giving Kaelik a list to rip through would produce satisfactory inserts.

...or simply result in no melee classes making it past his anti-melee boner. >_>

Classes that don't have a Tome variation don't all need a Tome variation. I'm not saying we need to replace every class, I'm saying we just need to include every class. If there's nothing that replaces the Bard well that's just fine, most groups don't care. Most groups don't go much above level 10, the Bard is fine enough in the 1-10 range. If there's no Paladin replacement that's also fine.

All we need to do is not cut out any classes at all. The resulting classlist should be a superset of the SRD.

I, personally, would like to see a Tome Paladin and Ranger (Or reasonable facsimiles). Primarily because the Ranger has been one of my favorite classes aaaaand because the Paladin has typically be underwhelming.

The classes in that link are ones with errata to apply, I think. Which makes updating them easier, if we wanted to do that (and we might as well for anything that we already have). But if you want replacement classes, you'd want to scan the community material thread instead.

Bard Options:

There's similar numbers of things for the Paladin, Ranger, Sorcerer, and Cleric as well (which I'll drop in the issue later). The only classes that I can't point to replacements for are the Wizard and Druid. It's not really a matter of finding replacements, it's a matter of agreeing on whether it's being tome replaced and which option is doing the replacing.

For example, I would prefer to replace the SRD fighter with a weaponmaster (samurai), knight, and marshal in place of the fighter because I'm over the fighter as a class, don't particularly want it in the game anymore, and those others cover it conceptually, but just doing the tome fighter instead isn't a big deal. I don't really want to classplode in the core book on the off chance I ever feel like printing a copy though. We don't need more than 15 in here, even though we could have them, but we can generate as many supplements as we want.

Ok. Since I've declared myself dictator or whatever, I may as well exercise some power. Here's the base classes plan:

Current SRD Replacements

  • Barbarian - RoW version
  • Bard - SRD version, with bolt on performance styles from Frank and possibly redone spell list. I'll do it myself if I need to
  • Cleric - replace with this priest since we're redoing domains anyway and there's been a request for clerics to be more differentiated
  • Druid - SRD version. I'd like to do something else with this, but it's probably fine.
  • Fighter - Tome version with errata. I want a version of the pdf without it because I think its inclusion makes it worse, but we already have it and including it costs us basically nothing and people want it, so we'll do that.
  • Monk - Tome version.
  • Paladin - SRD version with bard casting progression, priest casting model, domains, and revised smite mechanics. Which doesn't really sound like the SRD one at all, but it's closer to it than the other paladin options we have (and I have about half of it written already). Want to do an alignment independent version that covers more conceptual space, so blackguards and paladins of slaughter or whatever are included by default. I'll probably just do this one myself.
  • Ranger - SRD version with bard casting progression, tome combat feats assigned, and a better animal companion writeup. I can also do this myself if I need to.
  • Rogue - SRD version with updates from recent Rogue 2.0 writeup.
  • Sorcerer - Wiki version based on Franks' PF sorc path thing. Link
  • Wizard - SRD version. I'd like to do something else with this, like give it actual class features instead of just spells and random bonus feats, but it's probably fine.

That covers the current SRD classes. Here's the ones we should add before anything else:

New Base Classes

  • Assassin
  • Jester
  • Knight
  • Marshal
  • Samurai, possibly reflavored a bit
  • Summoner
  • Thief-Acrobat

That's every other base class available to humans except the conduit (currently excluded because I don't think we should spend pages on spheres unless they're better incorporated / merged with domains, and that's more design work but something we should consider and I might just do). It also brings the list up to 18 (or 20 if the conduit and spherelock are in), which is a bit higher than we need but should be ok.

But 20 base classes in core also means that we should probably push off any other base classes to appendices or supplements or whatever. Like "Simple mages: acid, cold, electricty, fire, force, etc." or "Koumei's crazy shit: When you want Saint's Row instead of Grand Theft Dragon".

That plan is subject to contributor acceptance of course, but it seems to cover what people are looking for, and it gives us stuff to start on already.

Soulborn and Totemist are both very cool classes as well, if we can scratch off the "incarnum" bits and get a flavor that isn't IP.

In terms of classes, I think we might be better going towards more classes than less. If we do have a classplosion then we'll seem less stupid when we inevitably mark the Multiclassing rules as "we know it's broke but we can't fix it, use with caution".

Classplosion in the core PDF isn't a huge problem, even if you want to print it. Primarily because you can just comment out the erroneous classes ( according to your preferences ) and just recompile.

Once we have a sculptex project complete or mostly done we could even provide supplemental builds that make printing easier. Like Core Tome (20 classes ) + Tome splat! (100 BONUS CLASSES!!!111)

As long as everything being embraced in the project is of "Tome quality" and up to date. Not just a class designed by a Tome fanboii with no eye for balance.

If we decide to replace some of the standard 3e classes (the Tome versions, that is), I'd prefer we replace them all and have the originals in the additional classes section. As for class 'width' I'd prefer that the classes we decide are core be of moderate or greater width. I'd say that fire mage is probably more narrow than I'd want, but that assassin is right on the cusp of acceptable.

Except, within my own experience, Assassin is nearly unplayable within a standard group and Fire Mage is perfectly playable. I'm not sure that "width" is the only criteria to look at with classes, or even a very useful one. Barbarian also has a similar lack of width, but it's still a class that people love to play.

The assassin has some nice tricks, but it's a rather advanced class in that you have to play it very smartly and it did not benefit from the RoW scaling feats so there's certainly pitfalls to avoid. Kaelik's errata thread was going to give it feat support instead of class adjustments, but I'm not sure those ever came.

So, options for assassin:

  1. Make a bunch of relevant feats for them. I suppose we want this to happen anyway.
  2. Tweak the class frame a bit. JE has some not ridiculous ideas here, but they probably need to go a bit farther.
  3. Let them use their actual spells during the round that they're studying a target, so long as the target is targeted or within the area of the spell (ex: silent image around target, then death attack).
  4. Something else (which is always an option I guess)

Just throwing these out for thinking really, don't really have an immediate preference.

[EDIT] I added another option above.

And while I'm thinking about it:

  1. Fighter - reduction to 6 skill points: yay or nay? Personally, I'm in favor of it, since they get to benefit from [combat] feats and don't need piles of skill points to benefit from [skill] feats as well.
  2. Class skills: abolish or retain? Since skills don't do particularly amazing things, I'm leaning towards abolish and setting max rank == level. We can adopt something like the PF "you get +3 if it's a related skill and you have ranks in it" sort of thing if we want some sort of differentiation, thought I'm not even sure that's necessary or useful when you can just buy your skill bonuses in item form.

And I'm done for the night.

What about classes giving bonus ranks (does not allow the ranks to go over max rnk == LVL) to some specific skills?

I'd want to ditch the current implementation of class skills. Personally, I'd change max ranks to be equal to class level, and grant a +4 bonus (+3 if you want to keep some legacy compatibility) to any 'class skill' that a character is trained in (has at least one rank in). This would mean that anyone with training in a class skill gets an immediate +5 to it, which is equivalent to one tier of difficulty for most things (most DC being based on increments of 5).

I'd also want to get rid of bonus skills for having a high intelligence score (and negative skill points for having a low one), and just have each class (or racial hit die) hand out a flat number of skills per level. This would get rid of weird things where animals generally get one rank per level and have a bunch of racial bonuses to make up for it. If you wanted some sort of skill-based reward for high intelligence, I'd have bonus ranks that can only be spent on talents/skill tricks (if we do that). This is a comparatively greater (but not grand) change to the system.

Edit: I'd also like to get rid of synergy bonuses, no one ever fucking remembers them.

I was looking at formatting the sorcerer, when I suddenly realized that we have a new master document to work with. Do we want to use the class formatting from the awesomeTome pdf, from Lokathor's PDF, or do we want to come up with a new format? The awesometome formatting looks fine if you include the packages and newcommands it uses, but I do thing we/I could do a little better.

Use the sorceror as an example of what you have in mind, upload it and let us see. :p

I would like to see more formatting hidden in new functions, because I think that makes it easier to make changes later and get new contributors, but otherwise I defer to the more experienced LaTeX coders as to what works best.

So if you think we could do better, let's do better.

Also, maybe hold off on the Bard until next week. I've kicked a few things back at Cid, and he might be gearing up for a refresh.

I'm trying to make a class template file we can use to base new classes on, and to test out some new commands.
I'm trying to add some color to the classes. I'm currently wrestling with the mdframed package, might take longer than I thought it would -_-

I think we can wait a bit for a better overall presentation.

@ExplosiveRunes Have you ever checked out Minipage? Just ran across it today, haven't had time to look into it much, though.

Well, I got mdframed to do what I wanted it to, and I made a simple example class file and compiled it. If you check out the tome-ref-doc.pdf now you'll be able to see the sort of format I'm looking at. All I did was use some simple grays to visually separate out the different class features and the table rows. Tell me what you guys think. The colors can be changed around easily too.

I just decided to check how the format looks on a phone (Samsung galaxy 3) and its readable without zooming in.

I'd have edited my previous comment, but the github app won't let me.

I like the table and the potential for sidebars / well contained sub features like animal companions or familiars, but the alternating class feature thing seems like it would end up more distracting than helpful.

I liked the alternating grays for the class features (obviously, having done it) I felt it helped more when reading on the phone. If y'all don't like it though, it's easy for me to change. I just thought the endless expanse of white was boring.

I'll probably leave the abilities in the environment I created for them, which should allow us to easily change things back and forth if we want. The alternating colots were already automatic, using a bit of ifx logic (which seems to me a bit clunky, but my work on the tome pdfs is not only my only latex work, but my only programming work of any kind. Being referred to as one of the more experienced latex people on this project is scary) so someone contributing wouldn't have to worry about it.

There are also several new commands to reduce required input and make it easier for potential new contributors.

Any requests on the formatting aside from getting rid of the gray?

I actually like the alternating colors for HD, skills and skill points.

Class features... with more description might not look so awkward. I don't have any particularly strong feelings about removing the striping for class features.

I might have come off stronger than I wanted to. I like it for the the table and class info lines. I have concerns about it for class features, but I could well be wrong and we should certainly try it with a full class to see how it works out. Maybe it's fine as is, maybe it's fine with a lighter shade of grey for the class features (saving a darker one for sidebars or other enclosed box things), and maybe it doesn't work at all. In any case it should be a useful tool to understand for the eventual monster writeups.

Nah, didn't come off strong. I'm going to try applying modified versions of the format to several different classes and putting them into one PDF later today so we can compare them easily. I also want to see what some larger tables and floating tables look like with the table format.

I'll probably also try and make a more generic environment and a few commands to allow people to do some basic things without being familiar with the mdframed package.

I've pushed another commit, this time I've reformatted the assassin as an example. I'd prefer to move the whole document to 10pt. Many of the tables from legacy-source, especially the floating ones, don't render quite right in 12pt. I can locally change the font size in the floats, but they look a bit odd when doing so. I've provided three examples of the assassin, because it's a relatively complicated class to format. A long description, a full size class table, and a floating table within its class features. Tell me what you think. If this seems good, I can move the commands to the main document and start formatting other classes.

Edit: I meant I wanted to move the document to 10pt.

Well, it doesn't seem that anyone has any objections on that front. So I'm going to go ahead and change it. We can always change it back.

Also, I managed to get my phone stolen, so for at least a week here I'm only going to be able to read and comment at the end of the day.

No objections. Comments though. That will have to wait for me to be 1)not busy, and 2)not losing time fucking around with LaTeX.

Alright I incorporated the class related commands into tome-ref-doc.tex, along with documentation in the form of comments. I cleaned up the code to make it as easy as possible to format a class for beginners, or really for all of us too.

Next time I have time, I'll turn the example class into an example that contains an instance of every command that can be used, and turn it into a tutorial for beginners via comments. Right now the assassin along with the commented commands can serve as a guide for us, if someone else wants to format/re-format a class before I get to it.

I also decided to start documenting what ALL the new commands do, so that new contributors (...and me) will have an easier time parsing what the hell things do.

I'll strip it out for a copy/rename/fill in preload page. And then I'll get back to semi-automating tables. Yes, really (I can point you at a wiki example if you don't believe me).

I lied, I did the table thing first. Class tables should be a lot simpler to do for everyone now, and we can alter the formatting in a single place instead of doing it for each class. We might want different header functions (1 for those that expect a trailing column like Death Attack, and one for those that don't), but otherwise I'm pretty happy with it.

I'll get on the preload making later I guess, other things to sort for a bit.

Tenacious... I like that. :p
I was looking into table functions the other day.

Class template page uploaded. Copy it, rename it, and then go through it replacing the <-stuff-> blocks with what should be there. Normally the 'stuff' part of the block will tell you what that is, but it will probably be snarky about it.

I'm not clear on what the "\vspace{8pt}" is doing at the end of the item lists though, and @ExplosiveRunes may want to remove that if it's not helpful.

Otherwise, we can go ahead and port all of the Tome classes using the classtemplate.tex format at this point.

Potentially stupid question. Certain basic things are not included in the SRD, like starting age for classes. Is it legit to use the same starting ages as the PHB version of classes for OGL classes with the same name, because its a fucking number? Or is it a gray area?

We can use the "as X" stuff, but that's just a redirect to something else and we want to remove those and eliminate external lookups. It is not legit to use the actual WotC writeup for them, so we can and should make these whatever we want that is not that or a redirect.

Alright, I started trying to complete formatting on the templar. I was trying to come up with some way to display the Vows and Styles, and failed. I spent a few hours and just hit a wall. I wanted to come up with some standard that could be turned into an environment or command (or both) for any of the "You get to choose a thing here, see the things at the end of class features" features so that they could have the same format between classes (this would be things like vows on the templar, but also gadgets for the gadgeteer. Anything where the options are not in the main body of the class entry).

I think I couldn't come up with anything because I really don't know how I want it to look, and I was all over the place.

Halp?

I've been staring at a table loop all night. I know the feeling. :p

Not quite understanding what you're trying to do though... are you maybe overcomplicating the issue?

Nah, I don't think I'm over complicating it, just frustration over not knowing how/what I want to do exactly with the look. There's several classes that have complex features where all of the options get stuffed at the end of the class entry because there huge-long. Vows, Faith Styles, Gadgets, and soldier Maneuvers are examples of this. I want those sorts of things to share a format. I think I might just end up temporarily redefining subsection header formats while within some sort of new environment to achieve a good look.

Seconding shared formatting for those things. There are enough of them to be worth the effort to make them visually similar. It might be a place for the alternating colors you were previously working with, or a larger margins for differentiation from other sections, or something similar. Not sure what you're working with though, so I don't have much in the way of actual suggestions.

In case it was missed, I uploaded an alternate take on the option formatting that looks a lot like the option formatting on the Tome Sorc: normal text all around with darker blocks that contain the entire option. It will look different when someone else compiles it (because of compiling issues I'm having I guess), but I think I prefer the simpler look of that to the more complex looks that have been floated.

I think it looks fine to me. When I compiled it, it did look different. Simply adding ~//* to the end of the option command made it render for me similar to how it was on your push.

Is everyone okay with the simpler rendering, or are there preferences for something else?