Main      Site Guide    
Smash

The minimal changes you need to make to your AGLL code to get it to run under Smash are listed below. Note that these are only the minimum syntactical requirements of Smash. Ideally, and assuming you do not already have a preponderance of AGLL code that would be impractical to port, further changes would be implemented as well, such as renaming numbered variable names with more identifiable strings. Additionally, the syntax v 1 = 1 and s = 1 is supported only for backwards compatibility with AGLL. With Smash, the preferred syntax would be to name the variables explicitly, that is, v v1 = 1 and s s = 1.

File Extensions

The objects, eobjects, win, and lose files must have the extension .txt added to them if they are present. Unlike AGLL, however, they are no longer required files, so you don't even need them at all unless your game makes use of them.

All other files, including the start file, must have the extension .sma. The rule of thumb is, any file with Smash code in it gets a .sma extension. (No, the descriptions files are not exceptions; see below.)

game.txt

Smash requires a game.txt file. Minimally (and normally) it contains just one line, which is the complete title of the game.

Lines after the first may be used to set the game's credits, synopsis, difficulty level, and hall of fame parameters. Details about the syntax of this file will be documented at a later date.

For now, know that you can enable a Hall of Fame for your game (with the default parameters Name, Moves, and Date) by adding the following line after the title line:

h:

objects.txt and eobjects.txt

The format of the objects.txt and eobjects.txt files have been changed to include the "object tag" for each item in your inventory. Ideally, this object tag would be a human-readable string, such as "coin" or "sword", but this would require every a, d, and e command to be changed to refer to the new object tag instead of the old item index number.

So, to conform to Smash while avoiding a lot of recoding, you can simply make the object tag the same as the item index. For example, if a "Gold Key" was item 0 under AGLL, you would explicitly assign it the object tag "0" in Smash, and the rest of your code will work properly.

The required syntax of the objects.txt file is illustrated below:

AGLL Smash Quickie AGLL Conversion Example
Sack Sword Gold Coin Broken Tooth Empty Bottle sack|Sack sword|Sword gold|Gold Coin tooth|Broken Tooth bottle|Empty Bottle 0|Sack 1|Sword 2|Gold Coin 3|Broken Tooth 4|Empty Bottle

Note that now you can rearrange the inventory simply by reordering the objects.txt file; no pervasive code changes are required to get all the a and d commands to refer to the correct item indexes.

The syntax of the eobjects.txt file has been altered in a similar manner:

AGLL Smash Quickie AGLL Conversion Example
Silver Coin|Silver Coins Red Gem|Red Gems Piece of Lint|Pieces of Lint coins|Silver Coin|Silver Coins gems|Red Gem|Red Gems lint|Piece of Lint|Pieces of Lint 0|Silver Coin|Silver Coins 1|Red Gem|Red Gems 2|Piece of Lint|Pieces of Lint

Note that object tags from the objects.txt file and the object tags from the eobjects.txt file are distinct from one another, so it's perfectly ok to use the same object tag in both. Just don't reuse the same object tag within the same file.

objectactions.sma and eobjectactions.sma

The descriptions files have been dramatically changed from the AGLL syntax. Rather than these files being predefined text files, they are now literally nothing more or less than files containing Smash code. Specifically, they contain one function per item and define what actions should be taken when the user selects an item from his inventory.

Furthermore, they have been renamed. descriptions has been renamed to objectactions.sma, and edescriptions has been renamed eobjectactions.sma.

It is recommended that Smash games continue to use the inventory selections to examine the items, but there is no longer this requirement: you could have selecting an item from the inventory imply using the item, or giving the item, or whatever else you want. Be consistent, however, and make sure that the user always understands what he's doing before he does it.

Constructing an objectactions.sma file that matches the functionality provided by your old descriptions file will mean defining functions with p commands and maybe the occasional I command. Here is an example:

AGLL Smash
; It looks shiny. ; It looks stupid. mouthwash.jpg; It looks nasty. ~ coin p It looks shiny. ~ mask p It looks stupid. ~ mouthwash p It looks nasty. I mouthwash.jpg

Note that if you made your item tags numbers, to expedite the conversion of an existing AGLL game to Smash, then the function names found in the objectactions.sma file will all be numbers. For example:

~ 0 p It looks shiny. ~ 1 p It looks stupid. ~ 2 p It looks nasty. I mouthwash.jpg

The eobjectactions.sma file is formatted in exactly the same manner, except that the requirement for both a singular and plural version of the text makes things slightly more complicated:

AGLL Smash
; It looks delicious.|They look delicious. ; It is dirty|They are dirty. marbles.jpg; It is small and round|They are small and round. ~ cookies c e:cookies=1 p It looks delicious. C p They look delicious. ~ mudballs c e:mudballs=1 p It looks dirty. C p They are dirty. ~ marbles I marbles.jpg c e:marbles=1 p It is small and round. C p They are small and round.

If you used numbers as your object tags in the eobjects.txt file, then your eobjectactions.sma file would look more like this:

~ 0 c e:0=1 p It looks delicious. C p They look delicious. ~ 1 c e:1=1 p It looks dirty. C p They are dirty. ~ 2 I marbles.jpg c e:2=1 p It is small and round. C p They are small and round.

Confused about the C command? The C command is new to Smash; basically, it's an "else" statement. If the prior c conditional fails, the C block will be executed. If the prior c conditional succeeds, the C block will be skipped.

Confused about the e: syntax? Read on.

Enumerated Object Checking

In AGLL, the conditional c e3>0 could be used to check to see if the player had any of enumerated object e3 in his inventory. With Smash, this syntax is ambiguous: e3 could refer to a variable named e3. And what if the enumerated object tag was a name instead of a number?

Because of this problem, Smash's syntax for checking how many of an enumerated object a player has in his inventory has been changed. Now, this conditional should be rewritten c e:3>0. With a name for an object tag instead of a number, it must read c e:coins>0.

This is more consistent with checking of regular objects, which still occurs with the same syntax. For example, c a:1,d:2,e:3>0.

The Colon Command

Smash does not have a colon command. It was not common in AGLL anyway, but if you used any colon commands anywhere, you need to change them to dot commands. AGLL required text after a dot command, which is why a colon command was created in the first place; with Smash, text after a dot command is optional.

AGLL Smash
: .

Functions

In AGLL, all functions had to be stored in a file called functions. This is not true in Smash; a function can be located in any .sma file. The default is no longer functions, and, in fact, use of a filename as generic as this is discouraged. However, if all you're looking to do is make an AGLL game run under Smash, then you can make your function calls Smash-compliant by doing the following:

AGLL Smash
f do_the_thing * 1 Pounce on the weevil. f weevil_pounce f do_that_other_thing f functions.do_the_thing * 1 Pounce on the weevil. f functions.weevil_pounce f functions.do_that_other_thing

Constant (Start File) Options

@ option blocks, defined in the start file in AGLL, must now be moved to a file called copts.sma.

This is probably all you need to do to get constant options ported to Smash, but if you tried the AGLL trick where you put constant options inside impossible conditionals to hide them initially, then expose them in code later, you'll need to do more.

First, ditch the impossible conditionals. The copts.sma can't have anything in it except constant option blocks anyway, so you don't need them. Next, in the start.sma file, hide the initially unavailable options with @ - commands. For example:

@ - option_tag_1 @ - option_tag_2 @ - option_tag_3

Then, when you want to expose a constant option, replace the AGLL lines that would do this (basically, a repeat of the constant option definitions, without its block) with @ + commands. For example:

@ + option_tag_1 @ + option_tag_2 @ + option_tag_3

Referencing Images From Text

If your game uses any <img> tags in area or action description text, you'll need to change those. Rather than relying on the file structure a particular Smash interpreter uses, it is better to leave it up to the Smash engine to display images the way it wants to; this ensures that Smash games work regardless of what interpreter is being used.

To embed images within area or action description text, simply enclose the image filename in square brackets. For example:

. You see the strange symbol [symbol.jpg] etched into the rock.

Note that if the term between square brackets is not a valid, existing image file, the square brackets (and what's inside) will appear literally in the displayed string. You can force a literal [ character by preceding it with a backslash, but most of the time this should not be necessary.

If your game does not use images, or only uses images via i or I commands, then it is not necessary to make any changes to your code to get images to work in Smash.