Thanks, Runonthespot. Wow, so some games have no player collisions? That explains the player overlap I've experienced in some games. I didn't realize they simply didn't have player collisions. Thanks so much, you've filled a void I had. So it's all about geometry for collisions and some games allow multiple characters in a single spot. In addition, the characters contain their own location data typically, and the engine is constantly checking to see if one character is located where another character is (and adjusts accordingly).

The problem is you're mixing logic here, for all intents and purposes in code anything that is drawn on the screen is seperate from the logical representation of it. To think of it like this, the graphics device and the library you use to work with it basically keeps its own coordinate system, you feed vertices and information into it and it simply draws whatever you like onscreen. The rendering library has no real rules about what an object is, it's like a giant paintbrush that just draws where you like, you can even place vertices in the same coordinate point.

Now if you think of it like that, you can also think of it like a camera, basically the job of the drawing part of the game is to take a "snapshot" of the current state of your game and translate that into a visual. Of course the library itself doesn't do that, you have to write the code to generate those instructions yourself, but if you think about it that way you can basically see that the part that really matters is the logic part of the code.

The logical part of the code is what you create yourself, it's not unusual for you to create your own coordinate system and handle how objects can move in those coordinates and interact with each other. You basically make your own rules for that. When it comes time to draw it all you have to do is convert it into drawing commands, telling the rendering code where the objects are and how to represent them. So really the rules of the game are up to what you decide.

Thanks Satharis, and you are correct. I realize there are 2 layers I'm dealing with (the camera/visual, and the underlying coordinate/grid/technical logic). There is also the issue that I have never developed or worked with a 3d type game with real collision and physics. I'm developing a 2d tile based game and a lot of the information out there is really geared towards 3d development (or you have to sift through tons of information that doesn't apply in order to get to the kernel that does apply to me). It's like I have to learn how the 3d games are created, then dumb it down and make it related to my own tile based project which is an extra step I am making in the learning process. I appreciate your help. It is soaking in. ;)

I don't want to over-post a number of various topics but I really do have more questions and would like additional help guidance in some areas and am trying to figure out how to best word them and post them as new topics without ticking people off (I know how some forum-people can get).

The problem is you're mixing logic here, for all intents and purposes in code anything that is drawn on the screen is seperate from the logical representation of it.

This is why MVC is a good thing in games. (referring to that other thread about MVC)