This section of the documentation tells you about the differences in ASL between single player games and multi-player games.
Single player games are ASL or CAS files which you give to players, who then open the game in Quest to play it on their own computers.
The way games are played is different for multi-player games. There is still an ASL or CAS file which contains all the game code, but it is opened and run on QuestNet Server rather than Quest. You then tell players the IP address or host name of the server, and they can then enter that address onto Quest's "Network" tab. Quest then connects through the internet to the QuestNet Server, and as far as the player is concerned they play the game in much the same way as a single player game, except that they can also see and interact with other players.
For more information about running a QuestNet server, see the QuestNet Server User's Guide.
When a player connects to QuestNet Server, they are allocated an ID. The first player to connect gets allocated ID 1, the second ID 2 and so on. When players disconnect, their player ID becomes available again for another player to use. So if player 1 connects, then player 2 connects, then player 1 disconnects, the next player to connect will get ID 1 rather than ID 3.
When you are creating games for QuestNet Server, you should always bear user IDs in mind, so that you don't end up, say, printing some text intended for one user to a different user's screen.
When any ASL script runs in QuestNet Server, it runs in the "context" of a particular user ID. For example, say we have an object and we've set a take tag so with the object can be picked up automatically. When a player with ID 4 picks up this object, the events that follow it all happen in the context of ID 4. In the case of our empty take tag, this simply means that the object will be put in the inventory of player ID 4. This means that the coding is exactly the same here as for a single-player Quest game - in most circumstances there is no need to do anything special to keep track of user IDs.
If instead of the empty take tag, we specify to run a script, e.g.:
take msg <It is too heavy to pick up.>
then the msg script command still runs in the context of user ID 4 when that player tries to take the object. This means that the message is printed to the screen of the user with ID 4. You can find out which context a script is being run in by looking at the %userid% numeric variable.
In most cases, the default behaviour is for any script you specify to be run in the context of the player that initiated it, so all messages appear on that player's screen. With the exception of the differences specified in the rest of this document, that means that QuestNet Server multi-player game programming is substantially the same as for single-player Quest Games.
However, when two players interact, you need some way of getting some things to happen to one player, and other things to happen to the other player. This is where the with command comes in. Using this command you can run a script in a different context. For example, with <2> background <green> will change the background of the player with user ID 2 to green. Usually of course you won't want to hard-code player IDs in this way, and will instead be using the result of a function or a numeric variable. You can use the player object name instead of the ID, which makes using with in custom commands easier. For example, the command below sets up an "ATTACK" which will deduct five health points from the other player's health and turn their background red, while the attacking player gains 100 dollars:
command <attack #@player#> {
with <#player#> {
dec <health[userid]; 5>
background <red>
}
inc <money[userid]; 100>
}
Here, the dec and background commands are run in the context of whichever player was specified after the word "ATTACK" in the user's command, while the inc command runs in the default context of the user who did the attacking.
There is a special user ID of 0 (zero) which corresponds to the admin window. Use this ID to print commands to the admin window (either using with <0> msg <text> or the shortcut msgto <0; text>) or to run other script commands such as background or foreground.
Several script commands work only in QuestNet Server, and there are several that don't work (mostly relating to showing pictures and playing sounds). Also, some commands behave slightly differently in QuestNet Server. To find out more, see the script commands reference.
In a single player game, you can use startscript in the define game block to set up variables and to display introductions. Do not do this in QuestNet Server.
In QuestNet Server, use startscript for server variable initialisation only. If you want to code an introductory sequence for players, use player startscript for the introduction code.
You can specify a disconnect script in the "define game" block which will run whenever a user disconnects. See ARENA.ASL for an example.
All built-in string variables are implemented as arrays in multi-player games. So, instead of using, for example, #quest.currentroom#, use #quest.currentroom[userid]#.
Quest has a virtual inventory room for accessing the contents of a player's inventory directly. In QuestNet Server, this is renamed player1, player2 etc.
An easy way to access the inventory of the player for the current context is to use player%userid% as the room name.
QuestNet adds $id(...)$ and $name(...)$ functions for converting displayed player names into user IDs and vice versa. (You'll notice if you go to the Object Debugger while a game is running on QuestNet Server that all players are implemented as objects with names player1, player2 etc.)
Use the login and register options in the define options block to specify whether players must log in to your game.
QuestNet includes NET.LIB, which is used by ARENA.ASL and will probably be useful for your games too. The idea of NET.LIB is that it implements some extra or necessary QuestNet Server features entirely using ASL, which stops QNETSERV.EXE from becoming too bloated.
The included version of NET.LIB adds one feature to a game - it lets players give objects to each other. You need to set "type <giveable>" to each object that you want to support this (and of course, you need to have "!include <net.lib>" somewhere too).
NET.LIB also includes QDK interface data so you can use the giveable objects feature in QDK. QDK automatically adds NET.LIB to multi-player games.
The following user commands have no function in QuestNet Server:
Type HELP on the QuestNet Server window to see a list of available admin commands. You can use these commands to send a message to all players, see player information, etc.