the point of this is to relegate pretty much all game content manipulation to text files, and all actually programming stuff to some scripting language of my own invention, because I can't get LUA to link (although I know how to compile it now...).

Anyway, I basically have two kinds of data -- global and non-global. Whenever a new game is started, the non-global data gets copied over to the player's save directory. This basically means that save/load processes are limited to folder creation and batch copying (you can do this with C++, right? I shoud look that up :P. If not, I could just have a batch-file preloader. Which wouldn't be a bad idea at all, although does BAT still take user I/O?). Anyway, I'll just copy this text file I made over.

<
///###DATA INITIALIZATION###\\\

###ROOMS###

A) A master list of files will be loaded from a text file in /room, which lists ever room file, in the format of:
<
[total number of rooms]
room_file.txt
room_file2.txt
room_file3.txt
...
>
This data will be stored in a one-dimensional array of variable length. The length will be determined by [total number of rooms].

B) Room data text files contain room name, room description, and information on which room is in which direction.

C) Room data will be stored in a global room folder, accessed by all players.

D) *ROOM FILES ARE NOT EDITED BY THE PROGRAM*

###ITEMS###

A) Item definitions are stored in text files. They have a similar setup to the room data files. The exact information they contain is not yet decided.

B) Individual items are stored in text files. Each text file has a name corresponding to a room. When "look" is performed in a room, the corresponding text file is read in and printed. There will probably be an option to supress being listed, and it will be stored

C) Item definitions are not altered. Item location lists are.

D) There are seperate non-global state files for items which can be manipulated. These are editted and non-global. The exact data they contain is not yet known.

E) There might be global items. These will act as interface.

###SCRIPTS###

A) The scripting language will be hardcoded. I might use LUA.

B) The interpreter will also be hardcoded.

C) Scripts are stored in a global folder.

D) There is an events folder. This stores text files, whose names correspond to room names. These contain event queues for each room. They simply list script.txt files in a specific order.

F) There'll also be a set of item_events. These will probably be referenced in the item state lists.

###ERRATA###

A) There's an abstract "player_state" text which stores stats about the player. Whatever stats these are should be hard coded.

B) I'm not sure how I'm storing player position. I could have a current_room room.txt which DOES get altered, in correlation to a current_room pointer.

C) Consider an "automaton" thing for monsters or certain inventory items.

###SAVING/LOADING/GAME CREATION NEW###

A) When a new game is created, the player specifies the name of the save. A new folder is created with this name, and takes all non-global data files from "default."

B) When the game is loaded, its contents are copied to /current subdirectory. --ALL GAMEPLAY IS DONE ON THIS SET OF DATA.

C) When a ame is saved, the data from current is copied to the folder name specified. If no folder is specified, use a default name (save?). If the folder already exists, confirm overwriting. If it doesn't, then make a new folder. Copy the contents of current to this folder. Clear current (Or not, if leaving it full doesn't cause problems).

D) Come up with wacky file extensions to deter people from snooping.

>