Internally, how does AGS store the background images?

[AGP]

Is it a quadruply-linked list? For instance, when the hero moves to the right of his screen, in a quadruply-linked list the list would do the same. Or is it some other way? I want to know this because I'm writing an adventure/RPG by hand (redundant, I know, but I like the control) and I'd like to know what has worked in the past. Thanks in advance.

[scotch]

The backgrounds are bitmaps similar to any other, just rows of pixels one after another. It's hard to tell quite what you are saying a quadruply linked list might be used for in this case.

[AGP]

For the individual screens (not the image storage in the hard drive, but their organization in the RAM). Hero moves to the right screen, list moves to its right, hero moves to the screen at the bottom, list moves to the bottom link.

[Khris]

There are events who call the player.ChangeRoom(x) function; in theory, the event can be anything, like picking up a rock.
The new room is then loaded into memory and its background image is displayed on the screen.

Are you talking about how to achieve a SNES Zelda room change effect?

[AGP]

OK, put differently, what algorithm does the changeRoom(x) function implement? A quadruply-linked list seems intuitive in the sense that for most games you only have four possibilities for screen change in any given room. I suppose it could also be something like this: hero crosses barrierX->is taken to screen Y, (perhaps each barrier being an object (or struct) holding the link to the next screen.

[zabnat]

OK, put differently, what algorithm does the changeRoom(x) function implement?

How about something like this: You have four room game, so your have array of pointers rooms[4] to your room objects. Then you trigger a player.ChangeRoom(n) event and you load up the rooms[n]?

A quadruply-linked list seems intuitive in the sense that for most games you only have four possibilities for screen change in any given room.

No, because...

There are events who call the player.ChangeRoom(x) function; in theory, the event can be anything, like picking up a rock.

..so if you happen to have 50 of those rocks in your room and passing the room edges also change room, you have 54 possibilities for screen change in that room.

I don't understand what you are talking about quadruply-linked lists. Maybe you are trying to too complicated?

edit: If I understood correctly what you are saying is that you are not using AGS but writing your own engine and wish to know how AGS works internally so you could use the same methods in your own engine? Am I right?

[Khris]

It IS possible to implement a system of auto room changes, but most games simply use regions that trigger the change. (A region is usually a small piece of the walkable ground drawn by the game designer within AGS' room editor.)
Or e.g. interacting with a door makes the player change the room.

I suppose it could also be something like this: hero crosses barrierX->is taken to screen Y, (perhaps each barrier being an object (or struct) holding the link to the next screen.

These are implemented already to simplify room changes in Kings Quest style games. Yet the triggered event doesn't have to be a room change, it's all completely up to the game designer.

Why don't you familiarize yourself a bit with how AGS works first?

Edit: ChangeRoom doesn't implement any algorithm...
During the design stage, each room is stored as a single file holding it's background and all other room-specific data.
The rooms are numbered and bundled into the exe when the game is compiled. If AGS encounters e.g. player.ChangeRoom(3); all it does is load room 3 into memory.

[paolo]

I think AGP is asking whether the rooms in a game are stored in a 2D array, so that moving off the right edge of room "x" in one row of the array takes you into room "x + 1" of the same row. Similarly for the other three directions. So, for example, if you had 50 rooms, these might be in an array of 10 rows of 5 rooms each, so that moving right from room 6 would take you to room 7, while moving down from room 6 would take you to room 11.

But AGS doesn't work like that - there are no real links between rooms. When a player leaves a room, you can use the ChangeRoom function to move the player to any room you like in the game. So, for example, when the player exits room 6 by crossing the right edge of the room, they might end up in room 4 because that is how you have programmed the game to work (with something like cEgo.ChangeRoom(4)).

So you can think of the "links" between rooms being like hyperlinks on a web page - the pages and sites that the links take you to are not in any actual physical order - the way you move between them is up to you.

[DoorKnobHandle]

Yes, a quadruply linked list wouldn't really be efficient for ANY game except for one where you NEVER change the room in any other way or direction than north, south, east or west. That means, no "jumps" (like teleporting) and no more than 4 exits per room. Even a black room for the intro or cutscenes that use room-graphics would have to be embedded in that system.

Overall, I'd say, go for a simple array or a std::vector for the rooms. Since the number of rooms won't change dynamically, a simple array would be my choice. Then just implement a Character.ChangeRoom function that removes a character from one room and adds it (at a specific position maybe) in another. Depending on the rest of your engine, this should be a more or less trivial implementation.

[Shane 'ProgZmax' Stevens]

Alternatively, if you wanted to implement something like this for a game it would be as simple as converting a two dimensional array into a large 1-D array (since AGS doesn't natively support multi-dimensional arrays yet) and a variable into the array that would track the player's position.  Then when you step onto a region it would set the array variable and use it to check which room it should lead to and changeroom.  This way if you changed your mind about the room number later all you'd have to do would be to alter the room number in the array itself rather than edit the region data.