Text adventure engine idea. thoughts?

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.

>

I might be the only person to put input, but I think "Go For It". I really am still learning but what you put sounds pretty neat. :)

I just can't imagine anyone would actually still play a text adventure game.

Quote:

---

Originally Posted by rockytriton

I just can't imagine anyone would actually still play a text adventure game.

---

suzak, he is very well right. If i were you I would make something worth while because you could probably make something better than that, but, to some people, what you are doing is great practice.

At this point in programming it is not a matter of what you think would be popular out there. It is a matter of learning as much as possible. Have a little look at this thread. As I said in there: you have to crawl before you walk, and then you have to walk before you can run. I think it is great to see people wanting to do textbased games now instead of rushing into graphical gameprogramming, only to find out that it was too hard and drop the whole thing with gameprogramming.

right on Shakti. by the way, could you look at my post on my dos menu for a text rpg here?

Interactive fiction is still immensely popular. It's also an extremely versatile genre. also, it gets around having to draw graphics, and, er, given that my primary interest is writing, I get to focus on that more.

That, and it's not like text-based stuff is THAT different from graphics. In one, you're loading in text from a .txt file. In another, you're running IMGLoad(some.png). While there are variations specific to the API, and different methods for handling the loaded data, conceptually, stuff isn't terribly different. You're always going to be writing an engine to handle resources, and you're always going to be aiming at the most efficient and robust method.

that aside, my method makes very little sense (Or perfect sense. I'm not really able to gauge. I like it though, but eh, relative depravation). I basically hacked out room classes and the master load list array thing. I think I'll post my source because I can't really describe it properly. Given that all the resources are just textfiles, though, it's NOT going to be a hard disk space hog, even if there are a lot of text files. 100~ room definitions is a total of about 19 kb. Also, loading them in constantly seems to be extremely quick. And since hardly anything's going to be hardcoded, modability and .exe size should both be great.

Anyway, here's what I've got:

http://www.rafb.net/paste/results/a5XcDx76.html

Text adventures lend themselves nicely to using IDs for everything. The ID can either be it's index into the object_type array or you can use the STL and use some of the find and search functions to get the data.

You can also use pointers to rooms, objects, etc. It's up to you.

http://www.rafb.net/paste/results/MSEvik19.html

Okay, this is problematic. I wrote this block of code to move item entries from one text file to another text file. However, it doesn't seem to be doing that. when it gets to the point where that function is called, the program hangs. Now, reading through, it my procedure seems to bein the correct order. I'm wondering if seekg doesn't return to the beginning of the file, like I thought it did?

After running in sum debug number, "while(read != item)" seems to be the hanging point.

Okay, question. I already mentioned that each room defintion is its own textfile. Performance-wise, though, is it more efficient to just keep loading each file via fstream on runtime, or is it more efficient to store every room definition in ONE text file, read this intoa list of string arrays, and then search through the list? I don't expect either to really have any major slowdown issues, so...

Traditionally a single file is where its at.

I think I'm going to write the parser next, simply because I'd really like to be able to interface with my own software (beyond the crappy movement.cpp I'm using right now. Which consists of a bunch of ill-devised switches and random variables).

anyway, the more I think about it, the more I realize that the difference between a user input parser is, ultimately, no different than a script interpretor.

Anyway, back to the... script interpretor. I figure I should make my own metalanguage for this thing. It'd probably be easier to just learn LUA. However, first and foremost, I really don't need something THAT robust. I primarily need something to act as an external way to interface with the program. Effectively, they'd just be function macros. Anyway, my basic idea is to have a command follwed by the arguments it takes. I'll then read it in with getline delimit \n, and then do the same getline delimit \n on the variables, and stick them into an arguments vector or something. It... then procedes to stick something in a stack or some other STL class. I'm working on this.

Every script command has a corresponding function. Each script function takes the argument vector. I also believe they take something else, although I can't remember what. Anyway, stuff's read out of the argument vector and plugged into varioust hings in the function. Effectively, the functions do everything, and the scripts just call them externally.

Example, in pseudocode:

ADD 3 5 <- In script textfile

Code:

---


function parser:
{
  command = getline(textfile, delimit space)
  while(input string != some undecided line terminator
  arg vector = getline(gets the arugments. Delimit space)
  //some sort of checking to see which function gets called. See below!//
}

function add:
{
  x = atoi vector[0]; 
  y = atoi vector[1];
  store x+y in some sort of result buffer; <- All results will be stored in another vector. This also gets passed around.
}

---

If this sounds really freaking stupid so far, please, help :)

anyway, assuming I didn't just cause everyone to go stupid with my in(s)ane ideas, and assuming I've got everything dealt with in a stack or some other STL for sequential processing... well, assuming the code is focusing on a single script command, how should I have it tell WHICH related function to load?

The first idea I had was switch statements. This usually looks ugly, though. Also,I question their speed when they get larger. Perhaps I could figure out a way to class commands and then tier the switch (although, would that actually reduce search time?).

The next idea involved using function overloading. However, each function's going to pretty much take the same number of args.

erm, also considered finding a way of putting functions, or pointers to functions, or references to functions, into a cointer class and indexing it by strings, where the string is the name of the command. That's problematic in that it's probably slow, and that I don't really know if array elements can point to functions.

Also, I think there's something I can do which also involves function pointers. The example, though, would require a switch statement to determine which... function got passed into the pointer though, so... (http://www.newty.de/fpt/intro.html)

Don't bind your script directly to functions and you will thank yourself later. Try a message based approach.

Quote:

---

Originally Posted by Bubba

Don't bind your script directly to functions and you will thank yourself later. Try a message based approach.

---

Do you have any recommendations for tutorials, articles, or books containing information on messaging?

Indeed. Unless it's the process that http://www.gamedev.net/reference/art...rticle1633.asp , which involves virtual machines and op_codes, then I'm not having a whole lot of luck finding information on a messanging system.

As for messaging I leave that to you to figure out.

As for the text string problems:

Instead of storing the text descriptions of rooms as lines of text, there is another way.
To use this method you will need to create an editor to create the text file and the text file information.

Store the text descriptions in one huge array. Load it at startup. To find the description for the current room, you need a starting index and ending index in the array. Print from start to end and wallah...description - and fast too.

Code:

---

struct RoomDescripInfo
{
  DWORD dwRoomID;
  DWORD dwStartIndex;
  DWORD dwEndIndex;
};

---

So your text descrip file is a huge file full of these structs. The first DWORD of the file would be how many structs (or rooms) there are. Then read in that many structs. Then read in the entire text file containing the room descriptions and stick it into a buffer. Using the information in the map, you retrieve the ID for the current room, then you look in the array of structs and find out the starting and ending index into the description buffer or array. Print the description starting at dwStartIndex and stop printing at dwEndIndex.

This way all descriptions are in memory and you are simply indexing into a huge array to get them. With tons of memory at your disposal I see no reason not to load everything at load time and then access it as you need it.

You decide on how to interpret new line and carriage return characters.

Code:

---



#define MAP_ERROR  0xFFFFFFFF

#pragma pack(1)
class CMapHeader
{
  DWORD dwWidth;
  DWORD dwHeight;
  DWORD dwChunkSize;
};
#pragma

class CMap
{
  friend class CMapContainer;
  DWORD *m_pMap;

  DWORD  m_dwWidth;
  DWORD m_dwHeight;
  DWORD m_dwMaxOffset;

  bool m_bInitFlag;

  CMap(void):m_pMap(NULL),m_dwWidth(0),m_dwHeight(0),
  m_bInitFlag(false) {}
  virtual ~CMap(void)
  {
      if (m_pMap)          //MSCV bug for delete on NULL pointers
      {
        delete [] m_pMap;
        m_pMap=NULL;
      }
  }
 
  bool Create(DWORD dwWidth,DWORD dwHeight)
  {
      //Can't init more than once
      if (m_bInitFlag) return true;

    //Setup class data
    m_dwMaxOffset=dwWidth*dwHeight;
    m_dwWidth=dwWidth;
    m_dwHeight=dwHeight;
    m_pMap=new DWORD[m_dwMaxOffset];
   
    //Bail on allocation failure
    if (!m_pMap) return true;

    //Class is ok
    m_bInitFlag=true;

    //Function success
    return false;

  }

  DWORD SetMapValue(DWORD dwOffset,DWORD dwValue)
  {
      if (!m_bInitFlag) return MAP_ERROR;

      if (dwOffset<m_dwMaxOffset)
      {
        DWORD dwPrevValue=m_pMap[dwOffset];
        m_pMap[dwOffset]=dwValue;
        return dwPrevValue;
      } else return MAP_ERROR;
  } 
 
  DWORD GetMapValue(DWORD dwOffset)
  {
    if (!m_bInitFlag) return MAP_ERROR;

    if (dwOffset<m_dwMaxOffset)
    {
      return m_pMap[dwOffset];
    } else return MAP_ERROR;
  }

  bool SaveToHandle(int iHandle)
  {
      if (!m_bInitFlag) return true;

      CMapHeader hdr;
      hdr.dwWidth=m_dwWidth;
      hdr.dwHeight=m_dwHeight;
      hdr.dwChunkSize=m_dwMaxOffset;

      //Write out header     
      _write(iHandle,&hdr,sizeof(CMapHeader));

      //Write out map data
      _write(iHandle,m_pMap,m_dwMaxOffset);
  }
 
  bool LoadFromHandle(int iHandle)
  {
      CMapHeader hdr;
      //Read header
      _read(iHandle,&hdr,sizeof(CMapHeader));
     
      //Check for existing map and delete
      if (m_pMap) delete [] m_pMap;

      //Setup class data
      m_dwMaxOffset=hdr.dwChunkSize;
      m_dwWidth=hdr.dwWidth;
      m_dwHeight=hdr.dwHeight;
     
      //Create map
      m_pMap=new DWORD[m_dwMaxOffset];

      //Bail on error
      if (!m_pMap) return true;

      //Class is ok
      m_bInitFlag=true;
     
    }

    //Read in map data
      _read(iHandle,m_pMap,m_dwMaxOffset*sizeof(DWORD))

    //Function success
    return false;
       
  }

  CMap &operator = (const CMap &map)
  {
      //Assign class data
      m_dwMaxOffset=map.m_dwMaxOffset;
      m_dwWidth=map.m_dwWidth;
      m_dwHeight=map.m_dwHeight;
   
      //Ensure passed object is valid
      if (map.m_pMap && map.m_bInitFlag)
      {
        //Setup pointer to passed object
        DWORD *ptrMap=map.m_pMap;

        //Check for existing map and delete
        if (m_pMap) delete [] m_pMap;

        //Create our map
        m_pMap=new DWORD[m_dwMaxOffset];
     
        //Only way out is an exception
        if (!m_pMap) throw CEngineException("Out of Memory") ;
         
        //Setup pointers and temp data for asm routine
        DWORD *ptrClassMap=m_pMap;
        DWORD tempMaxOffset=m_dwMaxOffset;

        //32-bit copy from [DS]:ESI to ES:EDI
        _asm {
          mov  esi,[ptrMap]
          mov  edi,[ptrClassMap]
          mov  ecx,[tempMaxOffset]
          rep  movsd
          }
      } else throw CEngineException("NULL pointer assignment");
     
        //Class is ok
        m_bInitFlag=true;
   
      } 
    //Return this object       
    return *this;
  }
};

enum Directions {
 UP=0x01,
 DOWN=0x02,
 WEST=0x04,
 EAST=0x08,
 NORTH=0x10,
 SOUTH=0x20
};

 
struct CRoomDescripInfo
{
  DWORD dwRoomID;
  DWORD dwStartIndex;
  DWORD dwEndIndex;
};

class CRoom
{
  WORD  m_dwID;
  CRoomDescripInfo  m_RoomInfo;
  WORD  m_dwExits;
  WORD  m_dwDoors;
  ....
};

class CRoomContainer
{
  std::vector<CRoom *> m_vRooms;
  ...
  public:
    ...
    void ShowDescription(void);

};

---

This is the very beginning of a text adventure game. The map class would have a map container that controlled all access to and from the map. Each map could be of varying sizes If the player moves up, he moves down in the vector and down is up in the vector. Doors can be coded by using the Directions enum as well as directional data for each room.

I leave the rest to you.

For the message system, think about how Windows does it.

I wrote this code while sitting here so I'm sure there are bugs in it. This system needs to completely implement the following classes.

CMapContainer

CRoom
CRoomContainer

CObject
CObjectContainer

CCharacter
CCharaterContainer

CParser

CMessageSystem

CMessageSystem 'could' send a message to the CObjectContainer and/or CCharacterContainer which would then route the message to the correct MessageProc of the CObject class or CCharacter class. The message is then processed by the class. This means that the central message system is only responsible for sending messages, not for responding to them. The bulk of the work would be done in each class's MessageProc.
You don't have to worry about function pointers because if the MessageProc is inside of the class and is public, then all CMessageSystem needs is a vector or array of pointers to all objects/characters in the game.

CMessageSystem->CObjectContainer->CObject->CObject::MessageProc()

Like that.

This is what I'm doing for the room handling now, BTW. Keep in mind that it's sort of sloppy, so the variables probably look a bit funky and there's no bounds checking. This is mostly a proof of concept thing. I've already written half of these functions in the main project, and they're somewhat better.

Code:

---

#include <fstream>
#include <iostream>
#include <sstream>
#include <string>
#include <vector>

using namespace std;

int main()
{
  int x = 0;
 
  ifstream file("rooms2.txt", ios::in);
  vector<string>rooms;
 
  string search = "bedroom";
  string read_in;
  vector<string>current_room;
 
  search = "<" + search;
 
  for(;;) //read-in file to vector
  {   
    getline(file, read_in);   
    if(read_in == "#") {break;}
    rooms.push_back(read_in);
  }
 
  x = 0;
 
  while(rooms[x] != search) //search function -- would return X.
  {                                       
    x++;
  }     

  int y = 0;
 
  while(rooms[x] != ">") // loads search sector.
  {
    //f(current_room[y] != ">") {break;}
    current_room.push_back(rooms[x] + "\n"); 
    x++;
  } 
 
  y = 0;
 
  for(y; y < current_room.size(); y++) // y should be a size_t -- Also, this prints the room data
  {
    cout << current_room[y];
  }
 
  cin >> search;
  return 0;
}

---

Basically, it loads an ifstream into a vector. It then searches through the vector for some search string (searching for the last word in the vector, in a 1300~ odd entry vector, produced no slowdown at all. I'm assuming because x++ is the only operation being done?) Anyway, it then runs this x value (a position inthe vector, of course) through another while statement, which loads lines into another vector till some delimiting char (>, in this case. It's not put in the resultant vector. That might change later if I need it to.)

Search, in this function, would be a string read in from the room definition file*. There are several methods to do this. I've outlined one below.

I'm sort of shying away from using a class for this. The concept of a room is rather fuzzy, in the scope of this project. It's a general place that holds items. As such, a room could be an inventory, or some sort of interface, with the directional parameters being menu options or something. Assuming it is a literal room, then by leaving it how it is now, I could also change the number of directional parameters each room takes by altering the data textfiles. Making it a class limits it, unless I leave the class extremely vague, at... which point I no longer need the class. Furthermore, by leaving it as a vector of strings, I can process it with a generic function that loads stuff from and fstream into a vector.

Also, your method seems to produce a gridded map. That's not entirely desirable.

*
<name
desc
#
to north
to south
to east
to west
to up
to down
>

which line does which will be either stored in a header or an external data file. to get a directional line, I run the search function on #, return the X position, and basically just plug the x value into search=vectorname[x].