Thinking of a Classic JRPG Design. Help me understand

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.

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.

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.

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?"

Right now, I'm splitting my time between learning to understand programming, and doing tile art :D Which I do really enjoy!

That's a good attitude to have, but it also depends on what you want to get out of it as well. If you're really interested in learning to code, and using your own artwork in-game, that's certainly an option but it is time consuming. There are a few successful one-man teams out there, so it's possible but doesn't come easily. Don't let us stop you from giving it a try if you're that motivated though, and see how you take to it.

It can also help just to pick one discipline to specialize in, too, while still contributing to designing the mechanics. If you prefer art, you could prototype some of the gameplay in a game creation kit, and use that as a base to explain your concept to others. Even if some features have to be left out, it'll be easier to get the idea across.

If you want to code, you can start learning and use simple placeholders for the graphics. When the project starts coming together and you want to involve other artists, (or do it yourself separately,) you'll have a clear idea of what assets you need. Just remember that you need to build up your skills to program more ambitious projects, the same as I won't be painting like Michealangelo tomorrow morning. It takes a solid foundation of knowledge to support designing a game, and it takes time and effort to get there.

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?

It could be done that way (called "hardcoding" the data) but it'd be less flexible, and make for much slower development.

Instead, if you write the code for displaying the map, then you could load from a file every map you want to display next.

To explain that, let's simplify the tiles temporarily to this structure:

struct TileImage
{
   unsinged tilesetID; //The id of the tileset to get the tile's image from.
   unsigned imageID; //The id of the tile in the tileset. 0 is no visible image.
};

If a layer of a map is simply:

struct Tile
{
   bool isWalkable; //False if this tile is a wall or something similar.

   //The scriptID to activate when either stepped on, or activated with a keypress.
   //For example, a switch on a wall might be unwalkable, but the the player can still face it and
   //press (for example) SpaceBar to trigger the script. 0 if no script is assigned to this tile.
   unsigned scriptID;
   
   //These images are shown underneath the player: (multiple images layered over each other to provide more details)
   TileImage background1, background2, background3;

   //These images are shown over the player: (for things like treetops, so the player can walk "behind" them).
   TileImage foreground1, foreground2;
};

struct Map
{
   //The width and height of this map in tiles.
   unsigned Width, Height;

   //The id of the background song to load.
   unsigned backgroundMusicID;
   
   //This vector is resized to (Width * Height).
   std::vector<Tile> tiles;
};

You can then imagine a tiles being loaded from a piece of text, like this:

X 22 0-0 0-0 2-4 0-0 0-0
W 0 2-3 0-0 5-2 2-1 0-0

'W' might mean walkable. 'X' might mean not-walkable.
Then the next number might be the scriptID, or 0 if there is no script.
Then comes 3 two-number pairs, separated by hyphens. Those are the background tiles (tileset-tile pairs).
Then two more two-number pairs, which are the foreground tiles.

This means, an entire map can be saved in a text file, like this:

20 30 //Map width and height
5 //The background music ID
W 22 1-2 0-0 2-15 0-0 0-0
X 22 0-0 5-2 6-1 0-0 2-2
X 22 0-0 0-0 2-4 0-0 0-0
W 0 2-3 0-0 5-2 2-1 0-0
... //(for Width * Height tiles)

This is a very basic format, and as you program more and more, you will come up with better formats.
Another possibility is to use Microsoft Paint, and make the color of each pixel determine what tile is there. That can get really messy though, and I wouldn't advise it.

For your first game, a simple text-based format would probably be best. You can edit the files in notepad, and you will understand how they work and so would learn from the experience better.
For later games, you might want to use a pre-existing map editor and map file format, so you can create maps faster. Or maybe even make your own editor for later games.

As you develop your game, if you make it so you can not only load maps, but also save maps, you could then make your editor inside your game, by hitting something like F1 to go into 'editing mode', and make mouse-clicks on tiles change the tile to something else, and then save the maps again. But that's a lower priority - it needs to work before it can be edited.

Right now, I'm splitting my time between learning to understand programming, and doing tile art Which I do really enjoy!

Great! I do the same thing. It's good to have something you can switch between when you need a break from one or the other. It's good to know which of the two is going to be your primary skill, like Haps mentioned. There's no urgency to decide that until after you've tasted of each for a year or so.

Both skills are good skills, and are different that they teach your mind in different ways. Both require intuition and knowledge, practice and alot of patience.

PS: Your trees look alot better than mine.

Servant,

Thanks for all the info.. It's really got me into it now and thinking in terms of how to proceed! I am super excited!

And thanks My trees have actually come a long way --- this was one of the first tile map screens I ever put together YEARS ago..

P.S. I dig your site by the way!