Agast Morningstar

[rodekill]

Wokka wokka

Anyone mucked around with it? Still seems complex as hell to me.

[Nellie]

Well, it's shiny and nice, and sounds powerful.  I haven't the foggiest idea how to begin writing a game, but I guess that's what the acronym RTFM was invented for.

Anyway, I propose Chris appends a piece of medieval weaponry onto AGS for the next release, because we don't want to be left behind in the 'cool name' stakes.

[remixor]

AGS Pitchfork!

[Russell_AGAST]

Chris occasionally stops by the AGAST forum,  so I thought I'd return the favor and respond to this thread.

Well, it's shiny and nice, and sounds powerful.

Thank you.

I haven't the foggiest idea how to begin writing a game, but I guess that's what the acronym RTFM was invented for.

That's not an abbreviation I'm particularly fond of,  but I think we do have a very fine manual,  and we spent a lot of time updating it for this release.  The message board is also a great place to get help starting out with AGAST-  both Todd and I check it several times a day,  and we're especially attentive to new-user questions.

Anyone mucked around with it? Still seems complex as hell to me.

Well,  Morningstar isn't too complex,  at least not for beginners.  However,  its way of doing things is pretty very different from AGS's. Without going into my full pitch,  let's talk a bit about the basics of using AGAST.

The key parts of AGAST are scenes,  objects,  resources, and events:

*Scenes- Just what they sound like: individual locations in your game.
*Objects- Objects the player can interact with.  (They can be used for other stuff,  but that's not really important here.)
*Resources- Files containing sprites,  sounds,  or anything else you create outside of AGAST scripts.
*Events- Scripts that are triggered in response to something happening in the games.  The most common event types are "object-on-object" events (like when the player uses a key on a door) and "enter" events (when the player enters a new scene).

You create a scene by creating a folder.  You put the resources and script files for that scene in that folder.  You set up a scene with by using an enter event.  Here's an example:

Code: ags

event enter
{
   backgroundImage = tree_image;  // The background picture
   backgroundZbuffer = tree_zbuffer; // The zbuffer, which is like an AGS walk-behind

   Ego:  // This is where we set up the player character
   path = tree_path;  // The "path" that the character can walk on
   move(320,240);  // Put the character around the middle of the screen
}

That's your basic scene.  Objects are set up roughly the same way:

Code: ags

object girl
{
   SetAnim(girl_sprite);  // Set the default animation for the character
   SetTalkAnim(girlTalking_sprite);  // Set the talking animation for the character
}

Then you'll want events for interacting with the objects:

Code: ags

event lookAt -> girl
{
   Ego:

   "Hm, it's a teenage girl. She looks suspiciously like a piece of example code."
}

Those are the basics of scripting with AGAST (more detail is available in the Scripting Made Easy FAQ and this basic tutorial).  Now,  you can get into a lot of complexity with AGAST-  that's one of its advantages.  For example,  you can write a GUI library entirely in the scripting language (a nice fellow called ARKBAN did,  and it's included with AGAST).  You can write a script that generates a pretty shadow in realtime from a sprite you specify (I did,  and it's in the demo).  You don't have to do any of that,  though,  and frankly,  most people don't.

Mostly,  I don't think that AGAST is more complex than AGS.  Some things seem to be harder in one than in the other,  though.  For example,  AGAST requires that you give coordinates for most things in numbers (as in "move(320,200)"),  which means that you do a fair amount of alt-tabbing between ANGEL (our text editor) and Photoshop.  AGS lets you do the same thing by clicking around in the room editor.  On the other hand,  controlling multiple objects at once is trivial in AGAST,  whereas it seems to me to be a lot more time-consuming in AGS.  Also,  a lot of "complex" things are less complex in AGAST than in AGS-  for example,  fancy graphics stuff,  like the aforementioned shadow, can be done in the AGAST language,  instead of having to jump out and write DLLs in C++.  In fact,  browsing the AGS plugins list,  they all seem to do things which could be easily scripted with AGAST,  or are already provided as part of the core AGAST features.

Here's a basic list of things the AGS editor does and how they're done in AGAST.  Hopefully,  this will demonstrate how the AGAST and AGS approaches are different:

Things the AGS editor does

1.   Set global game properties
2.   Edit GUIs
3.   Specify inventory items
4.   Edit global message strings
5.   Edit palette
6.   Edit dialogs
7.   Edit parser keywords
8.   Import sprites into project
9.   Group sprites into views
10.  Create mouse cursors
11.  Import fonts
12.  Set room properties
13.  Set room music
14.  Create background animations
15.  Create background hotspots
16.  Create walkable areas
17.  Create objects
18.  Edit object events.

How to do them in AGAST

1.   Just set the property the normal way ("property =").
2.   Call Midnight functions.
3.   Create item objects ("object item whatever{}")
4.   Define with "string =" statements.
5.   Not applicable.  AGAST does not use palette-based graphics.
6.   Build with case statements,  or use the Diabolog Dialog Editor.
7.   Follow parser docs. (Parser is admittedly incomplete.)
8.   Just place the sprites in project directory.
9.   Sprites are organized inside objects with the setAnim functions.
10.  Any sprite can be a mouse cursor in AGAST.
11.  Use the font converter,  then place the font in the project directory.
12.  See 1.  Alternatively,  use SceneEdit.
13.  Use StartMusic() in the room's enter event
14.  Put a loop inside a start block.
15.  Use object click areas or click masks.
16.  Use Pathedit to create the path.
17.  Just use an "object{}" definition.  Alternatively,  use SceneEdit.
18.  Add events to the object scripts.

The way I look at it,  AGAST has a "flat" approach,  where we design everything to be equally accessible through a single interface (the scripting language).  This is probably a little counter-intuitive for people coming from AGS,  which uses a "tiered" approach.  In the AGS model,  there are different interfaces for different tasks.  The simplest tier is the editor,  where graphical interfaces are provided for the tasks I listed above.  The next tier is the text scripting system,  where more sophisticated interactions are defined.  The final tier is the plugin API,  for custom graphics tasks and other code that would be impractical within the scripting language.

[Archangel (aka SoupDragon)]

!

[rodekill]

Wow. Thanks for the post Russell.
I'll probably take a deeper look if I get the time.
Good to see the lack of rediculous fanboyism in the thread so far.

[remixor]

Rode: I was pretty surprised as well at the lack of AGS jingoism.

And Russel, thanks for that post.  I admit I knew pretty much nothing about AGAST before today.  After I found AGS I didn't bother checking out any other engines, but I may take a look at AGAST now to see what it's like.

[PeaceMan]

I was going to have a go at using AGAST once but when I downloaded all the tools it looked a bit difficult so I didn't bother. But since it's been updated I'll have another look.