Messages

I would say that the following lines need to be "comment out"  using the "//" chars because they are not reconizeabe to the compiler.  You probably also need to define the variable "name" as follows;

string name;

//******************** HOW TO MAKE CURSORS CHANGE OVER HOTSPOTS/OBJECTSA/CHARACTERS *******************************
// Using the GetLocationType function you don't have to write a code for every hotspot in the game and you get
// the cursor change also above objects and characters ( tou can modify it to change only on hotspots or objects,
// change it to TALK when above characters etc)
// Let's say your cursors are:
// 0 WALK
// 1 LOOK
// 2 USE
// 3 TALK
// 4 TAKE // NOT USED
// 5 CHANGED WALK
// 6 CHANGED LOOK
// 7 CHANGED USE
// 8 CHANGED TALK
// 9 WAIT
// Just put the following code in the GLOBAL SCRIPT'S REPEATEDLY EXECUTE function

Hope this works for you.  Cheers.

Well that's just it, it's not specific to enums.  ...

Hehehe ... I'm too embarrassed to tell the silly things I have done to myself... but  #define is too useful to abandon.     

Please understand that my first priority is to get all the built-in AGS functions working in an OO-fashion (specifically, all the GUI stuff).   Once that's done I'll concentrate further on the user scripting side of things.

I understand completely .  I think you do a really good job of listenig to ideas and setting priorities accordingly.  The cool thing about the AGS community is that you take inspiration from our ideas and then implement cool stuff  8).  That in turn inspires us to have more ideas which in turn inspires you to implement more cool stuff.   It's a real pleasure for me to participate in the process.   Thanks CJ.

Strange, what did your script look like? I just tried this:
if (i $$ 2) { }

When I did the following I got the unny error message.

while ((i<INIBUFSIZE)$$(status==ININONE)) {

}

Good question, there is ample room for confusion there. We'll have to think about that.

  Probably before you spring this on everyone ,,,

This could well be because of the use of "filename" as the variable name in the struct and for the parameter -- try changing the name of the funciton's parameter and see if that fixes it. If so, I'll have to add some sort of compiler check for this.

No I still get the type mis-match error.  Here is a code snippet.  I am also going to zip up a copy of the game where this and the above $$ error occur. 

Code: ags

//===================================================================
function IniFile::setfilename(string xname) {
//  	
// Copy the filename from the parameter to the object. The status of 
// the operation is returned as follows:
//
//    INIOK  - successfully completed operation
//    INIERR - N/A 
//===================================================================
   int i, len;
   string filename;

   len = StrLen(filename);
   while ((i < len)&&(i < ININAMSIZE)) {
      this.filename[i] = StrGetCharAt(filename,i);
      i++;
   }
   this.filename[i] = 0;
   i=0;
   StrCopy(this.filename,  xname);
}

Here is a game that contains the above two problems.  Just uncomment  lines 97 and line 249.

http://www.gaia-spa.com/project/ags/modules/IniFileGame.zip

Re: break -  Not currently, no ...

That's what I thought but after seeing my little IniFile module you probably know why I mentioned it.

re: StrCopy(name[7], filename);           // Doesn't work
That won't work because ...

I understand.  I was trying to see if I could use StrCopy() to grab part of the buffer.  Damm I'm lazy

That would be handy; but because the enum is compiled into numeric values, it's not possible for the runtime to know the enum names. Of course, there's the wider issue of having the ability to include debug information in the script to assist things like this, but that's not something I'm looking into at the moment.

If you ever decide to add debug info into the exe then perhaps this would deserve consideration then.  I can see why it's not much of a priority at the moment.

Because #define is a preprocessor thing ...

Understand.  Perhaps my confusion is worth remembering whenever you get round to explaining enums in the manual.

Looks good, that's some handy work with the OO functionality

Thanks for the kind comments.  Since the topic came of recently I thought that it would make for a good test of the OO stuff.   Do you think that you might devise an easy way of including or using such things, maybe something like the plugin-manager or just a simple directive in the header like use IniFile?  Maybe it will be part of the borader scoped import/export mechanism you mentioned.  Anyway just some thoughts here....

It needs to be:
import IniFile Config;

OOooooooooo!  :o      That makes my day!!!

Great work CJ, the OO stuff was easy and fun to work with. 

I think being able to have different schemas for different things would be useful.   

[StrCopy() nd Objects]

StrCopy() nd Objects

You can use StrCopy to copy a string to/from a char[]

StrCopy generates runtime errors when trying to pass a char[] as a parameter
when the char[] is defined within an object.  A similar and possibly related
situation occurs when attempting to pass char[n] as a parameter to StrCopy(). I  mentioned this problem earlier but mis-communicated by referring to character arrays when I meant to say char[], sory for the confusion.

Exporting/Importing Objects
CJ, did you intend that it be possible to create an instance of an object in the global script and then be able to access it from a room script?

I unsuccessfully tried to do this.  I defined the struct in the script header and placed the functions in the global script file as you instructed.   I created an instance of the object in the global script file.   I was able to access and test everything by placng my object.function() calls in the GUI interface_click() interaction.  Next I tried to export the instance of the object and got a compiler error.

Global Script:
IniFile Config;
export Config;

Script Header:
import Config;

File I/O
Works great!! 

IniFile Module
CJ, here is a link to the user module I created.  It implements the ability to
work with INI configuration files.  I used this try out the OO stuff and thought you may want to have a look.  There is also a comment file I made while working on the module containing some of my thoughts you may find amusing. 

Everyone else is welcome to take a look as well.  I plan on making a general release after an official AGS OO release is announced.   I am happy to take C&C but I think we should start another thread for that.   Well anyway it's an example of how to make your own oobjects.

http://www.gaia-spa.com/project/ags/modules/IniFile001.zip

object vs object
How can we avoid confusion between object-oriented obnjects and room objects when discussing things in the forums or writing about them in docs or tutorials?  Should we consider some kind of convention like oobject  for OO objects and just object for room objects?  Just curious! 

*** Edit ***
$$
I incorrectly typed $$ instead of &&.  The compiler error correctly identified the line number but the error message, "How did we get here?", was amusing.  Just out of curiosoity does $$ have a meaning relative to this message or is that message  just a polite way of saying "You're a bloom'in idiot!!" because that's how it made me feel 

[StrSetCharAt()]

StrSetCharAt()

I think the better way is the scripter himself to be more aware of it and use StrLen() to check for it if required.  ...  If it's set to append the character, in my opinion it's even harder to spot bugs as it won't generate an error and it may be doing something you don't want to (well maybe it can generate an error to warning.log though)

I pretty much agree with this until the game is released and distributed.  After  that point I think it would be better to not have a runtime error that crashes the game in response to this situation, IMHO.

... the problem is, when you, say, set a character to the 10th position of a string which is only 5 characters long, what should the behaviour be? ...

As you suggest there is not really a correct behaviour but just appending to the very end and making an entry in the warning.log file, as you suggest would probably better than completely bailing out of the game.

If he really needs to append something just use StrCat().

Except that strings can't be defined as a member of a struct and char[] is the workaround and StrSet/GetCharAt() is the conversion mechanism.

Compiler error message generated without line number
When I incorrectly wrote this (in the proper context  in the global script of course):

len = seclen + 3 + this.length;

instead of this:

len = seclen + 3 + this.length();

the compiler correctly complained about a missing '(' but didn't give a line number.

Thanks wyr3x for the link.  Looks really cool.  Trying it out is  now on my to do list. 

Just out of curiosity, could this be accomplished by using 2 GUIs;  one with the buttons and a transparent image and the other with the translucent background image?

[StrSetCharAt()]

StrSetCharAt()
If the char position is larger than the length of the string a runtime error is generated.  Have you considered just appending the char to the end of the string in this case instead of generating a runtime error?   

Compiler and Objects
The compiler doesn't seem to check that the object and function definitions match.      I don't know if you are aware of this or not so I thought I would mention it.

// Script Header
struct IniFile  {
    :
    import function GetInt(string section, string option, int value);
    :
};

// Global Script
function IniFile::GetInt(string section, string option) {
    :
    :
}

*** Edit ***
Corrected format above

EIP -189 is the free disk space check, which is done before any of the game scripts are loaded .... Bit of a mystery, I have to say.

I only have 2GB free disk space but since AGS doesn't mind when starting games then I suppose this is enough.  Right, so I'm back to dismantling the offending program to see if I can find the problem by the process of elimination.   

StrCopy accepts a char array for either parameter...

:o  No s#@%t!  Well that's all I need!   
***** EDIT ******
I got a type mismatch error when a character array is specified as the destination in the statement "StrCopy(this.name, name)" .   

Actually, if this were to work, then all I need would be a StrnCopy() function added some day.   
****************

You can place the struct definition in the room script rather than the script header, and that should then make it local to the room.

I get a compile error  "Error (line 7): Variable 'TestObj::Init' is already imported " when I do this ....

Code: ags

// room script file
struct TestObj {
   int    var;
   import function Init();
};

function TestObj::Init() {
   this.var = 0;
}

TestObj MyObj;

#sectionstart room_a  // DO NOT EDIT OR REMOVE THIS LINE
function room_a() {
   // script for room: Player enters screen (after fadein)  
   MyObj.Init();
   SetCursorMode(6);
}
#sectionend room_a  // DO NOT EDIT OR REMOVE THIS LINE

I believe it would be nice for local variables to also get initialized to zero (since the alternative is making them 'undefined'...)

Radiant, I don't usually depend on variables being initialized to anything and normally prefer initializing them in the declaration (i.e. int var=0).   My point was that there doesn't appear to be a way of doing this with variables that are contained within a user defined OObject.

Using IE does the same thing so I don't think it's Firefox. 

I tried your test game but I didn't get a crash. All I got was it ran through the first room and then got an Array Index Out of Bounds error on global script line 1075.
At what point does it crash for you?

It crashes right at startup.  I may even happen before the video mode is switched etc.  I happens both when I do a Test or when I execute the exe directly.   I didn't have any problems with V2.62.   

I guess I'll go check line 1075 and see what's going on there and let you know if I can get it to work.  Maybe I'll just start doing surgery until the problem goes away.  If you can't repoduce the problem then there probably isn't much you can do on your end.   If you have any other ideas or things you would like me to try just let me know.

Yes, strings within structs are not supported. This is the main reason why structs are an undocumented feature. I'll update the compiler to give an error message if you do this, to clarify matters.  The workaround is to do:
char filename[200];

I didn't know if you had intentions to support them as part of the OO stuff or not.     I don't mind the workaround much because it is less wasteful of memory.  Conversions between string  and char[] is a bit inconvient at the moment though.  Maybe some day I'll ask you to add a couple of functions; one to copy a string to a char buffer and another to do the reverse. 

I'm not entirely sure what you're getting at here. If you're referring to inheritance so that you could add methods to an object then I can't make any promises about that I'm afraid.

I wasn't thinking of inheritance at all but rather scope.  I would like to define  OObjects that have scope only within a specific room.   Specifically I would like to declare the struct and methods/functions within a Room Script so that they would only have scope within the room.   So that in the room script I could do someting like this. 

Code: ags

function room_b() {
   FrontDoor.Open();
   BackDoor.Close();
}

All of the object, view, loop, and sound id numbers could be embedded in the OObject definition, making the game/interaction logic cleaner and easier to read.  Anyway that's what I was askin about.

That's a possibility for future -- for now I just want to get the basics all working in OO-fashion for 2.7.

I understand.  I have been playing with that read/write INI file thing using the OOisms.  In several instances I found opportunities to excise code and put it into  utility functions.  I haven't done so, so as to keep everything as part of the object.  Private functions would have ben ideal for this. 

The other thing I wish were available is a way to initialize an object in some way.   I don't mean this in the sense of constructor/destructor functions.  A flag would be enough so that when the object is created (i.e. MyObjDef  MyObj;)  the flag would be set to a known value (i.e. 0 would work just fine) and not just a random value.  The methods then could be able to know if this is the first time they are running.   I know,   the workaround is to simply call the init method before doing anything else. 

Anyway these are just a couple of things that occured to me while I have been trying out the "make your own object" stuff.  I really like it and I am looking forward to upgrading the BlueGui and AnimationEngine. 



*** Edit

I think I saw something above about the editor and the auto indent feature.  I am finding that pressing ENTER after a closing brace "}"  causes it to unindent to the next outer level of indentation.....

Never mind operator error.   It's because I was manually backing up the brace to align with the "if" on the previous line and then of course pressing enter after that casues it to backup again.  Now that I know how to use it  : it works just fine for me.   

Since moving to the new host I haven't been able to stay logged on from sesion to session as I was able to do before (i.e. checking the "always stay logged in'  box on the login dialog).  I have deleted and examined the cookies left by the forum.  They always specify "expires at end of session". 

Is anyone else having this problem or is this by design?   

Since moving to the new host I haven't been able to stay logged on from sesion to session as I was able to do before (i.e. checking the "always stay logged in'  box on the login dialog).  I have deleted and examined the cookies left by the forum.  They always specify "expires at end of session". 

Is anyone else having this problem or is this by design?   

[edit]

Ok, I found the "forum Upgrade" thread in the GenGen forum.  I did a search before posting here and obviously didn't find it til now. 

I also found a thread in the SMF support forum talking abut similar problems.   So I guess that I'm not alone and that eventually this will pass. 

http://www.simplemachines.org/community/index.php?topic=11671.0


PS Moderator,
Please move or lock this as you see fit.  Thanks.

Ok here is a link to the converted game that causes a problem. 

http://www.gaia-spa.com/project/ags/Test.ZIP

Please re-read my previous post as I added two more questions while you were responding to it.  Thanks

*** Edit


One more OO question please.   Have you considered about allowing OOobjects to have both private and public functions?   If so perhaps just replace the "import" directive with "private" or something. 
 

Code: ags

[String Types with in Oobjects]

CJ,

Tried converting some of my current stuff and got the following error message when trying to test the game.   

An exception 0xC0000005   ...
ACWIN.EXE at EIP = 0xBFF8C158 ...
program ptr is -189
ACI Version 2.63.786

I have a safe copy so I'm not in a bind or anything.  Thought you might want to know about this.  If you want a copy of the source that produced the error just let me know. 

[edit]
String Types with in Oobjects

I may have found another problem accessing strings within an object.   I believe the statement StrCopy(this.filename, filename); causes the exception.   I don't know if you intended strings to be supported by the new object stuff or not, but I don't think it works at this point.  There is an example below.

Script Header

Code: ags

#define CFG_SIZE 500

struct IniFile {
   int    fp;            // file handle 
   char   modified;      // TRUE if changed, FALSE otherwise
   string filename;
   char   db[CFG_SIZE];
   import function Open(string filename);
   import function ReadInt(string section, string option);
   import function ReadStr(string section, string option,string value);
   import function WriteInt(string section, string option,int value);
   import function WriteStr(string section, string option,string value);
   import function Close();
};

Global Script

Code: ags

function IniFile::Open(string filename) {
   // Read in an INI type config file 
  
   // Open the file
   this.fp = FileOpen(filename, FILE_READ);
   StrCopy(this.filename, filename);       // Execution of this line seems 
                                                              // to cause a fata error

   // :
   // : 
}

Room Script

Code: ags

function room_b () {   // any click on hotspot

   IniFile Cfg;
   Cfg.Open();
}

Oobjects in Room Scripts
I tried this and then read the docs at the beginning of the thread.  I was hoping to be able to do this at some point in the future.  This would allow all of the loop/view/id stuff to be embedded in an Oobject so that, for example,  to implement a specific door in a specific room one could simply have something like door.open() or door.close.    In another room  there could also be door.open, door.close but would work in different manner (i.e. different views, ids, etc, or functionality). 

Is this something that is planned or should I just put it out of my mind ?   

I can't really disagree about doing it with the existing File I/O functions. 

It's a shame there isn't some kind of script module thingy where a moudle could contain a collection of functions, variables, etc and where modules could be included or installed to extend the AGS internal functions.  :  I know you've been thinking about it so I'll stop short of asking.   

[Concept[/b]This would be your "BIG IDEA" expressed in the form of a single paragraph.Character Development[/b]For me this is the single most important step. Usually good adventure games tell interesting stories. Interesting stories are interesting because we come to know and care about what happens to the characters. I write out a one or more page biography, for each character, that includes not only the character's appearance and personality traits but also the character's history, family history, education, work experience, etc. The more detail the better. Not everything will be used explicitly used in the game but every detail will have it's impact on the final result. I have found that with a group of well developed characters the stories tend to write themselves. Storyboard[/b]This is an overview of the game or story that simply paragraph, the overall plot and objective of the player character. It gives an idea of what, when, and where stuff happens. Include sketches if you like. Start with a high level and then add details. Typically yould nd up with a one paragraph description and sketch for each location and the overview. Puzzle Design[/b]Start by categorizing the types of puzzles that this project lends itself to or that are desired. In each category define a suite of puzzles starting with the simple and progressively becomming more difficult. Ideally the more complex puzzles can be solved by taking lessons from the solution of easier ones of the same category. The idea here being to introduce the easiest puzzles at the beginning of the game and the most complex near the end. Technical Specifications[/b]This is a list of requirements to which all work will adhere to ensure compatibility and consistency. Deciding on these things at the beginning saves time and eliminates wasted effort throughout the development process. Here is a partial list of specifications.Artwork - This includes the color depth and resolution of the game, the pixel scaling of the characters (I use 20px/ft for 320x400 and 40px/ft for 640x800 games), methodologies, artistic style, and deliverables (i.e. what files will be produced for import into AGS). Interface - The interface determines how the player interacts with the game and so effects what kinds things are possible and how well they will be percieved by the player. The interface description should include a style/type (i.e. Classic Sierra), cursor modes, mouse functinality, text parser, inventory management, etc..Programming Practices - The easiest way to identify programming errors or to eliminate them entirely is to simply not have them in the first place. This is acomplished through good and consistent programming practices that would include naming conventions, #define usage, documentation, comments, and style or visual appearance.Workspace Organization - Defines how will the project files will be organized; everything in one big directory : or a sub-directory structure where everything has a place and there's a place for everything. Library of Resources - Defines where resources, such as fonts, sounds, etc, that are to be imported into one or more games are located. Archival and Version Control - How and when will backups of the game files be created and how will they be identified. Typically a zip file is created where the file name contains a version number. unknown developer - "Head my warning newbie ... for WOE are those who fail to religiously backup lest they be utterely humbled and their works corrupted and lost to eternity." Character Production[/b]For many this is the most challanging part of a game project and is a common obstacle to completing a project. This process should begin as soon as practical. This is somewhat related the Character Development discussion above. It is not necessary for all characters to be completed before starting other aspects of the production process but ideally the main character should be complete (or an initial version) before doing anything else. A properly sized main character will be needed to setup and test backgrounds/rooms as they are produced. Interface Production[/b]This is definately not for beginners and non-programmers. The easiest thing to do is use the default AGS interface. The next best thing to do is to use one of the many game templates many AGSers have made and shared with the community. Decide on a game template, create a blank game, or creat your own template (containing your own interface of course). Import the main character into the game and CAREFULLY remove unused graphics, views, etc. Cut and paste your standard header into the Global Script, Script Header, and the introduction Room Script (i.e. room-0 or intro.crm ). Select the desired options on the Game Options page in the AGS Editor.Room Production[/b]As background art is completed it should be imported into AGS so that walkable areas, scaling, lighting, etc can be setup and tested with the main character. Add objects and hotspots, such as doors, that lead to other rooms. Add the interactions that initiate transitions to these other rooms. The idea is that the player can walk around the game world from one room to the other. Complete each room to this level of detail before starting on the next one. Object Production[/b]The next step is to add the remaining objects to each of the rooms. This includes inventory iitems as well. For each room, interactions, look, talk, use, pickup, etc with every object and hotspot, contained in the room, are appropiately defined. At this point the game should be a fully functioning 2D world where the player can walk around look at the things he finds. He can pickup inventory items or use/operate other items. There are no challenges but everything works and is easily testable. Game Logic[/b]This is where restrictions are imposed upon the player character per the plot and storyboard. It includes dialog and interaction with other characters, solving puzzles, and progressing through the plot of the story. This is done one room at a time, usually in game chronological order. NPCs are added toi the game as they are encountered. Testing[/b]People are recruited to play the game and report any problems they are having. Publication Distribution[/b]Upload a ZIP file to a place from where people can download it. Setup a website advertising the game and the download link. Make an announcement in the completed games forum. Make an entry in the AGS games page advertising the game. Sit back and wait for accolades.That's the general idea anyway of how I approach things. There is sure to be g'zillion other equally valid ways as well. Good luck with your project...]

Most people make the mistake of underestimating the amount of effort required and end up taking on somthing too ambitious for their first project.  Consequently many never finish anything.  So my first advice is to make a very small project so you can finish it.  At the end of it you will be familiar with AGS, some pitfalls of game making, more aware of your own limitations,  and will have answered your own question which is the subject of this thread.   Here is hoiw I have answered this question for myself:

• Concept[/b]This would be your "BIG IDEA" expressed in the form of a single paragraph.
  
  
  • Character Development[/b]For me this is the single most important step.  Usually good  adventure games tell interesting stories.  Interesting stories are interesting because we come to know and care about what happens to the characters.   I write out a one or more page biography, for each character, that includes not only the character's appearance and personality traits but also the character's history, family history, education, work experience, etc.   The more detail the better.  Not everything will be used explicitly used in the game but every detail will have it's impact on the final result.  I have found that with a group of well developed characters the stories tend to write themselves. 
    
    
    • Storyboard[/b]This is an overview of the game or story that simply paragraph,  the overall plot and objective of the player character.  It gives an idea of what, when, and where stuff happens.  Include sketches if you like.   Start with a high level and then add details.  Typically yould nd up with a one paragraph description and sketch for each location and the overview.
      
      
      • Puzzle Design[/b]Start by categorizing the types of puzzles that this project lends itself to or that are desired.  In each category define a suite of puzzles starting with the simple and progressively becomming more difficult.  Ideally the more complex puzzles can be solved by taking lessons from the solution of easier ones of the same category.  The idea here being to introduce the easiest puzzles at the beginning of the game and the most complex near the end.   
        
        
        • Technical Specifications[/b]This is a list of requirements to which all work will adhere to ensure compatibility and consistency.  Deciding on these things at the beginning saves time and eliminates wasted effort throughout the development process.  Here is a partial list of  specifications.
          
          Artwork -  This includes the color depth and resolution of the game, the pixel scaling of the characters (I use 20px/ft for 320x400 and 40px/ft for 640x800 games), methodologies, artistic style,  and deliverables (i.e. what files will be produced for import into AGS).   
          
          Interface - The interface determines how the player interacts with the game and so effects what kinds things are possible and how well they will be percieved by the player.   The interface description should include a style/type (i.e. Classic Sierra), cursor modes, mouse functinality, text parser, inventory management, etc..
          
          Programming Practices - The easiest way to identify programming errors or to eliminate them entirely is to simply not have them in the first place.  This is acomplished through good and consistent programming practices that would include naming conventions, #define usage, documentation, comments, and style or visual appearance.
          
          Workspace Organization -  Defines how will the project files will be organized; everything in one big directory : or a sub-directory structure where everything has a place and there's a place for everything. 
          
          Library of Resources - Defines where resources, such as fonts, sounds, etc,  that are to be imported into one or more games are located.   
          
          Archival and Version Control - How and when will backups of the game files be created and how will they be identified.  Typically a zip file is created where the file name contains a version number. 
          
          unknown developer - "Head my warning newbie ... for WOE are those who fail to religiously backup lest they be utterely humbled and their works corrupted and lost to eternity."  
          
          
          • Character Production[/b]For many this is the most challanging part of a game project and is a common obstacle to completing a project.  This process should begin as soon as practical.  This is somewhat related the Character Development discussion above. 
            It is not necessary for all characters to be completed before starting other aspects of the production process but ideally the main character should be complete (or an initial version) before doing anything else.  A properly sized main character will be needed to setup and test backgrounds/rooms as they are produced. 
            
            
            • Interface Production[/b]
              This is definately not for beginners and non-programmers.  The easiest thing to do is use the default AGS interface.  The next best thing to do is to use one of the many game templates many AGSers have made and shared with the community.   Decide on a game template, create a blank game, or creat your own template (containing your own interface of course).  Import the main character into the game and CAREFULLY remove unused graphics, views, etc.  Cut and paste your standard header into the Global Script, Script Header, and the introduction Room Script (i.e. room-0 or intro.crm ).  Select the desired options on the Game Options page in the AGS Editor.
              
              
              • Room Production[/b]As background art is completed it should be imported into AGS so that walkable areas, scaling, lighting, etc  can be setup and tested with the main character.  Add objects and hotspots, such as doors, that lead to other rooms.  Add the interactions that initiate transitions to these other rooms.  The idea is that the player can walk around the game world from one room to the other.  Complete  each room to this level of detail before starting on the next one.   
                
                
                • Object Production[/b]The next step is to add the remaining objects to each of the rooms.  This includes inventory iitems as well.  For each room, interactions, look, talk, use, pickup, etc with every object and hotspot, contained in the room, are appropiately defined.   
                  
                  At this point the game should be a fully functioning 2D world where the player can walk around look at the things he finds.  He can pickup inventory items or use/operate other items.  There are no challenges but everything works and is easily testable.   
                  
                  
                  • Game Logic[/b]This is where restrictions are imposed upon the player character per the plot and storyboard.  It includes dialog and interaction with other characters, solving puzzles, and progressing through the plot of the story.  This is done one room at a time, usually in game chronological order. NPCs are added toi the game as they are encountered. 
                     
                    
                    • Testing[/b]People are recruited to play the game and report any problems they are having.
                      
                      
                      • Publication Distribution[/b]Upload a ZIP file to a place from where people can download it.  Setup a website advertising the game and the download link.  Make an announcement in the completed games forum.  Make an entry in the AGS games page advertising the game.  Sit back and wait for accolades.
                        
                        
                        
                        That's the general idea anyway of how I approach things.  There is sure to be g'zillion other equally valid ways as well.    Good luck with your project...

Re: Read/WriteConfigOption()

I guess I would find it useful having an easy way of working with M$ ini files if that is what is under consideration.   I prefer to leave the AGS config file alone and use another file for the kinds of things discusse so far.   So  then may I propose the following suite of functions in place of the previously suggested Read/WriteConfigOption() functions.  Thanks.

OpenConfigFile(string filename)
ReadConfigStr(int id, string section, string option, string value)
WriteConfigStr(int id, string section, string option,string value)
ReadConfigInt(int id, string section, string option)
WriteConfigInt(int id, string section, string option,int value)
CloseConfigFile(int id)

Java and .NET have good ideas on how to do pointers -- they're actually stored as memory handles which get resolved to the actual memory address at runtime, and that sort of approach can probably work with AGS.

Just a bit more thingking about pointers.  You already have characters and objects in a table format.  Why couldn't you implement pointers using somthing like the following construct?

struct POINTER {
     int type;    ///  OBJECT, CHARACTER, GUI, USER, ....
     int id;
}

The "type" component would identify which table to look into and the "id" component would be the offset.   So you have a situation like so:

POINTER ptr;
ptr = object[7];

would result in:
ptr.type == eOBJECT
pty.id == 7

AGS would, of course,  need to use this info to get at the actual mem pointers...   hmmm,  or would it?   I mean internally wouldn't it just be a couple of extra steps to decopose such a pointer into object[7] and then just continue as is done currently.   

This may also may be a sensible way to deal with pointers in the script.  Everyone is fairly familiar with the concept of things having id numbers.  So for them a pointer would just be the id number bundled with the type of thing it is.   

I'll be interested in seeing what you come up with this weekend.  Cheers!

  Wow!  That was fast...  Thanks.   

[edit]

On second thought though,  although being able to change the object's size from the script is quite useful, it doesn't address my problem.  Let me explain further:

I have a room with three identical, animated  doors on the left wall.  Although they are identical they are of different sizes because of the background drawing's perspective.  Having to adjust the size in the script makes it difficult to correctly locate the door over the doorway. 

I guess what I was asking was to have the scale factor active while moving the object around in the editor in addition to being able to specify a value.  I guess if one were using the walkable area scaling you would use that instead while in the editor.

Something like this would also be useful in setting up walkable area scaling if one could drag around a character sprite to different parts of the background to see if the walkable area's scale factor was correct.

Sorry, I didn't realize I was asking that the scale factor be active during edit.  It really wouldn't  be very useful otherwise.   Seems like a lot more work than I originally thought.   The workarounds are easy enough so I am not so sure how important this is.