Needs help building new system

[scarmiglionne4]

I am having issues with organization of tasks I suppose you could say. I find myself bouncing around quite a bit from one section of my ruleset to another.

Anyone out there with experience in making games have any tips for me? Is there any sort of order of tasks or checklist used? My notes are just a mess of ideas.

[Meeki]

As far as completing your project is concerned, you need project management skillz. Look up some techniques for planning out a creative project and go from there.

From my experience as a project manager, it is best to look at your desired end product and work backwards from there. Say you want to develop a fantasy game that simulates a steampunk setting with blah blah blah....

You can flesh out that idea then work backwards. Ok, you know you need a setting and game mechanics. What else do you need? Editors? Game testers? Artists? Layout professionals? Writers? Mathers?

Game mechanics -> Develop concepts for the mechanics. Are there skills? Combat? Stats? Magic? Building stuff? What feeds into what?

Start writing down a hierarchy if that even exists in your game. Do stats feed into skills or combat? Are stats the only modifier to rolls?

Say you know you want skills, combat, items, magic, and travel rules. The outcomes will be fed with stats, races, class, etc...

You don't need to pick individual skills, combat moves, types of dice, etc... until after you have an outline planned at least. Develop a web of what feeds into what, organize it in a progressing fashion, if it turns out to be progressive, perhaps every aspect of the game effects another aspect.

Eventually, you will have something like below:

Stats -> Skills/Combat/Magic -> Resolution of mechanics -> Game
Race -> Skills/Combat/Magic -> Resolution of mechanics -> Game
Class -> Skills/Combat/Magic -> Resolution of mechanics -> Game

Full disclosure, I'm not a game designer so this may not directly apply but my point is to make a relationship chart to find out what is at the center of your game. Then work from that center outwards.

[DMMike]

The bouncing around will happen a lot if all your rules tie into each other. Which is good.

But you should draw yourself an outline, similar to what Meeki said, and drop your ideas into the right areas. Say in Windows, make a separate file for each branch of the ruleset. When you get an idea, enter it into the appropriate file, and then go back to writing what you were before. You can flesh the new ideas out when you're done writing the ones you're on.

If whatever you're writing uncovers more and more rules to support it, then you're writing the wrong rules first. Start at the bottom. The core rules.

You could try what I'm doing: write a catalog of all the rules, and all of their dependencies. For example, one rule states: Enemies wearing armor use the hit-location table for "monsters." Well, that could be a great rule, but you'd better write the rules on which that one depends first, like "enemy" definition, wearing armor rules, hit-location rules, and "monster" definitions.

[Day_Dreamer]

Figure out what the rules are supposed to do, and what type of game you want to make.

If you're making a game about a bunch of adventurers going into dungeons and killing things, you're going to want strong mechanical support for that, so fun mechanics to make combat interesting.

If you're making a game about a bunch of vampires brooding over how much their lives suck, you're gonna want strong mechanical support for that, so fun mechanics to deal with brood-levels and social interaction.

Then, look at some other games that've done that pretty well. Like D&D, or one of the Vampire games. Try to pick apart specific mechanics that work.

Next off, try to think of a dice system. Take a look at probability distributions, and common RPG dice system (d20, d10, fudge dice, etc.) Think about which one best reflects the type of game and theme you're going for. If a player should always have a 5% chance of doing something, d20 works. If people should be heavily constrained by their skills, d10 or fudge works better.

Then, think about how conflicts work and are resolved in this system. In most d20 games, the player rolls a d20, compares it against another roll or a static number, and then either succeeds or fails. In other systems, you have degrees of success, or variable numbers of dice. Try to think about how you want the meat of the game to go. If you're game has a lot of social encounters, try to think about how you can represent that in your dice system

Then, design whatever needs to go in to make it work. If you want to have specific proficiencies, think about how a player acquires them. Do they have a class? Do they level up? Should they be able to just point-buy whatever skills they want?

Then, round out the engine with whatever stuff it should be able to do. Add special actions or rules for attacks of opportunities. Write up classes or powers.

The key is to have a strong sense of vision, so you can make sure that you're actually making progress towards a goal.


Also, playtesting may reveal that things don't work. Your dice system may have seemed like a good choice, but just not function. This isn't the end of the world, and you might be able to salvage. Just keep your initial idea in mind, and always check if a given change or addition helps that take form or not.

[Grod_The_Giant]

Bouncing around isn't necessarily bad-- it keeps you from getting bored hammering at any one part of the game. I'd advice you to make sure that your core mechanics are nailed down first, though, otherwise changes there will have to be copied across everything you've written.

[Lappy9001]

Don't feel bad about abandoning one version to write another, if it comes to that. However, you will need to finish one evenrually :smalltongue:

Others have said it, but keep yourself to a few key ideas and don't waver from them. These are the most important parts of your system, goals to achieve, and guidelines to build from. It's like the thesis of a paper.

Keep. Everything. It's a good idea to save files or documents with different version numbers as the system evolves. But when you are stuck for ideas, going through your old material can help immensely.