Suggestion: unify script language

Started by James Kay, Sun 01/02/2004 12:25:53

Previous topic - Next topic

James Kay

The main problem I, as an amateur non-programmer, have with scripting at the moment is that a lot of commands are unexpectedly different.
For example, to switch something off, the script command is either RemoveSomething or DisableSomething or SomethingOff. Before I had a problem with SetCharacterView versus ChangeCharacterView. One worked, the other didn't. But why the two seperate commands for what seems to me to be the same function?
It'd be nice to unify scripting commands to make more sense, overall. Like all disable type functions contain or start with Disable--, or all character related functions start with Character--.
Just a thought.


(But not before implementing isometric directions for character turning!  ;D)

Fuzzpilz

I don't think it's enough of an issue to necessitate that much messing with established names; there aren't so many script functions that forcing them all into one scheme would be worth it. Beginners would have to do a lot of looking things up in any case, so why break a working system?

Quote from: James Kay on Sun 01/02/2004 12:25:53
Before I had a problem with SetCharacterView versus ChangeCharacterView. One worked, the other didn't. But why the two seperate commands for what seems to me to be the same function?

They're quite definitely not the same at all. Check the documentation - they're intended for entirely different purposes.

Timosity

It's probably good in some aspects to have it unified and it can be confusing sometimes. but I would imagine it could become a problem when it comes to programming upgrades so that when upgrading a game to a new version it still works. There seems to also be some obsolete functions in script that are still possible to use.

eg. I think GUIOn & InterfaceOn are the same thing (GUIOn being the more recent)

It would be hard to unify everything as it would confuse people that are fimiliar with the way things already work, but I think CJ has been slowly trying to do this

Eg. sometimes speed was faster when the numbers went up and other functions it was when they went down, but now it's either speed or delay

as for SetCharacterView versus ChangeCharacterView there is a distinctive difference: eg:

If you use "SetCharacterView" it will set the character to a particular view, then if you use "ReleaseCharacterView" it will return to the original view.

If you use "ChangeCharacterView" you can then use "SetCharacterView" to change to another view but then if you use "ReleaseCharacterView" it will return to the view you set with "ChangeCharacterView".

just to make that clearer, just say your original character starts off wearing a hat, then later he loses it, you would use "ChangeCharacterView" to the view without the hat so that if you then  "ReleaseCharacterView" the character doesn't go back to the hat view.


I got a bit worried at one time when I'd used "player stands on hotspot" and when I upgraded it said it was now obsolete use regions, I thought "oh no my game won't work anymore" but it still did, I'm sure CJ is well aware of keeping in old bits of code so that upgrades still work, otherwise people would complain and get pissed off.

So as it sounds like a good idea, it's probably hard to make it all happen especially when new things get added all the time, It's not as though it's all planned out before hand, which is another thing that makes it great.

anyway, I can't really speak for CJ as he is the one that really knows all this stuff, I'm just guessing.

Kweepa

I agree this is a good idea, but it sounds like the sort of thing best left for v3.0.
Still waiting for Purity of the Surf II

Pumaman

You're right that the variation in script command names can be confusing, and it's probably just that they were all added one by one with no overall strategy.

There are other problem ones such as StopMoving (which should really be called StopCharacterMoving) - so yes, the whole deal should really be overhauled.

However, due to the problems and confusion it would cause for existing users, I don't think it's something I want to do at the current time.

NavyNuke04

And if you were to change it, wouldn't it cause a ton of errors when people upgrade their games to the new version of AGS? They'd have to go back through and change all the commands to be the new name. Quite a pain.

Trust me, after a little while, it becomes second nature and you don't really spend much time looking things up at all.

James Kay

Quote from: Pumaman on Sun 01/02/2004 15:18:08
You're right that the variation in script command names can be confusing, and it's probably just that they were all added one by one with no overall strategy.

There are other problem ones such as StopMoving (which should really be called StopCharacterMoving) - so yes, the whole deal should really be overhauled.

However, due to the problems and confusion it would cause for existing users, I don't think it's something I want to do at the current time.


Fair enough, but it might be something to consider for a future full-numbered version, if you ever feel the need to overhaul the engine. I recon it would really really help.
Just imagine wanting to do a particular character script, but you forgot the exact command, so you type charact, the listbox pops up, and you can browse all relevant character commands until you find the one you need.
Just a thought though.  ;)

Ytterbium

Maybe you could do it InterfaceOn to GUIOn style...unify the commands but keep all the obsolete ones in there.

Currently in production: Septigon

auhsor

Hmm, i was thinking that you could change them to more useful names, and whenever someone types in an old one, the program will automatically notify the programmer. It may be a pain, but I think then the programmer will slowly start to learn the new ones, and it will help noobs get a better feel for the engine.

Ishmael

Well, for those really simple/easily confuseable people, someone could wrap up a template (Even me, but I always forget things like this) where the commands are unified...

like using the script header (but see my not under this):

#define DisableHotspot HotspotOff
#define EnableHotspot HotspotOn
#define RemoveWalkableArea WalkableAreaOff
#define RestroreWalkableArea WalkableAreaOn

etc. (I'm not sure did I type those correct...)

But the problem is, that AGS will be lost with the parameters then... another way is to re-function them:

function HotspotOff (int hotspot) {
DisableHostspot(hotspot);
}

and then importing them in the header..

but this is useless, I know, it just popped to my head.. someone could use it tho...
I used to make games but then I took an IRC in the knee.

<Calin> Ishmael looks awesome all the time
\( Ö)/ ¬(Ö ) | Ja minähän en keskellä kirkasta päivää lähden minnekään juoksentelemaan ilman housuja.

Gilbert

Actually it's similar to the original interface-->GUI conversion used internally.

However, my opinion is that the unify thing may not be a very good idea, for several reasons:
1. No matter which route it takes, either complete renaming or defining alias, it's still a massive job, as there're quite a lot of functions right now.
2. If it's done by complete renaming, there may be problem when compiling with new version a game developed with old version, sure you can do the notify  (or even automated renaming) stuffs, but if the scripts are large, it would be quite annoying fixing them.
3. Worst of all, a game developed with old version may already has some of the functions with these new names defined for some reasons (the interface->GUI change was light, most people can cope up with it, but if there're many changes, it's quite possible that name clashes between "new" internal function names and old user-defined name would occur).

I think the best choice is to leave it as-is, and try to keep the style more consistent for future function names.

Pumaman

Yeah, I agree for now. You can always create #defines as TK suggests to rename the commands for yourself, but I think it would be too confusing to do it full-scale for the various engine commands.

I will hoever keep this in mind if there is a engine overhaul (eg. AGS 3.0, object orientation of the script language, etc) which would be an opportunity to change things then.

Scorpiorus

QuoteI will hoever keep this in mind if there is a engine overhaul (eg. AGS 3.0, object orientation of the script language, etc) which would be an opportunity to change things then.
OO script language in 3.0??! Or is it just for example :P I'd really like to see that in AGS though I appreciate how much rebuilding it'll take.

Alynn

if you do have OO in 3.0 please have overloading, (being a java programmer I found myself trying to overload functions until I finally got it through my thick skull, I can't do a MoveArm(int Obj) and a MoveArm(short dir) (One was for Moveing the char's arm and turning off an object, the other was to either move the arm up or down) So I ended up finally changing it to Grab(int obj) and MoveArm(int dir)....

Sorry for bringing up old topics, but I seemed to have missed the part of the possibility of OOP... I had to put in my 2 cents

Pumaman

I don't believe even java would allow you to overload an int and a short function - if you called it like this

MoveArm(5);

5 is both an int and a short, it would be ambiguous.

Alynn

Quote from: Pumaman on Wed 03/03/2004 20:49:31
I don't believe even java would allow you to overload an int and a short function - if you called it like this

MoveArm(5);

5 is both an int and a short, it would be ambiguous.

Actually, I couldn't remember exactly what I did... actually I think one was (int) and the other was (int, int) either way... OVERLOADING!!!! (oh and a true boolean would be nice)

Gilbert

Actually I see no benefits in introducing boolean variables, as all the integer types covered it up already. Apart from, maybe easier to read codes, but then I think you may be able (not sure, but may work) to fool yourselves by adding the line #define boolean int, so you can declare" boolean" variables in your codes, to remind oneself what those variables are for.

Maybe it's just me, I don't really like a scripting language to have strong type checks, I'll just like to use the variables in whatever ways I like.

SMF spam blocked by CleanTalk