Potential problems with rooms numbered over 300

[pcj]

My game is divided into sections, each of which is numbered in the 100's.  So, for example, the Intro is rooms 100-108, the next section is rooms 201-214, and so on.  The idea behind this is we can add rooms to a particular section without having to renumber all following sections.

To be able to keep track of which room is which in AGS, I've simply numbered the rooms as indicated above.  The sections obviously number above 3, and while I don't really have 300 rooms, on sections 3 and above, it shows that it will be non-state-saving.

Is this going to be a problem?  Should I find some other way to number my rooms in AGS?

[GarageGothic]

Non-state-saving rooms are a mess if used for normal locations (not cutscenes, menus or other special uses for which they might be excellent). So yeah, you're stuck with rooms 1-299. Of course you can still group them, but make a realistic estimate of how many rooms each section will have and then for example let section 1 be 0-19, section 2 20-40 and so on. With all the other arbitrary numbers in AGS (sound effects, dialogs, global ints) you should already be keeping track of things in an external text document for easier organization.

[Khris]

I'd do it like this:

Code: ags

// script header
#define INTRO1 1
#define INTRO2 2
...
#define CORRIDOR 12
...

Then use only player.ChangeRoom(CORRIDOR, ...).

Now you can easily reorganize the rooms by renaming the .crm-files and adjusting the header accordingly.

[strazer]

Good idea. Or how about an enum instead so the list of rooms pops up when you start typing, for example, eroom...:

Code: ags

// main script header

enum MyRooms { // arbitrary name
  eRoomIntro1 = 1, // arbitrary eRoom prefix
  eRoomIntro2 = 2,
  //...
  eRoomCorridor = 12
};

player.ChangeRoom(eRoomCorridor); // list of rooms pops up when you type eroom