just do stuff randomly

if you're working in a team create a gamedesign document

no, do this anyway

if you are asking a question like this, you should probably do small scale projects to get experience that will help you understand the process better. i would say there are general guidelines that can be applied when making an rpg, but i think it's a little different for everyone. you need to understand how you work creatively first. doing smaller, manageable projects will prepare you for bigger projects and naturally teach you the workflow.

you could get more help if you posted with more detail what you are trying to do, problems you had in previous projects, and anything related. there is only so much advice you can give to a general question like "where to start in rpgs?"

I try to think of every piece of the game as a system that needs to be designed, planned and implemented. Each system needs to be introduced at a particular point in development and needs to be completed in it's entirety before I can move on to the next system (the most difficult thing here is patience as it does take some of the fun out of designing a game.)

So what "systems" does an RPG need?

Let's look at game mechanics first:

Menu system: Customized? Will you need images, etc? Draw up a basic layout of what you want to see in the menu. If you plan on having a Quest Log, an Action Battle System or a unique inventory system, then you might as well customize your menu. Will it include a stat screen? What else will it have. Again, draw up a basic design of what you want as this may change as you figure out what you want in other systems (in which case, the menu might not be the first thing you develop.)

Battle System: This has several steps or sub-systems as I like to call them. Everything from monster development to battle animations to monster stats coupled with equipment stats. If it's an action battle system then there is a lot more to consider when it comes to programming.

Now if you are starting development from the above stages, planning around game mechanics, then you are probably trying to bring something unique to the table in regards to game play. Chances are you got a real good idea for a battle system first and then decided to make a game around it. If this is the case then design, implement and play test the crap out of that battle system before moving on to any other steps. Have it perfected. If it's an action system chances are there are events that need to be on every map, thus programming this first is essential to saving time as you can then copy a blank map with the events already on them to save hours of your time. This is not the approach I take...

If you are making a traditional RPG using one of the RPGMakers and you intend to use default menu/battle system, then I suggest the following...

Build a world map. If you haven't completed a game before then start small, 100x100 or 200x200 or so for your whole world. Fill this in with detail and really think about where your towns and other objectives are being placed. What order will the player be reaching these places, if any (non-linear). Have your world map perfected? Excellent...

Now there are two ways I see to proceed. The first (and unfortunately the way I choose) is to map out the entire game. Get ALL the mapping out of the way with the exception of possibly a few special quest locations that you may plan on later. Map the cities, map the interiors, map your caves, map until you hate mapping (I hate mapping.) Good, now STOP MAPPING AND MOVE ON. Again, the trick is to complete an entire "system" before moving on. Mapping is a system. If you map one town now, then spend 6 months developing other parts of your game, then you go back to mapping, you might start mapping in another style, or you might decide your first town is too dull, etc. This makes you jump around a lot. FOCUS. Get the mapping done first. It's frustrating, but you can do it. Something that helps is to plan to make the game expandable LATER. For instance, make a city so big now, then when you complete the game you may wish to add maps to that city to make it larger. Perhaps you'll add whole other towns in expansions. Keep it under your control to start though. Plan what you are mapping out ahead of time and stick to that mapping plan. I added blank maps organized by region, city, interior with everything named before I actually started making the maps. This way I just had to fill in the blanks. It's like a personal progress bar on the side.

If you don't want to jump right to mapping the other way to go is to really flush out your world (I recommend this way). After making your world map write a whole bunch of history for each location and the world itself. Design the religion, the politics, previous wars, current events (is there a war brewing? noooo... in an RPG? wowzers), etc. Develop some dialog for the NPC's, specific to each location. In city one perhaps people are really concerned about the King having a bad hair day and this may somehow result in taxes being raised. In another city people might be really chillaxed and not give a crap, even though they are facing impending doom. For a real approach create a ton of dialog and implement it in common events so that it's easy to give to multiple NPC's while maintaining variety. Maybe there are 20 things an NPC in city 1 might say about religion. Well, make an event that allows you to ask about religion and then have a variable choose 1-20 with a different phrase in each. Random every time. Summary: History, dialog, general interest in each region (what will city one include? a library, boat launch, castle, casino, mostly houses, etc?) Why will the player want/need to visit each location? If there is no reason to visit, there is no reason to have the location. What is unique about each location? Basing cities around the real world adds uniqueness believe it or not. Perhaps one city will have waterways instead of roads (Venice), be high up in the trees (Amazon), be western, industrial, etc etc. Plan the hell out of your world. Once you do this coming up with ideas for quests is REALLY easy. So easy in fact that you should have a file open while designing your world to put in quest ideas as you go, as they will come naturally. The next step is naturally to fill in your quest ideas. From here your game is essentially planned. All that's left is the work (boo). You need to program in the systems to fit with the design you've come up with. Again, mapping is a great way to start if you're using default systems. It's pretty difficult to implement quests if you don't have any maps or NPC's. Take logical steps.


WHAT NOT TO DO:

Make map 1 a house you start in, place your start spot. Add an NPC that welcomes you with some bullshit undeveloped story of what is wrong with the world and how you are an unlikely hero, but still need to fix it all anyway. Have him give you a sword and a smile and say good luck. Then add music to the map and fill in some overlay. Then start adding party members and making your first monster battle. Then go back to the room an add a book that gives you a fire ball spell so you can test magic on your monster. Then make a map of the around around your house and put a barrel next to your door with a wooden shield in it. Then program a plant that gives you an ingredient you just made up because you suddenly decided alchemy would be fun to have.

Don't do that.

Basically there are tons of ways to make a game, few of them successful, none of them successful without planning. Plan and stick to that plan, whatever order you want to do it in. Perhaps you can work on two unrelated portions of the game at once so it doesn't get too tedious. For example, I map for a while and when mapping pisses me off too much I do some quest ideas. By the time mapping is finished I have 50 quests to implement (not a daunting task at all).

i didn'tread

11. poor formatting

oh hello you must be a software engineer. probably useful advice but:

1. better to (mentally) pitch your game to people you already like and respect rather than people in suits with cash - if you just want money there's easier fields than games.

2. formal design documentation is maybe harmful as  a first step for hobbist game devs because most of us have serious concentration problems and should realistically have START WORKING DO A THING STOP SLACKING as step one and then write down anything that crucially needs to be remembered. whether or not you can remember your own idea is probably a decent test of how good it is / how carefully you've thought it out anyway. i think that the number of projects that devolve into pointless fantasy about concepts is probably quite high. if you write good code, you can reuse it later when your concepts suck less, and as a general rule initial concepts don't work out.

I can't say much about actually creating your game, but I'd say the first step has to be coming up with an idea. For me, this is the easy part: I have a lot of ideas, and most of them just get filed away in the back of my mind.

But one idea doesn't make a game. Some people might disagree, but I'd say when you have an idea, just make a note of it and keep it somewhere safe. If it happens to match another idea, stick them together.

For example: "A system where characters learn skills from each other" is an idea, not a game. Then I glanced at it and added the thought: "some (temporary, maybe older) characters might have a lot of starting skills, but are only in the party to teach others". That's still just one idea with a little branch off it, not enough to really work on, so it goes into the file.

Then I have another idea: "Old hero comes out of retirement, but finds that the industry has changed a lot". This was inspired by reading a story about a guy who was in hospital for years, then found that he had to learn a whole new set of skills because his old employer had started using a production line.

Now that one's just a single idea too, but they both work with old people, so they get stuck together.

I think you should keep on until you've got 4 or 5 ideas in a bundle before turning it into a game. If possible, 3 ideas that all connect to each other, making a little loop, will be preferable to 4 in a line.

Before you start with the actual "making", I'd say you should decide on the basics of your world, characters, system etc. So start with your ideas and ask questions. "Why is he retired?", "What's he been doing for all these years?" "Are heroes common? Do people acknowledge their role in society?" "Is there magic?" "What's the tech level?"

If the ideas you have naturally suggest answers, that may be a good omen. If there's more than one possible answer, think about both. If one of them loops back to another idea, or connects to something else in your ideas file, then take it ... a big set of ideas that fit like a jigsaw is a perfect core for your game. As each answer raises more questions, try to answer those too, until you've got a pretty good idea about your world.

It's kinda sad that art students are giving out advice for software engineers.

The process I use normally involves not writing down an idea if I think it's good. I'll at least go a couple of weeks before writing it down for two good reasons:

1. If I already know it's a good idea, I already anticipate that I'll be thinking about that idea really often. If I haven't let myself not think about it long enough to forget about it, I can be entirely sure that it's an idea that's worth writing down at the very least.
2. The more I think about something, the more likely I'll want to change things around. If I write it down right after coming up with it, then I'll drive myself crazy opening and editing the document over and over every time I think of something to change or add. The things that I need to put in the document the most will end up being the things I think about most often anyhow, so I can trust how those essential things will be clear in my memory when I finally do get around to writing the whole idea down.

Of course documentation can only give you exactly what you put into it (hint: it's documentation), and as such counts more like a step 0 rather than the actual step 1. (It makes more sense to software engineers to start things at 0)

As to my own experience in an actual game development context, I still I have yet to reach step 1. (Although, I do have that step already well documented. Putting an immediate TO-DO list in a file outside your design document is a task I can't help but wholeheartedly support for ameaturs and professionals alike.)