1KM1KT Free RPG Community

It's a neat idea and I see this in places where you have a generic ruleset and then each setting adds their own rules on top of it.

The thing to watch out for here is combinatorial complexity. The more modules you add, the more difficult it is to work out how the ruleset combines to play together. This shouldn't stop you from building the modules but I think it's a lot of work that is hidden from the initial idea.

Don't forget that to give the system a good run, you need to create at least one setting. I obsessed with this idea, I know, but those systems that have no setting have real difficulty demonstrating the novelty of the system.

Are you going to be uploading and sharing in a modular way too?

I find the idea of "namespacing" the modules quite interesting. I think it's intuitive but then I'm a programmer. I'm guessing that you're a programmer too...

Barely; I started this year with PHP and I'm trying to pick up a little C++.

Isn't this GURPS? Ok, not the system, but the intention? I've played with this idea several times but I can't figure out a motivation to really work on it.

Not saying don't do it, but what is the hook that makes this more/less/different that GURPS.* Get something to hook into or it's just another universal system. The other problem with this approach is that if I don't like something in the core mechanic, I want nothing to do with the game. Is there a way to swap the core system? I think about playing Robotech for years and years. I played under several GMs that had totally different interpretations of the system. They were mechanically very different games, the only rooting aspect was that the character stats and MDC on the robots.

*Protip: "It's free!" is nice but it won't draw players away from an established name.

It should be possible to swap the core system–it's a little outside the scope of the project, though. I'm focusing entirely on an alternate interpretation of d20-driven design (i.e. not having anything to do with WOTC d20), but almost everything else is interchangeable. Much of the core line is based on defining stuff; the core module references using a d20, but doesn't talk about rules for it, as that's under the roll module, and the rolls module is the d20 one. Were you to convert it to a 2d10 system, you wouldn't even have to change anything but the dice you use (though it would change the balance).

My main focus with this system is to make it very light. My secondary focus is to have need-driven rules access, meaning that due to the modularization of the system someone playing, say, a monk, has all the information for a monk in their character, with the monk module mostly telling them more about how to set up their character. I'll admit that I'm only loosely familiar with GURPS, mostly from a few chats about it and a variety of references to it, but I think that I'm hitting a different distinction between modular and generic than they are; they aim for being extensible beyond a core, but I aim for making everything super-light and simply letting people use what they need for their game. One part of this is by treating every module as having output, but not necessarily requiring input. For instance, Combat has vague hooks into ABACUS, Skills, and Generic Gear, but you can either run more specific modules or simply drop those modules, though dropping those modules could mean that your combat basically amounts to whatever the GM deems appropriate.

For instance, if you wanted a simple(r) game, you could run my list, but simply drop Skills and Generic Gear to limit yourself to just five modules; you wouldn't have rules for carrying capacity (though Character handles basic untyped items), or weapons or armor, but you could still run combat because the Skills and Gear additions to combat flow out from them.

The main reason I'm making this is because I've gotten back into Pathfinder recently and got frustrated with the sheer volume of content I needed to play a simple character.

Going back to the programming side, it might be useful to think about things in a Object Oriented Programming (OOP) light. Import classes (get it?) to your design philosophy and inheritance.

A character is a representation of a person in the story world.
A PC is an instance of a character that a player takes control of. A PC has stats.
An NPC is an instance of a character that is controlled by the GM.
A Stated NPC is an instance of an NPC. A Stated NPC has stats.

Higher order classes are mostly just definitions, while more specific classes start having rules and values associated with them.

Besides, it will help you learn good programming practice. The trick would be not making it sound like you're reading off code.

I do that in part; I don't tend to take too much of an object oriented approach because most things are self-contained in their module, but I'm working on some things.

A large part of the appendix system is actually inspired by part of my work on XMICAE (my custom IF platform) and its heir YMICAE (which changes up the data storage from the XML markup language into the YAML serialization scheme, as well as re-writing).

Each module tends to have "function"-esque components, things that say "GM:" or "Storyteller:" or "Players:" and suggest things that should be done based off of it. In addition, you then have appendices, which serve to extend these modules with additional functions or provide additional data storage. I'm trying my darnedest to consider every possible variable at the same time; ABACUS is a "strict" criteria for attributes, but I'm thinking about handling skills as being loosely defined-you get the GM/Storyteller's permission to have them, and then you use them at appropriate times. Settings and functional modules can suggest potential skills. I'm partially inspired by for Pathfinder in some ways, though I'm focusing on rules-lightness and single difficulty checks, which also means that we don't have very much to reference.

One thing that increases potential core compatibility between different rules modules are difficulty ratings; as you add on modules they specify how difficulty ratings should be changed to reflect this–so if you're playing with only a d20 then a difficulty of 21 is "Impossible", and 20 is "Legendary"; both of those get bumped up as you add in the ABACUS attributes system and the Skills module, so that 20 is "Difficult", 24 is "Expert, 28 is "Legendary", and 31 is "Impossible" (Impossible tends to scale up quickly, though it doesn't necessarily outrun the modules you add).

Part of my focus, at least with my content is to make basically everything but the PC simply use difficulty ratings; this allows them to scale with the modules you have "loaded", and keep them in touch with reality.

I'm going to bump with progress:

I've been working on a rough setting/adventure for the D20m system; it's set in a grim dystopian future totally not inspired by Dredd (and by that I mean "it's a good thing I have a bad memory, or this would be a blatant ripoff"), and will focus on decision making and problem solving beyond gunplay (and the occasional high-lethality combat). No word yet on how long it'll be; I expect the writeup of setting information and gear to push three pages, and possibly

I've made rough drafts of five of the seven system modules (CORE-Core, CORE-Rolls, H-ABACUS, H-Skills, and H-Combat), and the character module will probably be pretty simple, since it's going to be a rudimentary point-buy system and a brief record sheet with an ABACUS and combat info stat-block, a few lines for skills and their ratings as well as a space for some gear. I'm planning to have a test of them on Thursday, which means that I probably won't post them until after that and some revisions, but if the test falls through or something I'll post what I have when it does.

The main roughness right now comes from editing and consistency concerns more than necessarily game balance; I use a system not that dissimilar to the d20 System that people know, it's just redesigned for simple, classless, play and more novice-friendliness, which includes making things draw more from attributes, skills, and gear directly rather than having fifteen thousand character sheet entries for things like a Will save, AC, or BAB.

EDIT: A note on the combat; I've eschewed simulationist combat in favor of having a cluster system; characters form clusters for close combat, and can only make ranged attacks against people outside their cluster. Clusters break and form pretty easily.