Hi Everyone!

I am "new" to programming --- although I know what code looks like, and in theory I understand what code does, I have no real experience with practically applying it in art.

I have always want to make a game. I am a passable artist, and I am a creative writer, but I know my lack of ability in actual programming is a hinderence if I actually want to make said game.

So, I have finally decided, at the ripe age of 31, to really focus on learning how to program. I just started tonight.

Anyway, I've had the creative juices going and I wanted to verify whether this is the right path to be thinking, or if I am completely wrong.

With a classic RPG in might, let's talk about the Function for the world map. Let's say that the world map is a 256x256 grid. Specific cordinates in the grid will take the player to a different location, maybe a town or a dungeon.

So, at the beginning of the world map function, would I have the program allocate the specific location datas into memory, then use pointers to point to the memory area containing the data (town or dungeon data), which would set at the specific coordinates?

Example: if I wanted the player to be taken into a city area at coordinate 100x100, a pointer would be placed at those coordinate, directing the program to take the player into that area?

You're close, except the part about setting a pointer at the coordinates. Instead of a pointer, how about you give that tile a string that's the name of the new area to load (after you unload the current area), and a x and y coordinate to set the player at inside the new area?

There are many ways it could be done, but thinking of a pointer in that way might be misleading. A pointer doesn't handle logic, it's just the location of bytes of memory somewhere. It'd be better to have the information (new map and tile location) you want, and to handle the logic yourself when the player steps on that tile. Sometimes this is done by triggering a script, or sometimes teleporting/warping from tile to tile (faking area transitions) is part of the data of the tile itself.

You're close, except the part about setting a pointer at the coordinates. Instead of a pointer, how about you give that tile a string that's the name of the new area to load (after you unload the current area), and a x and y coordinate to set the player at inside the new area?

There are many ways it could be done, but thinking of a pointer in that way might be misleading. A pointer doesn't handle logic, it's just the location of bytes of memory somewhere. It'd be better to have the information (new map and tile location) you want, and to handle the logic yourself when the player steps on that tile. Sometimes this is done by triggering a script, or sometimes teleporting/warping from tile to tile (faking area transitions) is part of the data of the tile itself.

Ah! I understand. Except for the exact setup for the string/unloading/loading, but, I can imagine how it should work.

I can especially imagine the teleporting idea. That would require a large tile map, yes? I understand todays PCs would have no problem working with such a large tile map, but atypically that would require a large amount of memory to hold the huge tile map if I would to have all areas exist within that huge tile map.

I'm still trying to figure out the proper time and place to use pointers --- when stuff should be allocated to memory for the pointer to be used, ect.

Classic RPGs are the kind of game for which the most gamemaker kits and engines exist. Unless you want something particularly fancy for combat or realtime minigames or hybrid sim or racing elements, you don't actually have to learn how to program a classic RPG as much as script it within whatever third party piece of software you pick. For this same reason it is fairly easy to find a partner to handle the programming side of this game for you. On the other hand, the art is harder than you think it will be, and will take more time than you think it will.

And you are absolutely right.. But, part of this is two issues: I really do want to learn "the ways of the force", but also I think the pain would be finding pre-existing kits that fit with my creative vison of the flow of the game. I have seen a lot of different implamentations of even the basic mechanics of the simple RPG ideas, everything from the movement of the characters, the scrolling within areas, ect..

And you are absolutely right.. But, part of this is two issues: I really do want to learn "the ways of the force", but also I think the pain would be finding pre-existing kits that fit with my creative vison of the flow of the game. I have seen a lot of different implamentations of even the basic mechanics of the simple RPG ideas, everything from the movement of the characters, the scrolling within areas, ect..

What you've asked about has mainly been on how to manage data, so it can't hurt to see how it was done in another engine.

You could test your idea using a game maker just to start off with, even while you're learning the basics of a programming language. Even if you have to leave out a feature or two, you might get a better idea of how things fit together behind the scenes when you see how they've organized it.

Imagine the player is outdoors. He walks up to a building, and walks on top of a door. The door is a teleporting tile that teleports him to the inside of the building. It's teleporting, but there are no flashy energy effects or anything, you just switch the player from (area, x, y) to a new (area, x, y), and the screen instantly changes. That's what I mean by teleporting.

I understand todays PCs would have no problem working with such a large tile map, but atypically that would require a large amount of memory to hold the huge tile map if I would to have all areas exist within that huge tile map.

Nope, because here's a secret: Each area is a different tile map. You only need to load the area the the player is currently in.

1. Player starts game.
2. Load "peaceful_town_outdoors.map"
3. Place character at tile (150, 75).
4. Player walks around.
5. Player walks on top of the tile that looks like a door.
6. Unload the previous map.
7. Load "peaceful_town_indoors.map"
8. Place character at tile (30,30).

The exact same thing happens when going from a town into a forest, or from the forest to the grassy plains, and so on. Invisible teleporting tiles.

Here are some screenshots from a tutorial I wrote ages ago for a game that is no longer online (the tutorial also is no longer online).
In this particular game, we'd have walls that'd look like this:

(stairs up and stairs down)

And in the editor it'd look like this:

Wl = wall

Wp = warp

Stepping "on top of" the stairway would teleport you to a different map.

Same with ladders:

When entering these areas, I'd make sure to make the "landing location" of the warp that led into the area go one tile beyond where the exit is.

Imagine this being a hallway that connects two separate areas together:

The same thing applies for walking into tunnels:

(ignore the light blue 'Nm' markers, they aren't relevant to the current discussion. Also ignore the FG, BG, Grd markings =P)

This is just one way of doing it. In that specific game, every area had an ID instead of a name. So we had area 1, area 2, ..., area 756, etc... (over 1000 areas in total).

Every tile in a area had, in addition to other things, five integers similar to (but not exactly like) this:

enum TileType{None, Wall, Warp, NPC, Chest};

struct Tile
{
    //The ID used to lookup what graphics to draw for this tile.
    unsigned int imageID;
   
    //What type of tile this is.
    TileType type;

    //The extra data given to the TileType.
    //Depending on the TileType, these arguments are treated differently.
    //For walls: these are ignored.
    //For NPCs, 'argA' is the ID of the NPC's dialog script.
    //For Warps, 'argA' is the ID of the area to warp to, 'argB' is the X tile to warp to, and 'argC' is the Y tile.
    //For Chests, 'argA','argB', and 'argC' are IDs of items in the chest (for up to three items. Set an arg to 0 if there is no item there).
    int argA, argB, argC;
};

I wasn't the programmer for that specific game, but when scripting or using the map editor, it gave a fairly good picture of how things worked under the hood.

This example is very simplistic, but it works. If you've already learned about unions, this might be a decent place to use them.

Nope, because here's a secret: Each area is a different tile map. You only need to load the area the the player is currently in.
Player starts game.
Load "peaceful_town_outdoors.map"
Place character at tile (150, 75).
Player walks around.
Player walks on top of the tile that looks like a door.
Unload the previous map.
Load "peaceful_town_indoors.map"
Place character at tile (30,30).

Ah! Yes. Gotcha. You set the program to unload and load each area when the player hits the "warp" coordinate, and not have to worry abount having the data in memory or using pointers. I guess I got stuck on pointers and how to use them.

For the "map" data, would that all be defined in a piece of code, as in each map or location would be defined line by line for placement of tiles and whether that tile is walkable, not walkable, or wrap somewhere else... Can it be done that way?

Classic RPGs are the kind of game for which the most gamemaker kits and engines exist. Unless you want something particularly fancy for combat or realtime minigames or hybrid sim or racing elements, you don't actually have to learn how to program a classic RPG as much as script it within whatever third party piece of software you pick. For this same reason it is fairly easy to find a partner to handle the programming side of this game for you. On the other hand, the art is harder than you think it will be, and will take more time than you think it will.

And you are absolutely right.. But, part of this is two issues: I really do want to learn "the ways of the force", but also I think the pain would be finding pre-existing kits that fit with my creative vison of the flow of the game. I have seen a lot of different implamentations of even the basic mechanics of the simple RPG ideas, everything from the movement of the characters, the scrolling within areas, ect..

Wanting to learn to program is a good enough reason to learn to program. If you're imagining doing all the art, story, and coding for an RPG yourself, though... that's an awful lot of knowledge and time needed from one person.

Well, I wouldn't do everything by myself.. Eventually, I would attempt to gather a team. But I have seen others who wanted to make a game, and pretty much act as the director or game designer, and only offer their ideas and need to rely on others to do art, coding and such. Usually those projects only progress so far. If I start a project, I want to be able to add more than just "I want it to do this... Can you draw the graphics and write the code for me?"