AGS v2.7 Final: Yet Another Edition

Started by Pumaman, Sat 13/11/2004 21:02:00

Previous topic - Next topic

jetxl

Quote from: Pumaman on Sat 13/11/2004 21:02:00
Where's all this going?
My long-term goal for the scripting language is to bring it up to an object-based standard, on a par with Visual Basic 6 ...

ARRG. NO!
To quote grumpy smurf; I hate object orientated programming.

(I'm gonna do some SQL now)

Pumaman

QuoteOkay. To avoid confusing people, maybe you could add a Property 'Room' as well? Because having everything capitalized is kind of neat.

Yeah, it'd be nice to clear all that up. I'll see what I can do.

Quote
And am I correct to assume that ANYWHERE and the other stuff are actually #defined to boolean values? Because personally, I prefer using 1 and 0 (or TRUE and FALSE) to lengthy text strings.

No, they are #defined to various different numerical values. This is because people tend to get the parameters mixed up where there is more than one TRUE/FALSE parameter. Therefore, by having a completely different definition, it should eliminate any confusion since the engine can give a useful error message.
It also makes the script more readable:
character[EGO].Animate(3, 5, 1, 1, 0);
vs
character[EGO].Animate(3, 5, 1, BACKWARDS, IN_BACKGROUND);

However, I know what you mean about being able to use 0 and 1 ... anyone else got any thoughts on it? I might make allowing 0/1 an optional feature.

Quote
This may be radical, but how about EGO->Clickable as a shorthand for character[EGO].Clickable?

That is something I'd like to do, but implementing pointers into the script language introduces various complexities, not least of which would be how to handle them in saved games. I'm still considering how to do this and whether it's worth the hassle.

Quote
The only useful thing I could think of for the Say trilogy is SayEx, which might combine SayAt and SayBackground. Not sure if that's useful though. The alternative is naming SayBackground 'Whisper' and SayAt 'Ventriloquate'

SayEx seems a very messy thing to do, since the functions arne't really related. Ideally the normal Say would have a Blocking parameter, but that would lose its %d/%s support so I'm not sure what the best plan is.

QuoteI'd prefer Walk not being blocking by default, but I guess I can get used to set the value if others find it better the other way...

Good point -- how often is Walk used in a blocking way, and how often non-blocking? Whichever is the most regularly used way should become the default.

QuoteARRG. NO!
To quote grumpy smurf; I hate object orientated programming.

Oh, but this is hardly object-oriented. I'm not making you write all your functions inside a class, and inherit things and so on.

That can come later  :=

Fribbi AGDI joker

The only think I can think of what should be in the next update is they should creat a button called "Import a Jpg sprite pictures" and it should also be a "Import jpg Background" button in the room section. And "view screenplay room" button should also be there so I don't have to click "Test the game" everytime I want to check if the screenroom I was working on is ok.

And it would be better if all of the MS paintbrush option are there too. It is so painful to draw with that thin pencil when I am drawing for a walkable grounds lines as you know so if would be better if I can make choose how thick the line should be.


I know there is a button where I can see the preview how the backgrounds looks but I want to see how the action in the same room I am working looks like in that room with all the objects and gameplayers. That would be great.

Scummbuddy

a) this is an odd beta thread, but suggestions dont typically go in beta threads.

b) since you are making a game, you should still be in debug mode. just use the code to go directly to the room you want, or you could change your characters start room number to be the room number you want to try. just make sure their start coor's are correct.

c) we've discussed adding some more tools to the walkable areas and such. he claims that we can just as easily import walkable areas after drawing them in our paint program. so he cant justify making the tools that are already available to you.

d) I believe we dont allow jpeg because its a lossy format, plus you shouldnt worry about filesize since ags uses its own compression format, so importing jpeg wont matter.
- Oh great, I'm stuck in colonial times, tentacles are taking over the world, and now the toilets backing up.
- No, I mean it's really STUCK. Like adventure-game stuck.
-Hoagie from DOTT

Fribbi AGDI joker


Pau

Using default parameters would be a great improvement because:

-The syntax is easy (for defining and using them)

-The number of instructions is reuced (bye to all the __Ex functions) so the manual would be more searchable.

-The code is more readable (you only specify the things you want to make "in a different" way)

paused -- get the startup menu creator (version 1.1) for AGS games. (Use save target as..)

RickJ

I must have ESP or something.  I remember CJ mentioning something about this a long time ago and was thinking about asking about it the other day.  Good thing I read this thread first.   Anyway here are some of  my comments about  the above discussion.

Set vs Change
Regarding the question about  using "Change"  instead of "Set" in function names, probably "Set" should be used when there is a corresponding "Get" function.   If there isn't a corrsponding "Get" then using "Change" instead of "Set" is probably satisfactory.   I prefer "Set" because it's easier to spell.  (hehe)

Function Overloading
This is one of my favorite things.  It makes things easier to code and easier to read.  It would also resolve most of the AgsFunction vs AgsFunctionEx issues and reduce the function clutter .  Should character[].ChangeRoom() include coordinates or not?  Function overloading gives both;  Include coordinates and a NewRoomEx() is performed, leave them out and NewRoom() is performed.   

So I hope function overloading makes the final cut. 

#define Constants
I understand the need for readability but I also understand the desire for brevity.  So perhaps comprimise could be reached by using abreviated  terms as follows:

ANYAREA / WLKAREA  instead of  ANYWHERE / WALKABLE_AREAS
FWD/BCK instead of FORWARDS / BACKWARDS
BLK/NOBLK instead of BLOCKING / IN_BACKGROUND

A proliferation of english words as #define system terms is problematic.  For example suppose BLOCKING and RUNNING are defined to have a value of 1.  Since both terms have the same value it would not be possible to use them in the user's script to enumerate the state of a character, object or other entity.  If these terms were given unique values then they could be used for other things but then it wouldn't be possible to substitute 0 or 1 in AGS function calls. 

Again using abbreviations/mnemonics instead of actual words, as much as possible, seems, to me,  to be an acceptable way to resolve this situation.   Another possibility is to use enumerated data types instead of #define constants. 

I appolgize about being a bit off topic but one last thing about #define,  I use it quite often and the current editor highlighting, with the grey backgound, drives me crazy.  Is there something that can be done in the way of an option or something.  Please ...   
Character Names
Wouldn't it be a lot easier to read if we could write:

Roger.Animate(3, 5, 1, BACKWARDS, IN_BACKGROUND); 

instead of

character[Roger].Animate(3, 5, 1, BACKWARDS, IN_BACKGROUND);

So I guess  AGS could define "Roger"  as "character[1] instead of defining "Roger" as "1".   This can be a "can of worms"  because there are plenty of things that want to see the character ID of "Roger" (i.e. "1").  If we were to go down this road likely the charcter array would give way to  character objects with  "Roger"  being the object name in this case.    I guess this ends up being almost the same as the EGO=> question above.  What do you thingk CJ? 

Broader OO Issues
The scope of the discussion so far is limited to the script language (appropiate since that's the subject of the beta) and using characters as objects.   As mentioned earlier in the discussion, it is intended that the other game entities have a similar fate.   

It seems to me that a character object (or any other game entity), in addition to it's properties and inherited methods as discussed above, would also be comprised of it's interaction methods, sprites, animation views, loops, etc.  Is there a plan to reorganize AGS's internal structure, at some point, to more closely correspond to this kind of paridigm?     

The reason I ask is that something like this would make it possible/easy to import/export complete game entities; or maybe even game entities would just be stored in seperate files.  IMHO, the weakest part of AGS is the dificulty multiple developers have in simultaneously working on the same project.  This is primarily due to so many things being inseparably stored in the main game file.   OO's inherient  modularity offer hope in this regard. 

I wanted to bring this up now to avoid locking-in on somthing that would preclude these kinds of future capabilities.  I am curious as to your thinking on this CJ.   


P.S.  CJ, I appologize for spamming your beta thread; feel free to take me to the woodshed.    Nice work with the OO script.

Radiant

Quote from: Pumaman on Thu 18/11/2004 19:15:19
Quote
And am I correct to assume that ANYWHERE and the other stuff are actually #defined to boolean values? Because personally, I prefer using 1 and 0 (or TRUE and FALSE) to lengthy text strings.
No, they are #defined to various different numerical values. This is because people tend to get the parameters mixed up where there is more than one TRUE/FALSE parameter. It also makes the script more readable:
character[EGO].Animate(3, 5, 1, 1, 0);
vs
character[EGO].Animate(3, 5, 1, BACKWARDS, IN_BACKGROUND);
I can understand that people would find the lower of the two more legible - however it does require that the coder looks up the exact syntax of the possible parameter values every time (especially since most functions use different parameters). So I would really appreciate a 0/1 feature. Maybe using something equivalent to an 'enum' would be the answer? C++ would give a warning like 'conversion from int to enum'.

Unrelated bug report... if you do a DisableCursorMode on the current cursor mode from within the dialog_request function, the cursor mode does indeed change - but the cursor's shape does not.


Rui 'Trovatore' Pires

Ok, I got a gripe.

I want to write "int number". Right? So I write "i", then "n", then "t".

When I press "space", however, it autocompletes to InterfaceOff. I have to delete it, type "int", hit the LEFT arrow key, and THEN the right arrow key and space.

Very inconvenient.
Reach for the moon. Even if you miss, you'll land among the stars.

Kneel. Now.

Never throw chicken at a Leprechaun.

Pumaman

QuoteSet vs Change

Now that properties have replaced most of the Sets, this is less of an issue. There is however a bit of an inconsistency remaining:
ChangeRoom
ChangeView
SetIdleView
SetSpeed

I prefer Set, but then I don't want to rename ChangeView to SetView because people will confuse it with SetCharacterView which is actually now LockView. If you see what I mean :)
So this is a bit messy, but the best plan is probably just to leave it as is.

QuoteFunction Overloading
This is one of my favorite things.  It makes things easier to code and easier to read.  It would also resolve most of the AgsFunction vs AgsFunctionEx issues and reduce the function clutter .

At this stage, I'm not implementing function overloading. However, the support for default parameters means that your examples are now neatly handled that way instead. ChangeRoom simply has an optional X and Y parameter, which you can supply but you don't have to. Almost as good as function overloading ;)

QuoteI understand the need for readability but I also understand the desire for brevity.  So perhaps comprimise could be reached by using abreviated  terms as follows:

Yeah, I like the idea of abbreviating them. Ideally I'd like to add proper Enum support, but realistically I don't think I'll have the time to do so.

So in the meantime, I propose some slightly longer abbreviations:
ALLAREAS / WALKAREAS
FORWARDS / BACKWARDS
BLOCK / NOBLOCK
LOOP / NOLOOP  (a new one for Animate's third parameter)

The problem is as you say that it takes a while of getting used to, and having to keep looking up what the names are. Autocomplete of #defines would help here, and I'll try and get that added.
An advantage of adding proper enum support would be that autocomplete could become smart enough to offer the valid options for an enum parmaeter, but as I say I don't think it'll make it.

QuoteI appolgize about being a bit off topic but one last thing about #define,  I use it quite often and the current editor highlighting, with the grey backgound, drives me crazy.  Is there something that can be done in the way of an option or something.  Please ...   

The grey background was deliberate, mainly because of the #sectionstart / #sectionend lines, to make them obviously different to the rest of the code.

What would your preference for preprocessor directive colouring be?

Quotewe were to go down this road likely the charcter array would give way to  character objects with  "Roger"  being the object name in this case.    I guess this ends up being almost the same as the EGO=> question above.

Yeah, this is the same as the question above. I'd like to add it, but it raises various issues with save games once pointers enter the equation.

It could be done with a load of #defines, but I'd really rather not do that -- for starters, autocomplete would no longer work and it's prone to mistakes when the macro gets used elsewhere by accident.

QuoteIt seems to me that a character object (or any other game entity), in addition to it's properties and inherited methods as discussed above, would also be comprised of it's interaction methods, sprites, animation views, loops, etc.  Is there a plan to reorganize AGS's internal structure, at some point, to more closely correspond to this kind of paridigm?

Well, the reason it's split up as it is at the moment is so that sprites, views, etc can be shared between different characters and different objects, which adds a degree of flexibility and stops you having to load duplicate copies of graphics.

I do understand the difficulty of team working on a project, and I'm hoping to add some sort of rudimentary diff/merge support at some stage. It is currently possible to work as a team, so long as people work on individual room files and only one person modifies the main game file.

QuoteUnrelated bug report... if you do a DisableCursorMode on the current cursor mode from within the dialog_request function, the cursor mode does indeed change - but the cursor's shape does not.

I'll take a look at some point.

QuoteOk, I got a gripe.

I want to write "int number". Right? So I write "i", then "n", then "t".

Hehe yes, I've noticed this too. It's because I added the space bar as an autocomplete confirm key, and it is quite annoying.

So what I've done for the next version is simply remove InterfaceOff/On from the autocomplete. You shouldn't be using them anyway, because they were replaced by GUIOff/GUIOn a long time ago.

strazer

QuoteLOOP / NOLOOP

Why not name them REPEAT / NOREPEAT (or ONCE) to avoid confusion with view loops?

Rui 'Trovatore' Pires

#51
QuoteHehe yes, I've noticed this too. It's because I added the space bar as an autocomplete confirm key, and it is quite annoying.

So what I've done for the next version is simply remove InterfaceOff/On from the autocomplete. You shouldn't be using them anyway, because they were replaced by GUIOff/GUIOn a long time ago.

Er, not a good idea, I'm afraid. First, there still remains the issue of trying to define a string (and I get autocompleted to StringToInt), and defining a char, which I use a lot (and get ACMPLTD to character).

Second... space bar an autocomplete key? How come? After the function people either use ( or [, and rarely some other symbols, but never space bar.

EDIT - Actually, there are MORE keys that make autocomplete VERY annoying. It's VERY annoying to type in, say, "if (interface == SKIP" and then type ")", triggering autocomplete and putting in "if (interface == SkipUntilCharacterStops)". Autocomplete isn't very tolerant of these things. Maybe it would be better if autocomplete didn't get triggered by quite so many keys. Me, I find it very, VERY annoying and even frustrating in parts.
Reach for the moon. Even if you miss, you'll land among the stars.

Kneel. Now.

Never throw chicken at a Leprechaun.

Pumaman

I added the extra keys because Visual Studio allows them and I tend to rely on them when coding.

However, there is the difference that Visual Studio doesn't autmoatically pop up the autocomplete list, it only does it if you press Ctrl+Space.

So which is the preferable option? Stick with the autocomplete window popping up automatically, but disable space bar and ) from being fillup keys; or allow these keys but make the window require manual popping-up?

Rui 'Trovatore' Pires

My vote goes for the former, naturally.

Oh, BTW - you said you were interested in this - I suffer from very, very slight slowdown with the "new" autocomplete. It's there, but not very noticeable. I have a Celeron.... something or other, and 128Mbs of ram. And apart from that, I can't tell you any more specs of mine.
Reach for the moon. Even if you miss, you'll land among the stars.

Kneel. Now.

Never throw chicken at a Leprechaun.

Hollister Man

Okay, I had the same problem as redruM, but with MANY other things, variables like 'objectA' etc.  Is there a way to make an option for spacebar to be autocomplete?  If there was, I would turn it off, myself.  I'm used to enter working well enough.  Or at least an abort key that would add a space without the autocomplete kicking in.
That's like looking through a microscope at a bacterial culture and seeing a THOUSAND DANCING HAMSTERS!

Your whole planet is gonna blow up!  Your whole DAMN planet...

Radiant

I second redruM's motion.

Also I believe I have pointed this out before, but the automatic alignment of closing braces doesn't work the way it should, and this is rather annoying if you're trying to add code below a line that has a closing brace.

Pumaman

Ok, beta 3 is up.

I've removed space and ) from the autocomplete, cos yeah it was annoying.

Most importantly, the manual is now updated. Because it was a huge job (probably took longer than actually coding the changes  ;) ) there are bound to be mistakes, so please point out any errors, broken links, etc in the new Characters section.

QuoteOh, BTW - you said you were interested in this - I suffer from very, very slight slowdown with the "new" autocomplete.

Is the slowdown there all the time, or only when the autocomplete list is visible?

QuoteAlso I believe I have pointed this out before, but the automatic alignment of closing braces doesn't work the way it should, and this is rather annoying if you're trying to add code below a line that has a closing brace.

Hmm, does anyone actually find the de-denting behaviour useful? If not, I might just remove it completely.

Hollister Man

I like it, I'm not sure what Radiant is mentioning, I've never had a problem with that part.  The one thing I wish worked right is that the editor allows indenting selected  'blocks' of code, but it only works in a standard 'tab' size, about 7 spaces.

That's my only other gripe. I'm thoroughly happy with the progress you're making.  Someday this engine might make a VERY useful resume piece.

"Name: Chris Jones
Reason we should hire you: I programmed the well-known Adventure Game Studio, all by my self. :) "

Kidding...
That's like looking through a microscope at a bacterial culture and seeing a THOUSAND DANCING HAMSTERS!

Your whole planet is gonna blow up!  Your whole DAMN planet...

Rui 'Trovatore' Pires

#58
QuoteIs the slowdown there all the time, or only when the autocomplete list is visible?
Only when the list is visible. By slowdown, I mean it takes slightly longer than it did to find a probable command (like, I can write GetObjectP and it takes a bit longer than it used to to get to GetObjectPosition). But it doesn't bother me at all.

QuoteHmm, does anyone actually find the de-denting behaviour useful? If not, I might just remove it completely.
It allows for neater layout... me, I think it's all the same. I don't find it to be a very big difference.

EDIT - One little question that's been bothering me... I know that one of the things AGS is known for is it's "compatibility" in a way (ie, recently-made-useless commands take a looong time to quit the scene so people don't have to re-script the whole thing, like InterfaceOff or the PlayerStandsOnHotspot interaction). But I'll ask anyway. How much longer AFTER 2.63 is out can the old commands be expected to work, do you think? Meaning, should we start changing our scripts already or will we live with the two styles for some time (like the Euro)?

EDIT 2 - The small slowdown isn't there anymore with the new beta. Maybe it isn't related, but the result's the same.
Reach for the moon. Even if you miss, you'll land among the stars.

Kneel. Now.

Never throw chicken at a Leprechaun.

strazer

QuoteI think 'character.skipuntildone' sounds confusing, since this command isn't an action affecting the character, so it shouldn't be a member thereof.

I agree with Radiant.



Now, for testing purposes, I've converted my CCS script to v2.63 Beta 3.
I really like the object-based approach and the new names. It's easy to code and makes the script more readable.

Only two minor things I've noticed:
- Autocomplete doesn't properly display struct members if they are indented with tabs within the declaration.
- The context-sensitive help for the old SetActiveInventory doesn't point to the new ActiveInventory property.

Some thoughts:

I think the ALLAREAS define for the Walk command is slightly confusing. I like Rick's ANYWHERE better.

And shouldn't StopMoving be called StopWalking? Or do you intend to use it later for stopping animationless movement as well?

I propose to rename SetSpeed to SetWalkSpeed since we also have animation speed.

Will you eventually rename (capitalize) all character variables like .walking and move them into the appropriate section in the help file? I was just wondering why you only chose .Room for this beta.

I think it's good we're discussing function names and the like. Since so much is changing anyhow, now's our chance to make it right from the get-go.

I also had an idea, but I don't know how feasable it is:
Would it be possible to have members default to the struct the current function is called by, so you could do
  character[EGO].FaceLocation(.x - 10, .y);
for example?
Just a thought as it would help shorten some lines.

SMF spam blocked by CleanTalk