Where to start on my RPG?

While I am not as experienced in programming as yourself, I would recommend creating a GDD (Game Design Document) first. This is not a 20 minute project as you may spend several hours or days on it.

By writing down all of your ideas and concepts, to include details such as sounds, music, graphics you want to do, features of your game, skills that characters will use, settings, world maps/dungeons, and so on, you can have a clear idea of the project in front of you.

Once this is complete, you have a road map to your entire project. Of course you can change things as you go along, but the framework is laid. At this point, you can now pick a reasonable spot to begin, such as developing the character and their skills, perhaps the progression system. For this, I'll leave it up to you and the advice of a more experience programmer in RPGs.

However, as you begin, you can simply work from this GDD, and you will be able to "check off" things that you've completed and work in some sort of linear fashion, making sure you aren't forgetting anything and capturing all the content you want.

Cheers. (I have a template of a GDD if you're interested)

Wow that's a great idea thanks!

Oh and yes could I have a template?

If you want to just get done with it, have you considered using a game engine to avoid this work and be able to get directly to the point?

If you intend on actually making the engine, I would believe that having created another engine before you have already went through some of the stones on the path. So this would be a little easier, even tho, once you reach unseen territory it'll be a new experience.

Anyway, I would start from the basics, how do I want to do maps? Using simple tiles? Ok, so you create a simple tile based map with an integer matrix representing textures. Simple map done? Now on to the drawable objects, such as the controllable character. A simple character placed on a location on the map. Now, how does he move? What are his animations? How do I work on the animations for the character sprites?

Great, now you have a base character that you can use to build enemies and npcs, being able to separate the npc behavior and enemy behavior in different entities, now that the components that all characters (player controlled, enemies, npcs, everything) have, are already done.

Long story short, what I'm trying to say is, I would take steps during which you would be able to see the progress and test fast. This is the way I build everything. Being able to actually make the minimum viable product fast will allow you to actually test how things work, find things you didn't expect when you planned, find gameplay issues, etc.

Making a design document can be a good thing if you have a billion ideas and you want have a great idea of how you want your game to be on the long run, but in my opinion considering the actual development, doing small steps one at a time and being able to see things working will give you better results overall.

Yeh that's what I've been doing for a while but I always end up making the programming all chunky with loads of bad short cuts.
I think I should plan this one instead of going straight in like I always do.
Thanks +1rep

Well obviously you need to have the story written somewhere for starters. After that you might want to start laying out the different concepts your game will include. These concepts will be useful to represent a low representational gap with your class objects. Perhaps making a quick domain model and a class diagram first will help you in avoiding those "shortcuts" you speak of.

These "chunky" programming you mention, do you write in OO or procedural code? Think of each object in terms of responsibility. What should "Entity A" logically do. I'd also suggest working in iterations. Start with the most difficult core functionality and review each step to make sure you are going in the right direction.

My experience mostly comes from business logic applications, but it translates rather smoothly to games if you plan things right.

And in the end, planning game design will not help you in writing clear code. Perhaps you should invest your time in improving your development knowledge, learning a bit more about development patterns, since the problems you face seem to be regarding code itself.

I think my code is fine. When I work on small projects which are pretty straight forward and don't have too much content I can code them very well.
It's just when I'm working on a big project on my own which has lots and lots of different features it gets a bit harder to think where to start.
I actually can't wait to start on making this game.

Most IDE's (with the exception of the uber lightweight) should support splitting your project into multiple files. For instance I could have main.cs with my game loop in it and a seperate file called actors.cs with all classes related to animating the characters and NPC AI etc in it. By moving these classes out of the same file as my game loop it massively improves readability IMO. I suggest you look into these features if you haven't done so already, just don't break it down too far, I think game loop, actors and map should do nicely as a 3 file set-up. A 4th file with some more misc classes could also be added, shouldn't need to go further than that at this point.

Might help you manage this larger project.

Yeah I already do that in eclipse. It's not about how I do it after I start it's about where do I actually start at all ;D

Ok, Set up your main game loop empty for now. Then in comment lines write what needs to be done in order which might be: read input, process input, run AI loop briefly, update character locations, draw. Change as you see fit. Then go from there.

Yeah I already do that in eclipse. It's not about how I do it after I start it's about where do I actually start at all ;D

Like I've said earlier, try to define your different entities as classes. Then look at their interactions with the rest of the system. Obviously you will have to tweak your initial analysis, but that's completely normal. It's also normal that you find bigger projects more difficult to keep organized.

Here are some guidelines to get you started with OOAD:

1-Think of the entities
2-Draw the domain model
3-Write generic use cases for what seems fuzzy(Such as, how will a player move around the world for example).
4-Make a class diagram with relations, use GRASP and think of Cohesion and Coupling for each of your classes.
5-When you are stuck on a part, review the GOF Patterns, perhaps one of them can help you with a specific problem.
6-Start writing code and keep going back to the domain model and previous steps to clarify your progression.

Obviously this isn't going in very much detail, I skipped contracts/glossaries and sequence diagrams for simplicity. This is what I do whenever I start a project with more than 50 classes. You can also look up architectural patterns(MVC is an example, but it doesn't map that well on games...), they can dictate how your classes should be organized.

If you are too lazy, then this is the most important principle in my opinion : Think of objects in terms of responsibility If you apply yourself during the creation of each class with this principle you shouldn't be too bad(Why should X do that, why should X have that, why should X talk to Y, does it make sense that X does this... and so on).

I've thought of a way to do it.
Have a base entity that has methods like move to place or interact with object.
Assign each entity with a script.
Run each entities script during game.
Have maps. Assign each map data file (position of entities). assign each map image file for the world.
Have a player. When a player does something a method in the Entities script is called for instance.
Player clicks on the NPC to talk. NPC's script is called at onPlayerTalk();
Something along the lines of that .