Suggestion for a more User-Friendly Adventure Game Studio

[Khris]

(I might be totally on the wrong track here, so please correct me in that case.)

Rich, there wasn't any (feasible) way to do everything using script only.

What "using script only" actually meant was that the only action you'll ever select in the interaction editor is "RunScript".

Everything else is then coded directly in the room's or global script, but it was inevitable to use the I.E. to make AGS create the needed functions.
So even people who did script everything had to use the I.E. in exactly the way you've described.

(Of course in theory one could put countless ifs inside on_mouse_click and repeatedly_execute to check for regions, clicks on objects and everything else, keeping the room scripts empty in the process, but that would become a horrific mess in no time.)

[rich]

Oh, excellent to know! I suppose I should've downloaded the new version before making a comment. I think this new version will work out grand.

[quixotecoyote]

I find the interaction editor is an excellent organizational tool.  My room and global scripts are completely out of order.  Trying to find anything just by looking at the scripts takes me forever.  It's nice to be able to click on the IE and jump right to the relevant portion of code.  It also makes sure I don't get distracted and edit the wrong section.

[Khris]

That being able to jump to a certain piece of code is handy is unquestioned.
This thread is really about the need to include the various other actions besides RunScript.
AGS 2.8/3.0 has ditched them but kept the functionality to jump to a specific function.

[Ashen]

Also, since the functions now have relevant names (Room_Load, oDoor_Interact as opposed to room_a, object2_f, etc) it's actually far easier to find things purely in the script, without using the Events menu. I can't find a way to jump to a specific part of the Global script, though (as used to be in the 'Script' menu) - is that gone, or just not where I've looked?

Maybe it's wrong, but I had to smile at the death of the Interaction Editor...

[quixotecoyote]

Also, since the functions now have relevant names (Room_Load, oDoor_Interact as opposed to room_a, object2_f, etc) it's actually far easier to find things purely in the script, without using the Events menu. I can't find a way to jump to a specific part of the Global script, though (as used to be in the 'Script' menu) - is that gone, or just not where I've looked?

Maybe it's wrong, but I had to smile at the death of the Interaction Editor...

<shrug>  Now I can stomach the loss without an issue, especially as you and Khris have reminded me that the core functions remain.

Eight months ago when I was deciding whether to write my game in AGS, seeing there was a shallow end to wade into first helped me start.

[frission]

:-\Hmmm...

How long did everyone take to learn Scripting? Curious I am.

Don't get me wrong, I have dabbled with scripting with my game construction. I even attempted to use Ahmet's RPG Scripting, but I became very frustrated with the results.

This is all I really want with my Adventure Game: I want the hero to walk around the rooms like a normal AGS Adventure Game, picking up items, using items, having conversations with people, solving puzzles.

Earning Wisdom and Honour Points like in A Tale Of Two Kingdoms. But also, being able do battle with monsters and to lose points. If all your life points are gone, the game switches to a room that says the hero is dead. Game Over. Start again or Load or Quit.

Or, if you win the battle you must have reduced the monster's life points to 0, or you can even stun it with sleeping dart.

That's all I can think of to say at the moment...

The nice thing about AGS's scripting is that it is fairly generic as far as syntax goes. That is, if you bother to learn AGS's approach to things, you actually will not have a hard time learning Javascript, PHP, and other high-level scripting languages (and conversely, if you already know said languages, learning AGS's scripting is super simple, as I can attest, having just started with it a week ago and already going along at great guns).

My recommendation, if you are totally new to scripting in general, is NOT to necessarily start with AGS. Do a few Javascript tutorials that you find on the web; get used to writing basic program flow (I started Javascript by writing a tic-tac-toe program), and once you have a little comfort in at least reading scripts under your belt, come back to AGS and take a look at how it does things. (Other than the fact that AGS is often more object oriented than Javascript, it has pretty much the same syntax.)

Scripting is not all as hard as it looks -- you are basically just charting out logical actions for the interpreter to follow or things for it to check. It's also a very marketable skill -- being an AGS scripter is not something that will be very impressing on the resume, but knowing how to use Javascript and PHP can easily make you a more exciting job candidate down the line.

Just my two cents! I don't script for a living but my ability to script (Javascript, PHP, VBScript, etc.) has helped me to get many a job, as it makes me much more capable than your average candidate in my non-computer science field of work (I am a historian by trade).

[VK Dan]

I can't find a way to jump to a specific part of the Global script, though (as used to be in the 'Script' menu) - is that gone, or just not where I've looked?

Look at the top of the script editor. There's a ComboBox with all the functions in the open script. Clicking on the script's name will take you to the function.

[Ashen]

Look at the top of the script editor.

OK, so just 'not where I looked', then. Thanks for that, makes things a lot easier.

Actually, I had looked there, I just didn't realise what it did - this is a very minor quibble, but if you select a function that's currently on the screen, it moves the cursor but doesn't always scroll to the relevant line. So, it's not always obvious that it's actually done anything. That's my excuse for not having seen it sooner, and I'm sticking to it...

[theatrx]

There were two little issues that confused me and they may be resolved in the new version but here they are anyway.

First is the different ways that things are removed or enabled...

RemoveWalkableArea(2);
RestoreWalkableArea(2);

EnableRegion(2);
DisableRegion(2);

It seems to me that it would be simpler if it were always either Remove/Restore or Enable/Disable instead of sometimes one or sometimes the other.

The other point is

SetCharacterSpeechView(2,12);
SetCharacterIdle(2,12,30);
ChangeCharacterView(2,12);
cEgo.ChangeView(12);
cEgo.SpeechView = 10;

Again, the last one is the question.  Why is SpeechView with an equal sign and nothing else is? 

That's it and not that it's a big deal but it would sort of streamline the code I should think.

[Gilbert]

RemoveWalkableArea(2);
RestoreWalkableArea(2);

EnableRegion(2);
DisableRegion(2);

Since there're some numbers of region-related features, the EnableRegion() and DisableRegion() functions are now replaced by the structural property Region.Enabled, while the Remove/Restore-WalkableArea() functions are still used, but as there aren't many functions related to walkable areas I don't think they would be changed soon. So, in other words, en/dis-abling walkable areas and regions are still done in different ways, but I think because of the nature it wouldn't matter, at least for now.

SetCharacterSpeechView(2,12);
SetCharacterIdle(2,12,30);
ChangeCharacterView(2,12);
cEgo.ChangeView(12);
cEgo.SpeechView = 10;

Again, the last one is the question.  Why is SpeechView with an equal sign and nothing else is? 

It's because SpeechView is a variable (err... property, if you insist), so we don't need two functions to get/set it, and you can just retrieve its value or change it just by accessing this property directly. For the other functions, probably it's how the engine works so it won't work properly if you just change the value to a variable (moreover, for functions like SetCharacterIdle() which can take more parameters you can't do this by a single property). If you're uncomfortable with the '=' assignment, just create wrapper functions for SpeechView.

[theatrx]

No Gilbot... you misunderstand.  All I am saying is that in both instances for the sake of consistency, the coding should be reflected in one or the other way.  Meaning...

RemoveWalkableArea(2);
RestoreWalkableArea(2);

This is fine since it works well with the autofill feature but then it should also be

RestoreRegion(2);
RemoveRegion(2);

This way Regions, Hotspots and Walkable area would all be removed and restored in the same way rather than bringing in another command for one of them

The other point is much the same.  Chris has established that views and options have been established in much the same way except for speech view which has an "=" sign thrown in.  I'm simply saying that speech view should be the same as the others.

SetCharacterSpeechView(2,12);
SetCharacterIdle(2,12,30);
ChangeCharacterView(2,12);
cEgo.ChangeView(12);
cEgo.SpeechView = 10; So, this would become
cEgo.SpeechView(10);

That's all.  It's just sort of a bummer in both instances that you have to remember that that one line of code is different from all the rest.  That's all I'm saying. Sorry to be a pain.

[Gilbert]

No Gilbot... you misunderstand.  All I am saying is that in both instances for the sake of consistency, the coding should be reflected in one or the other way.  Meaning...
...
This way Regions, Hotspots and Walkable area would all be removed and restored in the same way rather than bringing in another command for one of them

I understood what you meant, but I had already stated that regions are now objects that can have their own properties, including Enabled, so the functions Enable/Disable-Region() are now obsolete and should not be used anymore, so it doesn't matter whether we need to change these functions to match those of walkable areas. Moreover, as I stated, that walkable areas are not made into objects yet (not much benefit in doing so ATM I think) so it's okay to still have their own pair of Remove/Restore-WalkableArea() functions instead of an Enabled property like regions.

Similarly for the view part, I had written, Character.SpeechView is a property, not a function, so assignment with = is perfect. If it's made into a function, you need two functions instead of one:
cEgo.SetSpeechView(10);
cEgo.GetSpeechView(10);

In the other cases, just changing the value of a property is possibly not enough for the engine to work, so they need functions.

[SSH]

theatrx, you're mixing old and new style scripting there, so of course there are inconsistencies. Character.ChangeView is a function because it permanantly changes the main view of the character, when usually one just wants to do it temporarily which is better to use Character.LockView for. So CJ tried to discourage people from doing so by making it a function rather than a property and making the NormalView property read-only.

All the properties have underlying Set/Get functions that are invisible to us, so CJ could change it if he wanted.

[RickJ]

Just for reference:

I think this recent thread illustrates another good reason to eliminate the IE.  Note that in order to adequately explain the problem, it was necessary for the poster to grab a screenie, annotate it, upload it, and then link to it, in the thread.   I may be wrong, but I think that most people who ask for help using IE  are not willing or able to go to all this trouble to post a question.   And I would be very surprised indeed if someone went through this process to post a reply.  So typically this is all done via verbal description which IMHO is less than optimal. 

Contrast this to the equivalent in script where one can just cut and paste a portion of one's script directly into a post asking for help and where people often respond by posting corrected or alternate snippets of script that can be used directly by the original poster. 

So the difficulty in asking and answering IE programming questions in the forum is another reason to justify the dumping IE.

[Scorpiorus]

Yep indeed, and also being an external image the relevant screenshot could get deleted or something, making the original thread useless for other people looking for help at a future moment. Not to mention that the forum searching mechanism won't work with images.

[Ashen]

I've edited the post mentioned by RickJ, to include a text version of the IE setup (the image is still there as a link). So, it IS possible to describe IE problems without using a screenshot (KhrisMUC had already included 'psuedo-IE' text in his reply, in fact) or confusing verbal descriptions, it's just a lot more time consuming than using a picture - and so even fewer people are likely to do it.

Obviously, I'm not defending the IE, just explaining why there's no image in a post that was linked to because it used an image.

[rich]

Also, since the functions now have relevant names (Room_Load, oDoor_Interact as opposed to room_a, object2_f, etc) it's actually far easier to find things purely in the script, without using the Events menu. I can't find a way to jump to a specific part of the Global script, though (as used to be in the 'Script' menu) - is that gone, or just not where I've looked?

Maybe it's wrong, but I had to smile at the death of the Interaction Editor...

man, I'm really glad to hear that. Honestly, I wish it had been that way all along. It makes things much easier to read and organize. New question though... what will happen to games that have been worked on in 2.72 or earlier and are updated into 3.0 or higher. Will it still understand the room_a and object2_f functions that were created in the earlier versions? Will there be a way perhaps to automatically update them into the new naming scheme automatically? If not, will there be a way to conveniently manually upate the naming scheme?

[VK Dan]

what will happen to games that have been worked on in 2.72 or earlier and are updated into 3.0 or higher. Will it still understand the room_a and object2_f functions that were created in the earlier versions?

They will be imported and work the same as before.

Will there be a way perhaps to automatically update them into the new naming scheme automatically? If not, will there be a way to conveniently manually upate the naming scheme?

You can manually change the names. Just go to the events tab for the object/room/whatever and type in the name you want the function to have. Then make the room_a function have the same name you just typed in. It's not the most convenient way, but it works.

[Radiant]

Rich, there wasn't any (feasible) way to do everything using script only.

What "using script only" actually meant was that the only action you'll ever select in the interaction editor is "RunScript".

I beg to differ.

In fact none of my games use the interaction editor at all, not even for RunScript. Instead, the global script figures out what to do exactly, and uses CallRoomScript as necessary for hotspots etc.