Before I speak I'd just like to tell you about my past.

For me programming started when I was about 13 or so, but it wasn't really programming but scripting for the Warcraft 3 game.

I really enjoyed the game and decided to learn how to make maps using their editor, it wasn't long before I discovered the two different types of coding the maps, the graphical interface and the typing environment.

I learnt quite a lot for my age about how classes, functions, variables, using ready made functions (sin/cos, atan2 e.t.c) worked and it really had an impact on me.

A few years later I found that you can make games on the xbox with Microsoft's XNA with C# and learnt that as my first programming language, I never really made anything amazing with it apart from moving basic objects around and I realised programming at age 15 would take more time and effort to get me anywhere.

I ended up not really learning much about C# despite it being a 'simple' language to understand and instead made a massive mistake.

That mistake was me learning C++.

At first it was hard to grasp any concepts that C++ had to offer.

What is a pointer!? Include? Namespace... ?

But as time went on I understood the basics of a C++ console program (I thought to myself maybe it wasn't a massive mistake after all... ), and began to make just small applications such as basic text games.

This was amusing but it irked me that I could only make text games, so I searched the web and found SDL, luckily I came across LazyFoo's website which helped me set it up and gave a lot of explanation on how SDL worked.

I learned to make basic windows in C++ which could render images.

Now we come to the present.

I am a 19 year old University student in my second year of studying computer science, I really enjoy this course as it will hopefully help me get into software development (hopefully games, but you just have to be grateful for what you're given right?).

From using SDL I have made games such as Tetris, Astroids, Snake, basic platformers and other tiling 'systems' (but not really systems, just tests to see what works, if you get me?).

My current project is to just get a basic RPG which I can build onto in the future, I know it is seems like a daunting project for a single person, but I want to devote time to it and just understand RPG concepts and have this type of game 'under my belt'.

I have been browsing gamedev.net for ages and I read many posts per day, they are all inspiring and I love seeing the work and progress that others like me are making.

My current problem.

As I've been developing my problems are about structuring my code / files and circular dependencies.

Structuring my code

As I am using C++ I have headers and source files, this leads to quite a lot of files and I'm curious if there is any special way people organise their files in a project?

Like sub folders for files?

or Special naming conventions for things that are alike?

Circular dependencies

This is a joined problem with structuring my code, as I am in the process of making an RPG (albeit basic) I occasionally have thoughts on what I will do when I come to coding things.

People say that circular dependencies are mostly unnecessary and can be avoided, I would like some help on trying to understand this for my project.

What is the best way to structure a Map having Player and NPC objects?

Should the Map have references to Player / NPC's or should it be the other way around? Should they all have references to each other?

Should a Map have positions of all objects on it? Or should the objects store their own positions?

Maybe I have my classes structured wrong, but this is what this site is for right? Insight, Knowledge, Feedback and Help!

Sorry for the long post about my life but it just felt right giving some background, and to show that I'm not just jumping into something way over my head.

Thank you for reading this and hopefully sharing your wisdom with me!

You're asking some pretty big, open ended questions. I'll focus on the more narrow problem of circular dependencies.

This article on Gamasutra explains almost exactly the way our files are structured at my office. In the article you'll notice the author makes use of forward declarations (they look like "class Bar;") to avoid having to include an entire header file. This has two benefits: 1) compile times will be shorter, since each cpp file will have less data in it because there are fewer includes, and 2) it avoids circular include dependencies.

The author's stance against including .h files from other .h files is a good guideline, though many people will find it a bit extreme in some cases. It's a good rule to keep in mind, though: if you don't NEED to include a file, then don't. You'll almost always be better off putting a forward declaration in the header file if that's all you need.

Also:

That mistake was me learning C++.

It's never a mistake to learn C++. It's definitely not the easiest beginner language, but it'll easily be the most valuable language you learn if you are interested in working in the game industry. People may not universally love C++, but it's a fact of life. You're doing right by yourself by biting the bullet and learning the language. Subsequent languages you learn will be a breeze if you are already comfortable with C++.

[Disclaimer: I don't have any experience making anything like an RPG game.]

I would think the Map would know what the level looks like, the Characters would know where they are, and ideally the player would be just another Character, although I can see the case for treating it very differently. The Characters would know where they are (as in they have a member of type Point saying where they are). The Scene would be the object that knows about what Map we are playing on and what Characters exist in the game world.

I don't think there are any circular dependencies in that general way of structuring the code: Map and Character both use Points and the Scene has the Map and the Characters.

More generally, I usually structure my code so modules are users of lower-level modules and are used by higher-level modules. It's not always easy to structure things that way, but I usually find a way.

[Disclaimer: I don't have any experience making anything like an RPG game.] either!

I think the player should know where his is at all times. (what map, objects near by, position).

For Maps sectors in the system to know where the player is, I would register/unregistered the player to that sector as he comes in that sector or moves out of that sector. This way your collusion code could navigate the system by sector and take a peek at the registered players count and spin off more threads on the collision routine in that sector if the count is higher.

Just my drunk thoughts.

-CROW