Итоги голосования для комментария:
Ahill_ хм… мне не то, чтобы надоело писать, но у меня есть стойкое впечатление, что мы расходимся где-то в базовых установках. Вот например:
я: Заранее предвидя возражения: почему написать «нельзя и всё»… хорошо отвечаю: «размер рулбука имеет значения».
ты (следующим комментарием): Раз уж у нас НРИ = синтез литературы и игромеханики, то почему бы не вставить описания в игру?

Это я не к тому, что кто-то плохо читает (к стати говорю тебе спасибо — ты один из немногих, кто придерживается нумерации вопросах в постах) спор идёт по-существу, но о разном.
Поэтому предлагаю сделать так:
— выберем один «наиболее правильно отражающий недопонимание момент»
— разберём его до конца
— поймём в чём мы не сходимся (точнее на каком уровне у нас противоречие)
— разобравшись — вернёмся к началу обсуждения.
===========================================================
Я бы предложил последний раздел п4.б):
>> именно тык в правила «ХХХ нельзя больше 30» позволяет держать их под контролем… (до поры-до времени, пока они сами не поймут, что «пауэрлевельнее» не значит лучше для игры)
>> >> Та же фраза «Нельзя ХХХ больше 30» может быть выражена как «игрок может потратить на ХХХ до 30». И вот хоть из кожи лезь, система больше 30 не предоставляет и этой фразой также можно тыкать в новичков и указывать им их место.

Вот представь у нас условная 3.5-ка и нам надо ограничить персонажа игрока 30кой в любой стат.
ИТАК КАК ЭТО ВИЖУ Я:
1. стат = «base bility» + race bonus + lvl(4,8...) + enchancment bonus + unnamed bonus + sacred\profane bonus (и это если не оптимизировать, если оптимизировать ещё пару типов бонусов можно наскрести по книгам, но уже с бОльшим трудом).
2. У нас есть 30 книг книг + ещё 30 будет написано в будущем. Причём разные книги будут писаться разными авторами.
3. Какие есть варианты:
а) написать «стат в любом случае не может быть больше 30».
б) сделать дизайнерское решение такое, что как ты не изголяйся, стат у тебя больше 30 не выйдет (ну максимум 32).
в) ввести новую сущьность (кроме сущности «стат»<=>«attribute») и правило:
— — сущьность «эффективно видимый стат»
— — правило: «эффективно видимый стат» = MIN( «стат», 30), да правило скорее всего будет в виде таблички
— — не забыть, что все бонусы считаются от «эффективно видимый стат», а все бонусы \ пенальти \ дрейны и т.д. применяются к сущности «стат».
г) Вариант «нельзя больше 30, потому что» — ну да боле-менее подходит но это именно «вариант а) с объяснением».

вот знаешь я, как программист, работающий с большими проектами хорошо представляю все минусы вариантов б) и в) и всё красоту и надёжность варианта а). Просто задал правило (в явном виде) и наслаждайся. Все эти мороки и головные боли (которые в вариантах б) и в) лежат на дизайнерах) переложены на оптимизатора: делай шо хошь, но больше 30 не будет.

П.С.
Да ещё представь себе. Я такой умный парень сделал хорошее надёжное, не предвещающее проблем решение по варианту а) т.е. написал «больше 30 нельзя».
И тут ко мне подходит такой умный парень (из отдела маркетинга) и говорит: «слушай пользователи плохо воспринимают сентенции „ХХХ нельзя и всё“, давай-ка ты переделаешь это в вариант б) или в)».
Если я хорошой дизайнер — то я просто пошлю его на ХYZ (я без шуток просто немного грубовато (скажем хороший программист в аналогичной ситуации сделает именно так (если я верно вижу аналогию между программистской и дизайнерской работой), т.к. предлагается решение, которое реально сложно поддерживать и которое с течением времени «накапливает технический долг», т.е. будет обходится всё дороже)).
Если я плохой дизайнер — я соглашусь с ним и последствия этой моей бесхребетности проект будет расхлёбывать на протяжении ещё очень долгого времени.
+