But the 4e books says he should be a defender.
<snip>
4e shoehorned classes into a particular role by telling you what role each class is.
the way 4E presented roles, it came across to some people as the game telling them what to do with their characters.
I've put these two quotes together because I think the first once is a nice instance of the phenomenon that the second one describes.
When I read p 16 of the PHB, it never occurred to me that the game was telling me what a fighter, or cleric, or whatever
should do. I read it as describing what, by default, a character of that class is likely to do. So I read it as basically giving me some shorthand build advice: if you want to play a melee-oriented, "centre of the scrum" character, choose fighter or paladin; if you want to play a "force mulitplier" character, choose cleric or warlord, etc.
It also draws attention to some idiosyncracies that are legacy features of D&D: force multiplication and healing are grouped together as functions, and so are AoE damage and non-hit-point-condition-infliction.
The first character I built for 4e was a version of an old AD&D Skills and Powers cleric I had played. This character had been principally a strong melee combatant who did healing and divination also: after looking at the STR cleric options and the STR paladin options, I took the view that the best way to model him in 4e was as a STR paladin with warlord multi-class, aiming to take Ritual Caster sometime during mid-Heroic tier.
I probably could have worked that out without the role labels, but the labels give me a guide to what sort of combat capabilities the designers think a PC of a given class is likely to default to. I'm pretty confident the 5e designers had similar sorts of ideas - they didn't just throw the class options together randomly, and the core maths of 5e looks to be reasonably tight. It's just that they are, to a larger extent, leaving it as an exercise for the reader/player to work out what the feasible range of options is.
I still haven't seen any benefit that could be derived in 5e from adding labels on top of classes that in their description already tell the players what to expect. As for how they should best use abilities...how about they should best be used however you can creatively think of for the situation?
The benefit would be helping people build the PC that they want to build. In my experience most new players think of their PC first in terms of fiction, and then need some guidance connecting that fiction to the distinctive mechanics of the game system. Roles are a label that help make that connection.
My own anecdote to illustrate what roles are meant to help avoid: a new 2nd ed AD&D player whose mental image of his PC was as a lightly-armoured swashbuckler dancing among his enemies and cutting them down, and whose character was a fighter with a mediocre AC doing 1d6+1 points of damage on a hit. And who was, therefore, outshone in melee combat by my heavily armoured mace-wielding cleric.
This is a classic case of fiction/mechanics disconnect. Role labels should help avoid it. (In core AD&D I don't really think a swashbuckler is mechanically viable - at least until you start exploring fighter/thief multi-class options. In the 4e PHB, the role terminology points you to the rogue.)
As far as "creative thinking" is concerned - unless the game is being adjudicate solely by free roleplay and GM fiat, mechanics will matter. 4e is a very mechanically intricate system, and I think that 5e is not all that much less. Creative thinking has to happen within the scope of the mechanics, and role lables help give inexperienced players guidelines and advice.
Then I'm not sure I'm following you. When people talk about roles in the 4e context, they're talking about how 4e clearly defined for you that if you were class X, your role was Y.
Which people? That's not what I'm talking about, for instance.
When I talk about roles in the 4e context, I'm talking about the fact that (i) the way mechanics and fiction interact in 4e, by default there are certain salient modes of contributing to a party's effectiveness, and (ii) the designers have designed the various classes with an eye to contributing in one or more of these ways, and (iii) they have stuck a label on each class to give you some guidance as to what the designers had in mind at step (ii) in light of the reality of step (i).
I think that (i) is probably true in 5e as well, although perhaps not to the same extent as in 4e (for reasons I've posted upthread). I think that (ii) is likely to be the case also, for reasons I've stated in this post. Obviously (iii) is not the case.
I don't see value in trying to shoehorn the 5e classes into 4e roles.
Who, in the last 200-odd posts on this thread, has claimed that 5e classes correspond to 4e roles? It's obvious that they don't. The interesting question is whether 5e contains the mechanical space in which roles emerge, and if so what those roles are, and how they relate to various character build options.
I think that 5e probably does have that mechanical space - it's combat mechanics are not as intricate as 4e, but are more intricate than AD&D, and hence even more intricate than a game like Tunnels & Trolls or Marvel Herioc RP - and I think you have to get to mechanics as simple as those two for roles (other than perhaps "healer") to disappear completely.
And I suspect that there are interesting relations between class build options and those roles.
I remain unconvinced that 4e roles (by which I mean roles as they are presented, defined, etc. in the 4e corebooks) are the same "roles" found in 5e
I'm agnostic, but incline to think that there are sufficient similarities in the 5e and 4e combat mechanics that there are likely to be similar if not identical roles.
The change in movement rules and the reduction in mechanical duration of combat seem to me to be the most significant changes between the editions. But I haven't got a clear handle yet on the extent to which these dissolve the 4e roles and/or lead to new roles emerging.
Just getting to this post now. It is again very revealing.
Thanks.